Structuring engine code

Started by
5 comments, last by PumpkinPieman 18 years, 7 months ago
I've been working on my game engine for a little over a year and a half now, something that can help me with the ins and outs of learning how to develop a small game. Now that my projects are increasing in size I see limitations or little things that I forgot to add in my existing code. Instead of butchering my code I've decided to redo it so it will get cleaned up a bit. My classes right now have no namespaces, so my question is how exactly are modern day engines laid out in terms of creation and deletion of objects (devices and correlating classes)? Namespaces and operator overloading seem to be used a lot, I'm not using them too much and I’m not really enjoying the method I’m using either. Also, is it wise to have a global structure that holds pointers to initialized devices? Say for example I don't want to continuously supplying the device pointer to the texture object (or any other object).
Advertisement
namespaces are probably a good idea. I like to split my code up in several libraries, and it makes sense to put each in its own namespace. It gives you both protection from clashing names and some "automatic documentation". Not sure what you are referring to when you said operator overloading though. It really only makes sense for math types (vector addition etc) and for creating functors. Other than that I wouldnt use it since its most of the time less readable than custom method names.
Look for inspiration in existing libraries and APIs. Mimic how they have created their interfaces. Read up on design patterns if you are using an OO language.
Quote:Original post by rollo
namespaces are probably a good idea. I like to split my code up in several libraries, and it makes sense to put each in its own namespace. It gives you both protection from clashing names and some "automatic documentation". Not sure what you are referring to when you said operator overloading though. It really only makes sense for math types (vector addition etc) and for creating functors. Other than that I wouldnt use it since its most of the time less readable than custom method names.


cSwapChain sc;
sc = device.createswap(640, 480, hwnd);
I would suggest against re-writing from scratch. If you have working code, then that's a good indication that you're doing something right.

Instead, figure out what you don't like, and make the change, while keeping your existing code working! If you have unit tests, so much the better -- they should also be kept working. If you don't have unit tests, then write the unit tests for the new structure you want, before you write that structure.

Throwing away working code, even if it's all ugly and warty, is very seldom the smartest thing to do.
enum Bool { True, False, FileNotFound };

hplus0603 i agree, i'm currently on my 3rd version nad have promised my self i cannot restart again.

Just won't get anywhere


Laters
Well, I'm not completely rewriting it. The code itself is just getting old, I have lots of little things I keep forgetting to do so redoing the structure will at least give me a chance to go over the code.

I've been having this one bug where sometimes on reset I get D3DERR_INVALIDCALL, I supply it the same parameter that I created the device with. In general error checking in my code is very, very bad, so taking a look at it again will allow me to find out what is going wrong where and maybe implement some better checking.

This topic is closed to new replies.

Advertisement