Hello all,

So lately I have been trying to breach the seeming impenetrable wall of game development. I have tried to create games (not engines) because a certain man with a popular blog told me too (http://scientificnin...mes-not-engines). Anyway, when it gets down to whipping out the old IDE, C++, GLFW, and OpenGL docs, I start to plan out what I will do.

To get started I think to myself, "Okay, start small!". So I come up with the idea of making pong, but when I start planning out how it is going to get programmed is when I run into trouble. I start thinking of how am I going to render the objects, GUI, and text, and also handle shaders, textures, etc. Then I start planning how to play audio. Then I start thinking about how I am going to handle the window and input. (BTW I am not using SFML, SDL, Allegro, etc here because I want to learn use OpenGL, C++, GFLW, etc so that I can easily use those tools when making 3D Games)

After all this planning I almost have a full plan for a very basic ENGINE right? (Or wrong? ) Now I am in big trouble . I have tried making a game and I still end up making an engine.

Now my question is, how exactly do you program a game.. without making an engine?

Thanks,
Brent

You program the game, and the 'engine' for the game is part of the game.
You don't program an engine, and then build a game using that engine, or you'll find that most of the work you put into the engine won't be useful for the game you are now making, and you'll have to recode alot of it.

The phrase, "make games, not engines" isn't saying that engines are bad, but that putting your focus on making the engine without a specific game in mind is bad (unless your end goal is making an engine but not a game - which is fine too). When you make a game, yeah the basic architecture of the game becomes an "engine". That's not bad, that's good - you end up with a game, and a very game-specific engine. But if you make a general-purpose 'engine', or even a genre-specific engine, or even a sub-genre specific engine, you rarely end up with a (good) game at the end of everything.

Focus on making your game, and you can refine and polish the skeleton architecture of that game and reuse it for your next project as your 'engine' (if the next project is similar enough). But focus on making an engine for your game, and you usually end up rewriting everything anyway, or quiting when you find out you now have a engine that makes cool tech-demos but is worthless for a real game.

It's an issue of focus - Is the focus on making the engine, or the game? If the former, you usually write a bunch of stuff you don't need, and make the engine too generic to be of real use.

You program the game, and the 'engine' for the game is part of the game.
You don't program an engine, and then build a game using that engine, or you'll find that most of the work you put into the engine won't be useful for the game you are now making, and you'll have to recode alot of it.

The phrase, "make games, not engines" isn't saying that engines are bad, but that putting your focus on making the engine without a specific game in mind is bad (unless your end goal is making an engine but not a game - which is fine too). When you make a game, yeah the basic architecture of the game becomes an "engine". That's not bad, that's good - you end up with a game, and a very game-specific engine. But if you make a general-purpose 'engine', or even a genre-specific engine, or even a sub-genre specific engine, you rarely end up with a (good) game at the end of everything.

Focus on making your game, and you can refine and polish the skeleton architecture of that game and reuse it for your next project as your 'engine' (if the next project is similar enough). But focus on making an engine for your game, and you usually end up rewriting everything anyway, or quiting when you find out you now have a engine that makes cool tech-demos but is worthless for a real game.

It's an issue of focus - Is the focus on making the engine, or the game? If the former, you usually write a bunch of stuff you don't need, and make the engine too generic to be of real use.

Thank you very much friend! Now that I know I just need to focus on making the engine for the game I have some idea of what I need to do. I have one more question for you though, wont I end up making a very general purpose engine after I am done anyway? Or is that just a personal problem I have of always thinking of future games while I am currently making one?

For example: I will start programming a simple rendering system but then end up focusing on some sort of shader generator. (Focus problem?)

Thanks again,
Brent

The point is simply to prioritize. Instead of aiming to write a general-purpose engine, you aim to write a lot of games, and then extract the common elements into something general-purpose.

The idea isn't to avoid general-purpose code - far from it. It's to teach you how to recognize what general-purpose code tends to look like, and how to create it efficiently.

Thankyou very much! I get what you are saying .

It's good that you bring this up because I somewhat struggled with this confusing terminology too.
Maybe there should be a term that differentiates between game-specific engine and game engine as in a very general set of libraries that can power any game with minimal code writing on your part such as Unity, a program that allows end users to make games.
My goal is to create games but with my own engine as in very specific. i.e. Other people might not be able to use it but it should serve my purposes. If it can be improved so the better.

There's no well-defined difference, that I know of, but here's how I think of it:
The problem in the terminology is that the point of every library is to abstract away another layer of nitty-gritty details beneath it, in a domain-specific way.
It's only once too many libraries abstract the details further and further, and start adding logic to what it's doing, that it starts to become a "engine" instead of just a "library".
Game engines usually tie together multiple different "problem specific" engines like physics engines and graphics engines. Also, just because a library offers graphics capabillities and sound or networking capabillities, doesn't make it an engine... unless they start adding logic for how those things are handled. Without logic, it's just a library or a collection of libraries bundled together. With logic, it becomes an engine.

In my own personal opinion, once the main loop of the code is controlled for you, it probably is a game engine instead of just a set of libraries.
It becomes a 'game engine' once it starts dealing with the overall architecture of the game.

Also, I fully agree with ApochPIQ, I'm not trying to villify general purpose code... but I feel like the people who best can make useful general purpose code, are the ones who have already had to write domain-specific code dozens of time.
Unreal Engine and idTech engine are written by people who have already made game-specific engines (by writing games, not engines) so many times that they understand what's common between them and what's not, and so know where to generalize, and where to be specific.
Otherwise, if people are stabbing in the dark writing general-purpose code, it's too generalized and needs to be wrapped in yet more layers to actually become useful.
The point of libraries is to take that already super-general, and remove some of the generalities to make it more useful in a specific area. If an engine is too general, it's just a wrapper around a bunch of libraries... but doesn't take the libraries any further into usefulness.

Also, I fully agree with ApochPIQ, I'm not trying to villify general purpose code... but I feel like the people who best can make useful general purpose code, are the ones who have already had to write domain-specific code dozens of time.
Unreal Engine and idTech engine are written by people who have already made game-specific engines (by writing games, not engines) so many times that they understand what's common between them and what's not, and so know where to generalize, and where to be specific.
Otherwise, if people are stabbing in the dark writing general-purpose code, it's too generalized and needs to be wrapped in yet more layers to actually become useful.
The point of libraries is to take that already super-general, and remove some of the generalities to make it more useful in a specific area. If an engine is too general, it's just a wrapper around a bunch of libraries... but doesn't take the libraries any further into usefulness.

Okay so I am going to be stabbing in the dark and am going to be guessing what general functionality is right? Or should I just avoid looking for general functionality at this point?

Also I have a question about design, should I program what I want in the game and then program the underlying structure, or build the underlying structure first? Which is the best way to design? For example:

Top down: I code this first, then code the underlying engine so I know exactly what I need.

int main()
{
Render game;
Sprite test;
game.Add(test);
while(game.Running)
{
game.Render();
}
}


Bottom up, I write all the functions/classes I am pretty sure I need for my game first and then write the game.
No example because that would be a lot of code ;)

Thanks,
Brent

They say you shouldn't try to write the most optimized version of a function and instead write the function and get something that works first. I'd like to thing it's the same with writing your game down. I don't see how you can fall into such troubles thinking of a pong game. When you start writing it aim for the simplest parts first. I'd start with drawing rectangles on the screen, eventually moving the ball and then collision detection. After that you can start thinking of showing off some stats and putting sound effects. You can't possibly go out and think of everything at once.

I'm not saying it's bad to plan ahead a little, but if you don't have the experience take one step at a time. If you are smart, you will divide your functionality into classes. A few games down the road you will probably be able to reuse a sound class, a timer class, a physics class... and that can compose an "engine". You seem to worry way too much about the global aspect of your project, don't get overwhelmed. Worse thing that can happen is having to re-write a class because it wasn't good enough or you realized you could make it more generic. Aren't you noticing something? By making that mistake you are writing better code!

Biggest problem for all the beginners around here is that their too afraid to make mistakes. Get your hands dirty.

Obviously not getting my hands dirty hasn't worked out for me well because after what seems like a year haha. I haven't actually finished a game-related project in that long :/. Looks like I should stop trying to be perfect