1.1 Features of a successful program
| Here are two reasonable criteria for a successful program. Does it make money? Is it beautiful? A program you write can make money in a direct way if it is so attractive that people are willing to pay to use it. Indirectly, a program can make money for you if it is good enough to convince someone to hire you for a good job. It's also important for a program to be beautiful. Beautiful things don't always make money, but they do have their own value. In trying to make a program that is profitable and beautiful, there are four areas to bear in mind.
Let's say a few words about each of these. ConceptThis is the hard one. If your program is to make money, people need some reason to want it. Your program must do something which people value, and it should do it better than competing programs. If your program is to be beautiful, it must be based on an original and interesting idea “ and these aren't easy to come by. If you look at the kinds of programs people buy, you'll notice that they fall into a few main categories: tools, games , education, and content. Tool programs are things like word-processors, spreadsheets, paint programs, compilers, web browsers, Computer Aided Design packages, and so on. These are large programs with lots of code and are usually created by big teams of software engineers . Tool programs are probably the hardest to create and the hardest to market, and for this reason the author's manager at Autodesk used to say, 'Apps good, tools bad.' App is short for application , which is what executable programs are usually called in the Windows world. And a really good app is often called a killer app . Game programs range from simple solitaire time- wasters up to interactive virtual realities. And the web has opened up a lot of interesting possibilities for shared-world games. As with tools, the key to a really massive success is to think of a completely new kind of game. But even a fairly standard kind of game can sell well if it is based on an original graphical concept and is soundly executed. It's worth noting that games and tools are about the only kinds of software that people are still willing to actually buy in a shrink-wrapped box. A game that you play on the screen of a wireless device like a cell phone will be tiny, but commercially successful console and computer games are huge. As well as including game-engine code, a game will use lots of data files with things like sounds, bitmaps and level designs. Some contemporary games are said to take over 100 person- years of work. The projects in Software Engineering and Computer Games will focus on smaller games, of a complexity at about the level of a classic arcade game. Educational programs cover a wide range. The largest part of educational software consists of very low-end programs to teach readin', ritin', and 'rithmitic. Simple educational programs can involve even less code than games; indeed these are usually developed in a high-level programming environment such as Microsoft Visual Basic or a Macromedia product such as Director or Flash. More sophisticated education programs often illustrate scientific concepts with computer simulations. Simulation programs can model abstract mathematical ideas like fractals and chaos theory, for instance, or they might model biological systems using the techniques known as artificial life. The style of programs known as cellular automata simulate real and imaginary kinds of physics. Artificial life programs show creatures moving about as if they were little pets inside a toy world. Higher dimensional programs display objects that can't fit into the confines of three-dimensional space. These are some examples of beautiful calculations that computers are good at doing, but which would be absolutely impossible to perform by hand. Content programs are multimedia packages of text, pictures, video, and sound clips with a computer interface. A content program might be an encyclopedia or a travel guide. It's common to have a huge number of support files, including bitmaps, sounds, and animations. Many programs are in fact small engines whose main purpose is to navigate through the contents of a data base. Encyclopedia and reference programs are examples of this. A modern commercial computer game often includes enough media resources to be a kind of content program on its own, by the way, with the content presentation driven by the play of the game. Although there's no money in them, it's worth mentioning that you can also create programs which are art. The best known examples of art programs are screensavers. These programs create images that people like to look at. A really good artistic program can produce such a variety of interesting outputs that people are mesmerized. In this book, the programs we focus on will be computer games whose agents , or critters, have behavior driven by an underlying physics simulation. (We'll use the Wild-West word 'critter' throughout this book for the creatures in our computer games.) In that the critters are more or less autonomous, the programs are a simple form of the scientific computer programming known as artificial life. We focus on computer games because they're interesting. To work hard on a program, it has to be attractive to you in the first place, and to finish a program, you have to want to see it in action. Just as you need something to write about in order to learn how to write, you need something to program about to learn how to program. Games are a rich source of inspiration. InterfaceHardly anyone is happy with a program that is to be run from a command-line prompt and controlled by special keyboard combinations. Any serious program must run in graphical windows, support the mouse and include menus and dialog boxes. One great virtue of developing for Windows using MFC is that in this programming environment it's very easy to implement a rich graphic user interface. Of course a good graphic user interface, called GUI for short, takes a lot of thought. You usually need to try out several interfaces till you get it right. Drawing sketches of the interface before you build it is a very good idea. There are some commonly agreed upon principles of Windows interface design, but getting a really nice and easy-to-use design is an art in itself.
It may be that you can envision several different ways in which someone might want to use your program. In this case it's a good idea to make the interface user-customizable. That is, you might have menu selections that change the program's response to certain kinds of mouse or keyboard controls. Or you might have menu selections to control the kind of view that the program displays. In addition to the user controls, you might also regard the selection of your games graphics and sound media files as being a part of the interface design. Of course if you plan to work primarily as a programmer, there's a good chance that you yourself won't be responsible for interface design. Nevertheless, in the projects we do in Software Engineering and Computer Games , you will be developing the entire package: code, interface, media files, and documentation. It's good to have some hands-on experience with interfaces, so that you have a clear idea both of what kinds of interface are possible, and also of how to provide code hooks to work with various kinds of interface controls. A final interface- related feature is file-handling. If you can support file-handling, you allow the user to save and reload the current state of the program, including all of the current parameter values. Alternately, file-handling can be used as a way to extend user- customizability , perhaps by allowing the user to load different graphics backgrounds or sound files into your program. Depending on what files get loaded, your program can behave in very different ways. It's worth mentioning that bug-free file-handling can be tricky to maintain, so programs often settle for simplified kinds of saving and loading. DocumentationThis is often the last thing that software engineers think about. But you should really think about it right from the start, and in this book we'll stress the importance of working on your User's Guide at the same time as you work on your code. You should keep in mind that the important thing about your documentation is that it has useful and accurate information, not that it has a whiz-bang web-like interface. The user cares more about real information than about the exact way in which the topic windows are indexed and linked. Programmers tend sometimes to get lost in the maze of help file design. The User's Guide should include an explanation of why your program is interesting, a guide to installation and quick start, and a feature by feature explanation of all of the menu and dialog controls. The User's Guide is both the printed manual and the online help file. These two are normally based on the same document. Your work, once again, is in making this a good document, rather than worrying about giving it an intricate interface. As it turns out, there is a tool called the Help Workshop that makes it quite easy to convert your documentation file into an online Windows help file to distribute with your program. With a certain amount of additional work, you can eventually give your help file a wide range of hypertext features. It's worth mentioning too that you should also put a lot of documentation into your code in the form of comments to help future programmers who might work on your project “ or to help you when you come back to the code in six months and have forgotten why you made some of the choices that you did. StabilityIt goes without saying that your program shouldn't crash. Its behavior should be stable and consistent no matter what the user does. Attaining this goal means putting energy into testing and debugging. Of course every program has bugs. Keeping them down to a manageable level takes a sustained effort on the part of the software engineer. Bug management has several parts : coding defensively, inspecting and testing the code to find existing bugs, and fixing those bugs . Another aspect of stability means that you, as a programmer, should be willing to leave out a flaky feature that always causes trouble. The tendency to include unnecessarily complicated features is sometimes known as 'developer gold- plating .' You have to have the willpower and big-heartedness to disable or comment out the flaky code when you ship. |
