MAIN PAGE

PROJECT SPEC
WEAPONS CHART

SCREENSHOTS
CONCEPT ART

TEAM INFORMATION
STATUS REPORTS
LAB HOURS

FORUM

INTRODUCTION
Our game concept can be best described as a first-person shooter distinguished by combinatory weaponry. Each player will control a character avatar, which is set in a level characterized by buildings and structures. Littered throughout the environment will be various weapons, which players can pick up for use.

VICTORY CONDITIONS
Basic game goals are rooted in having players eliminate one another using the weapons they have attained during play, but from this concept stem various abstractions along the objective vein (more on these thoughts to follow). At the most basic level, the game is framed along the axiom of a freeform deathmatch.

In a freeform deathmatch, players will eradicate one another, accumulating kills until an established time limit is reached, or until a given player reaches a kill limit. At this point, players are ranked in descending order of kill counts.

ASPECTS
Our game's primary unique feature is its weapon selection. The main principle bears two measures in design. The first is that there will be an extremely small set of weapon types. Preliminarily, there will most likely only be three types of weapons, varying in characteristic in four fields-weapon damage, projectile speed, firing rate, and blast radius. However, combining weapons will yield modified versions of their derivative types. Tentatively, there will be three weapons:

BASIC WEAPON TYPES

Players pick up these weapons simply by guiding their character over them. A player may only carry three weapons at once in a character's inventory. Should a player pick up two weapons of the same type, however, combinations can be formed. While the final combination chart is yet to be determined, a fair example of what to expect is as follows: should a player pick up a second rocket launcher, the character will now have a larger rocket launcher. This resulting weapon fires larger rockets which travel at lower speeds, but has significant damage and blast radius upgrades over a single rocket launcher's payload.

It should also be noted that carrying a weapon that is an amalgam of two or three weapons will result in that weapon taking up two or three slots, respectively.

FEATURES-MUST HAVE
Because of the limitations of development and presentation time, the aim in every aspect of the game's planning is to keep things simple but malleable. The weapon combination system described above is fundamental to our game product. Other features that are essential to our design include an accessible control scheme, and a single well-planned level.

For the time being, players will be given the motor abilities of moving, strafing, and possibly jumping (jumping is a function that sits somewhere between "must-have" and "would-be-really-nice").

Players will be given an equally simple set of combat commands. Besides being able to switch between the weapons (or weapon, single) in three inventory slots, players will also be able to drop any weapon of component of a combined weapon at any time, thereby voluntarily losing or downgrading a character's weapon selection.

Player health will be dictated by a regeneration system, where a character's health meter is always regenerating at a low rate. This means that a player who avoids battle for some time having suffered damage will end up with a full health bar in due time. This mechanic was chosen so that there would be no need for a health pack system, which can inadvertently promote the farming or hoarding of health packs.

When a player dies, the contents of the character's inventory are spilled, allowing anyone to claim them.

Finally, our level. Our game is planned to have only one level in mind. This is so that the level can be focused upon to be interesting, balanced, and fun. Initial hopes are to incorporate structures in such a way so that combat will be as vertically-oriented as it is horizontally. That is, the level will be implemented in such a way as to make it just as likely that an opponent will attack from above or below, as it is that the opponent will come from the left or the right. This is to encourage players to look around more actively at their surroundings.

Also, certain weapons will be much more effective from higher ground than from lower ground. For example, the rocket launcher is best aimed at the ground upon which the target immediately stands, but this is difficult when firing from below. Other weapons will not be as significantly affected by height levels, although of course it may be more difficult to spot targets from below than it is to target them from above.

FEATURES-WOULD BE REALLY NICE
There is a large set of ideas that is being contemplated. The first is much to do about some form of a non-playable character, or an NPC. Because of the issues related to programming artificial intelligence, NPC pathing and balance in computationally-perfect targeting would require some extensive testing to make NPC's an improving aspect to the core game design.

Randomized spawn points for characters and weapons is another idea we would like to see realized. The goal would be to prevent a character from spawning in front of another character that is carrying superior weapons, or from having a weapon pop up in someone's view. This feature should be in fact, invisible to the players, and would prevent spawn-camping and (very hopefully) lucky weapon spawns.

