Marc Vaughan wrote:Section Two - Implementing the Game
Basic Programming Principles
Advice on programming a large project
Debugging tools
An Overview
A common problem with developers is the daunting process initially of deciding exactly where and how to start on the development of their game. If you look at the game as a whole then it’s a daunting task and you'll probably never get past drawing up designs let alone finish the game.
WIthi this in mind I propose to split the development into more manageable chunks, this will give the developer a more managable task with a sense of achievement as each of the chunks is completed.
The chunks that the program will be split into are as follows:
• Graphic User Interface
• Database
• Match Engine
• Trade System
• Competitions
The User Interface
The user interface is commonly one of the most overlooked areas of game development. While a sleek and intuitive user interface won’t save a poor game from being slated, a poor user interface can kill the desire to play an otherwise well thought out and addictive game.
Text Based Sports Simulations require a user interface which is intuitive and which allows users easy access to every area of the game world with a minimum of fuss.
The next few sections of this book will take you through the basics of drawing on the screen, rendering text to a display and finally creating your own user interface.
Screen Displays
A screen display module deals with the displaying and interaction with the user interface for the game. All professional management games user a GUI of some sort.
Front Office Football, Jump Shot Basketball and a few other game some implement their games using the standard windows look and feel, while Championship Manager and some games use a custom interface designed specifically for their game.
I have listed briefly below the comparative advantages and disadvantages of each approach to a games user interface.
Windows Interface
Advantages
Intuitive as most users are familiar with the windows interface
Quick to develop as there are many RAD tools available for Windows
Very few incompatibility issues
Disadvantages
Not graphically appealing
Doesn’t ‘look’ like a game
Limited flexibility in components
Custom Graphic User Interface
Advantages
Customised to the game so it is ‘exactly’ what is required
Can be made to appear very attractive
Looks more ‘like’ a game
Disadvantages
Increases development time
Can be incompatible with some machines is based on DirectX
Should you decide to develop your game using the standard windows interface I would recommend that you purchase a book dedicated to Windows GUI development as that topic is tool large to discuss in this tome.
The options available for developing a ‘custom user interface’ (DirectX and GDI)
Direct X
DirectX is the name given to the set of libraries which are provided by Microsoft to enable people to make fast sleep graphical presentations that are needed in certain high end applications and of course games.
These libraries can be used for implementing many fancy techniques such as texture mapping
Basic Graphics Using DirectX8
Many of us have been programming in DirectDraw for a while. We are used to locking our surfaces, writing out our screens, and flipping our buffers. We all have code for how to blit a sprite, and how to handle the surfaces. However, DirectX8 changes all that. While you can still count on backwards compatibility with DX7, you will be short-changing yourself on the improvements gained by moving to 3D (blit speed, alpha blending, stretching, etc.) .
This sample will show how you can still use 2D coding techniques in the 3D world, and how you can gain a speed increase over standard 2D DirectDraw code.
There are really only two basic parts to 2D programming. Rendering a bitmap, and writing directly to a surface (for lines, circles, etc.) This tutorial will show how to do that.
Opening a screen
Drawing a pixel
Copying a bitmap display buffer to the screen
Basic Graphics Using the GDI
Opening a screen
Drawing a pixel
Copying a bitmap display buffer to the screen
Constructing a user interface
Making a screen manager
Constructing Screen Objects
The Game Engine
The Game Database
At the heart of every Sports Management Game is a database containing the details of the players and teams modelled in the game.
This database is crucial to the game and accesses to it must be quick and efficient regardless of the size of the database that is being stored.
There are two approaches an SMG designer can take to implementing such a database, he can either implement his own ‘custom’ database format or use an existing standard database format (such as Jet - the Microsoft Access database engine).
I have briefly listed the advantages and disadvantages of each approach to database development below:
Standard Database Format
Advantages
Existing Database format with no bugs
Easy for users to update the database themselves
Disadvantages
Slow to access, search and save
Custom Database Format
Advantages
Fast to access, search and save
Disadvantages
Because it is implemented from scratch may contain bugs
Harder for users to edit the database
Should you decide to implement your game database utilising a ‘standard’ database format I recommend that you purchase a book dedicated to interfacing with your chosen database engine.
Implementing a custom database is fairly easy so long as care is taken in the initial design for the game.
The most important thing when designing the database is to initially determine the data that will be held within each of the database tables and how each of the tables in the database links to the other tables (if appropriate). An example document doing this for my ‘xxx’ game is shown in the ‘High Level Database Design’ document held on the CD.
Once the data to be stored has been determined it is now time to write an engine to allow access to this data quickly and efficiently.
When designing our database system there are a number of important points to bear in mind:
• Unique ID’s
Ensure that every item in a table has a unique id – this can be used to link data from one table to another.
These ID’s should equate to the location of the structure within the database table, for instance the first first item in a database table should have an ID of 0 (ZERO) because this is the value that would be required to access it from within the table array.
This means that any table which needs to reference this data can simply store the ‘id’ of the entry in order to be able to access it at a later data.
If speed is critical within your database you can make tables store raw pointers to other tables, however in this case you will be required to save down the base address of each table when you save the database so that upon loading the data links can be realigned.
• Speed
Read/Write in large blocks where possible as the longest delay in accessing data off disk is the ‘search’ period.
This usually equates to keeping all frequently accessed database tables in memory while the game is running and only storing in-frequently accessed tables on disk.
• Creating the database
A binary database can be read up much faster than a ‘text’ based database – however creating one is fairly awkward because you have to design a ‘custom’ editor to create the database with.
An easy work-around for this dilemma, which we will be using, is to allow your database to be fed from either a text or binary base but to always save its data in binary format. This will allow you to initially setup your database using a standard text editor however you will be able to release the game using a fast and efficient binary format should you so desire.
• Capacity to access old database versions
Hopefully your game will stand the test of time and be succeeded by a ‘sequel’ to the original. This sequel will undoubtedly be more in depth and require even more data than the first game.
Because of this it makes sense to allow your database to read and write different versions so that when you come to implement your ‘sequel’ you can build upon the existing game without having to re-implement your database from scratch.
File Access In C++
Detail the basics of opening a binary file and reading/writing from/to it. Also emphasise the importance of closing the file after use.
Implementing our database (Including Version numbers)
The first step of any management game is to define exactly the data that will be present within the games database. If this isn’t known the the game will quickly become unmanageable and hard to program.
For the purposes of this example I will define a simple database table holding the player information for players in a ficticious soccer management game.
Table Field Type
Player Name Character String [length 100]
Player Strength Character [range 1-20]
Player Agility Character [range 1-20]
Player Skill Character [range 1-20]
Player Heading Character [range 1-20]
Player Tackling Character [range 1-20]
Player Age Character [range 15-40]
The easiest way to create databases from scratch is to simply create them by reading data from a text file and placing it into an array of structures within your game.
The structures should be nearly identical to the table which is defined above, with the addition of a
For the purposes of this example I will define a simple database table holding the player information for players in a ficticious soccer management game.
Define the basic database structure that we’ll use for the test application
Reading up the test database as a text file
Writing the test database down as a binary file
Reading the test database as a binary file
Accessing the database in memory (inc. building a basic factfile display)
The match engine
There are many different approaches to implementing a ‘match engine’ itself, the only common component behind any match engine is the requirement for that engine to select a team of players for a CPU club to field.
There are several different approaches to doing this, the most common is simply matching players to their best role within a team.
Discuss how to implement Computer AI for team selections.
Detail the different approaches possible (simple random numbers, zonal play-offs and full simulations).
The Competitions
League
Cup
The transfer system
Buying and selling players
AI for computer purchases
Appendix One – List of Text Sports Simulations and Developers
Company: Solsemic Sofftware
URL:
http://www.solsemic.com
This company is run by Jim Grindin and concentrates purely on the development of the American Football Management Game Front Office Football.
Appendix Two – Useful URL’s for the novice developer
Useful URLs for the novice developer
Appendix Three – Recommended Reading
However, how do you plan to simulate matches? The reason I ask is that if the game is simulating every second of the match then technically you'll have already created a 2D match engine.
