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.
"Make Games, Not Engines".. But how?
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.
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.
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!
).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!
Author
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
