Program Design

[BippyM]

One of the biggest area's of programming is the initial design stages and the continual improvements, additions and modifications of the design.

I was wondering how you experienced programmers did your program design and do you have any real examples to show us?

I am referring to designing right down to the last subroutine, where the main loop branches etc.. In the book I am reading Paul Overaa firmly believes in using warnier diagrams to pretty much completely design the whole program and then break every section, routine and sub-routine down into small parts that would make each section easy to code.

He says that if a section is proving difficult to code then the diagram may need breaking down even more etc..

So guys let's have it (I know Codetapper is writing a game, so maybe some design idea's off him). Galahad, Photon, CFou, Girv, Stingray, Ray Norrish, musashi, steve and even you PC boffins, give us some examples please

[musashi5150]

I've never really 'designed' anything per se. Usually I just sit down and code it. If it's a tricky problem I might think about it for a couple of days before hand and just mentally work out some of the harder bits. I guess if you are starting out though maybe some kind of flowchart might come in useful to get your head around things.

When I coded something once that relied on extremely tight copper timing I did some doodles on squared paper to work it out

I find trial and error works best - just interactively tuning your program when it doens't work.

Shhh... I work as a software engineer and if you promise not to tell anyone I'll admit that I still don't 'design' anything today

[BippyM]

that is classic, I never designed anything either and as such I always ended up with spaghetti code!

I should post the blitz code to my swoseditor one day and you guys will see what I mean. Surely a well designed program can be written better as each routine is written and tested and also nothing is left out!

Maybe it's me though.. more guys come-on

[ant512]

I'd suggest that not many bedroom coders bothered to design their programs before they started hitting keys. The main incentive for me to code is to learn new things, which is difficult to do if you can't test your program as you write it. And if you do learn everything you want to whilst designing a program, there's no real reason for you to finish coding it all.

That's one of the main reasons why homebrew rarely gets finished, and why there are so many emulators around with basic compatibility but with no real polish - once you achieve what you wanted to, you move onto the next project.

The same tends to be true in the business world - you're in such a hurry to hit stupid deadlines created by clueless managers that you just have to start coding immediately.

I think that the only places you'll find real planning are dedicated software houses that create complicated software like operating systems, browsers, IDEs, graphics packages, etc, or major open source efforts like Apache, Audacity, and so on.

There are bound to be exceptions, though!

[StingRay]

I never really designed anything either. When I started to code it was all 'trial and error', time consuming but also a lot of fun, specially when you had one of those "heureka!" moments. Nowadays I usually know what I want to achieve before I start to code so I don't need any UML diagrams or smth. like that. What I sometimes did though, I just tried out the theory on paper before even coding 1 line, that way I could figure out possible flaws in the logic and correct them. My first texturemapper was developed using that approach more than 1 decade ago. I think everyone should develop software using his/her own approaches, don't just feel obliged having to do diagrams/planning everything etc. just because some author said it is necessary. Each coder has a different approach to tackle problems, for some diagrams might be a useful help while for others (like me) they are just annoying. I work as software developer myself as well and I just code the way I use to code on Amiga at work and it works fine.

[Graham Humphrey]

I'm not patient enough to design a game properly. I'll always start but then I just think "What the heck" and just start coding. My games all seem to turn out completely different to my initial designs anyway.

[Zetr0]

if its worth anything heres what I do....

its like a form of structured freefall, this allows you explore coding and achieve something to continue further.

Structure Free Fall: (similar to OOP but less rigid)

1. grab a collection of pens/pencils and some A4 / A3 paper.. dont be afraid to use colour!!!

2. armed with your game idea or project put a big circle on the page. this is YOUR space for the project... from the out side draw what the project needs ie things like graphics... music... etc in little bubble on the side, each of these can be explore later....

3. taking each object bubble in turn see if you can make it into smaller bubbles such like GAME ENGINE, INPUT HANDLER, SOUND HANDLER, OUTPUT etc..

4. now that we have the smallest item we can now look at what this item should do, in the case of INPUT HANDLER it could just be a simple collection JOYSTICK, MOUSE and KEYBOARD routines.

5. as you complete these little routines i found it invaluable to print it out and stick it / staple it on the A4 paper with the object itself so you can refer to it later.

this method is repeated of the series of items and object that your project has... you dont have to explore all the areas at once... you can go as deep as you want in a specific are like say My3DEngineXtreme or SoundHandlerXLBeast... but this gives you like if you will a road map or guildine to the project over all... and in all truth... its a good way to spend time will drinking a cup of coffee....

