Sign in to follow this  
ill

Setting up the game engine cleanly

Recommended Posts

OK, so right now I'm just setting up the game engine on which my game will run. I'm writing it in C++ using SDL and OpenGL and FMODex for a 2D hardware accelerated game engine. So I know how to initialize everything from all the tutorials I've read but I've just gone through like 3 recodings of the sound code. First I was just making a module then I decided to make sound part of the main game engine then realized that completely cluttered the main game engine code and now I'm making it a utility class of its own. Basically, how do you guys set up and manage all the sound, graphics, resource management, and event handling? Those are the basic things I'm trying to create before I get into the actual game logic coding. I want the engine to be put together cleanly, not in a way where I feel like I'm coding on a piece of crap I put together and constantly rewriting parts of the engine because I'm not satisfied with the way its done.

Share this post


Link to post
Share on other sites
Many people are going to post the obligitory "make games not engines".
I to sugest you go the other way.
Start coding a game. Write all the game logic you can, and every time you have to write a piece of engine to further your goal. Do it then. It means you end up prototyping a lot of stuff at a dos prompt, or as little dots on screen before you end up making model loaders and textures and resources, and sounds etc. But it also means that you will have a game at some point instead of a pile of useless "engine" code.

Share this post


Link to post
Share on other sites
Quote:
Original post by ill
Basically, how do you guys set up and manage all the sound, graphics, resource management, and event handling? Those are the basic things I'm trying to create before I get into the actual game logic coding. I want the engine to be put together cleanly, not in a way where I feel like I'm coding on a piece of crap I put together and constantly rewriting parts of the engine because I'm not satisfied with the way its done.


I'll offer my approach.

What I do is I sit down and start writing code that uses interfaces and classes that do not yet exist.

I start with the place that the program starts with under normal circumstances.
That is, the main() or WinMain() if I'm drunk or/and for some reason using a windows OS.

I then decide how I want the code to work.

// main.cpp
#include "game.h"
int main(int argc, char* argv[])
{
if (game.init())
{
game.start();
}
return 0;
}



Once I have that, I then start implementing the first thing that the compiler cannot compile yet.
Which in this example the first thing I need is a class that the "game" variable will be instanced from, and that it will need a boolean method called "init".

Lets say a class called Game, and lets toss in the start method for good measure.

// game.h
#if !defined(GAME_H)
#define GAME_H
class Game
{
public:
Game();
~Game();
bool init();
void start();
private:
};
extern Game game; // in game.cpp this is declared.
#endif



And the game.cpp would then start as

// game.cpp
#include "game.h"

// declare the global instance that we will use
Game game;

Game::Game()
{
// init only vars of types such as int, bool, float, etc here
// that way all init code beside default values will be setup by the init method
}

Game::~Game()
{
// clean up here
}

bool Game::init()
{
// load resources here, and return false if loading them failed

// init any data structures we need here and return false if initialization failed

return true;
}

void Game::start()
{
}




So now, at this point, the "game" that I've written will compile.
It does nothing yet, but it works.

I continue on this path until I've written the desired framework.
Once I have it in place, I start doing the same thing with the game code.

I prefer to create a Manager class for resources, sometimes one for each type.

class ImageManager;
class SoundManager;
class MusicManager;
class ModelManager;
class TextureManager;
class ActorManager;

etc...

I like to have a single instance of these classes made as a private member of the Game class, and have methods in the Game class return a pointer or a reference to these instances.

The managers should load only once.
So if you load up "hero.png" as an Image like this

Image heroimage = game.get_image_manager().get_resource("hero.png");



If you ask the manager for the same resource again, you should get the already loaded resource, so that you don't re-load the same image from disk.

There are countless way to implement that. Ask around or search google for how to write a resource manager class.

So thats basically my approach.
I don't claim its perfect, many will argue against my methods, but all that matters is that it works for me.
You gotta find what works for you.
Good luck.

Share this post


Link to post
Share on other sites
Hmm OK.

I already have a basic game that I'm porting from Game Maker(LOL sick of it) to C++ so the basic game is already there and I know what it will need to do. I even have all the gamestates and stuff working and a level editor already made which I will too port over to C++ later.

I have something like Developer_X has minus the resource management so far. My Sound class I guess is acting as the sound and music manager at the moment. I don't see a point in loading more than one song at once unless I had a game where the scores constantly changed which I don't so it loads music as a stream. Also it manages all the sound resources and code like playing a sound.

I guess I'll do the same for graphics. So you distinguish textures from images? I was thinking of combining the two and having actual textures/sprites inherit from images or something. IDK...

Share this post


Link to post
Share on other sites
Quote:
Original post by KulSeran
Many people are going to post the obligitory "make games not engines".
I to sugest you go the other way.
Start coding a game. Write all the game logic you can, and every time you have to write a piece of engine to further your goal. Do it then. It means you end up prototyping a lot of stuff at a dos prompt, or as little dots on screen before you end up making model loaders and textures and resources, and sounds etc. But it also means that you will have a game at some point instead of a pile of useless "engine" code.


Actually I think your interpretation of the obligatory "make games not engines" statement is backwards. When that is said it actually means exactly what you have described, that is, start creating code that you need and as it grows and different sections form a theme you separate them into their own modules which then form the backbone of an emerging "engine".

