Accessible Object Storage In a Game Engine

Whether you're a newbie or an experienced programmer, any questions, help, or just talk of any language will be welcomed here.

Moderator: Coders of Rage

Post Reply
User avatar
THe Floating Brain
Chaos Rift Junior
Chaos Rift Junior
Posts: 284
Joined: Tue Dec 28, 2010 7:22 pm
Current Project: RTS possible Third Person shooter engine.
Favorite Gaming Platforms: PC, Wii, Xbox 360, GAME CUBE!!!!!!!!!!!!!!!!!!!!!!
Programming Language of Choice: C/C++, Python 3, C#
Location: U.S

Accessible Object Storage In a Game Engine

Post by THe Floating Brain »

Good day,

I was thinking about the most efficient way to store objects (game objects (entities), components, levels) in my game engine.
So far what I have is the basic concept of storing them as a static member of the main base class.
This would make it easy for all the objects to access resources easily without the mess of pointers
(like my last game engine), as for the implementation of this my thoughts so far have led up to a std::map of
strings and vectors to store everything. For example:

Code: Select all

//Everything in the engine will inherit from Dummy.//
struct Dummy
{
   //Stuff.//

   //Is this a core?//
   virtual bool IsCore() {
      return false;
   }
};

struct Core : public Dummy
{
   //Mostly virtual methods, and some data.//

   //IMPORTANT DATA: //

   /*A "type ID" will be assosaited with the
   heirarchy branch that the particular class instance
   is a part of, for example: "component", "entity", "level".*/

   std::string typeId;

   /*A compID, is used to specify a particular subclass, while and id
   is used to specify a specific class-instance (object).*/

   unsigned int compId, id;

   //////////////////////////
   //The code in question.//
   /////////////////////////

   static std::map< std::string, std::vector<Dummy*> > cache;

   //This is a instance of core.//
   bool IsCore() {
      return true;
   }

   //Cast a Dummy pointer to Core pointer and return it so it can be processed.//
   Core* CastToCore( Dummy* core ) {
      //Stuff.//
   }
};


class Entity : public Core
{
   Entity() {
      typeId = "Entity";
      compID = 0;
      id = 0;
   }
};

//Example of how this would be used.//

int main()
{
   /*Imagine this for components, more 
   entities, sub-classes of entities and components, levels ect.*/

   Core::cache[ "Entity" ].push_back( new Entity );

   return 0;
}
However I am not convinced it is the most efficient and or stable (stable being the keyword here I need more
stability in my engine) method of going about this. Does anyone have a better idea? How do you do it in your
game and or game engine?

Thanks for reading!

P.s Please tell me if it is too much code. Thanks :-)
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself

ImageImage
User avatar
dandymcgee
ES Beta Backer
ES Beta Backer
Posts: 4709
Joined: Tue Apr 29, 2008 3:24 pm
Current Project: https://github.com/dbechrd/RicoTech
Favorite Gaming Platforms: NES, Sega Genesis, PS2, PC
Programming Language of Choice: C
Location: San Francisco
Contact:

Re: Accessible Object Storage In a Game Engine

Post by dandymcgee »

THe Floating Brain wrote:However I am not convinced it is the most efficient and or stable (stable being the keyword here I need more
stability in my engine) method of going about this.
I think you would do well to start by answering some simple questions:

Why do you need more stability in your engine, what about your engine is unstable as it is currently?
Would your proposed solution fix all known stability issues? If so, what is it exactly that causes you to doubt it will work?
If there are no doubts, and you believe it fixes all current issues, then why are you still looking for alternatives?
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches! :twisted:
qpHalcy0n
Respected Programmer
Respected Programmer
Posts: 387
Joined: Fri Dec 19, 2008 3:33 pm
Location: Dallas
Contact:

Re: Accessible Object Storage In a Game Engine

Post by qpHalcy0n »

Dandy is essentially right on. You need to answer some very significant questions primarily about the access patterns of the objects.

*Are the objects tied to static loadable assets (textures, models, etc...)? Eg: Are they a resource??
*What are the access patterns of the objects? Do they need to be accessed multiple times per frame? Are they spatially partitioned? How many are there? Is fast access an issue? Are they large (see sorting)?
*What is a "main base class"? ;)
*Who should see them?
*Who should access them? (privilege levels) ?

