Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    162
  • comments
    262
  • views
    167671

Rambling thoughts on design, engines and refactori

Sign in to follow this  
OrangyTang

119 views

Settle in folks, this is a big one. If you're lazy, just skip to the last paragraph...

About a year ago I made an effort to start looking into design patterns more formally, however other than a few particular cases (MVC, FSM and Factories) I haven't really found it to be nearly as useful as I first thought it would. Although I am very aware that this is probably due to my limited understanding of most patterns, and I expect that at some point I'll probably have an "aha" moment and realise what I'd actually been missing.

However I did (by a rather roundabout route) end up much more interested in refactoring, in particular because lots of the techniques were ones that I was basically already doing - just more sloppily and without clear names for them. For me refactoring is a great help, and when dealing with existing code (which unless you're a special case, is much more frequent than writing new code) it makes it easier to think in terms of discrete refactorings to achieve a goal rather than going from start to finish in one big step.

I also came across a fantastic piece of advice from reading about XP - when adding a new feature, refactor until adding it is trivial, then add it. This may sound silly but it is more powerful than it first appears. By refactoring the existing code in the area you're about to work you remove all (or at least some) of the 'cruft' that has accumulated there. You remove the dead code, simplify that which is still used and bring it all better in line with the current thrust and ethos of your codebase. This refactoring also has the side effect of making you understand the code better - you're now more aware of the special cases which need to be handled, the dependencies and structuring already in place, and so on. You're also likely to have seen an alternative (and usually better) way of adding that new feature of yours. If you haven't seen a better way then you've probably still had a few present themselves but you can now be more confident that your initial plan was the best.

I find this a very powerful way of developing code - I've never really been a fan of the Big Design Up Front method, and this way I'm free to do a simple high-level design at the start and let it evolve over time to fit the (probably changing) requirements. It's important not to get too attached to the initial design, things can and will change. Rigidly sticking to the initial design assumes that I knew better then than I do now. This is obviously nonsense - I've now had several weeks/months/years extra experience on top of when I wrote the original.

My final point from this is that you shouldn't be making lots of big, hard and difficult design decisions up front. Avoid the big design documents (even if they're just in your head). Instead refactor mercilessly, listen to your code and never be afraid to deviate from your initial design. By doing so you can 'grow' your engine/library/game in ways that you never expected - and it'll be more robust, more flexible and more useful to boot.
Sign in to follow this  


2 Comments


Recommended Comments

Glad to see you're still posting in your journal, and with a post that's strangely relevant to what I'm presently working on (high-level design of a game engine).

Are you still working on your shmup game? That seemed to be going great.

Share this comment


Link to comment
The shooter is, er, 'dormant' at the moment. I've not made much progress on it but it's definately not been ditched. I started on a seperate game but for various reasons thats now been killed off (I might post a few screenshots in a bit). I've been going back to my platformer project (playable via my website) and adding to that.

Mainly though I've been working on some shared/library code - in particular a nice particle effect system (largely data driven) and currently a minimal game GUI system. When they're finished I aim to go back and retro fit them to the platformer and the shooter which should make them much more polished and user friendly.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!