IMGD 1001: The Game Development Process
Project 4: Game Logic

Due date: Monday, September 28, by 11:59pm


Objective:

This is the third project that your team will complete in working towards creating a computer game prototype. With your game assets in hand, this project focuses on the development of your game objects and the logic that defines their behaviors. For this assignment you be using Flash for your development platform upon which you will script your game's code.


Motivation:

At the core of any game are its underlying rules. From physical simulation to artificial intelligence, all aspects of a game are ultimately encoded in rules. If a game contains abstract ideas, such as events (e.g., "first-downs"), units (e.g., "hit-points"), objects (e.g., "phased plasma-rifle in a 40-watt range"), people (e.g., "John Doe"), etc., then its code must contain rules that govern these abstractions and their properties.

You have already laid out the vision for how your game will behave. The purpose of this project is for you to implement the behavior laid out in your game documents. With this project, your group will begin prototyping the game that you have been designing, and in the process, gain experience implementing and testing game logic.


Overview:

For this project, your group will begin coding the prototype of your game using Flash. For this prototype, you should use the treatment document from Project 2 and the art assets that you have accumulated from Project 3 (the intent is not to spend additional effort on art!). The focus of this phase of the project is on your game's objects and their behaviors, with the vision that careful level design can be used in a subsequent project to put it all together.

All of your effort will be focused on implementing a variety of objects for your prototype in Flash. This first version of your prototype will be evaluated based on several criteria: object activity, object interactivity, user interactivity and AI/reactivity. In addition to meeting these criteria, you will be required to submit an informal README file that briefly describes these objects. Grading for this project will be flexible based on the needs of your game (see the Grading section for details).


Details:

Your group is responsible for creating a simple prototype that demonstrates how your game's objects will behave. This prototype, along with an informal README document will be handed in when the project is due.

Your prototype should define at least 10 objects (the number of different objects required for a fully functioning prototype will ultimately depend upon your game, but 10 are required as the minimal for grading purposes). Each object should have somewhat unique behavior - it must be more than a copy or subset of another object. As a whole, your objects will have to meet the following criteria:
Object Activity Some of your objects must have the ability to change state, and this change must be reflected to the user in some fashion. This could take the form of a change in location being reflected by motion on the screen, motion along a path, or some other change causing a change in sprite, etc.
Object Interactivity Some of your objects must have the capability of interacting with each other, i.e., an interaction between the two must cause at least one of the objects to change state. For instance, an interaction could take the form of a collision between two objects causing one object to rebound off another. Or, an interaction could be of the form "picking it up" causing one object to dissappear.
User Interactivity At least one of your objects must respond to user input (keypress, mouse motion, etc.).
AI/Reactivity At least one of your objects must exhibit "intelligent" behavior by reacting to the objects around it. This differs from the "object interactivity" requirement in that the "intelligent" object must adapt its behavior as the situation changes. An example of this might be an object that pursues other objects no matter where they move (e.g. a dog that follows a character from room to room).

Make sure you organize your Flash project so that graders can easily find your test objects! Use whatever technical means necessary to demonstrate that you have filled the object criteria. Remember, these are test objects. They don't need to work on the timeline the same way they will work in your final project.

For testing these objects, make sure you have at least one simple stage in the timeline. Note that this is not meant to be representative levels of your finished prototype, so do not spend much time on the stages themselves (completing the levels/stages will be the focus of the next project). You will use them to test your objects, and in grading, we will use them to evaluate your project. Use as many stages and as many copies of your objects as you feel necessary to show that you have filled the criteria.

You are also required to start the implementation of user-defined options that allow a user to change/influence the game world. There must be at least two options that the user can use to change some aspect of the the game world (number of lives, hit points, game speed, difficulty, etc.). You may make the options accessible by a separate stage (say, when the game starts up) or by some other menu or buttons on the interface.

Finally, you must write a short README (text file) that describes the objects that you have created, their behaviors, and which objects fill which criteria. Your README file should also mention the options available for the user to influence the world, and specifically how they affect the objects. Also, your README should list the members of your group, the criteria which you would like to weight for grading (see Grading below) and instructions on using this version of the prototype.


Submission: All documents (Flash source and project files (.fla, .html, and .swf) and README) are to be submitted electronically via turnin by 11:59 pm on the day the assignment is due.

Each document should list the names of every member in your group somewhere on the first page.

When you are ready to submit, zip everything up into a single archive file. Name the file TeamName_proj4.zip.

You will use the Web-based "Turnin" facility to submit your work. Information about submitting can be found here:

http://web.cs.wpi.edu/~kfisler/turnin.html.

Choose one of your team members to submit the document.

Your WPI user ID should be used to login, and you should have been emailed a password.
The Turnin assignment ID is proj4.


Academic
Honesty:
Remember the policy on Academic Honesty: You may discuss the project with others, but you are to do your own work. The official WPI statement for Academic Honesty can be accessed HERE.

Grading:

Grading for this project is intended to be flexible. In order to grade your project based on the specific requirements of your game, we have have reserved 25 percentage points for you to allocate to the various criteria. You will be allowed to evenly distribute these 25 points across one, two or three of the criteria (Object Activity, Object Interactivity, User Interactivity, AI/Reactivity). This means that you can add 25% to the weight of one criteria, or spread them across all four criteria.

Assigning these points to a specific criteria tells us that you believe your efforts were focused there, and thus grading of that criteria should undergo extra scrutiny in computing your project grade. For instance, assigning all 25 points to "Object Activity" would tell us that you put extra effort into the motion of your objects, so you will not receive full credit for that category unless we see your objects exhibiting a variety of complex changes, perhaps based on mathematics.

In order to communicate to us where you would like these flex-points to be allocated, please include in your README a list of categories and weights to split your flex-points across.

Grading Breakdown
Category Weight
Object Activity 15%
Object Interactivity 15%
User Interactivity 15%
AI/Reactivity 15%
Options 5%
Stages 5%
README 5%
Flexible 25%
Grading Rubric
100-90 89-80 79-70 69-60 59-0
The prototype more than satisfies the content requirements of the project. All required objects are present, obviously unique, easily accessible and clearly exhibit a mixture of all four expected behaviors. The game options are clearly defined and easily accessible. The README document clearly explains how the objects and options operate, and how they meet the requirements. The prototype satisfies the content requirements of the project. All required objects are present, unique, accessible and exhibit a mixture of all four expected behaviors. The game options are present and accessible. The README document explains how the objects and options operate, and how they meet the project requirements. The prototype minimally satisfies the content requirements of the project. All required objects are present, but their behaviors may not clearly fulfill the four expected behaviors, or be easily accessible. The required game options are present, but may not be easy to find or understand. The README document is present but may be incomplete, or lack specificity about how the objects and options meet the project requirements. The prototype falls short of the content requirements of the project in a few places. All required objects are present, but may not be unique, exhibit all four of the expected behaviors, or be difficult to access or understand. Game options are present, but unclear or hard to access. The README is present but somewhat disorganized, or fails to explain how objects and options meet the project requirements. The prototype does not satisfy the content requirements of the project. Objects and/or game options are missing or unreasonably difficult to access. The README is missing, incomplete or hard to understand.

Resources:



Back to course page.