Software Engineering and Computer Games

Introduction

     In developing Software Engineering and Computer Games and its accompanying software framework I had four broad goals.

     

·            To teach a lively style of object‑oriented software engineering.

·            To show how to bring a complete program to the level of a commercial release.

·            To provide a “game engine” framework of linked classes for game development.

·            To create programs that are interactive, rapidly executing, and visually beautiful.

     

     Software Engineering and Computer Games was originally developed for use as the primary textbook in undergraduate Software Engineering and graduate Software Projects courses in the Department of Computer Science at San Jose State University (SJSU for short).  In these classes we cover the topics of Software Engineering in the context of having student teams design and implement computer games.  Depending on the nature of the course, lesser or greater emphasis can be placed on the student projects.

     The book is also meant to be suitable for self-study.  Readers are encouraged to use the book to create their own games.  Software Engineering and Computer Games is specifically designed so as to allow would-be game developers to get their own games running easily and rapidly.

     In order to make it feasible for readers of this book to carry out a game project without getting lost in endless details, I’ve created an open source C++ software framework for developing computer games; this is the “Pop Framework,” with source code available for free download from the book’s website:

     www.rudyrucker.com/computergames

     As well as working as a software engineering text or as a self-study guide for budding game-developers, Software Engineering and Computer Games can also serve as the text for a course on computer games such as the Computer Game Design and Programming such as the one we have at SJSU.  The idea of having university Computer Science departments teach computer game programming is a fairly new idea.  Software Engineering and Computer Games should serve to show that a course of this nature can be taught in a sound and academically respectable fashion.

     Software Engineering and Computer Games uses the Windows platform.  Why Windows?  Although the death of Windows is regularly predicted, it remains the most popular operating system on personal computers.  Windows is a strong, mature platform for writing graphics-intensive and/or computation-intensive programs to run on a desktop machine.  By using Windows we get, essentially for free, a lot of goodies that can otherwise be hard to implement: things like menus, toolbars, cursor tools, resizable windows, multiple document interface, cutting and pasting and file handling.  Certainly the Java environment can implement these features, but the process is definitely easier with the Microsoft Visual Studio development environment.  And in terms of job-hunting, it’s very nice to have a solid Windows computer game project of one’s own to demo.

     As at most other universities, SJSU has no formal Windows programming prerequisite for the Software Engineering or Software Projects courses, in fact we’ve recently switched our introductory courses to Java.  But it’s valuable to study Windows programs in some upper-division courses so that the students can gain experience with full‑featured real‑world desk-top projects.  Software Engineering and Computer Games is designed so as to be self-contained, with no prior knowledge of Windows programming required.  Though a familiarity with C++ is recommended, we have a C++ review chapter for those starting with only a knowledge of Java.

     The book has two parts.  Part I: A Computer Game Software Project is the essential lecture material to be covered in the course, and Part II: Tools and Techniques contains detailed reference information about topics essential to fully understanding Part I.

     My procedure in using this book as a textbook is to lecture during the first half of the course and during the second half of the course to help the students spend the classroom time working on projects in three-person teams.  We try and cover the Part I material during the lectures, and the students read from the Part II material on their own as needed.  If using the book for self-study, you might expect to read through most of Part I and to occasionally refer to Part II.  If your immediate goal is simply to get going on making working games, you can skip right to Chapter 3 and do the exercises at the end of Chapter 3 to get a first game working, and then study Chapters 7 - 17 to see how to make more complicated games.

     The necessity of breaking the book into two parts arises from the dilemma of wanting to teach Windows‑based software engineering to people who might not know Windows programming.  Part II covers topics such as the advanced features of C++, Windows programming, the Microsoft Foundation Classes (MFC), and the use of Microsoft Visual Studio — which is indeed the standard tool used by computer game designers.

     The book touches on nine topics:

     

·            Basic software engineering principles and techniques.

·            How to organize and complete a substantial software project.

·            Practical examples of object‑oriented design and programming.

·            The design of computer games.

·            Artificial life, or how to simulate live creatures inside a computer program.

·            How to use three-dimensional computer graphics.

·            Windows programming using the MFC application framework.