Be careful w/ std::map. Map will fall flat on its face under certain circumstances (and I mean HARD...we're talking atrocious). There may be a much better suited data structure for the objects. This will also depend on the nature of the objects themselves and what role they play in the game/engine.

You're getting into DESIGN choices here and straying away from programming concepts. The design, structure, and algorithm always supercede the code. Disregard the inheritance model until it becomes apparent that it is necessary. Stay away from the compiler and start answering these questions.
User avatar
THe Floating Brain
Chaos Rift Junior
Chaos Rift Junior
Posts: 284
Joined: Tue Dec 28, 2010 7:22 pm
Current Project: RTS possible Third Person shooter engine.
Favorite Gaming Platforms: PC, Wii, Xbox 360, GAME CUBE!!!!!!!!!!!!!!!!!!!!!!
Programming Language of Choice: C/C++, Python 3, C#
Location: U.S

Re: Accessible Object Storage In a Game Engine

Post by THe Floating Brain »

Thank you both for your responses! :mrgreen:

To dandymcgee

Current Instability:

From a Run-Time Perspective:
Memory is not well handled, a lot of miscellaneous data does not get deleted, additionally about 1/5 times the engine crashes due to a vector subscript out of range, or about 1/30 times due to a pure virtual call. Finally I implemented a quick fix so some objects flicker, this "quick fix" and all the other issues are do to a poor method of storing and managing objects.

From a Programming Perspective:
Currently some of the basic functions (Instantiate(), InstantiateLevel(), AddSprite(), ect. )are "finicky", and objects get deleted and allocated for reasons unknown to the programmer (me).

Besides these issues the engine is in alpha and is fully functional (sorta :lol: ).

The Proposed Solution:

Would your proposed solution fix all known stability issues? If so, what is it exactly that causes you to doubt it will work?

What Do I Think This Proposed Solution Will Do?:
I believe this solution will keep objects in one place and allow them to be accessed easily. I think it is much better than having a singleton within a singleton, and having a vector for each different render-type (sprite, vector-graphic, polygon) and another for collidable areas stored within the "internal" singleton, and having a vector for levels, and another for entities, with yet another vector for render-layers within the "upper-singleton"). XD

What Doubts Do I Have?:
Like my last solution it is very cohesive, if something goes screwy in the singleton, everything goes screwy.
Also I do not know if it will be fast enough, and again, I do not know if it will be stable enough, anything accessing and or writing to it will have to be completely synchronized.

----------

To qpHalcy0n

*Are the objects tied to static loadable assets (textures, models, etc...)? Eg: Are they a resource??

Yes, some are and will be, sub-classing is allowed in my engine so anything is possible.

*What are the access patterns of the objects?

Everything But an Entity:

Code: Select all

Find typeId
Sort through the vector for the compId
Is it the correct compId and id? Then return it.
Entity:

Code: Select all

Find typeId
Sort through the vector for the compId
Is it the correct compId and objId and id? Then return it.
Anything must be able to access everything else.

* Do they need to be accessed multiple times per frame?

90% of the time yes.

* Are they spatially partitioned?

If you mean randomly instantiated and added to the vector; yes.

* How many are there?

There can be from 0 to as many as the computer can hold.

* Is fast access an issue?

Yes.

Are they large (see sorting)?

Unknown; my engine allows sub-classing so they could be of any variable size.

*What is a "main base class"?

The Core class, sorry that is how I think of it in my head.

*Who should see them?

Everyone, and everything.

*Who should access them? (privilege levels) ?

Everyone, and everything.

I should add I am planning on adding objects within objects within objects...
qpHalcy0n wrote:
Be careful w/ std::map. Map will fall flat on its face under certain circumstances (and I mean HARD...we're talking atrocious). There may be a much better suited data structure for the objects. This will also depend on the nature of the objects themselves and what role they play in the game/engine.
That sounds scary, so I agree there is probably a better data structure I can use, I just liked the idea of being able to access an element through a string. Also the objects essentially do everything.
qpHalcy0n wrote: You're getting into DESIGN choices here and straying away from programming concepts. The design, structure, and algorithm always supercede the code. Disregard the inheritance model until it becomes apparent that it is necessary. Stay away from the compiler and start answering these questions.
Thank you! That has been what I have been doing for the most part

Concept -> General Algorithm -> Will it fit into code? -> Implementation.

Il try to think a bit more in algorithms now though :-)
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself

