Nope the definitions there sound like what I have in my mind.

Though many on IRC and A.cc, have said I excel at failure. I was reading a thread I made when I first joined where Matthew said "Ambition + No_Talent = Depression", but does that mean ML is saying I have no talent . My ambition hasn't changed and nether have my goals, I just learned to never post my ideas or thoughts here in regard to video game programming. This is really the only place I ever asked questions at and now I don't ask questions at all . Oh well depression is many faceted, I'm int the "God, I suck!" stage safely away from the "God, I want to die!" stage out of the several stages.

Money is tighter => he has less money.

Ohhh... My bad...

Of course it is! and he's comparing himself with Specter it's impossible man, you can't do that...

Hmmm... I hope so...

Your problem Specter is that you're too busy thinking that you can't do anything to actually do something...

And by reading your code above, it's like you sit in front of your computer every time you want to program something, and that's not the way it works.

What you have posted, it's already in your brain, you knew how to do it before writing it, for that reason you did it. In programming, and in other aspects, you need to think about what you're going to do before doing it, but in programming this is even more important.

You need to pass throw levels of abstraction before writing anything, if you know the language then you have everything, what you need is the logic, think about the behavior of your program. Before using the programming language use the human language, abstract your idea, then get a level down, for example:

I'm going to make a ping pong game:

First level:

I want two paddles with a ball bouncing, the ball is going to collide only with the paddles and I don't want scores or anything. It's very important in this step to know exactly what you want and what you don't.

Second level

How the user is going to see this game, fullscreen, windowed, static fullscreen, or dynamic fullscreen?. Mouse... Keyboard... Graphics... Sounds... Depending on this choice you might or might not need more abstraction levels.

Third Level

Ok I have chosen a windowed mode, and the game is going to be played with the keyboard. My resolution is going to be 640 X 400. With this info I already know that the paddle is going to stop moving if its position is equals to 0px, or 400px( y axis) less the height of the paddle.

Something like this:

move_paddle(ALLEGRO_EVENT *ev){

   if(ev.keyboar.keycode == ALLEGRO_KEY_UP && posiY != 0)
      posiY--;

   if(ev.keyboar.keycode == ALLEGRO_KEY_DOWN && 
      posiY != al_get_bitmap_weight(paddle_img) - 400)
   posiY++;
}

The same for the other paddle. Now the ball, the ball is going to change its Y position when its posiY is 0 or when is posiY is equals to 400 less its height:

if(ball.posiY == 0)
   falling = true;
if(ball.posiY == 400 - ball.height)
   falling = false

if(fall)
   posiY++; //See that I'm just moving pixel per pixel here... the same with the paddle
else
   posiY--;

The same with the sides, if the ball reaches less than 0 pixels... Game over, if it reach more than 640 pixel you win... and so on...

The collision detection for the paddles and the ball is very simple too. And everything depend in what you have thought before reaching this point.

My game is so simple that I know that my paddle has a margin of 20pxs from the borders, so if the ball is in 20px or 640px-20px-its_wight and the ball.posiY is bigger than paddle.posiY and smaller than paddle.posiX+its_height that means that you're colliding... So you need to change its X direction:

if(ball.posiX == 640-20-balls_width && ball.posiY > paddle.posiY && ball.posiY < paddle.posiY+its_heigh)
   left=true;

if(ball.posiX == 20 && ball.posiY > paddle2.posiY && ball.posiY < paddle2.posiY+its_heigh)
   left=false;

if(left)
   posiX++;
else
   posiX--;

Probably there are some errors, I just did it in some minutes, but what I want to say is that you need to think A LOT if you're not sure about what you're going to do before writing something. Try to abstract your ideas and then go down until you finally know how to write them using a programming language.

I disagree. You should have joined this last SantaHack regardless of "I can't make a game in 7 days", and plenty of people encouraged you there. ^[1] You'll be amazed of how much you can actually do in a small amount of time if you just let go of any fears about it. Even if you don't succeed in it, you still learn from any failures.

You can even cheat and set up some basic code for common game stuff in the previous days to the competition. Now I realize we're like 7 months away from another possible Hack compo, but it's just something to think about.

