"Make Games, Not Engines".. But how?

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.

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.

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

Focus your work and decisions on benefiting the end product you care most about most directly. That's probably the most general way to say how I always took the phrase.

If your goal is to make a game, then you shouldn't be worrying about how complete your general purpose classes might be so long as they are complete enough for your game. Similarly, if there is an API available that does what you need, even if it may not be exactly what you need or it might be more than you need, then use it and focus your work on what makes your game special, not on rewriting something that already exists.

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

In my opinion that is the core conclusion from "Make Games, Not Engines". Rather get your Game "done" with some very specific (and probably ugly) code for it in it, than waste time on framework-functionality you don't need in the end. Getting your game to run, share it with your friends, play it for a bit and then being able to add it to your protfolio is a great motivation and will help you to go along the road for a more complex game. While spending hours and hours coding framework stuff without getting even something simple as pong to run will be frustrating. The power of an engine is measured by the things that can be done with it, but in order to measure it things have to be done first.

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?

Don't avoid looking at general functionality or guess what might be generalized in some way, but unless you don't need it for your current project don't implement it yet. Put in a comment with your ideas on how to generalize a feature or what is missing to make a function more general or keep some notes about the components you think might be generalized.

After your completed your pong-style game go on for something a bit more complex like a Tetris clone and you will discover that you probably can reuse some code from your original game by adding some bits here and there. In time you will get some quite general code for common tasks which will let you create new games with minimal code overhead. Thus you have created your game-engine by simply writing games.

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?

Avoid it for now. That's the idea behind the "make games not engines" thing. Focus on getting your game up and running. Don't worry about what you can and can't reuse. That becomes apparent to you over time, when you've got a few games under your belt. Otherwise you can easily get bogged down in architectural details that, without experience to guide you, will likely do more harm than good.

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 ;)

[/quote]

My advice is to work at it by setting goals for yourself, one at a time, and coding up what you need to achieve that goal. For example, the first goal might be to get a window on the screen that you can close and exit cleanly. Once that's done, the next goal might be to handle keyboard and mouse events. After that, maybe display a triangle. And so on. Throughout, you can look around at what other people have done, at tutorials and forum posts, to get ideas in how to actually go about implementing each specific task.

Don't tie your hands by worrying over whether you're approaching it the right way, or if there's a better way to do this or that. Just get it done. As the process goes along, you *will* find yourself refactoring and reimplementing this bit or that. And you may hit a dead end now and again. But this is how you build up experience. Then, after you have a finished game and feel all good about yourself, you'll go back and look at your codebase and realize what a mess it is. And in your next project, you'll realize that something you did the first time around could be done a better way. And you'll start to notice that this bit of code from the first game would be quite handy here in the second game as well. And the same will be true of the third game and the fourth. Before you know it, you'll have yourself a good picture of the common bits of all your games and will be able to put together a nice little game framework to help you make future games. And so it goes.

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

Rule #1 Always finish what you have started.

There's nothing worse than seeing a clutter of half-finished projects in a folder. You have nothing to show and you have nothing to be proud of if you know what I mean. Even when you are nearing the completion of something that is starting to bore you, take some time off and try finishing it off at a later time. You'll feel more confident knowing you have a few games that work well.

[quote name='Riztro' timestamp='1341975984' post='4957870']
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

Rule #1 Always finish what you have start.

There's nothing worse than seeing a clutter of half-finished projects in a folder. You have nothing to show and you have nothing to be proud of if you know what I mean. Even when you are nearing the completion of something that is starting to bore you, take some time off and try finishing it off at a later time. You'll feel more confident knowing you have a few games that work well.
[/quote]


Apart from that, one of the best reasons for having games or other software projects completed all the way through is that it shows that you can dedicate yourself to finishing the "less fun" aspects of a program. Eventually, having a portfolio of different types of completed projects will reflect your flexibility, which is important to a career, because very often you will not get to work on exactly what you like the most.

Everyone has their own favorite kind of topics in programming. Some, like myself, enjoy graphics programming and theory the most, others really like programming AI, and others simply prefer programming the rules of the game itself before everything else. By having a completed project you can find out what you enjoy doing the most, and demonstrate that you can deal with everything else that comes with it.

It sounds almost like a chicken & egg thing. You'll have a better idea of what sort of structure you need to design when you have learned what you really need. You won't know what you really need until you started working on the structure.

To me the "make games not engines" idea suggests in part that at some point you have to take the plunge to get anywhere.

I have also started not long ago, about 4 months or so, trying to make games.

Initially my advice is become a sponge, there are lots and lots of techniques, names, and stuff you just need to learn to even display a single triangle on the screen, the other advice is, find a simple basic demo, like how to display a triangle or sprite, and go step by step with it, trying to make it on your own, and understading completely each step done.

At this point don't think about engines or games, just think of learning small pieces of info that will get you closer to you initial goal, which should be make x or y kind of game. once you have a grasp on the absolute basics, start learning things that will help you shape your game a little more, for example, on a pong game, you need to learn,

how to display single images, like cubes, bars, and balls,
next learn how to make the ball move on its own,
how to make the user tap a key and make something happen, then make it move the bar,
lear about coalitions, how to make the ball hit the moving bar,
how to make the ball hit the fixed blocks,
how to make the ball bounce on the corners,
how to make the blocks on your screen dissaper on hit, and maybe spwan items on a random basis, make you bar collect those falling items,
how to play sounds on impact,
keep track of your score of each hit, and how to make a level up once all blocks on screen are gone
make a menu screen, a you loose screen, and a you won screen.

At the end of your learning curve, before you know it, you will have small basic parts of what will become a simple game engine. Then on your next project you can grab the player input code and expand it to accept more keys, the sound code to play more sounds at the same time, make a differnt kind of layout, for a tile game maybe, make the player code accept a sprite for a guy instead of a bar, and make move in all direction instead of just left and right, well you get the idea... you knowladge will start growing and you game engine will evolve with it, from a pong game engine it can become an rpg, an rts, or what ever you want it.

On the other hand comercial game engines are designed to accept variables for lots of game types, that makes it normally a waste of time for developer that are focusing on a single game, and want to develop their games from 0.

All this to say, Focus on your current game, and your next game and engine will evolve with the knowledge you gather from your previews experience.

To me a 'game engine' is a one size fits all approach. If you decided to go down that path, you would be forever pulling out your hair (I have been there ).

If you are making a side-scroller (for example) will you ever need a first persone camera? If no, then why go through the trouble of adding it to your 'engine'?

If you don't need a one size fits all solution, then just code the 'shell' of your game with what you need. This then becomes your 'framework' and in escense is your game engine. But not neccesarily a game engine from the point of view from others, as it doesn't suit their particular needs (If I am making sense).

The bottom line is, if you code a full game engine for every forseeable requirement, you will be forever coding the engine and will never start your actual game.

Code the game and have fun solving the actual problems you come across. Good luck!

Thank you all for your replies! I think after receiving all this advice I am ready to make a game and not an engine

Yah this is all good advice, and its something I have been trying to hammer home with my hobby team. It's especially important if you lack experience. My team and I are creating a disposable game at the moment just to see if we have the people to do it. After that we'll decide if we want to make somethign more serious at which point we'll start from scratch and plan it using the mistakes we made as a guideline to creating something a little more all purpose. (Reuse, refactor, rewrite, etc). We'll also have a better idea of what kind of game we're capable of making, besides it being fun ;p