Oh, by the way, since you specifically asked for architecture/structure, check this https://hero.handmade.network/episodes

He makes an entire engine + game and show you every line in more than 400 videos... 

4 minutes ago, Kylotan said:

I personally recommend steering well clear of the Handmade Hero stuff when trying to work out how to write good code.

I can't comment on that since I saw only 20 videos and also don't have the tools/knowledge to judge it, though I can say I definetly wish more developers would attempt what he is attempting

50 minutes ago, MarcusAseth said:

Oh, by the way, since you specifically asked for architecture/structure, check this https://hero.handmade.network/episodes

He makes an entire engine + game and show you every line in more than 400 videos... 

 

Have you looked at that index? How is this going to motivate someone ?

Furthermore, if you have trouble understanding someone else's C++ code (whether it is good or bad code), stay away from someone else's C code. I studied a compiler implementation written in C in some kind of OO fashion (very deep union/struct alternations); the verbose codebase was a real monstrosity.

2 minutes ago, matt77hias said:

Have you looked at that index? How is this going to motivate someone ?

lol

Still entertaining though, for when you want to just lay down on bed and passively assimilate some knowledge, it's just like listening to a podcast

6 minutes ago, MarcusAseth said:

just lay down on bed and passively assimilate some knowledge

Not enough time for that  .

It would have been nice if he can summarize everything in <10min. Currently it will take you more than 500h< to go through all that, passively or not.

5 hours ago, LuridRequiem said:

I wanted to build a super basic version of PONG. I wrote classes to handle the window and Player Paddle and placed it all in a game loop function that I called in main(). Everything at that point ran fine, but it wasn't what it should've been. Nothing else was completed. In this main loop, I was basically calling objects in full. I know now that I shouldn't have done it like that, but at that point, I didn't know how I was supposed to build this game loop that would keep the game running.

I suspect you're hitting Analysis Paralysis by getting too hung up on doing things the "OO way".

Pong is really no different to any other kind of application:

1. It gathers input
2. It processes that input into some state
3. It presents that state as output

The only notable variation is that for a real-time game those 3 step needs to occur every single frame.
So all we do is wrap them up in a game loop like this:

World world;

while (true) {
	Keys keysPressed = checkInputs();   // input
	update(keysPressed, world);         // process
	render(world);                      // output
}

World maintains the state of the game (paddles, players, scores, ball, etc) and its public methods model the interactions that you have available to you when playing. In the case of Pong it might have a method like: movePaddle(amount).

The update() function knows how to convert inputs (keypresses) into actions that modify the world. For example it knows that if you push the right-arrow key then it will invoke: world.movePaddle(1);

The job of the render() function is to translate the state held by World into something visual. If the process of rendering requires  state all of its own (textures, shaders, models, etc) then a simple render function isn't enough. That's fine. Just make it a method in a class:  renderer.render(world);  This class can now hold all that rendering gumpf, available only to the render() method.

Of course as you scale this up to larger and larger applications/games you'll find that these pieces become bloated. At which point you'll want to start sub-dividing ("refactoring") them.  For example you can move code out of your World class into Paddle and Ball classes and World just glues them together. Or you might move code out of render() (or Renderer) into renderPaddle, renderBall, etc.

This "refactoring" process helps keep your code organised and maintainable. But it's not where you start. You start simple and you subdivide structure into it only when needed. This is how we all do it!

With lots of experience we developers can sometimes foresee what sort of factoring is appropriate and then shoot straight for that. But in reality it's an unreliable process (because we're only human, we stumble across pitfalls or we learn something new or requirements change).  Ultimately it's a skill that you will never master and you will never stop improving!

1 hour ago, dmatter said:

I suspect you're hitting Analysis Paralysis by getting too hung up on doing things the "OO way".

Pong is really no different to any other kind of application:

1. It gathers input
2. It processes that input into some state
3. It presents that state as output

The only notable variation is that for a real-time game those 3 step needs to occur every single frame.
So all we do is wrap them up in a game loop like this:

World world;

while (true) {
	Keys keysPressed = checkInputs();   // input
	update(keysPressed, world);         // process
	render(world);                      // output
}

 

World maintains the state of the game (paddles, players, scores, ball, etc) and its public methods model the interactions that you have available to you when playing. In the case of Pong it might have a method like: movePaddle(amount).

The update() function knows how to convert inputs (keypresses) into actions that modify the world. For example it knows that if you push the right-arrow key then it will invoke: world.movePaddle(1);

The job of the render() function is to translate the state held by World into something visual. If the process of rendering requires  state all of its own (textures, shaders, models, etc) then a simple render function isn't enough. That's fine. Just make it a method in a class:  renderer.render(world);  This class can now hold all that rendering gumpf, available only to the render() method.

 

Of course as you scale this up to larger and larger applications/games you'll find that these pieces become bloated. At which point you'll want to start sub-dividing ("refactoring") them.  For example you can move code out of your World class into Paddle and Ball classes and World just glues them together. Or you might move code out of render() (or Renderer) into renderPaddle, renderBall, etc.

This "refactoring" process helps keep your code organised and maintainable. But it's not where you start. You start simple and you subdivide structure into it only when needed. This is how we all do it!

With lots of experience we developers can sometimes foresee what sort of factoring is appropriate and then shoot straight for that. But in reality it's an unreliable process (because we're only human, we stumble across pitfalls or we learn something new or requirements change).  Ultimately it's a skill that you will never master and you will never stop improving!

 

You can try to program Pong in Elm (Functional Reactive programming). Very fast and a joy to debug due to the steps.