Instead of coding a game right away, you could try coding up some stuff like a basic game engine to handle resource loading, drawing, all that stuff. The motivation on it is that it will just make the process much easier later if you intend to make a game from it(and it's actually pretty fun too, at least the first time). Low-level stuff like that shouldn't get in your way when you WANT to code actual game mechanics.

Yeah because it is the same boring framework taught by almost every book I've read and every tutorial I've done. When it comes to anything complex the tutorials and books really don't do a good job and preparing you because most of them are here is the concept, feature, and example code, next concept/feature and leave it at that. So the advance stuff confuses me because I never know where to start. With the pong clone I did I got as far as "I need two paddles and a ball bouncing around the screen" then breaking it down more was like me trying to speak japanese without ever learning it.

I've noticed that is one thing that is lacking in a lot of CS and such courses, they just assume you are top notch at problem solving and throw you into problem solving in software terms when most people are taught their entire school education how to do mathematical problem solving and real world problem solving. Even my problem solving course in both IVY Tech and DeVry were all mathematical or real world of "Susan is having a problem with Sarah at work. What possible ways could she approach the problem." The one that sticks out in my head is "You're the judge of a dispute. Jim is a farmer who has a family near a stream. Danny is the representative for a large company further up the stream. Proof has been given that the company is having run off in the stream which may or may not be dangerous during the high rain fall months. Read both sides and then come up with a solution that you think would benefit both sides." While it is great for problem solving in real world situations it sucks for programming so I don't understand the point of them in a computer degree.

Woah, woah, woah. That is seriously over complicating pong. At most, a basic OOP implementation of pong would have these classes {ball , paddle , game}, and these methods for each class {check_input() , update(double dt) , display()}.

K.I.S.S. F.T.W.

Usually you'd use UML to describe this stuff though.

When pong needs listeners and events, you might as well stop programming altogether, because You're Doing It Wrong^TM.

Case(s) in point :

It would be simpler to give the Game class a ScoreTable, and manipulate it directly.

OR, you could give the Game class some sound objects that it plays when it detects certain events taking place (not necessarily actually using events).

Listeners are classic over complication in my opinion. Events passed to parents are much simpler, and you don't have to keep track of some crazy inheritance tree created by making everything and its brother inherit Listener classes. Sure you only have to overload one method, but it's the same with events, and events keep things simpler.

Think of it as Lego. You have lots of bricks and all you need to do is start taking these basic blocks and build a larger structure. There are generally two approaches a top-down and bottom-up. In the former you begin from the whole structure and fill in the blocks at the end.

Though, at first I'd recommend the latter, where you begin from the blocks and build the stuff up from the ground often using scaffolding code that will get replaced later. Richard Phipps had a great tutorial somewhere, where you've actually completed a whole game using this approach.

I like building stuff, I like thinking about solving engineering problems. Though I lack the motivation and time to actually do it. My sticking point is to begin. I have lots of ideas lying around, lots of building blocks to use, but no will power to actually begin.

EDIT:
Oh, I knew I saw them somewhere on the wiki:
http://wiki.allegro.cc/index.php?title=Create

though, they seem to be incomplete

I think he actually finished the articles, just no-one finished importing them into the wiki.

Either help to reformat for the wiki , or zip them all up and attach them to the Create page. That way anyone can download them and help to add the rest to the wiki.

Yes, it is more complex, but for me it is worth it to take the extra time in order to make debugging and refactoring much easier. Otherwise my GameScene (the parent) would be well over 4,000 lines of code with well over 100 methods (so far). There is quite a bit going on in the game scene.

I have made projects where I did use the mediator pattern in Java and they got out of hand and I had to stop. I made a Drawing Application where the Panels were responsible for the logic of their children. As I added more features I got lost. After that I started making lots of listeners and while it took much longer, I found myself able to manage much bigger projects.

I have not yet programmed professionally. I'm on my last year of college. Maybe writing code for a company will better enlighten me on the benefits of parents handling child logic, but as it stands, I find myself able to much more easily debug, test, and add features with listeners.

With C++0x, more references is not really a big deal for me.