·            How to develop a project using Microsoft Visual Studio.

     

     The code accompanying the book is called the Pop Framework.  The Pop Framework consists of C++ implementations of a few dozen classes that are useful for constructing two and three-dimensional computer games.  Software Engineering and Computer Games starts with the basics of software engineering, and then presents the user with the Pop program, which incorporates a number of different game modes. The game modes include an Asteroids-style Spacewar, a Picknpop game of picking and popping bubbles, an Airhockey game, a three-dimensional shooting game, a free-play game called Dambuilder, a side-scroller stub called Ballworld, and a few more.  Each of the games can be run in two-dimensional or in three-dimensional graphics.

     The name “Pop” for the framework was chosen in memory of my beloved father, not that he was at all interested in computers, but what the heck.  This is for you, Pop!

     At the writing of this introduction nearly a hundred different student projects have been built using the Pop Framework, with the result that the code has become quite solid and easy to extend. In Software Engineering and Computer Games, the workings of the Pop code is explained within the general context of software engineering, and the user is guided into extending one of the game modes to create his or her own computer game.

     Why teach something so seemingly frivolous as computer game programming and design in an upper-division computer science class?

     

·            Breadth.  Computer games integrate techniques and code from the whole spectrum of computer science: software engineering, graphics, artificial intelligence, and user interface design.

·            Depth.  Developing a computer game involve many different levels of skills, from low-level algorithm implementation to high-level object-oriented design.  Completing a computer game project requires a deep, sustained effort.

·            Excitement.  The visual and interactive nature of computer game projects can deeply engage a student’s interest.  Because it’s fairly easy to tell if a game works well, the goal is satisfyingly clear-cut and challenging.

·            Simulation Applications.  Writing a computer game involves creating an object-oriented real-time simulation of a certain kind of toy world.  The skills and techniques can be transferred to simulating a wide range of other systems.

