Engine Design
Author
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.
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.
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.
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).
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).
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.
Author
So basicly I am destined to plan as I code, and keep refactoring all the time ? This is going to take ages... ?
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.
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).
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).
Quote:Original post by ToohrVykYou 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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
