For the final project in this course, you will build a complete game using the C4
Game Engine from Terathon Software. IMGD-3000
focuses on the technical aspects of game development. Therefore, it is your duty
to make sure the result plays well with respect to the stated technical aspects; you will not
be graded on how good your game looks.
This project must be done in the teams you made for the course. Both the scope and
compressed timeline (only five weeks!) of this project require that the project be done in teams.
The desired outcomes of this project are as follows:
- To go through the process of developing a game of significant size
- To gain experience with a sizable game engine codebase
- To gain experience in team-based development
- To determine and follow a timeline of milestones that must be met to complete
a project of this size on time
- To get a good idea of what serious game development is all about
- To have fun!
There will be several, rapid milestones to be met along the way to delivering your
working product. These are listed below.
The timeline for significant milestones of the project is as follows:
- Jan. 27 (Thu): Project teams formed
- Feb. 02 (Wed): Team brainstorming session
- Feb. 02 (Wed): DUE: Project summary ideas (Example: PDF, Word)
- Feb. 04 (Fri): Project approved
- Feb. 07 (Mon): Detailed Game Plan due (Example: PDF, Word)
(A more-detailed example from IMGD-1001: PDF)
In addition, see this list of other items.
- Feb. 07 (Mon): Project kickoff meeting!
- Feb. 08 (Tue): WPI SourceForge Project set up
- Feb. 08 (Tue): Web page set up to show your progress
- Feb. 14 (Mon): Basic game structure in place
- Feb. 16 (Wed): Milestone 1: Progress presented in lab
- Feb. 21 (Mon): Milestone 2: Playable game alpha presented in class
- Feb. 21 (Mon): Begin internal testing of implemented parts. Build, build, build!
- Feb. 23 (Wed): Progress presentation in lab
- Feb. 24 (Thu): Milestone 3: Playable game beta presented in class
- Feb. 28 (Mon): Milestone 4: "Feature-complete" game, all major functionality in place. No new ideas! Time to finish up and test, test, test!
- Mar. 02 (Wed): Game complete. Go home and get some sleep before launch day.
- Mar. 03 (Thu): Final Prototype Presentations
- Mar. 04 (Fri): Final Prototype Presentations
Keep in mind that the teams only had about 5 weeks to go from idea to prototype.
Game Description: This is a first-person 3D roguelike implemented in C4. It will feature
procedurally-generated dungeon levels, with a number of monsters/obstacles and pseudo-retro,
ASCII-based graphics. As is typical for games in the genre, the difficulty will be
unforgiving and not permit multiple save files.
Everything is Terrible
In this game, the maze is no longer your friend. Traditional maze-solving algorithms will
fail when the maze restructures itself around you! Any square outside the player's current
field of view is subject to be "restructured", limiting the static maze at any given time
to a few always and doors. The only exceptions are the exit square, which is fixed, and any
maze in which a chocolate tart was placed - but be careful, you get a limited number, so
don't waste them! In addition, ghoulies keep spawning at faster and faster rates and the
traitorous mushrooms, the only way to heal, alert them to your presence.
2011: Escape Odyssey
You are trapped on a space station that has been attacked and is losing life support. Your goal
is to get to the outer level of the space station and get away in an escape pod before the
station completely shuts down. You have a remote that can control the amount of gravity on the
ship, and you have deployable teleporters to help you get around. However, the station is
severely damaged, so getting out won't be easy! This is a puzzle based game where you must
get to specific key points on the map, and then manipulate the level to make it through.
Team: A Couple Minutes Studio
This game is set in space in which the player only has one resource, which we are
calling energy. The player must fight their way through enemies to gain more energy,
but must be careful, because everything they do costs energy. Player movement and
shooting both cost energy, and energy slowly decays over time. Destroying enemies
give the player more energy, so the player must find a balance between fighting and
energy consumption. When the player earns enough energy, they may purchase weapon
and ship upgrades, but they must keep the balance in mind, because if they run out
of energy, they die.
Fight or Flight
Fight or Flight is a 3D action platformer that follows the story of a spy who
is sent on a mission to steal a jetpack from a research facility. The spy,
controlled by the player, must escape the facility, and in doing so encounters
security and laboratory subjects that pose a threat to his safe completion of
the mission. The player must depend solely on the jetpack for combat, transportation,
and survival, and will need to constantly manage their fuel when deciding to fight
or fly (avoid enemy contact).
Team: Mostly Black
Hellfire 2: The Descent
Hellfire 2 - The Descent will be an attempt to take the roguelike genre into
a more approachable 3D world, while still maintaining many of the classic
elements that roguelike players have come to know and love. The player will
be placed inside a massive randomly generated dungeon considting of many
floors connected by stairs (which the plsayer will interact with to descend
or ascend) and will be given the task of reaching the macguffin defended by
the big-bad on the bottom floor.
Team: Viva La Mayhem
JaegerBomber: A Night On The Town
The game is a challenge to be the last man standing. Characters roam the maze placing
JaegerBombs on the floor, which explode. Any player or destructible walls caught in a
JaegerBlast are instantly destroyed. Walls that are destroyed may deposit a power-up,
which can change some element of the player's abilities, such as movement speed, the
number of JaegerBombs you can drop, etc. There are walls that cannot be destroyed,
and additionally block JaegerBlasts. There are three different color bombs, each of
which can only destroy walls of the same color.
Team: Wonder Weasel Productions
The player navigates a ball through a series of either randomly generated or
predetermined mazes (the player might be able to choose which they prefer).
Each level has a designated end zone that, when triggered, takes the player
to the next level. There could be multiple elevations and different obstacles
with which to interact (elevators or spring boards for example). The payer's
goal would be not just to make it through the level, but to do so in the
shortest amount of time, of which the game would keep track.
Guardians of Poseidon
Guardians of Poseidon is a puzzle game in which players attempt to
escape from a labyrinth while avoiding monsters inspired by Greek
mythology. Players must find their way to the maze's exit, collecting
treasure along the way. As monsters are generally only killable by
well-armed heroes of legend, players must instead use their environment,
leading their enemies into traps or simply getting them out of the way.
Team: Angry Fish Arrow
Parkour: Race Against Time!
This game features acrobatic racing through a course of obstacles. Players can
jump great distances, jump off of walls, and sprint for bursts of speed. Race
against the clock to the finish line while avoiding hazards and performing stunts.
||In order to make sure you gain experience with modern development and team-based tools, you must
use WPI's SourceForge for this project. Each team should, therefore, create a new project, and add all the team members,
in addition to both instructors and TAs, as administrators.
You must create adequate documentation, both internal and external, along with your assignment.
The best way to produce internal documentation is by including inline comments. The preferred way to do this
is to write the comments as you code. Get in the habit of writing comments as you type in
your code. A good rule of thumb is that all code that does something non-trivial should have comments
describing what you are doing. This is as much for others who might have to maintain your code, as for
you (imagine you have to go back and maintain code you have not looked at for six months -- this WILL
happen to you in the future!).
Create external documentation for your program and submit it along with the project. The documentation
does not have to be unnecessarily long, but should explain briefly what each part of your program does, and
how your filenames tie in.
NOTE: For this project, you must also include a document stating what each person on your team did towards
completing the project. This can be as simple as a list of deliverables, placing names
next to each one. Or it can be more precise. If you feel you would like to express your views individually, send
an email to the instructors.
|Submit everything you need to build and run your program (source files, data files, etc.)
The command to archive everything, assuming your code is in a directory "final", is:
zip -r TeamName_final.zip final
Place this file in your SourceForge space, and label it as such.
Here are some links to the final projects from previous offerings:
Here is a list of some ideas that might help you when working in groups:
|Remember the policy on Academic Honesty: You may discuss the
assignment with others, but you are to do your own work. The official WPI statement
for Academic Honesty can be accessed