Game Engine Design

Started by
6 comments, last by Rob Loach 20 years, 5 months ago
I''ve been developing an engine using Allegro for the past week or so, and I (once again) made the mistake of not writing out the design on paper before coding. So, now I''m re-working it and wondering about how the final product should look like. Which do you guys prefer? (If your prefered method is not up there, then please tell me about it!) The goal of the engine is to make it as script-kiddie compatible as possible. Method #1:

int PlayerBitmap;
PlayerBitmap = Engine.LoadBitmap("picture.bmp");
PlayerSprite.SetBitmap(PlayerBitmap);
Engine.Renderer.AddSprite(PlayerSprite);
Engine.Renderer.Render(); 
Method #2:

BITMAP *Bitmap;
Bitmap = Engine.LoadBitmap("picture.bmp");
PlayerSprite.SetBitmap(Bitmap);
PlayerSprite.Render(); 
Method #3:

PlayerSprite.SetBitmap("picture.bmp"); //Loads it automatically if it isn''t already loaded
Engine.Renderer.AddSprite(PlayerSprite);
Engine.Renderer.Render(); 
Method #4:

PlayerSprite.SetBitmap("picture.bmp"); //Loads it automatically if it isn''t loaded already
PlayerSprite.Render(); 
I personally think that method 3 is the most script-kiddie compatible at the momment. What do you guys think? If you think of another way of doing it, PLEASE SPEAK UP! Rob Loach
Website: Over-Development
Current Project: Pong, The First

"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed."
- The Boondock Saints
Rob Loach [Website] [Projects] [Contact]
Advertisement
Here's how I do it. I have an object called spriteInfo. Then I have a spriteHandler which contains a linked list of these spriteInfos. I never touch the linked list, as it is used to sort sprites front to back. I merely return a pointer to one of these objects and play with that. My call goes something like this.

spriteInfo* playerSprite = spriteHandlerObj.addSprite("picture.bmp");

Now i can do something like

playerSprite->x = 3;
playerSprite->sclY = 2;
playerSprite-> bla bla bla

And you wouldn't want render right after adding the sprite, or you would be adding a sprite every frame.

--Vic--

The future of 2D game development:
Flat Red Ball

EDIT: Guess I should add, my addSprite creates a sprite in memory, and then searches to see if I have that specific texture already loaded. If so, it just sets the sprite's texture to that texture. if not, it loads it up, and then I'm set. Some might argue that takes too much time, which is why I have a "performance" version of the function which will only work if you pass an already loaded texture, and the sprite it returns is premade at compile time. I have 1000 or so precreated sprites ready for action. Very good for particles.

[edited by - Roof Top Pew Wee on November 16, 2003 12:35:15 AM]
Method 3. I have found it is generally a good idea to have a Renderer object render everything that needs rendering instead of each object rendering itself. Having a general purpose renderer leads to a more efficient rendering process as it is easier to sort objects by state to minimize state changes and other such good things.
If you want to make your code re-usable for linux or other OS''es, you might want to make an abstract base-class for "bitmap" first, and couple it to your engine

So you get something like:
class CBitmap{    CBitmap();    ~CBitmap();    virtual Load(const char* file) = 0;    // ...} 


In this case, "CBitmap" is universal, now you can use this abstract base class to make a CWindowsBitmap or a CLinuxBitmap, with each their own loading code.
Abstract base classes are really great to use, you just use google on that if you didn''t do that already. Template classes are great too, they allow you to set the commonly used variable type on class-creation.
Eg. if you want to make a color, but for the first application all color values have to be floating point numbers you do:
CColor floatcolor;
But if you want the color to be a regular bit-wise color:
CColor bitColor;


"My basic needs in life are food, love and a C++ compiler"
[Project AlterNova] [Novanet]
[www.LifeIsDigital.net - My open source projects and articles.
quote:If you want to make your code re-usable for linux or other OS''es, you might want to make an abstract base-class for "bitmap" first, and couple it to your engine


Allegro _is_ cross platform (Win, Dos, MacOS, MacOSX, Linux, BSD...) so therefor an Allegro BITMAP _is_ cross platform.
quote:Original post by nonnus29
quote:If you want to make your code re-usable for linux or other OS''es, you might want to make an abstract base-class for "bitmap" first, and couple it to your engine


Allegro _is_ cross platform (Win, Dos, MacOS, MacOSX, Linux, BSD...) so therefor an Allegro BITMAP _is_ cross platform.


Oh I see, didn''t know that! I personally like to write that kind of code myself, because it often fits the project better (in my case).

"My basic needs in life are food, love and a C++ compiler"
[Project AlterNova] [Novanet]
[www.LifeIsDigital.net - My open source projects and articles.
quote:Original post by Roof Top Pew Wee
Here''s how I do it.

spriteInfo* playerSprite = spriteHandlerObj.addSprite("picture.bmp");

Now i can do something like

playerSprite->x = 3;
playerSprite->sclY = 2;
playerSprite-> bla bla bla


So, in your linked list of sprites, would the node object be:

typedef struct SpriteNode{    rA1Sprite SpriteObject;    SpriteNode * nextNode;} 

Or
typedef struct SpriteNode{    rA1Sprite * SpriteObject;    SpriteNode * nextNode;} 
Rob Loach [Website] [Projects] [Contact]
Definitely use the second struct. This enables you to better manage your sprites. I would suggest having a ''sprite manager'' which is responsible for the creation and deletion of sprites, and then you just assign the pointer returned into the node. Think of it this way-> the node just references the sprite, it does not own the sprite so it should be a pointer.

James

This topic is closed to new replies.

Advertisement