IkarusDowned

As someone who is an avid C / C++ fan, but works a LOT in Python, Java and other languages, I would like to say that a solid understand of C (and the concept of constructors and destructors in C++) will take you a LONG way. Understanding how memory works, what pointers are (and what references AREN'T) can help you pick up other languages REALLY quickly. Having to train people in programming and software development, I find that the people who do well not matter WHAT gets thrown at them have the concepts of scope, memory management, construction / destruction firmly in their head get more work done faster and understand things better.

That being said, it takes both effort and time to get to a level comfortable with some of the craziness of pointers and all that. What is your main purpose to learn programming? The OP doesn't state "game programming" explicitly. If you are interested in just learning some basic programming, the vast majority of scripting languages are just fine -- Perl, Python, Ruby, any of those give you the ability to rapidly produce results with minimal fuss. the core concepts of "programming" are in all languages.

Too often, people get into the "Language Wars." Languages are like the paints and paintbrushes to an artist, or the tools in a toolbox to a craftsman. Each language has its strengths and weaknesses -- pick the right tool for the job, but most importantly is to know WHICH tool is right for which job. 

yeah, frob explains much better what I tried to say.

just outta curiosity frob, doesn't this also depend on the boomerang velocity and how much the player can move in a single update? It seems like if the motions were too rapid, you'd get a stutter with the motion. I guess attenuating the velocity would take care of that tho?

are you looking to just be able to have the boomerang come back to the player in a direct path? One "simple" way is that once you hit the maximum distance:

1) figure out the vector from the current boomerang position to the player

2) calculate the step towards them

3) move the boomerang that distance

this will make the boomerang seem kinda funky tho...it will look like its attached to a zip-line as opposed to a nice arching return...

just a thought

"The candle that burns brightest, dies fastest."

Don't push yourself to constantly be motivated, because like any human being you need downtime. Ask any serious athlete -- even olympians take massive chunks of rest, not only to rest their body but to actually have some time to rest their mind and spirit.

As a fellow software developer, I can tell you that its the balance of both:

1) studying and programming and learning

2) keeping my body healthy as much as my mind

3) days of just doing nothing (except maybe sitting around and drinking beer )

What is more important than "constantly driving yourself," is to check yourself from time to time to see if you are heading int he direction you want to be. Remember that you are just starting your career -- getting a job isn't the end goal, its merely a step on the way. All you need to do is make sure feel like you are in an area you want to be in, and the rest will fall into place with enough long-term motivation

for general programming tricks and practice Alpha_ProgDes has provided an awesome list.

if you are looking for practice with things like polymorphism and such things, here's a suggestion:

if you haven't already, pick up a book on Design Patterns. Most of these books provide sample programs and examples for each of the major design patterns. In my opinion, if you are comfortable with C++ syntax and mostly want to challenge yourself with classes, polymorphism, etc., then it might be easier to pick a Java-based Design Pattern book and simply do the examples in C++. This is a matter of comfort, and remember that you won't get the more C++-only stuff out of such a case (such as static polymorphism)

go through the design patterns and you will generally understand how C++ deals with pointers, classes, polymorphism, etc. It will also build your confidence up.

Its a bit unclear how you are handling the generic collision testing. Could you elaborate a little bit more?

for example, since it is tile-based, can we assume you have a multi-tier grid to partition the space? 

the general algorithm I've seen over and over is something like this:

assume:

- each character has a bounding-box that is either calculated at run time or pre-calculated on a per-frame basis. In other words, you have the rectangular "space" your guy occupies

- each character also has its x,y coordinates stored somewhere

1) for each character, do a bounding-box vs space partition test. For example, if you are using multi-leveled grids then you would "query" the grid for the possible tiles that collide with the character's bounding box. If you get no results, then you know that there are no collisions

2) for each possible tile you collide with in (1), re-check the character's bounding box against the tile, removing all the tiles that you DON'T collide with

3) now for each remaining tile, you can offset the character's x and y location using a similar algorithm to what xinifinite33 mentioned to "stop" the character from going thru the tile. 

There are other algorithms i'm sure, and your information provided is a bit vague so I apologize if this is more info / different info than you wanted

as ultramailman mentioned, try not to look at it as one big task. when you do that, you'll get the ol' "step 1: everything" problem.

My suggestion is the take your simplest AS3 game and try to recreate that.

start with the basics, as already mentioned:

1) create a window

2) draw still images to the window

3) draw animated images to the window

4) handle basic keyboard controls, like knowing when a button is pressed

5) handle basic mouse controls, such as button click and mouse movement

if you can get those 5, that's the core for most of your other apps i'd imagine. Then you build features from there.