Sign in to follow this  
Trillian

From engine to game programming

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
It's fairly natural to have explaining something to somebody (even if it's just yourself) help your understanding. There are a few different levels of understanding:
1) Hearing something.
2) Being able to do something.
3) Being able to teach someone else how to do something.

Each of those requires successively deeper understanding of a topic. So, taking the time to write something out requires you to corral your thoughts, thereby improving your understanding.

For #3, I always think of writing code as describing a process in the simplest possible terms, with little or no room for ambiguity.

Share this post


Link to post
Share on other sites
Quote:
Original post by BUnzaga
Write stuff down.


I'd like to add to this:

Planning your game project is about the most important thing you can do to accomplish the tasks you set out before yourself. However, occasionally the medium with which one designs stifles innovation and creativity.

As basic and obvious as it sounds, I feel it also needs to be said: using pencil and paper is one of the better planning mediums available to you. Drawing relations between objects, scribbling and scratching out ideas, brainstorming with the pen traveling as fast as thought (though some of you might notice that you can't write worth a damn due to keyboard exposure!), and even doodling, are all elements of the creative design process that are impossible in <insert favorite note software here>.

I've "gone back to the drawing board" recently with two games I've been working on for a while, and I can't say that I regret abandoning "engine design" in favor of "game design"; I switched to a more-or-less-complete engine for my game, and I couldn't be happier.

Share this post


Link to post
Share on other sites
1) Everybody has experienced such trouble
2) Switch to a commercial game engine
3) Yes, but I wont' tell you, dont waste your time
4) A space shooter takes 1 week using a commercial game engine, 1 year otherwise

Share this post


Link to post
Share on other sites
I found that I had to pay some dues, and maybe I still am. By that I mean that I first had to make a crappy inflexible game, with very poor style, littered with DirectX dependencies throughout, and basically a real mess, but it met its simple goals in the end. I had resigned that it would not be much of a game.

I'm on my 3rd iteration (my first is at the link below), things are looking much better, and I was able to clean up and reuse the best stuff from my earlier tries.

I've set aside trying to be elegant and clean for now. That's for open source libraries to strive for. Although I try to avoid getting sloppy. I plowed in and maybe got a little dirty, but its working great, despite the slight mess under the hood. This may not be the approach for everyone though.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this