Jump to content
  • Advertisement
Sign in to follow this  
PumpkinPieman

Structuring engine code

This topic is 4813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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);

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!