ImageImage
qpHalcy0n
Respected Programmer
Respected Programmer
Posts: 387
Joined: Fri Dec 19, 2008 3:33 pm
Location: Dallas
Contact:

Re: Accessible Object Storage In a Game Engine

Post by qpHalcy0n »

Given your answers it sounds like you want to have your cake and eat it too.

You really need to think of the ramifications and the outcomes of some of those particular problems.
User avatar
THe Floating Brain
Chaos Rift Junior
Chaos Rift Junior
Posts: 284
Joined: Tue Dec 28, 2010 7:22 pm
Current Project: RTS possible Third Person shooter engine.
Favorite Gaming Platforms: PC, Wii, Xbox 360, GAME CUBE!!!!!!!!!!!!!!!!!!!!!!
Programming Language of Choice: C/C++, Python 3, C#
Location: U.S

Re: Accessible Object Storage In a Game Engine

Post by THe Floating Brain »

qpHalcy0n wrote:Given your answers it sounds like you want to have your cake and eat it too.

You really need to think of the ramifications and the outcomes of some of those particular problems.
Yaaaaa, I have never been good at this part, I can get everything else to run fine but, instantiation, object storage and de-allocation is always a mess.

In my head I try to run simulations basically saying to myself:

Okay x is my current solution, it will work on: y, z and adds w, to the list too,
but wait what if I want to do t, to w, then what happens... (goes on to make some solution).

If you (or anyone) wouldn't mind, could you share some patterns for this sort of thing? Also how do you (or anyone) think this will hold up so far (replacing std::map)?

Basically I need to handle tons of arbitrary data (mostly it can be catorgorized into entities, components, and levels; however there are other things that may be necessary to add such as "render layers" which other objects will need access to and vise versa) and every object needs access to everything else in a speedy, simple, functional, and stable manner.
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself

ImageImage
User avatar
dandymcgee
ES Beta Backer
ES Beta Backer
Posts: 4709
Joined: Tue Apr 29, 2008 3:24 pm
Current Project: https://github.com/dbechrd/RicoTech
Favorite Gaming Platforms: NES, Sega Genesis, PS2, PC
Programming Language of Choice: C
Location: San Francisco
Contact:

Re: Accessible Object Storage In a Game Engine

Post by dandymcgee »

THe Floating Brain wrote: Memory is not well handled, a lot of miscellaneous data does not get deleted, additionally about 1/5 times the engine crashes due to a vector subscript out of range, or about 1/30 times due to a pure virtual call.
These don't sound like the kinds of problems you're going to fix by simply reworking some engine architecture. These are problems directly related to poor programming practice and carelessness. You should NEVER be attempting to access a non-existent subscript of a vector, and with the proper checks you never will. Not deallocating memory is a huge deal, and can be the cause of all sorts of problems down the road.

The most elementary way to check this is to go through your code and find every instance of the word "new". Now ask yourself: Where are the resources that were just allocated being freed?
If they're not being freed, you need to write some code to do so.
If they are being freed, but you don't like where or how this is implemented, then and only then does it become a matter of altering architecture and design decisions.
In the worst case, you are unsure as to whether or not the resource is being freed, in which case your code base is likely a train-wreck of a mess and you need to do some serious stepping back and studying up on memory management in C++.
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches! :twisted:
Rapid Cube
Chaos Rift Newbie
Chaos Rift Newbie
Posts: 22
Joined: Mon Mar 14, 2011 11:43 pm
Programming Language of Choice: C++

Re: Accessible Object Storage In a Game Engine

Post by Rapid Cube »

If you're having problems with memory management you could always start using std::shared_ptr / std::unique_ptr.
User avatar
THe Floating Brain
Chaos Rift Junior
Chaos Rift Junior
Posts: 284
Joined: Tue Dec 28, 2010 7:22 pm
Current Project: RTS possible Third Person shooter engine.
Favorite Gaming Platforms: PC, Wii, Xbox 360, GAME CUBE!!!!!!!!!!!!!!!!!!!!!!
Programming Language of Choice: C/C++, Python 3, C#
Location: U.S

Re: Accessible Object Storage In a Game Engine