[Galahad/FLT]

when I was at college, they kept banging on about doing a program design, frankly, I could code in less time than it takes to do a design.

If you are a competant coder, you know what you need to do, you don't need to jot it down first, and then use it like some map to get to the end of the coding job.

I've NEVER done a program design, and never will, they are useless, and the time wasted on doing one could you be learning in code how to perform things.

My tuppence worth.

[Haakon]

My 2 cents as a none-coder:

Isn't design very important today? In 64k programming the design wasn't so important becuase of the length of the code (?).

I thought tidy code and logic design is a necessity in todays programming environment...?

[Galahad/FLT]

Tidy code comes from habit, a program design doesn't affect your ability to use optimised code.

[rsn8887]

I wonder how Toni keeps on top of WinUAE. It must be a monster of code. It must be organized pretty well for him to churn out these new versions and changes so fast...

The design in my mind should be more about making clear to yourself exactly what the program should accomplish, what its scope should be. That instead of sitting down and drawing stupid flow-charts, which sounds to me right now like being an excuse for fear or inexperience.

However, if one starts with a small efficient program and then tries to make the scope bigger later, it seems to me like it could escalate pretty damn fast into something unmanageable. I always end up going from a small program that does one thing well and efficient to a huge one that does much more, but everything half-assed and buggy

[Photon]

I agree with Galahad. Nothing wrong with planning, but flowcharts really aren't helpful at all unless you're so new to coding that you actually have to make it clear to yourself first.

For example, 1 page of flowcharts corresponds to 1 simple subroutine, if that. That's a lot of paper even for a measly 5 K of code So leafing through a pamphlet full of flowcharts will give you no better overview than scrolling through a subroutine and see what it does.

But planning is fine. Sketch a screenshot and draw where everything goes. If it's a big game or sth, make a simple memory map to remember where stuff is loaded.

Don't make to many small subroutines, like one for calculating the normal for a polygon It's only 10 lines of code or so. If a subroutine gets too big, judge whether blocking it out with macros or splitting into subroutines will make it easier. Often register dependencies decide.

I do have a small notepad next to me. If you're making a difficult function, jot down its inputs, its outputs and make an item list of the steps needed to deliver that output from the inputs.

One maybe obvious but helpful hints I always use is: if the output is wrong, either the inputs are wrong or the function is wrong. Nothing else. Simple, but helps when you find yourself staring at a piece of code. If code external to the function messes things up, you usually get more interesting effects on your screen...


Other things interestingly avoids bugs more than anything else:
1. Detect if your mind is tired. Try to write code that seems difficult when you have a clear mind. When you're tired, GIVE UP and jot down where you were, for tomorrow. Don't stay up waiting for your tired mind to eventually crack it so you can sleep well.
2. Keep 'everything' fixed; no complicated dependencies (like pointers that change); as few (as possible) variables/macros/subroutines defined in some file in some directory; follow register conventions, like d7=loop counter, a0=source, a1=destination, a6=library or custom reg base, and so on. Assumption is the mother of all fuckups (c) Steven Seagal

Example: myNewWindow=libbases[6].NewWindow(defNewWindow)

wtf?

Whereas: ButtonPanel=graphics.NewWindow(0,0,640,512)

clearly explains what it does. (The above is some kind of weird pseudo code, but I think you catch my drift. :P)

3. Make changes in small steps, and save under a new, meaningful name each time. Every version that works should be saved separately with an exclamation mark or the like. That way you can always backstep, and always start new from a working version.
4. USE the debugger. Many just notice that the Amiga hangs, hmm, reboots, loads the assembler, stares at the code, where is the bug? Install a level 7 button if your assembler supports it (or a cartridge!). If the debugger for your asm is dodgy and a subroutine gives you trouble, sprinkle it with macros that dump register values to a memory area and that wait for right/left mousebutton, so you can click alternately to step through until it hangs or bugs.
5. Comment your code. I'm serious. Every line, in principle anyway. Because it's a great way to kill assumptions before they are born You don't usually do this when you write new code, you make too many changes before it's finished. But when it's finished, many skip onto the next piece of code. Take the time to comment the code including inputs and outputs of the subroutine, and write whether it has been tested working or not. This helps narrow down the search for 'that subroutine that is to blame'.

[Zetr0]

I Found that three of the best ingedients to coding are:

