🔒 Locked

Singletons and Memory Management

Started by Stoic May 28, 2007 at 4:40 AM 40 replies 7.7k views

Original Post

May 28, 2007 at 4:40 AM

Hi all - Recently there has been a lot of discussion about Singletons on the boards, and I've noticed a lot of people are staunchly against them. I think I understand a lot of the arguments, and I'm starting to agree that in general, Singletons are a Bad Idea(TM). However, I'm still not fully convinced that they're _always_ bad, which means I might still be missing something. The two conditions for Singletons being appropriate are - 1) Only one instance is allowed, having multiple instances would be incorrect 2) Global access is required Much of the conversation has been about various major engine components not being appropriate as Singletons. (Logging keeps being brought up as a possible exception) I've been working on a memory manager, and I'm starting to feel like it should definitely be a Singleton, since I'd like to route all allocations through it. Specifically, I feel like the final game system should have a Singleton Primary Memory manager, which would keep track of the heap. The primary logic I'm seeing is that if the whole system is supposed to run out of a single memory pool (like on a console), then it would almost certainly want global access (so everything can use dynamic allocation) and you definitely would want only one (there's only one hardware resource). I know that you could simply "choose" to only instantiate one PrimaryMemory manager, but it feels like it would be wise to have the code enforce it. Is there a problem with this logic? Is there a more appropriate way to handle this than as a Singleton? Anyhow, it is certainly possible that I'm missing some aspect of the discussion against Singletons, and if that is the case, I'd like to clear it up. Thanks for any help!

ToohrVyk

May 28, 2007 at 4:49 AM

Typical questions to decide whether something should be a singleton:

Is there a reason why that something cannot be implemented to have more than one instance? The important element here is about implementation impossibility, and not about how you feel the class should be used. In short, can you implement your manager so that two (or more) can coexist, and if not, why?
Is there a reason why that something should be an object? Are you passing the instance by argument, or keeping references to it, anywhere? In short, why can't you overload operator new and operator delete instead?

Depending on your answers to these questions, your manager should be a new/delete overload, a singleton inheriting from an allocator base class, or a non-singleton class inheriting from the same.

Spoonbender

May 28, 2007 at 7:00 AM

Quote:
Original post by Stoic
I've been working on a memory manager, and I'm starting to feel like it should definitely be a Singleton, since I'd like to route all allocations through it.

How can you be so sure that you're never going to want to use two memory managers, for different purposes?

If you want a globally accessible memory manager, you could just make a regular global instance. Then, if later on, you decide you want to use multiple globally accessible memory managers, you can just create another global instance.
With a singleton, you'd be screwed.

Quote:

The primary logic I'm seeing is that if the whole system is supposed to run out of a single memory pool (like on a console)

Is there any reason why a console must be treated like a single memory pool?
And is there any reason why the memory allocator handling this must be an object? (malloc isn't an object. Just a function. new/delete overloads aren't objects either)

Quote:
and you definitely would want only one (there's only one hardware resource)

So?
What if I say "all addresses below X are handled by this manager, above X by that one"?
There's only one GPU too, but it's certainly possible to have multiple renderers. Or multiple threads on a single-core CPU. That's hardly a valid reason.

Quote:
I know that you could simply "choose" to only instantiate one PrimaryMemory manager, but it feels like it would be wise to have the code enforce it.

What about cout? Do you ever *accidentally* create a new ostream instead of printing to cout? It's not a singleton, but just a global object. I've never heard of anyone accidentally instantiating new ostreams when they just intended to output to cout... [lol]
So does the code really need to enforce that?

Antheus

May 28, 2007 at 8:33 AM

What happens once you need two different memory managers? One for ints, one for dynamic-sized blocks.

What happens once you need 25 different ones. One for ints, one for ints for STL, one for ints allocated within a tight loop, and one for ints used by rendering loop?

Also - what happens once you have two threads? Will you lock every call to the memory manager?

Obviously, these entities will be static and somewhat global in nature. But singletons are never implied, since they don't exist in OO. There is no "only one instance of".

Singletons are appropriate under one circumstance only - they hold invariant state. Your memory manager cannot do that.

Sneftel

May 28, 2007 at 11:15 AM

Quote:
Original post by Stoic
1) Only one instance is allowed, having multiple instances would be incorrect

"Incorrect" is a weaselly term. Incorrect with respect to what? The way in which it can be used? The way in which you intend to use it today? A singleton should only be used if having multiple instances would be (drum roll please) impossible. If the computer simply would not support it. Loggers don't fit that mould. Neither do memory managers, unless you're programming for embedded systems without an MMU.

BTW, the "global access" thing is sort of a red herring, which tends to confuse the issue of singletons. ToohrVyk's criteria are good ones.

Replicon

May 28, 2007 at 1:22 PM

I think something to remember is that when people say "ThisOrThat shouldn't be a singleton", it should be taken with a grain of salt. Their idea of what ThisOrThat looks like is different from yours.

For example, lots of people use the graphics *gulp* "manager" (sorry, couldn't resist hehe) as an example of something that shouldn't be a singleton, and they make arguments like "well how will you support multiplayer?" or "well what if you want two different views into your game?"

But the bottom line is, a "View" into your game is not the same as "the thing that talks to your graphics card." If I have like a graphics driver thing that's an interface to the hardware, and initializing it, in SDL lingo, initializes the video subsystem, there should only be one. You can have several VIEWS into it, but I can't imagine why one instance of a game should have more than one thing talking to the video card. As for multiplayer, your computer won't be rendering to your friend's computer's screen, so each box will have an instance of it. That's still fine. What if you have..... TWO screens? Still one graphics card... What if you have two graphics cards and two screens? ...well is it worth designing that in, for the .1% of people who would benefit from that? I know there are plenty of cases where singletons are abused (e.g. logging, much of the time), but you STILL need to take those arguments with a grain of salt.

Designing for massive extensibility is a great thing, but when it comes down to it, you have to draw the line somewhere and say "vectors of n interfaces to the graphics card aren't supported in version 1.0" or else you'll never get anything done.

ToohrVyk

May 28, 2007 at 1:34 PM

Quote:
Original post by Replicon
For example, lots of people use the graphics *gulp* "manager" (sorry, couldn't resist hehe) as an example of something that shouldn't be a singleton, and they make arguments like "well how will you support multiplayer?" or "well what if you want two different views into your game?"

These are frequent arguments against global variables, and are not really adapted to singletons.

The main argument against 99% of singletons is that there is no reason for these classes to be singletons at all—making them normal classes and creating a global instance of them would achieve the same effect with less overall complexity. In some cases, they shouldn't even be objects: they should be a set of functions.

Stoic

May 28, 2007 at 3:40 PM

Ok, I think I see what you guys are saying. If you don't _have_ to make it a Singleton, don't do it.

Let's see if I understand this properly. In my original design, I was thinking of something like this -

(Assume that you have a non-singleton class called HeapManager, which manages a big chunk of memory for you)

Pseudocode:

class HeapManager{   //interface for managing a heap, allocating, deallocating, etc..private:   unsigned char heapData*;   unsigned long heapSize;   //Additional data for keeping track of allocations -    //  lists, maps, etc.}//Intend to use this as our system's Primary Memory Managerclass TheMemoryManager: public Singleton<TheMemoryManager>{    //wrapper to interface of SystemHeap;    //  maybe some additional Loggingprivate:    //will be the size of say, a console's RAM    HeapManager SystemHeap;};

The design above seems rather sound - if you want multiple heaps, you can simply allocate them through the Singleton(they'll still be contained within the Single original Heap). However, the argument is that it's better to have the HeapManager from TheMemoryManager be a simple global, or perhaps wrapped by overloaded new and delete, right? That way you can still allocate the additional Heap Managers, but you never created the Singleton.

Am I on track here? Sorry to keep beating a dead horse...

Antheus

May 28, 2007 at 3:42 PM

Quote:
For example, lots of people use the graphics *gulp* "manager" (sorry, couldn't resist hehe) as an example of something that shouldn't be a singleton, and they make arguments like "well how will you support multiplayer?" or "well what if you want two different views into your game?"

In Java with the design pattern movement, singletons gained fame overnight. One year after, everyone was ditching them.

Why is it possible, viable and desirable to write a whole Java application without a single singleton? And I'm talking huge applications here. Millions of lines of code (most of it auto-generated, but still).

The only real difference between C++ and Java is Java's implied garbage collection.

So is the lack of garbage collection what makes singletons so apealing?

The true problem comes from "there will only be one". That is what conflicts with OO design, where you have relations between objects. Static or global isn't an issue.

It's also part of culture. Everyone does it. So why risk, and go the other way. And so, the circle is complete. New tutorials are written using singletons, a generations grows up learning from that aproach, writes their own tutorials, using singletons, ....

It's a very important topic about the overall design. Singletons are really simple, convenient - yet their flaws have been demonstrated often. And unfortunately, when relying on 3rd-party software, they are always there.

The irony is, they aren't that evil - it's their overabuse that is.

thre3dee

May 28, 2007 at 3:54 PM

Quote:
Original post by ToohrVyk
Quote:
Original post by Replicon
For example, lots of people use the graphics *gulp* "manager" (sorry, couldn't resist hehe) as an example of something that shouldn't be a singleton, and they make arguments like "well how will you support multiplayer?" or "well what if you want two different views into your game?"

These are frequent arguments against global variables, and are not really adapted to singletons.

The main argument against 99% of singletons is that there is no reason for these classes to be singletons at all—making them normal classes and creating a global instance of them would achieve the same effect with less overall complexity. In some cases, they shouldn't even be objects: they should be a set of functions.

Its funny because theres all these people that believe that you have to remove all accessibility from a project *just* so that you don't have any globals (either as Get* functions or global variables (yuck) or singletons (almost yuck)). But I've been thinking and thinking about this and I seriously can't find any way that you could make a game without having SOMEthing global so that each cpp or DLL can access the shared subsystems. I just don't see the point in going to those great lengths. All it does is lower the usability of the game code. Even if the engine itself is entirely non-global (say a BIG set of free-floating, ready to go systems).

ToohrVyk

May 28, 2007 at 4:21 PM

Quote:
Original post by thre3dee
But I've been thinking and thinking about this and I seriously can't find any way that you could make a game without having SOMEthing global so that each cpp or DLL can access the shared subsystems. I just don't see the point in going to those great lengths.

Receiving any necessary objects as constructor arguments?

If you asked me to think up a global architecture for a game now, I admit that I would be at a loss about where to start. It just doesn't feel natural for me anymore...

rip-off

May 28, 2007 at 4:27 PM

Quote:
Original post by thre3dee
Quote:
Original post by ToohrVyk
Quote:
Original post by Replicon
For example, lots of people use the graphics *gulp* "manager" (sorry, couldn't resist hehe) as an example of something that shouldn't be a singleton, and they make arguments like "well how will you support multiplayer?" or "well what if you want two different views into your game?"

These are frequent arguments against global variables, and are not really adapted to singletons.

The main argument against 99% of singletons is that there is no reason for these classes to be singletons at all—making them normal classes and creating a global instance of them would achieve the same effect with less overall complexity. In some cases, they shouldn't even be objects: they should be a set of functions.

Its funny because theres all these people that believe that you have to remove all accessibility from a project *just* so that you don't have any globals (either as Get* functions or global variables (yuck) or singletons (almost yuck)). But I've been thinking and thinking about this and I seriously can't find any way that you could make a game without having SOMEthing global so that each cpp or DLL can access the shared subsystems. I just don't see the point in going to those great lengths. All it does is lower the usability of the game code. Even if the engine itself is entirely non-global (say a BIG set of free-floating, ready to go systems).

Its quite easy, just pass objects to stuff that needs it. If subsystems have huge amounts of coupling then your design is probably at fault anyway...

[edit: lateness...]

Stoic

May 28, 2007 at 4:35 PM

@thre3dee - There are a number of ways it can be done. For example, your list of possibilities doesn't include global _functions_ (like printf(), for example, or new and delete, which can be overloaded, as we're describing here). Global functions can also have static data, which is kind of like having global data, except that it's only accessible by the function (like private data for a class). This static data can be used to maintain state, which greatly expands the possibilities, almost up to using global data structures.

Also, you could pass pointers to data structures around in functions. This can get messy, though, and a lot of people don't like to do it (myself included).

However, I think it's all really besides the point. Globals aren't evil. Singletons aren't evil, either, it's their misuse that becomes problematic. The biggest problem with globals is that they encourage dependency creep, and it's near impossible to tell when a global variable's state is changing when you get multithreaded. When everyone in the world can see and play with a variable, everyone is a suspect for mishandling it, and you can never count on it being in the same state you left it in before.

However, if you're disciplined in their use, globals can be a good choice for shared data. In fact, every engine I've worked in (3 commercial engines) has used globals for quite a bit.

@Everyone - Up to this point, when asked to describe what a Singleton was, I'd always refer to it as "a managed global of which you can only instantiate a single instance." I still feel like this is a good use for it. Like, I still kind of like the fact that the Author of a Singleton knows that the resulting class will be used as a global, and therefore can take steps to mitigate potential abuses from within the class. Also, the interface to claiming a Singleton drives home the fact to a programmer that they are accessing a global subsystem which has state. If the Singleton isn't going to have any member variables, then it's better to just have a bunch of global functions as services. But if it is going to have member variables, creating a specialized implementation allows you to add threadsafety, logging, specialized encapsulation, etc. It's always felt wrong to me to take an arbitrary class and make a global version of it, but creating a class as a Singleton seems to be a message: "Hey, this class has special significance as a subsystem, everyone's expected to be messing around with its state, just so you know what you're getting into." The fact that the system is global can still lead to all kinds of problems, especially dependency creep. Having bidirectional dependencies between Singletons should definitely be avoided at all costs (just like having bidirectional dependencies between layers of a design).

Hmm, I think this brings me back to the top. Like, I can definitely see that most Singletons don't have to be Singletons, and they're a bad idea most of the time. But I think I'm not experienced enough yet to see why a naked global is better in most cases. I do agree about repacing Singletons with global functions, though.

Promit

May 28, 2007 at 4:46 PM

Note that I only object unconditionally to the pattern as described in GoF and typically of the form T::GetInstance()->Function(). While globals, monostates, all-static classes, and free functions can be very similar, I think they all have their uses once in a while. But that particular design, where the class instantiates itself, inside itself, is stupid and pointless.

ToohrVyk

May 28, 2007 at 4:46 PM

Quote:
Original post by Stoic
But I think I'm not experienced enough yet to see why a naked global is better in most cases. I do agree about repacing Singletons with global functions, though.

Why are not all functions in C++ functors? Because the programmer overhead for a functor is greater than that of a simple function.

Why are not all global variables singletons? Because the programmer overhead for a singleton is greater than that of a simple function. A global is better than a singleton because it's simpler.

But wait, there's more. A singleton is a class which cannot be instantiated more than once. The fact that the unique instance is globally accessible is a mere practical consequence of the basic definition—the one-instance restriction. Because of this, using singletons only for their globality is a misuse: if your primary concern when writing a class isn't that you can't provide more than one instance, then then a singleton is not the solution you're looking for.

thre3dee

May 28, 2007 at 9:01 PM

Quote:
Original post by Stoic
@thre3dee - There are a number of ways it can be done. For example, your list of possibilities doesn't include global _functions_ (like printf(), for example, or new and delete, which can be overloaded, as we're describing here). Global functions can also have static data, which is kind of like having global data, except that it's only accessible by the function (like private data for a class). This static data can be used to maintain state, which greatly expands the possibilities, almost up to using global data structures.

Also, you could pass pointers to data structures around in functions. This can get messy, though, and a lot of people don't like to do it (myself included).

However, I think it's all really besides the point. Globals aren't evil. Singletons aren't evil, either, it's their misuse that becomes problematic. The biggest problem with globals is that they encourage dependency creep, and it's near impossible to tell when a global variable's state is changing when you get multithreaded. When everyone in the world can see and play with a variable, everyone is a suspect for mishandling it, and you can never count on it being in the same state you left it in before.

However, if you're disciplined in their use, globals can be a good choice for shared data. In fact, every engine I've worked in (3 commercial engines) has used globals for quite a bit.

@Everyone - Up to this point, when asked to describe what a Singleton was, I'd always refer to it as "a managed global of which you can only instantiate a single instance." I still feel like this is a good use for it. Like, I still kind of like the fact that the Author of a Singleton knows that the resulting class will be used as a global, and therefore can take steps to mitigate potential abuses from within the class. Also, the interface to claiming a Singleton drives home the fact to a programmer that they are accessing a global subsystem which has state. If the Singleton isn't going to have any member variables, then it's better to just have a bunch of global functions as services. But if it is going to have member variables, creating a specialized implementation allows you to add threadsafety, logging, specialized encapsulation, etc. It's always felt wrong to me to take an arbitrary class and make a global version of it, but creating a class as a Singleton seems to be a message: "Hey, this class has special significance as a subsystem, everyone's expected to be messing around with its state, just so you know what you're getting into." The fact that the system is global can still lead to all kinds of problems, especially dependency creep. Having bidirectional dependencies between Singletons should definitely be avoided at all costs (just like having bidirectional dependencies between layers of a design).

Hmm, I think this brings me back to the top. Like, I can definitely see that most Singletons don't have to be Singletons, and they're a bad idea most of the time. But I think I'm not experienced enough yet to see why a naked global is better in most cases. I do agree about repacing Singletons with global functions, though.

I'm not talking about the way the global is accessed; I don't like global variables (and I've gotten rid of singletons). Global functions are a good way of keeping the variable read-only.

The point I'm trying to get across is the subject of globability itself. People are going on about removing access to systems that are used by many things.

They're saying that I shouldn't be able to access a system that everything needs to access to. For example, a game might have one file system that has the all the archives loaded in, all the codecs you need and the correct setup for most file operations in the game. But people say that you shouldn't be allowed access to it. Now why would I code my game so I can't access a shared system???????????

Sure one specific subsystem might need its own file system setup, so it would then use its own one. But I'm pretty sure that you don't want to setup a new file system for every individual object.

And Stoic said it, I hate bloating constructors and functions with shared system pointers. Its very annoying to code. All it does is take longer to write classes and systems. What if a class uses a whole load of different systems?

This is related to game-specific code not engine code. The engine could have no globality at all - which gives complete control of the systems to the project its being used in. But when your game has a few you-should-all-use-this-already-setup-system systems, then why would you remove access to them?

And for your information, I have already worked in a game dev team which won an asia-pacific indie award (GCAP), so I have an idea of how annoying and stressful coding can get when systems aren't easy to access and use.

Our Game class was global. The fact that we used Ogre and CEGUI gave us a lot of singletons, but the Game singleton gave access to all our in-game systems such as Players and Level classes. They weren't singletons but the Game itself was. It was simple and easy to access the shared classes used by the game.

And so what if theres two render devices? Theres only ever gonna one Game in the Game, and that would give u access to both devices.. Anyone come up with a reason to have two Games objects??????

Spoonbender

May 28, 2007 at 9:33 PM

Quote:
Original post by thre3dee
They're saying that I shouldn't be able to access a system that everything needs to access to. For example, a game might have one file system that has the all the archives loaded in, all the codecs you need and the correct setup for most file operations in the game

And if "everything" needs access to this, it doesn't strike you as bad design?
That's why singletons are bad. They encourage you to design a system where everything depends on everything else, *and you can't even see that it's wrong*.

Quote:

But people say that you shouldn't be allowed access to it. Now why would I code my game so I can't access a shared system???????????

Why would you code your game so it has more shared systems than necessary? Why should everyone have to share (and synchronize access to) a component that is only actually *needed* one or two places?

Quote:
Sure one specific subsystem might need its own file system setup, so it would then use its own one.

If the filesystem is a singleton, just how do you propose to give it a separate one? [wink]

Quote:
But I'm pretty sure that you don't want to setup a new file system for every individual object.

I'm pretty sure not every individual object needs access to the filesystem.
And those *few* that do can get a reference to it in their constructor.

Quote:
What if a class uses a whole load of different systems?

Then it is badly designed, and will, no, *does* cause you problems.

Quote:
And for your information, I have already worked in a game dev team which won an asia-pacific indie award (GCAP), so I have an idea of how annoying and stressful coding can get when systems aren't easy to access and use.

In my experience, singletons are a major cause of annoyance and stress. Reducing coupling and making dependencies explicit (so I can actually *see* which components rely on what) makes the code much easier to write and maintain. Yes, I have to write a few characters extra in some of the constructors (to pass one or two extra references), which takes me all of 0.5 seconds.
On the other hand, I save vastly more time trying to maintain or update the code.

All theoretical arguments about coding style, coupling and dependencies aside, I used to think like you that "Yeah, but apart from everything else, it becomes easier to access my components if they're globals/singletons, so overall, it's less real-world effort for me".

Then I actually tested it. I took an old singleton-infested project and rewrote it using no globals at all, passing references where they were needed. Overall, it was easier and faster to code, and required much less effort, *despite* having to occasionally add an argument to a constructor.

thre3dee

May 29, 2007 at 12:53 AM

Quote:
Original post by Spoonbender
Quote:
Original post by thre3dee
They're saying that I shouldn't be able to access a system that everything needs to access to. For example, a game might have one file system that has the all the archives loaded in, all the codecs you need and the correct setup for most file operations in the game

And if "everything" needs access to this, it doesn't strike you as bad design?
That's why singletons are bad. They encourage you to design a system where everything depends on everything else, *and you can't even see that it's wrong*.

Quote:

But people say that you shouldn't be allowed access to it. Now why would I code my game so I can't access a shared system???????????

Why would you code your game so it has more shared systems than necessary? Why should everyone have to share (and synchronize access to) a component that is only actually *needed* one or two places?

Quote:
Sure one specific subsystem might need its own file system setup, so it would then use its own one.

If the filesystem is a singleton, just how do you propose to give it a separate one? [wink]

Quote:
But I'm pretty sure that you don't want to setup a new file system for every individual object.

I'm pretty sure not every individual object needs access to the filesystem.
And those *few* that do can get a reference to it in their constructor.

Quote:
What if a class uses a whole load of different systems?

Then it is badly designed, and will, no, *does* cause you problems.

Quote:
And for your information, I have already worked in a game dev team which won an asia-pacific indie award (GCAP), so I have an idea of how annoying and stressful coding can get when systems aren't easy to access and use.

In my experience, singletons are a major cause of annoyance and stress. Reducing coupling and making dependencies explicit (so I can actually *see* which components rely on what) makes the code much easier to write and maintain. Yes, I have to write a few characters extra in some of the constructors (to pass one or two extra references), which takes me all of 0.5 seconds.
On the other hand, I save vastly more time trying to maintain or update the code.

All theoretical arguments about coding style, coupling and dependencies aside, I used to think like you that "Yeah, but apart from everything else, it becomes easier to access my components if they're globals/singletons, so overall, it's less real-world effort for me".

Then I actually tested it. I took an old singleton-infested project and rewrote it using no globals at all, passing references where they were needed. Overall, it was easier and faster to code, and required much less effort, *despite* having to occasionally add an argument to a constructor.

I didn't say I was using singletons. I'm talking about global-ness itself. Singletons have nothing to do with it. I actually removed all of the singletons in my engine.

ToohrVyk

May 29, 2007 at 2:35 AM

Quote:
Original post by thre3dee
People are going on about removing access to systems that are used by many things.

This is a bad idea. What should be removed is the systems themselves. For instance, my current game does not have systems at all.

Quote:
And Stoic said it, I hate bloating constructors and functions with shared system pointers. Its very annoying to code. All it does is take longer to write classes and systems. What if a class uses a whole load of different systems?

Well, since there are no systems, you're passing no systems around... it still sounds to me that you're thinking of emulating global variables by passing them around as arguments. Don't. Do. That. It is essential that you stop thinking in terms of systems, because systems are inherently global, and doing anything global without using globals is obviously always difficult.

In essence, you should not be trying to remove global variables from your code, you should remove global concepts from your design.

Quote:
And so what if theres two render devices? Theres only ever gonna one Game in the Game, and that would give u access to both devices.. Anyone come up with a reason to have two Games objects??????

I once thought to myself that my Game class should have a global instance:

class Game {  SDL_Handle sdl;public:  Game();  void Run();};

Then, I realized that since nobody but the main function needed to access that one instance anyway, so I could make it a local variable in the main function anyway.

For more details, here is a quick list of the main classes in my game engine:

RenderGroup: a set of renderable objects (can be added and removed), with a member function to render them. The objective is to hold together objects which should be rendered together. Menus have one, game objects have another, credits have another, the pause menu has still another, and so on.
Sound: a sound. Can be loaded from a file with a constructor, and has a member function to play it.
Renderable: a sprite or mesh. Can be loaded from a file with a constructor, can be added to a RenderGroup.
Scheduler: a priority queue used to store events, with a member function to execute all events that ought to occur before a given time. There is usually one scheduler for the entire game world, and additional schedulers used by other individual classes.
Space: a storage structure used for quick spatial queries (closest objects) and for setting up callbacks for collision events between objects. Objects should have access to a Space which reference the objects they care about, and they can easily have access to more than one.
Environment: binds together a RenderGroup, a Scheduler and a Space, is used to share a given set of these with another entity in an easy and elegant manner. Entities all receive an Environment as constructor argument.
Entity: the base class for most in-game objects. Lives in an environment provided as a constructor argument.

thre3dee

May 29, 2007 at 4:39 AM

Well, what *I* mean by systems is simply classes that do fairly big tasks, such as the sound management/playing/loading etc class or the rendering device class.

And the reason I have a file system class is because it encapsulates archives, archive loaders and also some extra file naming features. As well, the file streams are encapsulated so that they can be a memory file, archive file, or a normal file stream (though archive files would probably extract into a memory file).

The scope of our engine is going to be quite large (my mate and I are developing it and its going to be a big project for us, also since its DirectX10). Its for a highly procedural space simulation game we are going to be making over the next few years (probably stretch to 5-6 yrs but hey). One such thing is the use of procedurally rendered planets (you won't be able to land on them, they'll be a quad with a few passes to create the surface, atmosphere and clouds etc using procedural texturing).

And don't worry, we know how overly big an undertaking like building our own fully featured dx10 engine is going to be...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.