Game Engine Design Help

I think using singleton is a good approach. You can built a simple application framework class and treat all other system as a plug-in module singleton. Then you can have much more control on the organized you features.

Wish it help!

I was also leaning more on the singleton idea but then again I'm not sure if it would be any better than just making some basecode. Also having everything singleton would be declared at the start... I'm trying to make a wide-range engine, lets say I want to make a simple 2D game with no multi-player capabilities, well only way these classes wouldn't make an instance of itself is if I don't add it in my project. oye, I'm thinking way too much and doing not enough... I'm gonna wait to see what other people's opinion...

I've really gone off using Singletons because they're easily abused. If you're trying to make a reusable system, they're probably ok - but for reusable components I'd say to keep their use at a minimum. If you assume you can access singletons from within other components you can quickly spaghettify your code; at least I did over the past few attempts at creating my engine. With abundant use of singletons I found that the temptation to be lazy and cut corners was too great - I don't realise until I found I needed to restructure or replace a component, then the whole thing just seemed to break.

Instead, I'd say that you should plan each of your components and define formal interfaces to access them. Anything that uses that component should accept a pointer to its interface at some point and use that. This method promotes reusable component code and keeps the use of interfaces well known; you know how the component found the interface and where it's used - there will be no "why the hell am I calling Singleton::SomeMethod here?" moments that creep up on you.

As for creating your own engine, I'd recommend looking into using as many third party components as you can. This way, you can focus on the structuring of the engine rather than the detail. Once you feel confident on how an engine fits together, you're probably going to be in a better position to construct your own.

[Edited by - evolutional on April 6, 2005 3:51:10 AM]

yeah I agree with you, Singleton classes are really quite usefull but I better just plug multiple sub-systems into a main class. I might be a little pain calling some child functions later on but at least it'll be structured and less messy than having a bunch of singleton classes. Thanks for all the help and suggestions. :)

For, one prerequisite of a clean design is that each class serves exactly one purpose. Putting all those subsystems into the class, they're not subsystems anymore, they tightly coupled with other code they normally would not have to care about. In the end, you'll probably have a 10.000+ lines source file full of just the kind of code you were trying to avoid.

Don't be scared about creating multiple classes, it makes life easier.

-Markus-

Hi,

I had the same problem until I found The Nebula Device 2.
Nebula Device is a framework which has an operating-system style of creating things, through server classes, and provides scripting wrappers and 3D stuff and so on. Please have a look :)

Thermo

Hey,

I know that I'll be shut down by someone, but I'd have to reccomend the 'static object' approach. Basically for my current engine [which is pretty simple, so this might be why it works] I just have static allocations for my classes. Eg, there's video, sound, input, and a bunch of other more exotic classes. They each have an init() and uninit() function, which allows me to start them up in any particular order that I see fit, but the memory for them is allocated so it can be assumed by my program that they exist and function properly - otherwise it doesn't start up.

Although more basic than many of the design patterns that oop would probably encourage you to use, it's actually meant code reuse for me, because the code is entirely self contained and adding it to another project is simply a matter of copying the files and then calling the functions when I need them.

So yeah, I'd have to say, Singletons get really ugly, really fast. An engine class or an application class might be handy, except you've got dependency all over the shop [after all, everything that has access to the engine class will need access to all of the components in the engine class, so adding new components or removing old ones is painful because you don't know where all of their stuff is]. If you want reusability, go with something that's relatively straightforward to implement, and is well encapsulated, so that it becomes easier to add to new code than writing replacement code.

CJM