I'll break it down really simply for you:
- first two years of college you learn how to write code that does nothing of value
- then you learn how to write code that actually works good, but does nothing of value
- then you learn how to make that code run much better and crash less (optimization), while also doing nothing of value
- you make your first user-interface program and realize that what is very good UI for you makes no sense for the real user that uses this software
- you learn how to better accomodate the actions that your user should be performing during his interaction with your app
- you learn basics of UI design
- you learn that, in order to have the thing look pretty and have it fully functional, you need a designer.
- the more you want it user-friendly and user-helping, the HARDER it is to make because - duuh, you have to expect what the user wants. All the while, making sure you do not make a mistake while expecting because then you have that "ugh, why did it do this now, why does it think i wanna do B every time i do A, this is stupid" frustration and instant un-install of your app.
- you learn that writing and maintaining software for free leads nowhere unless you are content with the gratitude of a very few people.
That's programming college + Masters degree in a few short lines.
But hey, on the brightside - we all started as complete noobs. So, for starters- the HUD you're referring to is called GUI - Graphical User Interface, abbreviated UI, or sometimes wrongly reffered to as "front-end". Being pragmatic, if you want to learn how to make GUI apps, lets start with a language where making GUI is easy. Which would be Java, exactly the language of choice for Superluminal, because not even seasoned C/C++ programmers don't like fucking around with QT.
So... I guess you can plan your summer around
- getting to know java
- compiling your first java program
- using SWING package.
and if all goes well, at the end of it you'll have a barely usable Alpha. Which then needs to be refined and bugfixed until a very stable Beta
then you poll for feedback, maybe come up with what else is missing, put it in and call yourself MyWeaponApp v1.0 and feel like you just beast-fucked and cummed all over the Universe's face. It's a very good feeling. And I really look forward to you having it, just know - it comes at a big (time) cost
Like, the difference between a program that prints "Hello World" on the screen and that actually opens a window that contains a text labes whose value changes to "Hello World" upon application start is a whole world apart ... they look (and work) drastically different under the hood. For one, we're not talking about the traditional "what happens next?" procedural approach, but rather a "what happens when I do/click this?" which is the event-driven approach... But hey, who am I to give you the ordering at which to pick things up
@kartoFlane: and GridBagLayout, MiGLayout or QT if you prefer C++. Personally, I'd go for command-line for a first try.
* When i say "nothing of value" these are mostly academic tests revolving around a clearly-defined math problem; in the real world, you are not trying to solve a math problem but a real-life software/algorithmic problem - meaning that "things left to do/fix on this" constantly change. When you're solving a math problem, it is always constant, very clearly defined and not changing. Example is "comparing bubble sort vs merge/shell sort" when all we do is use qsort and nothing else. The 'weapon modding tool' falls in this category because well, it's much easier to learn and make any sort of weapon by hand than making a tool to handle the basest of weapons with a very rudimentary UI, something like a 'calculator' or 'money exchange' app