Goals and Objectives
GameForge is a graphical tool used to aid programmers in the design and creation of video games. A game designer with little or no experience with Microsoft DirectX and/or Visual C++ programming can use GameForge to construct his or her own 2D-arcade games. GameForge also assists experienced programmers by generating the Microsoft DirectX code and Microsoft Windows9x overhead necessary for basic game construction, allowing them to concentrate on more detailed game design issues and implementation. The idea is to limit the amount of actual code written by the game designer, while providing an interface that is easy to use yet complete enough to remain functional.
As a short-term goal, GameForge is intended to assist students in completing their final game design assignments in CIS 587. As a long-term goal, PA Software hopes GameForge will be among the first in a growing selection of ‘do-everything’ game builders.
System Statement of Scope
GameForge is a graphical tool used to aid in the design and creation of video games. A user with limited Microsoft DirectX and/or Visual C++ programming knowledge will be able to construct a basic 2D-arcade game. The idea is to limit the amount of actual code written by the user. It will also assist experienced programmers in generating the Microsoft DirectX and Microsoft Windows9x overhead necessary for basic game construction, allowing them to concentrate on more detailed game design issues and implementation.
The software will consist of a number of inputs, graphically assisting the user in creating on-screen objects including the following:
- Bitmaps (with animation)
- Collision Detection Areas
- Movement Routines
- Additional Object Attributes
The software will also consist of a number of graphical processing functionalities including the following:
GameForge is being marketed as a CASE tool, to allow software developers to ‘build’ rather than code their game. It is not necessary for developers to have prior knowledge with DirectX or Visual C++, as long as they have a good art team and high production values. GameForge will be commercially distributed via the GameForge website (for information regarding the URL, see the Appendix.)
GameForge will be available free for educational use. It will be distributed for use in CIS 587, Computer Game Design and Implementation, at the University of Michigan-Dearborn.
GameForge is designed to be compatible with the Microsoft Windows 9x operating system. Microsoft Windows NT 4.0 and earlier versions will not be supported (Windows NT only supports Microsoft DirectX up to version 3.0. DirectInput had not been implemented at this time, making this version of DirectX very limited.) Microsoft Windows 2000 should also be compatible.
GameForge also requires Microsoft DirectX 7.0 or above. Users may also want to obtain the DirectX 7.0 SDK if they plan on expanding the GameForge library files beyond their original scope.
GameForge also requires the Microsoft Visual C++ 6.0 compiler. GameForge’s VC++ code may be compilable using Borland or some other VC++ compiler, but functionality is not guaranteed.
Management and Technical Constraints
GameForge has a drop-dead delivery date of 04/17/00.
Functional and Data Description
The following page includes brief descriptions of each subsystem illustrated on the Architecture model, as well as the nature of their specific interfaces.
User Interface Processing
There are a number of wizards provided to guide the novice user through the necessary steps for game development.
This wizard allows the user to begin creating a new world. General settings (like screen resolution and transparent color) are set here.
This wizard allows the user to create a new level within their game. Level specific attributes (like background color and level size) are set here.
This wizard assists the user in the creation of a new sprite. The user can select attributes and movement options.
The user is assisted in the animation process. They can create an animation cycle frame by frame, and test the result.
The user sets the collision area. It is displayed over the sprite.
The main interface displays the level/game the user is designing. A tree-view of all objects is also represented. All other interface options are accessed from this screen.
These files contain FAQ’s, Tutorial, descriptions of objects and VC++ code, and a search engine to find the information.
Process and Control Functions
Maintenance and Self-Test
Major Data Objects
Sprites consist of the following attributes:
Name (Primary Key) – Name of the sprite.
Image – Name of the Image file displayed representing the sprite.
Width – The width of the sprite in pixels.
Height – The height of the sprite in pixels.
DestinationX – The X coordinate for the destination of the placement of the sprite.
DestinationY – The Y coordinate for the destination of the placement of the sprite.
Framerate – The framerate of the sprite.
NumOfDir – The number of directions the sprite has.
NumOfFrames – The number of frames per direction.
Solid – Whether or not the sprite is a solid object.
KillsPlayer – Whether or not the sprite kills the player.
PlayerCanKill – Whether or not the player can kill this sprite.
OtherCanKill – Whether or not other sprites (other than the player) can kill this sprite.
Obtainable – Whether or not the sprite can be picked up.
Visible – Whether or not the sprite is visible on the screen.
AffectsScore – Whether or not the sprite has an effect on the score.
SoundAttached - Index of the sound is attached to this sprite.
ReactsToGravity – Whether or not the sprite is affected by gravity.
ReactsToFriction – Whether or not the sprite is affected by Friction.
ReactionToPlayer - Index determining how the sprite reacts to the player’s position.
Bounces – Whether or not the sprite changes direction when contacting another sprite.
Random – Whether or not the sprite has random movement.
Surface consist of the following attributes:
Alias (Primary Key) – The filename of the image.
Path – The directory that the image is found in.
Height – The height of the image in pixels.
Width – The width of the image in pixels.
Messages consist of the following attributes:
String (Primary Key) – The actual text to be displayed.
DestX - The X coordinate for the destination of where the string will be placed.
DestY – The Y coordinate for the destination of where the string will be placed.
ForeRGB – The RGB value of the foreground color of the text.
BackRGB – The RGB value of the background color of the text.
Transparent – The background of the text can be made transparent.
Visible – Whether or not the text is visible on the screen.
Sounds consist of the following attributes:
Alias (Primary Key) – The filename of the sound.
Path – The directory that the sound is found in.
Buffer – The buffer to load the sound onto.
Notifications – Breaks up sound into pieces for streaming.
State – Determines play state (playing, not playing, looping).
Levels consist of the following attributes:
Name (Primary Key) – The name of the level.
Width Overall width of the level (in pixels).
Height Overall height of the level (in pixels).
GoalSprite Index of the goal sprite.
GoalScore Value of the goal score.
External Machine Interfaces
External System Interfaces
GameForge requires a number of additional system components to operate. These include the following:
The interface will have on the left side of the screen, a treeview control, which displays elements in a directory tree structure. Placed in this treeview will be categories with which the sprites that user has input will be categorized. The user will be able to click on these categories and see the expanded list of the sprites that are under that particular category. In addition the user will be able to click on a particular sprite and bring up all of that sprite’s properties. When the sprite wizard is up, the right side of the screen will be the sprite’s image, and an area where that image can be placed on the screen, onto any of the particular backgrounds that the user has chosen. There will be a standard menu bar that is present on nearly every Microsoft Windows application, along with a toolbar for quicker access to the commands embedded under the various menu options.
Description for Access Databases
There are three databases used by GameForge, one for sprites, one for images, and one for sounds. Each database contains the locations of files, either data files describing the sprite, bitmap files for images, or sound files in .wav format.
Subsystem Flow Diagram
Access Database Components
Sprite Database Description (Processing Narrative)
The sprite database contains the locations of data files. These data files contain specifications for sprites, either pre-defined, or user-defined. This allows users to use existing sprites in their games, or to save the sprites they create.
Sprite Database Interface Description
The sprite database is referenced and written to be the user interface. The interface is written in Microsoft Visual Basic, which allows for easy interaction with Microsoft Access databases.
Image Database Description (Processing Narrative)
The image database contains the locations of bitmap image files. These files are the part of the sprite that is seen on screen. They can be files supplied by GameForge, or can be created by the user.
Image Database Interface Description
The image database is referenced and written to be the user interface. The interface is written in Microsoft Visual Basic, which allows for easy interaction with Microsoft Access databases.
Sound Database Description (Processing Narrative)
The sound database contains the locations of sound files in .wav format. These files can be supplied by the system, or created by the user. The sounds are tied to events in the game.
Sound Database Interface Description
The sound database is referenced and written to be the user interface. The interface is written in Microsoft Visual Basic, which allows for easy interaction with Microsoft Access databases.
The C++ engine must access the database. Any problems encountered in this interface must be minimized.
The databases contain only the locations of the files. Problems could occur if the files are moved. Special note should be included in the manual instructing the user to not delete files from the libraries.
Allocation for Access Databases
The databases will be created using Microsoft Access, and referenced by Microsoft Visual Basic.
Description for User Interface
The user interface must present the user with an easy to use way to implement game design. It is a GUI that shows the user where things are, and what they do in the game. It gives the novice user a better understanding of what happens in the game. Wizards are supplied to guide the user through all necessary steps in game construction. Game design is not a primary function of GameForge, preliminary design should be completed before construction.
Subsystem Flow Diagram
User Interface Components
Sprite wizard Description (Processing Narrative)
The sprite wizard is a tool that guides the user through the creation of a sprite. It prompts the user for a number of inputs including the following:
The wizard then creates a data file containing the information supplied by the user. Any necessary files are moved to the project space.
Sprite wizard Interface Description
The sprite wizard is a part of the user interface; it interacts directly with the databases to gather necessary information. It then moves the information to the game data file in the project space.
Project wizard Description (Processing Narrative)
The project wizard guides the user through the creation of the primary surface, sprite placement, game logic, and input. It prompts the user for information on these subjects, which is written to a data file in the project space.
Project wizard Interface Description
The project wizard is a part of the user interface; it interacts directly with the databases to gather necessary information. It then moves the information to the game data file in the project space.
The primary performance requirement is a screen refresh rate of 30 frames per second.
No special design constraints impact the user interface subsystem.
Allocation for User Interface
The interface will be implemented in Visual Basic. This will ensure proper interaction with the databases. It will also utilize DirectX to help translate the user’s game to executable code.
Description for C++ Engine
The C++ engine is the meat of the system. It is designed to be as modular as possible. A majority of the DirectX code is contained in header files to limit what has to be written by the engine. It gathers information from the data files, and uses it to create the balance of the code needed for the user’s game.
Subsystem Flow Diagram
C++ Engine Components
Window Creation Component Description
This component is responsible for the overhead involved in the creation of a window for the user’s game to operate in. it allows the size to be specified, as well as a title for the window.
Window Creation Component Interface Description
The necessary code for window creation will be contained in a header file. Any additional information will be extracted from the data file created by the user interface.
DirectX Component Description
This component handles all DirectX functions used in GameForge. These include DirectDraw, DirectInput, and DirectSound. These functions are responsible for the largest part of the game files. All on screen movement, all images, all sounds, are a result of the DirectX components.
DirectX Component Interface Description
The necessary code for the DirectX components will be contained in a header file. Any additional information needed will be extracted from the data file created by the user interface.
Data File Component Description
This component reads the data file created by the user interface, and uses the information to adapt the C++ code to the user’s game.
Data File Component Interface Description
The component interacts with the data file created by the user interface. The information in the document is used to create a main file for the game.
Game Logic Component Description
The game logic component keeps track of what every sprite and sound does, and when. it uses the data file to dictate the process order for all objects in the game. The logic can be modified directly in the .cpp file if necessary.
Game Logic Component Interface Description
The game logic component is created in the same way as the other C++ components. The necessary header files are accessed. Any holes in the code are filled with information gathered form the game data file.
The refresh rate of 30 frames per second must be maintained to have a playable game.
The code created by the C++ Engine must be compatible with Microsoft’s Visual C++ compiler, and DirectX 7.
Allocation for C++ Engine
The engine will be created using Microsoft Visual C++.
System Modeling and Simulation Results
Description of System Modeling Approach
System modeling takes place during early team meetings. No special tools will be used. The model will be developed on paper.
No simulations were used.
Special Performance Issues
Refresh rate of 30 frames per second.
The interface prototype will be created using Microsoft Visual Basic. The C++ portion will be developed in modules that will be individually tested.
Projected Development Costs
Function Point estimations:
Total FP: 546.49
Reference FP calculations:
Demon Tree FP: 121.03
Demon Tree Person Months: 2.5
Estimated Person Months:
Avg. FP per Person Month: 48.412
GameForge est. Person Months: 11.288
Cost in Person months:
Industry average cost per Person Month: $8,000.00
GameForge est. total cost (w/o equipment): $90,306.54
Note: dates have yet to be established.
GameForge may be distributed freely or as low-cost shareware. This decision will be made nearer to the project’s completion. If GameForge is distributed as low-cost shareware, Professor Bruce Maxim will receive a free educational copy for use with CIS 587 at University of Michigan – Dearborn. The software will also be posted on PA Software’s web site. There will be no additional commercial distribution of the system.
None at this time.