It's frustrating to see people asking questions about "what do I need to put in my engine to make it 1337 / useful / whatever", because they aren't creating anything with actual purposeful use as per their emerging requirements and are relying on others to give them as best an idea as they can so that they can produce this beastly engine that does everything and anything... but ultimately nothing. A haphazard mix of different things that have been put together with no real direction and communal goal. A bit like asking 10 different people to give ideas for a design for a house... sure each piece may be cool etc, but as a whole it would turn-out to be a disasterous and ugly house that no one would ever live in.

Therefore it's best that people write code and not engines, and as their code grows it's best to continually re-organise the code in a way that makes sense. Through doing this an engine emerges and is already useful as it IS being used already.

That's my understanding of the phrase at least.

Share this post


Link to post
Share on other sites
Quote:
Original post by ill
Basically, how do you guys set up and manage all the sound, graphics, resource management, and event handling? Those are the basic things I'm trying to create before I get into the actual game logic coding. I want the engine to be put together cleanly, not in a way where I feel like I'm coding on a piece of crap I put together and constantly rewriting parts of the engine because I'm not satisfied with the way its done.
That's called refactoring, and you shouldn't be afraid to do it.

(though of course, like with anything, there's a limit to how much you should refactor, don't just change stuff arbitrarily because you change your mind but at the same time, don't be afraid to change something if it becomes unwieldy or difficult to extend)

Share this post


Link to post
Share on other sites
Quote:
Original post by nb
Quote:
Original post by KulSeran
Many people are going to post the obligitory "make games not engines".
I to sugest you go the other way.
Start coding a game. Write all the game logic you can, and every time you have to write a piece of engine to further your goal. Do it then. It means you end up prototyping a lot of stuff at a dos prompt, or as little dots on screen before you end up making model loaders and textures and resources, and sounds etc. But it also means that you will have a game at some point instead of a pile of useless "engine" code.
Actually I think your interpretation of the obligatory "make games not engines" statement is backwards.
I read it that way too initially, but I think this:
Quote:
I to sugest you go the other way.
Is supposed to be 'I too suggest you go the other way.'

So in other words, he's saying he agrees with the suggestion to make games, not engines (at least that's how I interpret it).

Share this post


Link to post
Share on other sites
Quote:

Is supposed to be 'I too suggest you go the other way.'

So in other words, he's saying he agrees with the suggestion to make games, not engines (at least that's how I interpret it).

Even if English is my first language. Doesn't mean I speak it well. Yes, jyk, that is what i meant.

Share this post


Link to post
Share on other sites
Quote:
Original post by ill
So you distinguish textures from images? I was thinking of combining the two and having actual textures/sprites inherit from images or something. IDK...


In my case, a Texture has an instance of an Image.
The Image provides the pixel data and methods for manipulating said data.
The Texture provides methods to translate the Image pixel data to a format that another API would need, such as DirectX or OpenGL.

Share this post


Link to post
Share on other sites
Hmm OK, I guess maybe I will start making the game right away.

My sound code is already basically done since I ported over the exact same code from my other game into C++, to play a song, play a sound, play a sound with stereo and volume adjusted for faraway objects, and to adjust the sound panning and volume for that sound an object made when the view and object move around.

For graphics I just needed like image, sprite, surface, font, and functions to draw and manipulate those images rotated, colorized, transparent, and all that and different blending modes. That's about it. So I did have a clear vision of what the engine will need and wasn't setting out to create a super hardcore engine with no gameplay that would lead me nowhere.

Share this post


Link to post
Share on other sites
Quote:
Original post by Developer_X
If you ask the manager for the same resource again, you should get the already loaded resource, so that you don't re-load the same image from disk.
When considering resource management I've long suspected that design to be more of a local optima that people arrive and stop at. It's just that it doesn't seem very cohesive to me.

When loading a level one could build a up catalogues of resource descriptions, a catalogue is just a set of descriptors and a descriptor essentially represent a request for a resource. By definition a set cannot contain the same element more than once so multiple requests for the same resource get combined into one. Catalogues can do other clever things to like resolve naming conflicts that might occur due to a sufficiently complex level format.

Once the level has been parsed into these structures you send off the batched up requests to the various resource subsystems. Those subsystems could just iterate through loading the resources and setting them up appropriately as each request describes.

This has several benefits over the 'classic' resource manager design. Since my resource managing systems know about their resources up-front it means they can use optimistic allocation policies that allocate just enough space first time round and also guaranteeing a fixed position in memory for each resource. They can prioritise which resources get loaded straight away and which will be queued and loaded whilst the user starts playing. They can optimise the load order to minimise seeking around the HDD/optical disc.

I'm sure there are other benefits too, but it's very late/early for me here. I thought it worth sharing that possible design at least.

Share this post


Link to post
Share on other sites
Do you also unload unneeded resources? Since it's a 2D platform game I'm making, I doubt the resources will take up that much mememory from the core resources like all the sprites. But then again I'm making the estimate based on the png and gif images I have made. In BMP format the images might take much more video memory.

Share this post


Link to post
Share on other sites
1. Come up with a cheap solution: make a global std::map and preload all the data into it.
2. Use the images in your game code and just refer to that global std::map.
3. If the game lags, refactor the code at fault into a better implementation.

This will land you your first games very well, because you will otherwise start overengineering things and make 0 progress at your game.

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