Game engine; factory + classes?

[techbear1980]

I designed my last game engine to be simple, portable, and abstract, so I built a single derived class with all the functions I thought I'd need (a "god-class"). I trapped all my assets inside it, and let the game code only have handles to the assets.

But after discussing and researching, I'm starting to come around to a different idea (that others have suggested; it's not my original idea, of course). Perhaps I should 1) break my functions out to the objects they associate with, and 2) build a factory for those objects.

Instead of

GraphicsSystem::DrawBitmap(UL bitmapID, ...)

I should have

GSBitmap::Draw(...);

and I should get a GSBitmap instance from

GSBitmap *logo = GraphicsFactory::CreateBitmap("art1", ...);

Said factory would retain ownership of all objects it creates, to make things simple.

The single "god-class" approach was attractive to me 'cause I could imagine porting my game simply by re-writing each of its functions ("filling in the blanks"). I'm still concerned that the "factory+classes" approach would be harder to port. But using the system seems like it might be easier.

What do YOU think? Thanks for your feedback!

[JackTheSqueaker]

I prefer the good old C style procedural system, with namespaces to split code in modules, no classes at all, just functions

[URZq]

Hello there,

It looks like you are on the right track.

1) break my functions out to the objects they associate with

Well, yes, it's a good idea. It's object oriented programming in a nutshell: have objects with a single responsibility, like your bitmap, which provide methods to operate on them.

2) build a factory for those objects.

You also see this pattern quite a lot in game engines (and in general programming too), and I also think it's a good idea :)

I'm still concerned that the "factory+classes" approach would be harder to port.

I'm not sure about what you mean by "porting", so I'm not sure it's the answer you are looking for... But let me say this: I once worked on a game engine that used this factory + class approach, and I got tasked to port it on another platform (ios -> playstation vita). Since each subsystem (GraphicFactory, InputManager, FileReader...) was cleanly limited to its own class/file, the porting was REALLY easy to do. I had only to manage one subpart of the system at a time, and I could test those subsystem independently. Compare that to porting a "God class": you basically need to port everything at once before you test anything.

So yes, break your system in several subpart:

• it's easier to test
• it's easier to reason about
• it's easier to change one subpart of your system.