1. Drinking Coffe
2. Smoking
3. Pacing up'n Down

generaly all three at once.... this method seems to overcome most coding blocks...

irony is I have quite smoking for nearly two years and only drink De-cafe.... hmmm if my old programming chums could see me now... they would hurtfully say i wasn`t a coder any more

An interesting method that seems almost too obvious to mention (involving ASM) if your routine is a tad complex try writing it in a higher language like C, most compilers will output to asm, this is also a great way to begin learning asm too, if you know C or what ever higer language of course...

[Toni Wilen]

I didn't design UAE, I only modified/expanded existing design, basic structure is still the same.

New features are designed in my head (takes from 1 minute to years..) followed by coding some hackish implementation for quick testing and then rewriting it 1-n times until it "feels" good. (=add error checks, making it more compatible, add possible optimizations, clean up the mess etc..)

[korruptor]

I'm learning 68k atm, and I have to be honest, the easiest way I've found is to dive in and try and get stuff working, then throw that code away and try and do it with fewer registers etc. Seems to help let things sink in as well...

[musashi5150]

Originally Posted by korruptor

I'm learning 68k atm

Good on you Best of luck with it. I love 68K, it's my favourite

[korruptor]

Thanks!

I'm absolutely loving it. Few hiccups, but I've got sprites, bobs and scroll texts working and I've had a bit of fun with the copper. Going to try and put it together and make some thing bigger although I've no idea what.

It's just awesome to learn something that's not a C syntax derivative. Really gets the brain going

[pbareges]

i think that even the ones denying it design their code before typing it...but true it seems worthless to me to put it down on paper...i designed one click&point game under amos and patched a few things....i think it all starts with an idea, you think about the way to code this ("in head design"), you may try to perform some coding tests for the parts that seem the most difficult to you...then you go with the central engine of the game (user interface) and you develop empty modules within it, step by step,regularly testing your developments...

[zardoz]

UML is the industry standard modeling methodology

http://en.wikipedia.org/wiki/Unified_Modeling_Language

and I guess some UML packages can turn your models into working C++ objects.

There are a few development paradigms to help you move from model to finished code, like Waterfall (start with the spec and keep going back to the customer with the code until everyone agrees it's finished - most software houses do this), iterative (complete it in chunks) and extreme programming (not sure how this is supposed to work).

This is probably more applicable for business apps. than games? If you're going for a job interview as a programmer make sure you can spout this stuff!

[girv]

Originally Posted by zardoz

There are a few development paradigms to help you move from model to finished code, like Waterfall (start with the spec and keep going back to the customer with the code until everyone agrees it's finished - most software houses do this), iterative (complete it in chunks) and extreme programming (not sure how this is supposed to work).

Waterfall is the traditional one where you don't proceed to the next stage of the process until you're completely finished with the current one. So, for example, you won't do any (or very little) design work until all the requirements are finalised, you don't do any coding until the design is done and so on. You're right in saying that most large software houses do it this way today - certainly any I've worked in have done.

Iterative development is one of many agile methods and is used in Extreme Programming (XP) and other environments. It's the one where you go back to the customer with different iterations of the code until they're happy(ish).

XP itself is one example of an Agile Development methodology. It's a collection of different techniques but IMHO it boils down to rapidly hacking code together in response to customer whims and making many small, incremental releases of the app. It can work of course, but you need to manage it carefuly and having smarter than average programmers helps. There's a fine line between XP and Cowboy

Agile techniques are more popular in smaller companies with perhaps only a few developers. There are however a few examples of larger houses who have applied them with great success.

Wikipedia has some good articles on these subjects, if you're interested.

Waterfall Model
Agile Software Development
Extreme Programming
Iterative Development

Originally Posted by zardoz

This is probably more applicable for business apps. than games?

Absolutely, it is. These paradigms are better for projects that have a large team and / or will be maintained by different developers over a long period of time, which is not the case for most of the projects we're talking about here. IMHO, working by yourself, probably the most design you need to do is to have a cup of tea, think about it a bit, maybe sketch a few notes on used printer paper (envelopes will do too), then dive into the code and get something working. Let's call that the Cup Of Tea methodology.

Originally Posted by zardoz

If you're going for a job interview as a programmer make sure you can spout this stuff!

100% agree with that

Another tip is to learn the difference between Java and Javascript. You would not believe the number of graduates we see that say they know Java but, when pressed, say they use it for doing rollover menus on their websites. I love that one