Page 1 of 1

[SOLVED]Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 7:41 pm
by Sanshin77
Yes, I know I've been posting a few different posts and questions tonight, but hey, I'm working on my first engine/framework and it's not easy. This topic has been brought up in different threads and I've read some of you guys' views on this, but I'm still not certain on how to do this.

I'm using a mac and SDL for this, but this is really a cross-platform/cross-library subject so don't worry about the mac part. I know SDL isn't that great for drawing but I want to get comfortable with it before moving on to SDL+OpenGL. Thanks to avansc and his video, I was able to set up a static library in a nice way inside XCode.

I want to have a simple and clean setup, this is a pretty simple 2D project and doesn't require as much drawing, math or physics code as bigger 2D/3D projects like Elysian Shadows or GroundUpEngine. I have no intention of implementing advanced collision detection and physics.

This is what I have so far:
zaCoreLib.h (constants, includes, typedefs, enum and pointer to screen surface)
^
zaCoreFunc.h (basic initialization, surface loading, drawing and quit function)
^
zaEngine.h (Nothing Implemented here yet)
^ (Includes)
(User)
Things I need:
Better graphics handling - Textures, spritesheets and animation
Input and SDL_Event handling - Keyboard, Mouse, main loop
My own math functions - average, simple 2D non-oriented rectangle collision, random number generator and more
Sound - Sound effects and music
GUI - GUI, buttons and text
(Window class ?)

I know how to implement, and have implemented most of these "components" in different projects before, but I have no idea how to structure this in a good way.

Some important concepts:
Math functions will be accessed from almost every part of the engine/framework, as well as the executable(s)
Communication between Graphics<->Input<->GUI

So, here are my questions:
1. Should all of these be classes? To me it seems more reasonable to have the math part as just a collection of functions, how about the others?
2. Should any of these classes be implemented as singletons? Where does the user of my framework access these objects and when are they created?

Re: Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 8:38 pm
by Falco Girgis
This is programming related. It shouldn't be here. I'm moving it.

Re: Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 9:14 pm
by GroundUpEngine
1. You have a good idea from what I see, to answer your question they should all be classes linked to the Engine/Framework core but don't make an unnecessary classes if it's gunna end up with one function.

2. Stay away from singletons unless it's for a Debug/Log class or similar, there actually pretty messy and bad pratice from what I've learned recently.

I always stay by this basic structure, also I would reccomend splitting up what you have & what your gonna implement into something like this ->

Was bored! So I took my Engine's Hierarchy, took some stuff out and changed some stuff around :lol:
Image

Engine/Framework Core would be - zaEngine
~It would include all your main classes
~It would handle everything

General would be - zaCoreFunc
~It would include dependencies
~It would have general functions or whatever
#Get rid of any graphical functions, put them in Graphics classes below

Graphics would be - Sprites, Spritesheets, Animation, GUI, etc... (Class for each)
~Setup and use of Assets
~Rendering but this could be done in the Engine core
~The GUI class could use the Input class in a Function e.g. button clicks

Game Elements would be - Audio, Texture, etc... (Class for each)
~Loading and Storage of Assets
~Play and Pause or whatever

Logic would be - Math, Collision, etc... (Class for each)
~Functions of General Maths in one class
~Collision Specific Maths in the other

Window & Input would be - Keyboard, Mouse, etc... (Class for each)
~Function for Reading Keys and pass an argument like "W"
~Then a Function for Mouse e.g. pass "Left" for example

Clean and Simple ;)

Re: Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 9:52 pm
by Sanshin77
@GroundUpEngine - Wow, that is indeed helpful, thanks alot!

The zaEngine.h file would look like this then?:(w/o inclusion guards)

Code: Select all

#include "zaGraphicsEngine.h"

class zaEngine
{
public:
	zaGraphicsEngine Graphics;

private:

};
And then repeat for all the other classes?
Also where do I create the object If I'm not gonna use singletons? A global? Or does the users create one in their main() functions?

