[an error occurred while processing this directive]

| Alex Champandard Click the name for some bio info E-Mail: alex@base-sixteen.com

| 07/13/2000, Good Practice (TM)

I can't seem to be able to start a techfile without the standard apology for not having updated earlier, so here it is ;) Exam week has long finished, and the results have come through... I've started work on a new game, which leaves me little time to update techfiles. Needless to say that all other personal projects are also put on hold.
Anyway, I seem to have promised you an update on design and coding practice, so here it is.
Knowledge of the programming language
The first thing you need is to know the programming language you use like the back of your hand. I strongly recommend using C++ since it is a very common language, and finding tutorials or source code is fairly easy. Another reason is the very good tool support available: the best compilers in the business are C++ compilers (DJGPP, gcc, and the Intel Compiler), not forgetting Visual Studio, which drastically reduces development time.
There are a few books you could read to get some very good foundations in C++.

> - The C++ Programming Language, Bjarne Stroustrup
> - Effective C++, Scott Meyers
> - More Effective C++, Scott Meyers

I tend however to find reading these books quite tedious to read, especially when you're just getting started. In my opinion, there's nothing like actually getting down and writing some code. I strongly recommend this tutorial. Once you've got a bit of experience it would be a good idea to read the books, mostly to perfect your coding style, and to learn all the tricks in the book.
Design Methods
There are quite a few formal design techniques available, most of which are clearly defined step-by-step methods that are the result of years of improvement. Which method you choose pretty much depends on preference. And although some projects can be developed more elegantly with specific methods, in the end it's all up to you.
Here are a few of the most popular design methods, see which one you prefer.

> - Jackson System Design - A JSD specification is primarily based around a distributed network of sequential processes, each of which contain their own private information. These processes can only modify their own state given the data stored in other processes, to which they are allowed read only access. Messages are passed over the network in order for the processes to communicate. The JSD method has three main phases the Model phase, which defines and selects processes, the Network phase, which pretty much consists of the rest of the specification, and the Implementation phase.
> - The Yourdon Approach - The Yourdon method is based on event partitioning. This technique is based on a context diagram from the top level, and placing external events that define the system's interaction with the outside world. The top-level bubble is then split into subbubbles, which each handle one event. Once the partitioning has been done, it may be convenient to group some bubbles together, for extra simplicity. This process is called upwards partitioning. The system is therefore pretty much entirely based on interaction with the outside world, which makes conforming to the requirements that much easier.
> - Object Oriented Design - The design of the whole system is based around independent entities. These objects have internal data, and a set of operations that modify the internal data. Objects interact with each other by sending requests to other objects, which can then update themselves with their own local operations.

Choosing OO would make a lot of sense if you use C++ to implement the design.
The Procedure
If you decide to choose OO as your design method, there is a sequence of steps that you can follow to make your task easier.
Step 1 State the requirements

> - Problem scope
> - What is needed
> - Application context
> - Assumptions
> - Performance needs

Step 2 Model objects

> - Identify objects and classes
> - Prepare data dictionary
> - Identify associations
> - Determine attributes of objects and links
> - Organize and simplify object classes using inheritance
> - Iterate and refine the model
> - Group classes into modules

Step 3 Dynamic model

> - Prepare scenarios of typical interaction sequences
> - Identify events between objects
> - Prepare an event trace for each scenario
> - Build a state diagram
> - Match events between objects to verify consistency

Step 4 Functional model

> - Identify input output values
> - Build data flow diagrams showing functional dependencies
> - Describe functions
> - Identify constraints
> - Specify optimisation criteria

When I found out about this, I was quite surprised to realise that there actually was bit more to design than I thought ;)
Formal Methods
There are a lot of conflicting opinions in the literature about whether formal methods do actually help or not. The main reason for needing a formal method at all is that it turns the design procedure from an art, only based on the intuition of several engineers, into a precise science. A formal method removes all the fluffiness of the design, by introducing formality at a much higher level. It allows the designers to:

> - Rigorously examine and manipulate requirements specifications and system designs
> - Check for errors and miscomprehensions
> - Make reasoning about specifications and designs an exact procedure
> - Verify the system at various levels of abstraction
> - Be able to prove that the system is internally consistent
> - Prove that implementation conforms to specification

However, there is one major problem which it would be best to point out now: the use of a formal method does still not guarantee that the system will be perfect.
Formal methods are usually applied via Formal Specification Languages like VDM, B, Z or Raise. Most of them are considered as ISO standards, have useful tools to help the modelling, and provide a wide range of documentation to help the designer.
Standard Coding Practice
Once you've got past all those preliminaries, you can actually sit down and get the work done. Whether you work alone, or in a team, it's a good idea to have some sort of coding standard. The main reason for this is to make code easy to read and understand, quicker to maintain and expand upon. There are a few standards available that tell you how to indent your if statements, how many uppercase letters you are allowed to use per variable name, and how to sit on your chair when you type a semi-colon. You are of course free to define your own standard, but using an existing one will save you a lot of hassle and time, and probably would make more sense in the end. This is the one I prefer, and try to stick to: C++ Coding Standard.
Comments And Documentation
Last but not least, a good project is nothing without good documentation. The reasons for this range from ease of use for the customer, and maintainability in the distant future. In the games industry for example, when an engine is coded without comments, it becomes practically impossible to port to another game. Documentation can be made really easy if you are good at commenting your files. Programs like CcDoc can make your life a hell of a lot easier by generating HTML documentation automatically from the source code. It's definitely worth looking into.
Final Words
Or you could just ignore all that and code on gut feeling, like 804576327f the people do, and like I've been doing for the past, hmmm... 4 years now. However, being organised does have it's advantages: if you're working in a team, if you intend to distribute your code and do something with it in the distant future, if you wish to impress people with the tidiness of your code, if you want to optimise the program as much as possible, or if you're just a fan of abstraction...
Well, that was quite a rambling... I'm impressed you made it to the end ;) If you want to email me about this tech update, or anything else, feel free to do so.
Anyway, have fun!
Alex

> - 01/05/2002 - A.I., Websites and Voxels
> - 03/05/2001 - State Of The Art Character Animation
> - 01/24/2001 - Alternate Programming Languages
> - 01/11/2001 - The Sound Of Silence
> - 09/20/2000 - Engine prototypes, yet more landscape LOD and hard body physics
> - 07/13/2000 - Good Practice (TM)
> - 06/13/2000 - Revision Week Indeed
> - 04/11/2000 - Escape From Inactivity ;)
> - 01/05/2000 - Generic Shaders
> - 12/03/1999 - Start Of Term: Lots Of Good Intensions :)
> - 10/06/1999 - Dynamic LOD, Landscape Generation and much more...
> - 09/22/1999 - Water Contest Entry: Rendering Raytraced Refraction with 3D Hardware
> - 09/16/1999 - More About Bezier Patches And Fractals
> - 08/11/1999 - The Right Landscape Engine For You!
> - 07/12/1999 - Leftovers From The Contest: Fixing TP7's Runtime Error 200 bug
> - 07/01/1999 - Introduction

This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

[an error occurred while processing this directive]