The spawning solution might also make it possible to ensure that only a certain number of instances of each weapon type are in play at any given time. It would not do to have every character carry three rocket launchers, so a smart spawning solution could enforce that there by many x instances of machines guns, y instances of rocket launchers, and z instances of laser pulse rifles. For example, we might decide that after a weapon is dropped away from its original spawn point, a timer appears that dictates how long the weapon will remain in that position before it disappears and is respawned elsewhere in the level

A fourth special weapon is also under debate. The fourth weapon would most likely be classified as a melee weapon, meaning that it would involve a player positioning a character extremely near another. The fourth weapon could thus be very powerful, but perhaps require two slots instead of one. But to make it possible for the carrier to chase down a target, perhaps the carrier gains a boost to movement speed.

There is also the matter of a player attaining a fortunate position and "camping" other players. Thus, we hope to implement a "god-like" player-indicator. For example, should a player attain a certain number of kills in a certain time frame, or from similiar positions, eventually an indicator will alert all other players to the god-like player's position. This will encourage players to move often and explore the level.

In conjuction with the idea above, we would like to implement a system that will point the camera perspective of characters who have been in killed in the direction of the element that killed them. This way, players will not be frustrated by being killed from unknown variables.

FEATURES-COOL BUT ONLY IF AHEAD OF SCHEDULE
In conjunction with the notion above, a system of modifiers to character movement is worth thinking about. Perhaps a character's weapons determine the character's movement behaviors based on the weight of each weapon. Or, maybe power-ups may be made available throughout the level. Some variations of this theme are certainly easier to attempt than others, but again, extensive testing would be required in order to keep the game balanced and cohesive.

Another idea is to model the level after a futuristic, post-apocalyptic dystopian campus of the University of California, San Diego. Perhaps even professors will be the characters that players control. The second idea especially has been done before (to politically distressing results), but should our muse enlighten us, and if the game can be kept in focus of the goals stated from the beginning, then they may be incorporated into our final product.

Specifically, we are extremely interested in the rock bear statue by the EBU-III building. We hope to have it become an NPC of sorts that is not only destructible, but filled with personality.

There is also talk of an experience-based leveling system. Originally fabricated as a reward for attaining kills, this discussion also led to the possibility to having kills reward players with an increase in health. This would aid in preventing "cherry-picking," a situation where two characters in combat have decreased one another's health, providing an opportunity whereby a third player could enter the arena and gain an easy kill or even two.

Speaking of arenas, one final idea is to have an area of the level, denoted as the "arena," have special properties. This would be an easily accessible portion of the map, perhaps acting as the quickest detour towards any destination, making it likely players will visit the area and run into other player characters. It would be interesting if physical properties in the arena could be made unique, such as having all movement travel at one-third normal speed.

GROUP MANAGEMENT
Our representation of the project's various structural pieces consists primarily of graphics and animation, audio, and user input. Client and server game engines communicating by networking render and adjudicate the game's events.

Our group makes major design decisions by consensus. It is likely that lower-level decisions specific to a particular portion of the overall project will be decided by those team members responsible for that portion of the project.

Our group meets in the lab at agreed times, and corresponds frequently through e-mail. We will also have a web forum set up on our project website.

We have drawn up a milestone schedule and hope to abide by it. In the likely event that a milestone is not met as planned, we will deal with the situation individually. If other milestones are being met ahead of schedule, perhaps roles can be switched in such a way as to encourage extra effort towards getting the lost milestone back on track. Or, if the design can be altered to allow for a safe quick fix, that road may be taken depending on how much time remains before the date of the final presentation.

As for weekly status reports, all group members will offer input, and the final draft will be assembled by Jonathan Wang.

PROJECT DEVELOPMENT
There will be three main roles in development:

It should be noted that as the networking will probably be completed by the fifth week, from there Caleb Crawford will switch over to work on the game engine, while Dave Elgroth will shift over to graphics and animation.

Tools that will be employed include but are not limited to Microsoft Visual Studio.NET, Discreet 3D Studio MAX, and DirectX.

Unit testing will be employed, a process in which a checklist of possible scenarios are listed and individually tested for working order.

Documentation will include a change log, contributed by every group member, in addition to CVS commentary, forum announcements, and personal notes.

PROJECT SCHEDULE-HIGH LEVEL MILESTONES / TARGET WEEK DATES