Re: Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 10:20 pm
by GroundUpEngine
No prob :)

Dun use singletons you wont really need them, So ye the Engine Core does include your Graphics class, same with other classes. So you something like ->

Code: Select all

zaEngine::zaEngine()
{
    Graphics = new zaGraphics;
}

//example of use
zaEngine::DrawPlaya(Sprite &Sprite)
{
    Graphics->DrawSprite(Sprite);
}

Re: Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 10:34 pm
by Sanshin77
GroundUpEngine wrote:No prob :)

Dun use singletons you wont really need them, So ye the Engine Core does include your Graphics class, same with other classes. So you something like ->

Code: Select all

zaEngine::zaEngine()
{
    Graphics = new zaGraphics;
}

//example of use
zaEngine::DrawPlaya(Sprite &Sprite)
{
    Graphics->DrawSprite(Sprite);
}
Nice. So you just create the instance of the engine class in your main() then ?

Like this?

Code: Select all

int main(){
    zaEngine* pEng = new zaEngine;

    zaEngine->DoSomething();
    zaEngine->Quit();
}
Or do you create the instance somewhere else?

Re: Structuring my 2D game engine/framework

Posted: Fri Mar 12, 2010 10:48 pm
by GroundUpEngine
Yes and no, if your just testing the engine/framework then put it in main, but if you making a game I would use a base class like this->

main.cpp

Code: Select all

#include "Game.h"

int main(){
    Game* ye = new Game;

	ye->Init("zaEngine");
	ye->Run();

	delete ye;

    return 0;
}
Game.h

Code: Select all

#include "zaEngine.h"

class Game
{
  private:
	// Variables //
	zaEngine* Engine;
	bool Done;

  public:
	Game()
	{
		Engine = new zaEngine;
	}
	~Game()
	{
	}
	void Init(string Title = "Default Title")
	{
		Engine->Initialize(Title);
		Done = false;
	}
	inline void Draw()
	{
		// Draw Graphics //
	}
	void Run()
	{
		while(!Done)
		{
			Draw();
		}
		Quit();
	}
	void Quit()
	{
		Engine->Shutdown();
	}
};

Re: Structuring my 2D game engine/framework

Posted: Thu Mar 18, 2010 2:04 pm
by Sanshin77
GroundUpEngine wrote: Image
@GroundUpEngine:
Hey, I've implemented some text manipulation stuff, like convertion string<->int. Where would I put this? General(CoreFunc) or Logic?

Re: Structuring my 2D game engine/framework

Posted: Thu Mar 18, 2010 2:16 pm
by hurstshifter
GroundUpEngine wrote:
Dun use singletons you wont really need them, So ye the Engine Core does include your Graphics class, same with other classes. So you something like ->

Code: Select all

zaEngine::zaEngine()
{
    Graphics = new zaGraphics;
}

//example of use
zaEngine::DrawPlaya(Sprite &Sprite)
{
    Graphics->DrawSprite(Sprite);
}
This description has replaced a lightbulb in my brain that had since been extremely dim. Handling the engine this way makes perfect sense. Thanks for the info groundup

Re: Structuring my 2D game engine/framework

Posted: Thu Mar 18, 2010 2:28 pm
by GroundUpEngine
Sanshin77 wrote: @GroundUpEngine:
Hey, I've implemented some text manipulation stuff, like convertion string<->int. Where would I put this? General(CoreFunc) or Logic?
Ye, General
hurstshifter wrote:
GroundUpEngine wrote:
Dun use singletons you wont really need them, So ye the Engine Core does include your Graphics class, same with other classes. So you something like ->

Code: Select all

zaEngine::zaEngine()
{
    Graphics = new zaGraphics;
}

//example of use
zaEngine::DrawPlaya(Sprite &Sprite)
{
    Graphics->DrawSprite(Sprite);
}
This description has replaced a lightbulb in my brain that had since been extremely dim. Handling the engine this way makes perfect sense. Thanks for the info groundup
No prob :)