• Advertisement
Sign in to follow this  

Design design design

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

Well, I'm planning on doing a somewhat large project and I'm having a hard time planning it. As in planning the code and how it works, as well as stopping my self from writing code till I have a solid game plan(pun not intended) down. Last couple of times I've gone out and started the project I've always ran into a dead end only wanting to start over with what I have learned. Any tips on how to design a program? Should I literally write out the flow of the program and all the classes I need, so when I start programming I know how everything will fit together? Also, any good resources on different OOP design patterns for games...client/server games?

Share this post


Link to post
Share on other sites
Advertisement
everyone is different. I have found that planning does not work for me. Instead I have a three day process. First I get a rough idea of what I am going to implement and so I go in and refactor my code to make easier to implement. Then I implement. All good programming practice goes out the window. Then once it is working with no bugs I refactor the code until it is readable. So I spend 2/3 of my time refactoring but progress is 10x faster.

Share this post


Link to post
Share on other sites
I prefer planning ahead, and like you mentioned, I too like to think of it as what classes will be in the game and what will be in them so I can figure out what goes where. Instead of just hacking it all together over and over again.

If you'd like to see an example of how I design them out you can checkout my new tutorial/project here.

Share this post


Link to post
Share on other sites
Quote:

Last couple of times I've gone out and started the project I've always ran into a dead end only wanting to start over with what I have learned.


Then you don't know enough/need more experience. Though most everyone I know has this sort of phase; it's just a matter of getting better at program design which (for most everyone) takes experience to get the 'feel' for things. A few designs under your belt with some reflection to see what worked well, what was annoying, and why.

tips: beyond experience which really is key... a good design patterns book (Gamma et al.) helps a little, not coding sleepy helps me a lot, planning ahead however suits you best (right before bed or in the morning shower works best for me) so you have a good idea how you're going to implement things

Washu posted some links on proper OOP design which were insightful to self-learners. There's a few other things like keeping a class dedicated to one task, coding to what problem something solves rather than what it is (which the word 'object' promotes, despite the design problems it causes)...


But yeah; mostly it's just a matter of getting the experience necessary to get better at program design.

Share this post


Link to post
Share on other sites
nice site speedie.

I tended to be like you and jump in head first with no real idea of how things where to be layed out.

after hitting my head on one to many walls in my programing i decided to work out a system to design the game first on paper(or ms word) before starting any code.

i started out by desinging a simple wraper class for graphics, so i can choose between OpenGL and DirectX(makes it easy to start a project without having to code all the window junk).

after that a set out on decideing on what classes and structs need to be in the game and where they should be. so i write out the name of each page(.cpp and .h) and what classes and such will go in them.

after i have the pages and classes ect. i then go back and actually write out what function each class with have, and what if any classes it will inherate to or from.

none of this makes that much of a difference if you dont have a good outline of the game you are going to make, so before i start on any of this i write out a synops of the game its self. where it takes place, what classes or characters there will be to choose from, weapon types ect ect.

this synops does not have to be complete it just has to give you enough direction that you know what exactly you are going to do.

and the best piece of advice is write open ended code, meaning dont lock your self into things. make your code as flexable as posible. so if later down the road you decide to chage how something works you dont have to re-write entire blocks of code.

doing things this way has made it so projects that uses to take months now only take weeks because i know what i'm going to be coded before i start.

thats how i do things anyway, i'm sure almost everyone here will have there own little way. its all up to personal choice.

Share this post


Link to post
Share on other sites
Good job on the site speedie.

I'm defiantly going to go for the most flexibility and dynamics because I want to be able to easily add to it and enhance it without breaking the entire thing.

Share this post


Link to post
Share on other sites
that goes against the YAGNI principle: You Aren't Going to Need It. Why spend hours now to save minutes in the future? Beginners tend to make designs overly complicated and flexible. That is the main reason that we have so many failed projects. After years of failed attempts I have taken a hard look at my problems. It was all due to planning and flexibility. Instead of 5 years of experience I have 1 year of experience 5 times. Now I have moved on. The first step is admitting that you have a problem. Once you have completed a few games then you will have the experience to plan.

Share this post


Link to post
Share on other sites
Except of course when you really are going to need it. Requirements change, stuff breaks unexpectedly... Giving your design some flexibility ahead of time in certain places will keep you from 'running into a dead end' as the OP says. Experience is the best way to know where those places are, and what flexibility you need.

Share this post


Link to post
Share on other sites
My general advice is to not be afraid of rewriting code. If something starts to feel messy, complicated or anything, try to see if there's a better way, and if so, throw all the bad stuff away and rewrite it (use sourcecontrol though, so you don't loose it forever). I recently rewrote all of my UI stuff to use delegates instead of inheritance/overloading, and you have no idea how much better it is this way (perhaps not prettier or more readable, but alot simpler to use, and still more than pretty/clean enough).

Also, I wouldn't worry all that much about writing an engine that can be reused and stuff.. You'll likely just rewrite the entire thing all over again next time anyway (I know I do). Especially since you are learning and stuff.

Try to balance between simplicity and flexibility. Trust me, it sucks to not be able to add features later, but it also sucks to have something overly complicated just because some other type of game could possibly benefit slighly from some of it. When considering supporting some feature that makes your structure more complicated, consider if it's really worth it, or perhaps if there's a simpler way.

As for planning and stuff.. I recommend you try to think of (brainstorm) what features you want/need. When you have a list, review it and consider if some of the features are really worth it. For example, I was initially going to support rotated rooms (I more or less had them working, rendering correctly and stuff), but I dropped the idea because I felt it didn't add enough to make it worth the effort.

Share this post


Link to post
Share on other sites
In programming, knowing how to write code is much less important than knowing how to rewrite code.

Techniques exist for writing code that will be easy to rewrite without having to predict how the requirements will change. The single responsibility principle is a sturdy starting point (so that altering the functionality of the program will involve adding code more than it will involve changing it), upon which you can follow up with loose coupling (so that those changes you actually need will be confined in a handful of modules).

In fact, planning a long way ahead very often does the opposite of what it's meant to do. Instead of protecting the developer from unforeseen changes, it increases the amount of assumptions that are made about the requirements (and what they will become). In short, long-term planning relies on the predictions about long-term requirements being correct—which is the exact opposite of what we are trying to do. Code which makes no assumptions about the long-term requirements will always be more flexible than code which plans ahead.

The real danger, of course, is planning ahead without knowing it (unconsciously assuming that something will not be required, as opposed to consciously assuming that it will). So, the developer should be aware of all the assumptions that the code makes—if the assumption is easy to reverse later on (thanks to SRP and loose coupling). If the assumption will not be easy to reverse, but can be removed at very little cost right now, then remove it (this generally involves applying the SRP or achieving looser coupling). If it's hard to reverse and costly to remove now, then it's time for some decision-making, about wheter the assumption or its reverse becomes an explicit constraint on the program.

Share this post


Link to post
Share on other sites
I think what I mean is...mostly just layout how everything is going work and the basic structure of everything. Instead of just trying to wing the structure without knowing if it will work or not. Another problem I have is making a roadmap, a basic feature list for each version will also help me organize what needs to be done and what can wait. So its probably more just organizing thoughts and the main bigger parts then it actually going into great detail about each and every piece of the code.

Thanks for the replies,
Ryan

Share this post


Link to post
Share on other sites
I tend to use some form of todo list to decide what to do (which doesn't have to be top priority, but sometimes just what seems most fun to do).

Share this post


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

  • Advertisement