 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++. 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. 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 Step 2 Model objects Step 3 Dynamic model Step 4 Functional model 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: 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 
|
