Well I was thinking about making a Singleton object in my program that contains in a hashmap (or other associative container) where the key is a string (or numerical ID) and the value is an object that is both a factory that creates the object specified by the key (for example "Thread", "Goblin", "Socket" or any other object used by the program) and a container that holds all the objects it contains. Since it''s a Singleton and thus globally accessible, every object in the program can ''request'' access to any object held in this object. It would be useful for DLL-plugins, which can access any data created with this object. Now, what I was wondering was wether it was ugly oo design to give global access to every game-object? Or rather, is this entire idea bad oo design? Gyzmo ======================= Meddle not in the affairs of dragons for you are crunchy and go well with toast.

---- BEGIN QUOTE ----
Now, what I was wondering was wether it was ugly oo design to give global access to every game-object?
----- END QUOTE -----

Yes and no. I believe that some things, like a game-world, are just better when implemented as global variables. However, writing functions that manipulate these variables directly can lead to a design disaster.

For example, if you write a routine to perform transformation on objects, pass the global variables as parameters instead of hard-coding them in. You''ll be able to use this function on other model data later on.

Will your factory/container be able to handle multithreaded access? That might be a problem for a global access factory. You''ll have to be careful of that case. Other than that, i dont think there is anything wrong with a centralized global entity factory. I use several global factories as well to create my entites and other game objects such as packets, etc.. Though i would suggest implementing a form of refrence counting for the entities, it will make object management and deletion easier in the future.

Good Luck

-ddn

I''m still considering wether to make it thread-safe, I might though and make the functions that create/modify lock access to all functions (both reading and writing). And I will implement reference counting. I was thinking of creating a DLL/SO-template that creates a pointer to an object of the common base-type(which at least has functions for retrieving it''s type-ID and creating itself) which are stored in my container factory so new classes can be added dynamically (and without recompiling).

Also what I might do is instead of creating an actual factory is that each type-ID has a handle to the DLL/SO and let a function contained in the DLL create the objects. That wouldn''t require separate factory-objects inside the container factory...

Gyzmo
=======================
Meddle not in the affairs of dragons for you are crunchy and go well with toast.

''Megafactory''
''Omnifactory''
''Borgactory''?
ah here we go, Monolith

May as well do reference counting & garbage collection.
And thread-safe seems the way to go, you wouldn''t need such a monolith in a single thread app would you?

Magmai Kai Holmlor
- The disgruntled & disillusioned

Well the reason I just might implement thread safety is because it is slow. Since I''ll use STL as container for all data it IS thread safe in a per-object manner (i.e. it is thread safe as long as I don''t access the SAME container at the same time). I have some ideas for a perfectly thread safe queue without using any synchronisation. Using this queue I could make a seperate container-access-thread which would handle all accesses to a container(in a request based manner, i.e. a request is made to the thread (added to queue) and the container-access-thread handles each request sequentially, both input and output).

As for a name, how about Überfactory

Gyzmo
=======================
Meddle not in the affairs of dragons for you are crunchy and go well with toast.

quote:

---

As for a name, how about Überfactory

---

LMAO

crictical sections are not all that slow, as least not realy so bad as mutex etc...

My understanding was that STL contained no syncronization whatsoever (it would a serious portability issue if it did.)
What if a read was placed inline, right after a write - I think it fail if the object requested was just added to the queue - and it could take up to 10ms before it would be available.

If you make it thread safe (maybe add a compiler directive to turn it off or on?), you should probably use cs''s in the data access routines...

Cool idea, Gyzmo. It sounds elegant and mod-able. In fact, the way that things are named could make networking easy... And yes, I think it's nice OO design and not evil




Edited by - SHilbert on January 28, 2001 10:58:44 AM

Your design seems to be somewhat similar to mine.
Let me start off by saying that you might want to reconsider
making your factories global. There should always be a well defined place within the application where objects are created.
In my game, I have a creator agent, which receives requests, from objects to create things for them. The agent is the only object which has access to the factories. This insulates the game from creation methods, and makes it more flexible. Furthermore you can add creation conditions and rules later on, without recompiling, be replacing the agent with a derived agent.

Let me point you in the direction of a great CUJ(C/C++ Users Journal) article that helped me quite a bit. The November 2000 issue, contained an article called ''Better Object Factories'' by Early Ehlinger, which seems to cover what you are talking about. If you can''t get your hands on the issue, you can always downlaod the source from www.cuj.com and study it.

Hope this helps.



type entity
[
dynamic cmd_interface:
cmd c,
object o=0
[
if:c
call_remote[c,o];
]void;
]

quote:

---

Original post by archetype

Your design seems to be somewhat similar to mine.
Let me start off by saying that you might want to reconsider
making your factories global. There should always be a well defined place within the application where objects are created.
In my game, I have a creator agent, which receives requests, from objects to create things for them. The agent is the only object which has access to the factories.

---

Well, that was sort of the idea, i.e. you call:

MyObject = UberFactory::GetInstance()->CreateNewObject("MyObject");

well, at least something like that, the thing will first check if there is a factory contained in the UberFactory which can create a "MyObject" and than let the factory do the rest, and wheteher factory is something simple, or something derived from the basic Factory is all up to the one who creates the factory.

Gyzmo
=======================