From engine to game programming
Author
Hello!
So I've now been learning C/C++ for 1.5 (or is it 2.5?) years. I had anterior programming experience in a variety of languages including javascript, actionscript, php and a bit of basic so I got to learn C++ pretty quickly. I have already programmed a couple of games in flash/actionscript. I have been discovering OpenGL and Direct3D9 and I can now say that I understand them pretty well. I can use more "advanced" features such as shaders and all.
I've developped an OOP engine for the last 4-5 months and I think I can say without being mistaking too much that I understand well how engines are built (I've abstracted the render API, designed my engine for portability all).
Now that I'm a bit fed up with engine programming (and now that I have a somewhat decent engine), I want to start working on a game project idea that I've had for a year or so. It's a 2D side-scrolling space shooter like "Jets 'N' Guns". But, as much as I feel I know how to design well an OOP game engine, I really don't have a clue about how to actually program a GAME.
Each time I get to work on my project I feel like I'm not structuring well my OOP and game design and I have trouble seeing how I will be able an entire game on such poor code bases. This often results in discouragement and all.
So what I'd like to know is :
- Have anyone experienced such trouble?
- Do you have any tips or help for me on how to get started on game programming?
- Do you know any open-sourced project on which I could have a look to get started?
- From what I've said, do you think I'm attacking a too big project? I feel like a space shooter is not too complex but I might be mistaking.
Thanks a lot!
I am experiencing similar problems. I believe it all stems from the fact that it's very difficult, if not impossible, to make something flexible, "pretty", and functional (fast) at the same time.
When you write a non-isometric tile/sprite engine, you will try to make sure it can be used to write games ranging from tetris and tic-tac-toe to shooter, rpg, and sidescroller. You also end up trying to create multiple hooking points (usually in the form of virtual functions and subclassing), so that a game can be written to ride on top of your engine. All of this introduces a lot of complexity, and some of those things are too difficult to implement in a pretty or efficient way.
I think the way to solve this is to write a game, not a game+engine. That way, all the main concepts like maps, tiles, sprites, event handling, rendering, and collision detection, are "specific" to the game. So we don't need any general-purpose code that is hard to design and optimize, and we get extremely clean-looking code as a bonus.
So let's see... Here's an example. Suppose you are writing a 2d shooting game. Your game engine stores only visual data in tiles, plus perhaps some collision flags, like which sides this tile would block access from. This is all nice and general, because it would be applicable to a lot of games. But let's say that your shooter game wants to display bullet holes, blood, and other decals on walls. So we need a way to tell whether a given tile is a wall or a floor, and if it's a wall, we need to know which way it's facing (straight or diagonal, etc).
Suppose you also want the blood on walls and inclined surfaces to drip down, and the force pulling that fluid down would depend on the slope of that wall/floor, so then we need to store a normal vector for each tile. Suppose you also want to display shadows, and if the shadow falls on a tile with a slope of 0, it would not have any stretch, but if it falls on a wall, it is stretched in the direction the wall is facing, to look like real-world shadows that become shorter when they fall on an inclined surface. And just for the heck of it, let's say you also want to display a fake environment map for some tiles, like a shiny tiled kitchen floor with a highlight that pans when you move the camera. In other words, you need to store specific info for each tile.
With engine/client approach, you can (1) Create a tile-creation hook that instead of creating a Tile class, would enable client to overload a Tile class by deriving their own class from Tile, and have engine create tiles of those class instead. You may need virtual functions if you also want to customize tile rendering. (2) Store all the extra tile information in a separate array, and hope that there is nothing there that will be used each frame. (3) You could make each tile have a 32-bit user-data member that can contain a pointer to user information allocated for each tile. For (2), and (3), if you need special rendering for tiles, you would have to do it before all the tiles are rendered, after, or both, because you would not be able to use virtual functions. Which for tiles, is OK because they never overlap each other. But what about sprites?
Well, and so on. I think having a lite framework for a game is OK, especially if you find yourself testing stuff out often - but a game engine is not a good idea, unless it is specific. Even a 3D game engine like Unreal is created with shooter action games in mind, from what I could tell by looking at the docs.
When you write a non-isometric tile/sprite engine, you will try to make sure it can be used to write games ranging from tetris and tic-tac-toe to shooter, rpg, and sidescroller. You also end up trying to create multiple hooking points (usually in the form of virtual functions and subclassing), so that a game can be written to ride on top of your engine. All of this introduces a lot of complexity, and some of those things are too difficult to implement in a pretty or efficient way.
I think the way to solve this is to write a game, not a game+engine. That way, all the main concepts like maps, tiles, sprites, event handling, rendering, and collision detection, are "specific" to the game. So we don't need any general-purpose code that is hard to design and optimize, and we get extremely clean-looking code as a bonus.
So let's see... Here's an example. Suppose you are writing a 2d shooting game. Your game engine stores only visual data in tiles, plus perhaps some collision flags, like which sides this tile would block access from. This is all nice and general, because it would be applicable to a lot of games. But let's say that your shooter game wants to display bullet holes, blood, and other decals on walls. So we need a way to tell whether a given tile is a wall or a floor, and if it's a wall, we need to know which way it's facing (straight or diagonal, etc).
Suppose you also want the blood on walls and inclined surfaces to drip down, and the force pulling that fluid down would depend on the slope of that wall/floor, so then we need to store a normal vector for each tile. Suppose you also want to display shadows, and if the shadow falls on a tile with a slope of 0, it would not have any stretch, but if it falls on a wall, it is stretched in the direction the wall is facing, to look like real-world shadows that become shorter when they fall on an inclined surface. And just for the heck of it, let's say you also want to display a fake environment map for some tiles, like a shiny tiled kitchen floor with a highlight that pans when you move the camera. In other words, you need to store specific info for each tile.
With engine/client approach, you can (1) Create a tile-creation hook that instead of creating a Tile class, would enable client to overload a Tile class by deriving their own class from Tile, and have engine create tiles of those class instead. You may need virtual functions if you also want to customize tile rendering. (2) Store all the extra tile information in a separate array, and hope that there is nothing there that will be used each frame. (3) You could make each tile have a 32-bit user-data member that can contain a pointer to user information allocated for each tile. For (2), and (3), if you need special rendering for tiles, you would have to do it before all the tiles are rendered, after, or both, because you would not be able to use virtual functions. Which for tiles, is OK because they never overlap each other. But what about sprites?
Well, and so on. I think having a lite framework for a game is OK, especially if you find yourself testing stuff out often - but a game engine is not a good idea, unless it is specific. Even a 3D game engine like Unreal is created with shooter action games in mind, from what I could tell by looking at the docs.
I'd find it impossible to create an engine without making a game along with it. I've been working on my engine since late 2004, and it's currently in its third generation. Each generation had a progressively better game associated with it. (The first two got scrapped because the engine was evolving so fast that the game couldn't keep up. The third game is stable and is likely to actually go somewhere besides down.)
Don't worry about getting it right the first time (or the second or third time). Just come up with a design and implement it. You will learn along the way.
With regards to project size, if you can code an engine around Dx an OGl APIs then you most likely have the skill to make a game. Depending on how you want to design it, you may want to just straight code the game rather than make an engine for it. If you do decide to make your game, I'd recommend SDL as its' portable and fairly easy to use.
In the past if I've made an engine, I became bored with it because I didnt really have a solid game to go with it. And proof-of-concept demos get boring quickly. Now however I decided to make a game but found I'd still have to make an engine, and it's much easier because Im having somewhat tangible rewards for it, because the new graphical effect I make can be applied to my little soldier units in the game.
So to your proposal, I'd definetly go for it, that sort of game is basically drawing, taking input, checking collision and some minor AI, so theres a good chance you'll be able to complete.
And with regards to design, you probably know more than me about OOP. With creating the game, although it can be boring, make the simple things first, and build in cooler features later. You'll have a working half game, and you will constantly make progress.
In the past if I've made an engine, I became bored with it because I didnt really have a solid game to go with it. And proof-of-concept demos get boring quickly. Now however I decided to make a game but found I'd still have to make an engine, and it's much easier because Im having somewhat tangible rewards for it, because the new graphical effect I make can be applied to my little soldier units in the game.
So to your proposal, I'd definetly go for it, that sort of game is basically drawing, taking input, checking collision and some minor AI, so theres a good chance you'll be able to complete.
And with regards to design, you probably know more than me about OOP. With creating the game, although it can be boring, make the simple things first, and build in cooler features later. You'll have a working half game, and you will constantly make progress.
It is possible to write an appropriately abstract, but still efficient, game engine that's appropriate for multiple genres, but only after you've written a bunch of different games and understand what their needs are.
Before then, expect to need to significantly rework your code as you go. As someone once said, the trick isn't to avoid making mistakes, the trick is to make mistakes faster. :)
Before then, expect to need to significantly rework your code as you go. As someone once said, the trick isn't to avoid making mistakes, the trick is to make mistakes faster. :)
I'm going through all the same problems you are, Trillian. Early on it was very discouraging, especially when I not only had no clue about the game but even the engine itself. After a while I just started putting results first before elegance or performance, and since then I've had much better progress. Also, refactoring really helps a lot. You may have many parts of the game design mapped out on paper, but it's only when you sit down to actually write code that you can get a picture of what the actual problems are and how they fit together - especially when, like me, you have not coded a complex game before. Once you commit it to code, you can get some ideas about how to generalize it.
About your side-scroller project, it's certainly a step up from Tic-Tac-Toe but it's not at a complexity level where you should be pulling your brains out. Just go for it :)
About your side-scroller project, it's certainly a step up from Tic-Tac-Toe but it's not at a complexity level where you should be pulling your brains out. Just go for it :)
Author
Hey thanks a lot to you all for your numerous replies! I'm sorry I wasn't here during the day to reply. Anyways.
So I see you are pretty much all agreeing on a few things :
- I should have enough experience to create the game I described
- I should simply go for it and learn through my mistakes, restart from scrash if needed.
So that's what I'll do. I think my motivation will come when I'll see things coming up together. I might end up doing the same thing I've done with my engine : at the beginning I was abstracting in an uber-OOP way all the rendering stuff, after some time, I saw that all of this was way too complex for my needs and I chose to rewrite the parts of my engine in a lighter form ("Graphics" became "Lite2D", "Input" became "LiteInput"). If I find the need for complexity, then I'll rewrite my code.
Anyways thank you all, I'm more motivated to work on my game now!
So I see you are pretty much all agreeing on a few things :
- I should have enough experience to create the game I described
- I should simply go for it and learn through my mistakes, restart from scrash if needed.
So that's what I'll do. I think my motivation will come when I'll see things coming up together. I might end up doing the same thing I've done with my engine : at the beginning I was abstracting in an uber-OOP way all the rendering stuff, after some time, I saw that all of this was way too complex for my needs and I chose to rewrite the parts of my engine in a lighter form ("Graphics" became "Lite2D", "Input" became "LiteInput"). If I find the need for complexity, then I'll rewrite my code.
Anyways thank you all, I'm more motivated to work on my game now!
I am no programmer by any means, I have just messed around with simple javascript stuff, getting my feet wet and gaining the drive to move on to more complext stuff such as C++, but one thing I have found works out EXTREAMLY well for me is this:
Write stuff down.
Either on paper or on notepad, or however you like to do it. When you write things down, and put it into sensical (is that a word?) sentances, the code will just naturally put itself together in your mind. I can't tell you how many times I have been in the middle of writing a post on a message board, or replying to a message, saying I need the same help, when suddenly the way to do it becomes clear.
So I took that natural process to the next step, and now any time I tackle a project, I define what exactly I want to happen from when the user first starts the program to the end screen, to what each object in the game will do. It usually only takes a few mins to a day or two depending on the complexity of the project, but I guarentee you will be able to see the code in a much much clearer way.
Write stuff down.
Either on paper or on notepad, or however you like to do it. When you write things down, and put it into sensical (is that a word?) sentances, the code will just naturally put itself together in your mind. I can't tell you how many times I have been in the middle of writing a post on a message board, or replying to a message, saying I need the same help, when suddenly the way to do it becomes clear.
So I took that natural process to the next step, and now any time I tackle a project, I define what exactly I want to happen from when the user first starts the program to the end screen, to what each object in the game will do. It usually only takes a few mins to a day or two depending on the complexity of the project, but I guarentee you will be able to see the code in a much much clearer way.
Author
Quote:Original post by BUnzaga
I can't tell you how many times I have been in the middle of writing a post on a message board, or replying to a message, saying I need the same help, when suddenly the way to do it becomes clear.
Hey... now that you talk about it, I can also remind myself of something like 10-15 times when I started writing a new topic and found the answer to my problem doing so. I never got used to planning before programming but I'm sure that could help me a lot! Thanks for the tip, I'll put it in practice ASAP!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement