Hello!

I have been making small games for a while now (a few years, but just as a hobby on weekends) and I am ready for a big project, finally.

I messed around with unity and unreal and I just don't like it. I like coding things myself, I enjoyed the little time I spent with opengl, writing shaders, understanding how games work behind the scenes. For that reason, I'd like to make my own game from scratch in c++.

I want to say that I don't know where to begin, but that's not quite true. I understand that to make my codebase maintainable and sustainable I need some kind of structure and abstraction. I have in mind a vague idea of how it will work- specifically for my game. I sort of have an idea of what systems, modules, classes I will need.

But when I start a new project, I am just stuck. I don't know what to do, where to begin. What if my structure isn't that good after all? What if I don't actually understand it? These are the questions I want to answer before starting the project.

So I pinpointed exactly some of the things I don't fully understand. I made a prototype of the game in my head and realized some code is missing. And it is mostly about the distinction and separation between "writing a game" and "writing an engine".

In my opinion, writing a general engine is a good idea. I can make a renderer, a sound module, a simple memory allocator, etc. These things will be completely separate from the game. But where do I stop? What *is* the game exactly? Is it the main loop? Just the player? And if I don't make an engine, then what am I making? Just a game? What does it mean to make a game and not an engine? At some point I will have to abstract away things, and so what's the difference between the two, right?

Thank you in advance for any help.

This is why you iterate. It's perfectly normal to come up with a design that works for a while, but then stops working as the project evolves/gets bigger. Then you just rewrite from scratch several times until the bigger picture in your head evolves. I've re-written my engine 3 times and only on the 3rd time I got something that naturally works for what I'm doing. It took time to get a feel for it. I'd say just write it how it seems right at the time, but be ready to seriously refactor or maybe even rewrite several times.

Refactoring means using tools like intellJ or having at like 90% automated tests coverage.

I did some refactor-as-I-go (with only manual testing) and was nervous for 6 month that some strange bugs may pop up.

What is an engine?

I started coding on the C16 and a DOS PC. They were bare bones: No sprites, no music instruments. Just pixels and pulse width modulation.

An older computer, the C64, already had that in hardware. So emulating that hardware is kind of writing an engine. Even though the C64 has these hi-level objects and this natural border between its hardware engine and the software game, even then people expanded the engine parts: "Game Maker".

arnero said:

Refactoring means using tools like intellJ or having at like 90% automated tests coverage.

I did some refactor-as-I-go (with only manual testing) and was nervous for 6 month that some strange bugs may pop up.

No, I mean refactor is to re-think the way the code is organized into classes and what is inside what and what is below what (what is a client of what), etc, break up classes or merge them, and end up with similar code but organized in a future-proof way.

VoxycDev said:

This is why you iterate. It's perfectly normal to come up with a design that works for a while, but then stops working as the project evolves/gets bigger. Then you just rewrite from scratch several times until the bigger picture in your head evolves. I've re-written my engine 3 times and only on the 3rd time I got something that naturally works for what I'm doing. It took time to get a feel for it. I'd say just write it how it seems right at the time, but be ready to seriously refactor or maybe even rewrite several times.

This guys is giving really good advice. Whenever you create something while coding you very often do it multiple times before finding a good way to do it.

One thing that may help you a lot is to think about how you can make your pieces talk to each other. If you for example wanted to create a simple class for a sprite then the most important thing at this point is to figure out what information your sprite will need, and how the rest of your code will want to interact with your sprite. If you can then create a simple interface for your sprite that will work regardless of what the sprite actually does within the function calls, you can then modularize your code and rewrite smaller pieces without having to rewrite the entire thing.

Don't be so concerned with specific execution of your code, but instead concern yourself with how your code is going to communicate internally. This sort of thinking will make it a lot easier for you to refactor code when you inevitably need to.

aradarbe10,

I'd recommend looking into the video archive here: https://handmadehero.org/

aradarbel10 said:
I want to say that I don't know where to begin, but that's not quite true. I understand that to make my codebase maintainable and sustainable I need some kind of structure and abstraction. I have in mind a vague idea of how it will work- specifically for my game. I sort of have an idea of what systems, modules, classes I will need.

Maintainable and sustainable is a difficult aim, don't really expect that until 3 or more iterations. Each iteration you get a better design.

aradarbel10 said:
But when I start a new project, I am just stuck. I don't know what to do, where to begin. What if my structure isn't that good after all? What if I don't actually understand it? These are the questions I want to answer before starting the project.

You cannot get all the details right before you start. There are just too many details, and they are connected in too many unclear ways until you go down to code level. So let go of the idea that you do this in one time and get it right. Instead, start what feels ok, and start with something. At some point it will feel bad, then stop what you're doing , reconsider your ideas that led to what you have, and adjust ideas and of course the code.

By the end of it, you'll likely have something very different from what you now believe is what you should make. Then sit back, and consider how it turned out. What is good, what is bad, do you want change it, etc...

aradarbel10 said:
In my opinion, writing a general engine is a good idea. I can make a renderer, a sound module, a simple memory allocator, etc. These things will be completely separate from the game. But where do I stop? What *is* the game exactly? Is it the main loop? Just the player? And if I don't make an engine, then what am I making? Just a game? What does it mean to make a game and not an engine? At some point I will have to abstract away things, and so what's the difference between the two, right?

Engine versus game is indeed about "where does the game begin?". I use as guide "where the code doesn't change between games". Obviously, this has more than one answer. If you write only one type of game the "engine" is larger than when you want to write "any game" with the same engine. I solved this by thinking of the engine as a collection of modules. You don't need all modules all the time, or a game needs a small modification of a module. Also, maybe (not sure yet), the game should handle the glue between the modules, giving a lot of flexibility of organizing the modules?? The game would be leading in organizing the engine parts, no idea if that would be a good idea at this time, I'll have to try that.

"Make a game and not an engine" basically means you discard the whole idea of being generic, reusable, etc. There is just one goal, the first game and only the first game. That's what you have to produce. In theory, for the second game, you throw away everything, and then make the second game from scratch. In both cases you'll have abstractions, but games have a concrete and finite set of things that must be done, so you can reduce abstraction effort to just those specific things. It doesn't have to be generic for all games, or handle an unknown amount of things. The game has 6 things, so write code for those 6 things. The game dictates how the things interact with each other, no need to have arbitrary (not yet specified) interactions between an unknown number of things in an unknown number of ways. Way simpler thus :)

While this feels like a bad idea, it may be less bad than you think. To write generic reusable etc code, you need to understand deeply what you need to implement. The arguably simplest way to get an understanding is to write a few test-cases. Write a handful of different games, then find out what is common, what is unique, and why.

Personally, I am taking a different approach, I write a game but try to keep the game-specific code and the engine code separated. Likely I will fail to get it all right, and I will have to fix things, but I haven't reached the end yet to consider the good and bad parts.