·            Career Preparation.  A completed computer game is an impressive program for students to demonstrate to prospective employers, whatever the nature of the job.  In addition, a number of students are interested in getting jobs specifically as game developers.

     

     Software Engineering and Computer Games uses C++ and an object‑oriented approach throughout.  We use Unified Modeling Language (UML) for object-oriented analysis, we discuss Software Patterns and how to incorporate them into our object-oriented design process, and we consistently use the techniques of object-oriented programming to implement our classes.

     Among the special classes in the Pop Framework is a cCritter class to represent our computer game “critters,” and a cGame class for the games themselves.  We also develop some reusable utility classes such as a polygonal and bitmap-based cSprite objects for putting images on the screen, a cRandomizer with a useful randomizing functions, a cVector class and cMatrix class for physics and graphics, and a cPerformanceTimer class to make our animations real‑time and processor‑independent.  In addition, the Pop Framework includes some sound, toolbar, menu and dialog resources.  The Pop framework is built upon the underying framework of the Microsoft Foundation Classes (MFC), using some standard MFC classes: CPopApp, CMainFrame, CChildFrame, CPopDoc, and CPopView.  The Pop Framework’s MFC classes are customized so as to be easily usable for animated simulations or computer games.

     The Pop Framework has a cGraphics class that acts as a bridge between the framework and any specific kind of graphics implementation.  That is, all of our graphics functions are in the abstract base class cGraphics, with the specific implementation of the methods being deferred to child classes.  We presently have implemented cGraphicsMFC and cGraphicsOpenGL implementations.

     The cGraphicsMFC uses standard Windows API graphics calls.  These calls have an undeserved reputation for being slow; the Pop Framework’s speed is in fact more than adequate for typical computer games, easily achieving update rates far in excess of the  minimal thirty frames per second that one typically needs.  The key trick is to assemble each new frame in an off-screen cMemoryDC object provided by the Pop Framework , and to then rapidly block copy this image to the screen.  The cGraphicsMFC is optimal for two-dimensional games including sprites and graphics, but doesn’t have adequate support for fully three-dimensional games.

     The cGraphicsOpenGL provides support for three-dimensional graphics, with z-buffering, lighting effects, and so on.  On modern machines with graphics cards that have hardware OpenGL support, the cGraphicsOpenGL gives acceptable animation frame rates.  Sprites and bitmaps are supported, though with a certain cost on animation speed.

     Software Engineering and Computer Games was developed through nearly a dozen draft versions for use in my undergraduate Software Engineering and graduate Software Projects courses over the past fifteen years.  Above and beyond covering the syllabi for these courses, the agenda is always the same: to teach the students to write complete, visually interesting programs that seem to come alive.

     Being a programmer — or a computer science professor — is a little like living on a Stairmaster.  Your field never stops changing; your old knowledge is continually being swept into oblivion.  Software Engineering and Computer Games and the Pop Framework undergo updates and upgrades every semester.  It’s never really finished; there’s always more features one could add. The Pop Framework has many good starting points for further projects, ranging in level from a homework assignment to a Master’s Degree thesis.

     Software Engineering and Computer Games is designed for the latest flavors of Windows and C++.  As of 2002, the flavors of Windows we support are Windows 95, Windows 98, Windows Millennium Edition, Windows NT 4.0, Windows 2000, and Windows XP. The current Pop Framework was developed using Visual Studio version 6.0, but the code works fine with the more recent Visual Studio 7.0, also known as Visual Studio.NET.  (The Microsoft Visual Studio software development product is also sometimes called Visual C++, or Visual Studio.NET.  Throughout this book, we simply call it Visual Studio.)  Any problems or fixes will be discussed on the book’s web-site www.rudyrucker.com/computergames.  This is also the place to check for new upgrades to the Pop Framework and for examples of student projects.

     It’s my hope that Software Engineering and Computer Games can also be useful to individual readers who are looking for a quick path into Windows programming.  Let’s stress again that you do not need to know any Windows programming before using Software Engineering and Computer Games.  A familiarity with C++ is recommended, but Software Engineering and Computer Games does include discussions of all the key C++ topics that we use.

     A note on notation.  We’ve tried to consistently use some special fonts for different purposes.

     

     C Language, Windows API functions, Windows Data types, built‑in MFC classes and their methods.

     Names of special purpose classes and methods defined for our project.

     Names of directories and names of files.

     Menu item selections or dialog box controls.

     C++ code when quoted in text.

     C++ code off in a block by itself.

     

     There are already some very good books on many of the coding topics we treat.  For a more traditional Software Engineering course, it may be appropriate to accompany the use of Software Engineering and Computer Games with a book such as Steve McConnell, Software Project Survival Kit (Microsoft Press, 1997).  It’s worth mentioning that Steve McConnell’s other books Code Complete (Microsoft Press, 1993 and Rapid Development (Microsoft Press, 1996) are wonderful sources of information about, respectively, program‑level and project‑level practices to use for efficient software engineering.

     Perhaps the most popular older surveys of the field of software engineering are Roger Pressman, Software Engineering: A Practitioner’s Approach, (McGraw-Hill 2000) and Ian Somerville, Software Engineering (Addison-Wesley 2001).  And there is much to recommend in the more recent book, D. Hamlet and J. Maybee, The Engineering of Software (Addison-Wesley 2001).  Software engineering texts range from being very code oriented to being very process oriented.   Viewed as a software engineering text, Software Engineering and Computer Games is further towards the code-oriented end of the spectrum than the three books mentioned.

     Ideally, a CS curriculum might have two software engineering courses: a broad-based process-oriented course, and an in-depth software project course using a book like Software Engineering and Computer Games.  It would seem that the two courses could be taken in either order, as each would shed light on the other.  On the one hand, it’s nice to have studied the software engineering process before attempting a big project, on the other hand, it’s much easier to appreciate the purpose and importance of software engineering process after you’ve actually gone through the experience of building at least one substantial project.

     Two good C++ books are by Cay Horstmann: Mastering C++ (John Wiley 1991), and Practical Object‑Oriented Development in C++ and Java (Wiley 1997).  Charles Petzold, Programming Windows 95 (Microsoft Press, 1996) is a classic general reference for non‑MFC Windows programming.  The successive editions of Inside Visual Studio (Microsoft Press, 1997), by David Kruglinski and others, have good overviews of the Microsoft Visual Studio Developer’s Studio with many short examples.  Alan Feuer’s rich and knowledgeable MFC Programming (Addison‑Wesley, 1997) is an excellent book about MFC.  George Shepherd and Scot Wingo, MFC Internals: Inside the Microsoft Foundation Class Architecture (Addison‑Wesley 1996), gives a valuable low‑level guide to the workings of MFC, including some material which can’t be found in the official documentation or in any other books.

     Kendall Scott and Martin Fowler, UML Distilled (Addison-Wesley 2000) is a very nice little book covering the basics of the Unified Modeling Language.  The standard book on Design Patterns is the well-written and inspiring book, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley 1995).

     Regarding OpenGL programming, the so-called “Red, Blue, and White” books (named after the main colors of their otherwise identical covers) are canonical.  These are, respectively, Jason Woo, Jackie Neider, Tom Davis, and Dave Shreiner, OpenGL Programming Guide (Addison-Wesley 1999),  Renate Kempf and Chris Frazier, Eds., OpenGL Reference Manual (Addison-Wesley 1999), and Ron Fosner, OpenGL Programming for Windows 95 and Windows NT (Addison-Wesley 1997).  These books can also be found on-line.  A recent link to the Red Book, for instance, is http://fly.cc.fer.hr/~unreal/theredbook/about.html.

     Finally, let’s mention some recent books on computer game design and programming.  Andre LaMothe, Tricks of the Windows Game Programming Gurus, Sams, 2001, is an excellent, wide-ranging book on writing games.  LaMothe has written a number of other useful books as well.  David Bourg, Physics for Game Developers, O’Reilly 2001, is quite interesting.  Ian Parberry, Learn Computer Game Programming with DirectX, Wordware 2000, gets the user up and running with a simple DirectX game framework.  Also of interest are David Astle, OpenGL Game Programming, Prima Tech, 2000; Rouse, Ogden, & Rybczyk, Game Design: Theory and Practice, Wordware 2001; Andrew Rollings, Game Architecture and Design, Coriolis, 1999; and Mark DeLoura, Game Programming Gems 1 & 2, Charles River Media 2001.

     You are free to use the Pop Framework in developing your own programs.  The Pop framework source code is explicitly placed in the public domain.  This means that you can freely use any or all of the source code for any purpose, including commercial products or inclusion in other texts.  You do not need a separate permission from the author or his publishers to do this, and you are not required to acknowledge any use of the code (although a public line of thanks is always nice!)  You are free to place your own copyright notice on works which include the source code, with the understanding that the author accepts no liability for problems caused, and with the stipulation that all of the author’s code remains in the public domain and may be further re‑used by others.

     Let’s say a few words about some possible future extensions of the Pop Framework.

     A feasible near-term enhancement of the Pop Framework is an implementation of a cGraphicsDirectX class might faster three-dimensional animations than cGraphicsOpenGL.

     As support for three-dimensional games was only developed in late 2001, there was not time to develop classes for three-dimensional geometrical objects, classes to represent complex three-dimensional worlds, or strong examples of three-dimensional games.  This is an area that some of my students will be working on in the near future.  Any useful new code may be incorporated into new releases of the Pop Framework available on the book’s website.

     A less obvious future improvement might be to extend the framework to support four-dimensional computer games (e.g. a HyperPacMan in a four-dimensional maze or a four-dimensional Space Invaders).  This could open some interesting new ground.  The fourth dimension is a topic dear to my heart.

     Networking is lacking from the current Pop Framework.  Although the framework supports multiple players, it doesn’t support multiple players on different machines.  Perhaps a cListenerSocket child of the cListener class could to be implemented for this.  And one would need to research the existing work on architectures and programming idioms that can keep two game sessions sufficiently in synch with each other.  As future versions of the Pop framework are tailored to take advantage of Visual Studio.NET, it may turn out that we can get networking features fairly easily via the use of .NET methods.

     Experienced gamers will think of many other enhancements that could be made.  The Pop framework presently has no support for scripting, for joysticks, for DirectX Sound, or for loading meshes and skins.  As the code is open source and the architecture is resolutely object-oriented, adding these kinds of enhancements is quite feasible.  I gladly offers up these tasks to the more adventurous readers.  As time goes by, the book’s website will post the source and documentation for any significant improvements to the Pop framework.

     The Pop Framework is written in C++, and it makes essential use of the Microsoft Foundation Classes for its Document-View architecture.  Some will wonder about porting it to Java.  The port is feasible, given that: (a) the Pop Framework classes use solid principles of object-oriented design (b) most of the classes are independent of any specific features of C++, Windows, or MFC, and (c) the class members are, by and large, either primitives or pointers to other class objects (as opposed to instances of other classes, which Java does not allow.)  Regarding Java, the speed of Java applets does seems to be acceptable for game play; see for instance the prototype Java applet Asteroids game at www.rudyrucker.com/computergames/java.  Nevertheless, there are some disincentives to porting the Pop Framework to Java.  Among the disincentives would be that the Java lanugage standard is something of a moving target, that existing Java development environments don’t seem as powerful and solid as Microsoft Visual Studio, that deploying a Java package across many platforms is a “write once, debug everywhere” experience, and the fear that Java may yet be marginalized.

     In closing, I’d like to thank my colleagues Jon Pearce, Cay Horstmann, and Michael Beeson, with whom I’ve had so many useful discussions about the practical and theoretical sides of computer science.  Thanks also to John Sutherland and to John Foster who read a final draft of the book and made many useful suggestions.  Any errors that remain are my own.

     Special thanks go to the programmers I learned real‑world software engineering with at Autodesk, Inc., in the early 1990s: John Walker, Eric Lyons, Josh Gordon, Bob Holt, Steve Demopoulos, Eric Gullichsen, Marc LeBrun, and John Castellucci.  Thanks to my wife Sylvia for her patience and support during the seemingly endless hours of work this project took.  And thanks to my many students, without whom Software Engineering and Computer Games truly could not have been written.

     

     —   Rudy Rucker, rudy@rudyrucker.com

            San Jose, California, March 12, 2002.