Post by THe Floating Brain »

Thank you both for your answers!

To dandymcgee:

You are probably right, I had to finish the engine in a hurry, so my impression on it is a big jumbled mess. And in all honesty I do not know where half of the memory is going, not because I dont understand memory managment, but because I never (had the time to) kept seriose track. Some of it is freed, some is not, and I dont like how everything is stored, and accessed. My engine assumes:

A:
A vector will NEVER be sorted, jumbled ect.
B:
A vector will have some erases at any point.
C:
A vector will ONLY allocate onto the end of itself (.push_back, not .insert).

and hence implments a disfunctonal system of keeping lists of vector elements and keeping
track of everything that is deleted and the size of the vector.

Its buggy as heck and it works horrifically.

However as you can probably tell the engine was "coded" as opposed to "programmed", so in the face of all this and
the likelyness of adding a lot of new features I must ask myself, do I debug a really buggy, mostly uncommented engine, with some good concepts I could carry over into another one when I dont even know half of the bugs (I could release a beta), and port it; or do I re-write an entire engine with the new features that is "programmed" not "coded"?

To Rapid Cube

I have recently been considering it.

Edit:

Please keep in mind I wrote this at 2 AM and turning my head was making me dizzy. :lol:
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself

ImageImage
User avatar
dandymcgee
ES Beta Backer
ES Beta Backer
Posts: 4709
Joined: Tue Apr 29, 2008 3:24 pm
Current Project: https://github.com/dbechrd/RicoTech
Favorite Gaming Platforms: NES, Sega Genesis, PS2, PC
Programming Language of Choice: C
Location: San Francisco
Contact:

Re: Accessible Object Storage In a Game Engine

Post by dandymcgee »

Last I knew the term coded was not synonymous with memory leak. :nono:
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches! :twisted:
User avatar
THe Floating Brain
Chaos Rift Junior
Chaos Rift Junior
Posts: 284
Joined: Tue Dec 28, 2010 7:22 pm
Current Project: RTS possible Third Person shooter engine.
Favorite Gaming Platforms: PC, Wii, Xbox 360, GAME CUBE!!!!!!!!!!!!!!!!!!!!!!
Programming Language of Choice: C/C++, Python 3, C#
Location: U.S

Re: Accessible Object Storage In a Game Engine

Post by THe Floating Brain »

dandymcgee wrote:Last I knew the term coded was not synonymous with memory leak. :nono:
I am not trying to relate the two (in general).
What am saying is in this situation I "coded" the engine, and I believe doing so was a bad decision because I never considered the architecture fully; hence ending up with lists of indexes, which in-turn do not work well and have things like memory leaks. Also I couldn't keep good track of memory leaks because I had limited time to complete the engine.
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself

ImageImage
User avatar
dandymcgee
ES Beta Backer
ES Beta Backer
Posts: 4709
Joined: Tue Apr 29, 2008 3:24 pm
Current Project: https://github.com/dbechrd/RicoTech
Favorite Gaming Platforms: NES, Sega Genesis, PS2, PC
Programming Language of Choice: C
Location: San Francisco
Contact:

Re: Accessible Object Storage In a Game Engine

Post by dandymcgee »

THe Floating Brain wrote: I am not trying to relate the two (in general).
What am saying is in this situation I "coded" the engine, and I believe doing so was a bad decision because I never considered the architecture fully; hence ending up with lists of indexes, which in-turn do not work well and have things like memory leaks. Also I couldn't keep good track of memory leaks because I had limited time to complete the engine.
Perhaps you meant "programmed" vs. "engineered". Engineering is a process which involves much more than simply writing code. ;)
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches! :twisted:
User avatar
THe Floating Brain
Chaos Rift Junior
Chaos Rift Junior
Posts: 284
Joined: Tue Dec 28, 2010 7:22 pm
Current Project: RTS possible Third Person shooter engine.
Favorite Gaming Platforms: PC, Wii, Xbox 360, GAME CUBE!!!!!!!!!!!!!!!!!!!!!!
Programming Language of Choice: C/C++, Python 3, C#
Location: U.S

Re: Accessible Object Storage In a Game Engine

Post by THe Floating Brain »

Now that I look at the definitions yes :) that is just the way it was put to me.
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself

ImageImage
Post Reply