Jump to content
  • Advertisement
Sign in to follow this  

Engine Design

This topic is 3857 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

Hello all, I've got a question dealing with engine designing. In general it took me several years to get a good grasp of C/C++, OpenGL and other libraries. So far, I've made several small games and all was well and nice. Just until recently I tried to write a BIGGER game, to save me time I decided to use irrlicht instead of my own renderer. However, when I was busy writing this I got into several problems. My first attempt used a singleton which had all the classes such as an entitymanager etc as its members. This all worked pretty well even though I hear many people complain about it. My problem however came with the fact that I ended up having more and more files. And I just wasn't able to keep control of my source code anymore. Things got more and more messy, classes didn't fit anymore, I had to use hacky code etc. My question ? It's complicated yet simple, what is the cure against this ? It's the only thing that's stopping me from actually finishing a BIG game. Thanks a lot.

Share this post


Link to post
Share on other sites
Advertisement
Refactoring - When you find code that is messy, take a step back, think about it and then rewrite/redesign the messy parts. Its preferable to do this in small steps so you can check that your game still works and you havent introduced any bugs.

Another important thing is to actually organize your code files. If you have lots of classes dealing with graphics, move them to a "graphics" subfolder etc.

Share this post


Link to post
Share on other sites
Design the engine before coding, even the slightest bit, can also help prevent the dreaded refactoring part, since you should have a pretty good, or at least some, clue about the interconnections/relations that will take place within and between the different modules.
But also try not to design too much - that will prevent you from actually coding anything :P

There exist many tools to help you designing, such as the Unified Modelling Language (UML).

Share this post


Link to post
Share on other sites
The main problem with designing everything beforehand is Analysis Paralysis (see also AnalysisParalysis). Also of notable importance is that this would forego the YAGNI principle and quite possibly result in a lot of useless functionality. One should always strike a balance between upfront planning (on the short term, where it's easiest to take correct decisions) and rely on refactoring (possibly improving one's refactoring skills as a preliminary task) for long-term adaptation.

Share this post


Link to post
Share on other sites
Quote:
Original post by PinguinDude
So basicly I am destined to plan as I code, and keep refactoring all the time ? This is going to take ages... ?


This might take a long time, but it might be shorter than planning upfront, for several reasons:

  • You spend less time planning. Since you already have a lot of code already written and present, understanding what must be done will be more obvious than if you were planning things out of a vacuum. Setting up small tasks for your iterations also results in faster planning, while avoiding the "my design is crap, let's start over with a new idea" infinite loop. It also allows you to only code those things that you need, instead of writing something that you won't use under that form.

  • Part of refactoring-based development is writing unit tests, which make refactoring much easier to get right. This also has the effect of allowing you to write off inconsistent or incomplete designs right away, and document your expected usage in unit tests.

  • You clean up awkward and unwieldy interfaces, so that the code is always as easy to use as possible. When designing upfront, you may well end up with a very clean design that correctly represents your problem, but is difficult to use. When refactoring mercilessly, difficult interfaces become easier, and so using them is faster. Freshly refactored code is always much easier to work with than non-refactored code, no matter how much planning went into either.

  • You get a "working" result (something on the screen, some graphics, a passing unit test, anything) that motivates you to work further. This is unlike design-first methodologies where you work for a long time designing stuff and then implementing things bottom-up and lose motivation to go on along the way.

Share this post


Link to post
Share on other sites
No, its not going to take ages. It will take longer for small projects, but will save you time on big projects, and lead to much better more reusable code.

Knowing how much to refactor, and when to stop is a skill learned with experience (and I'm not sure its doable without externally imposed deadlines... I sure fret over stuff like this a lot more in personal projects without deadlines).

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
  • You get a "working" result (something on the screen, some graphics, a passing unit test, anything) that motivates you to work further. This is unlike design-first methodologies where you work for a long time designing stuff and then implementing things bottom-up and lose motivation to go on along the way.


  • QFT. This should not be underestimated in personal projects where the only thing driving you forward is personal motivation.

    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.

    Participate in the game development conversation and more when you create an account on GameDev.net!

    Sign me up!