Setting up the game engine cleanly
Author
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.
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.
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.
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_Hclass Game{public: Game(); ~Game(); bool init(); void start();private:};extern Game game; // in game.cpp this is declared.#endifAnd the game.cpp would then start as
// game.cpp#include "game.h"// declare the global instance that we will useGame 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.
Author
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...
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...
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.
Quote:Original post by illThat's called refactoring, and you shouldn't be afraid to do it.
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.
(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)
Quote:Original post by nbI read it that way too initially, but I think this:Quote:Original post by KulSeranActually I think your interpretation of the obligatory "make games not engines" statement is backwards.
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.
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).
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.
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.
Author
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
