Hi all! (First post here! Hehehe)

For nearly the past year I've been working in C++ and other game engines, Unity in particular, and I feel like I have a pretty good grasp at game development basics.

Now, I've decided to tackle a writing my own game engine for learning purposes, but I have no clue how to structure my code, or how to even begin.

I'm wondering where to start and what to do.

Right now, I have my main game loop which loads the update, input, and rendering functions, but I have no clue where to go from here.

Any help would be greatly appreciated!

Game engines are hard to design, at some point the generic engine code stops, and the game specific code starts. The problem is, where is that point.

I am reading from your post there are no obvious open areas in your engine any more. That means to me, you're finished making your engine!

Now, it is probably useful for learning purposes, to evaluate your engine. In other words, how good does it do its job?

(I do hope you have a list of requirements what your engine is supposed to handle).

Thus, testing time has arrived. Package the engine, give it a fancy name and version number (fooengine, 0.1 alpha, build 21583).

Then make a new directory, unpack the engine, and now make a game, like pong, tetris, pacman, space invaders, whatever you want. (Smaller is better, it's the first test, don't try anything big until you're confident small things "are trivial".)

Here you're supposed to write only game-specific code. Assuming you will finish at some point, leave it for a week, and then look again at the code you actually wrote, and the changes you made in the engine code (which you are not supposed to change?!). Could you re-use parts for another game? Did the engine code cause restrictions where you had to work around, or even hack the engine code to make it work?

At this point, you can decide to fix or expand the engine, making a new version, and a new test cycle begins.

If things look good, it's probably useful to do at least 2 or 3 games, to verify your findings.

And here you see the disadvantage of focusing at an engine. The games are not the goal any more, the engine is the goal. The games you make become sort of by-products of testing the engine. With each test cycle of the engine you have to write a lot of games, or update already written games.

If this is what you want to do, it's fine, just be aware of it.

In my opinion. Start by abstracting your core loops as functions/functors/pointers you can arbitrarily set as any function/method you want. If your update requires passing elapsed time, create a loop around calling the function which in addition to calling the function will acquire elapsed time. Beyond that obvious stuff, I'd recommend building the fundamental initializations into the engine. For example, my game engine works with OpenGL, I initialize GLFW, I also configure a window to render upon, and start up some threads then move the rendering context to one of those threads, I do this so I can poll input on my main thread without requiring the thread to do multiple things. I also keep the projection/view matrices as part of my engine. I have function callbacks for types of input as well as user instigated window resizing.

In a more abstract design-centric approach, I'd recommend determining what functionality your engine requires, and what the ultimate purpose of the engine is with regards to development of a game. eg. I need my engine to save me from setting up architecture, initializing opengl, and provide interfaces for loading and managing assets.

Once you have your requirements start making some simple object oriented designs, and the rest will likely take on a life of its own.

I hope that was as succinct and helpful as I'd like to think it was. Good luck, especially if you decide to implement object pooling and memory management features (that stuff kicked my ass hard).

edit:

Thus, testing time has arrived. Package the engine, give it a fancy name and version number (fooengine, 0.1 alpha, build 21583).

Then make a new directory, unpack the engine, and now make a game, like pong, tetris, pacman, space invaders, whatever you want. (Smaller is better, it's the first test, don't try anything big until you're confident small things "are trivial".)

This is very true. If you end up having a time even remotely close to the one I had, you'll end up finding countless bugs in the process of making a game. I made a bullet hell space invaders game. I ended up finding bugs everywhere: shader compiling, sprite data file formatting flaws, asset loading mistakes, memory allocation, object construction, matrix calculations, etc.. Making a simple game allowed me to worry about debugging the engine instead of, primarily, the game itself. I already had a bullet hell space invaders though, so it was a small game to me.

Game engines are hard to design, at some point the generic engine code stops, and the game specific code starts. The problem is, where is that point.
I am reading from your post there are no obvious open areas in your engine any more. That means to me, you're finished making your engine!

Now, it is probably useful for learning purposes, to evaluate your engine. In other words, how good does it do its job?
(I do hope you have a list of requirements what your engine is supposed to handle).


Thus, testing time has arrived. Package the engine, give it a fancy name and version number (fooengine, 0.1 alpha, build 21583).

Then make a new directory, unpack the engine, and now make a game, like pong, tetris, pacman, space invaders, whatever you want. (Smaller is better, it's the first test, don't try anything big until you're confident small things "are trivial".)
Here you're supposed to write only game-specific code. Assuming you will finish at some point, leave it for a week, and then look again at the code you actually wrote, and the changes you made in the engine code (which you are not supposed to change?!). Could you re-use parts for another game? Did the engine code cause restrictions where you had to work around, or even hack the engine code to make it work?

At this point, you can decide to fix or expand the engine, making a new version, and a new test cycle begins.
If things look good, it's probably useful to do at least 2 or 3 games, to verify your findings.



And here you see the disadvantage of focusing at an engine. The games are not the goal any more, the engine is the goal. The games you make become sort of by-products of testing the engine. With each test cycle of the engine you have to write a lot of games, or update already written games.

If this is what you want to do, it's fine, just be aware of it.

Agree with above. I worked on and with many game engines and one thing I found is that building a tech for a sake of building the tech isn't good option. You must have something to use your engine with. Otherwise you even don't know that maybe you're going in wrong direction, maybe you spend time on features that, from "enginish" point of view are useful, but in practice - there's barely usecase for them. 2D or 3D engine - it doesn't matter as much as you need to know what you want to achieve with it. Look at Unreal or IdTech. In the beginning they were not even called 'engines'. They were standalone games from which engines have been 'extracted'. When Carmack worked on the new engine, there was Romero taking care of using it.

Now here's answer to your question. You're saying "I have no clue where to go from here". Make something ( I probably mean 'a game' here ) with your engine. You may get surprised how many things you're not going to use and how many other things will be missing to meet the requirements. A potential game build on top of your engine will show you where to go from there. You got certain basics working and it's enough to start working on the actual game. Also look at it from an artist and designer viewpoint. Today the workload has been shifted towards content creators rather than programmers. The easier to make art and design related things, the easier to use your engine. Couple of years ago I worked on the engine and game. I worked very close with an artist who brought lots of requests about handling of particular things. In the beginning, what I didn't plan to place within the scope of the engine, I made it as part of the game layer. Later, whatever seemed to make sense, I merged with the core engine. My work though was not the engine only but also tools, scripts, assets pipeline etc. All those requirements came up while working on one single game. Since it was just "two of us" team I had load of work including coding the actual game. At the end of the road, the engine was shaped not by the code that I've done before the game, but by the game itself. So shortly - the game will show you where to go next

As an extension to the above thought, might I ask a related question?

If you've seen the YouTube videos about gaming concepts and game development on the Extra Credits channel, and/or have been considering game development for some time, you've probably come across the phrase "minimum viable product". This is meant to recommend to start very small and simplistic at first, then slowly add in functionality and enhancements as the final project requires. But does this also apply to making game engines?

In other words, how exactly does one go about creating a game engine from minimalist engineering, and go through iterations of the engine and its features, unless at some point we can expect what we add in may perhaps break previous functionality?

As an extension to the above thought, might I ask a related question?

If you've seen the YouTube videos about gaming concepts and game development on the Extra Credits channel, and/or have been considering game development for some time, you've probably come across the phrase "minimum viable product". This is meant to recommend to start very small and simplistic at first, then slowly add in functionality and enhancements as the final project requires. But does this also apply to making game engines?

In other words, how exactly does one go about creating a game engine from minimalist engineering, and go through iterations of the engine and its features, unless at some point we can expect what we add in may perhaps break previous functionality?

No. The engine is the minimum viable product to make the game (should you choose not to use an existing engine). Write a game and you will necessarily get a minimalist engine. An engine is a tool, and you can't realistically develop a tool without a customer, or at the very least a use case.

go about creating a game engine from minimalist engineering, and go through iterations of the engine and its features

I don't see any feature X that you MUST have to call some piece of software an engine. On the other hand, you do need one feature, or you are not helping in development. Theoretically, the smallest possible feature in a single game is thus a game engine.

I don't know how this scales in "viable", without a clear definition of engine, you cannot measure such properties.

You see incremental development a lot, and it does have some nice properties like not getting all problems at the same time. I believe it's the primary means to evolve to whatever you end up with. Software is just too complex to visualize the end-product, and design and implement it from scratch in one time without errors.

On the other hand, if you have a piece of software, you look at it, you throw it away, and you rebuild it from scratch, the new solution tends to be way better than what you originally had. I believe you need some balance between both, build incrementally when it all fits, otherwise redesign (some parts) from scratch.