Week 1 and 2 project summation

For the first two weeks, I was tasked with coming up with a concept for a game that would work within UDK. The idea I settled upon was a third-person puzzler game with the working title of "Higgs-Boson". Below is a copy of the design document...

Game design document for game prototyping.

High concept: A puzzle/platformer game with an emphasis on manipulating mass and gravity as gameplay.

Story: You control Higgs, a sentient boson particle trapped inside of a kaleidoscopic atom smasher. Using your ability to manipulate mass, you must brave numerous puzzles and challenges if you ever hope to break free.

Gameplay: The player will use Higgs’s ability to control his mass in order to traverse the level. Primary puzzle-solving elements will deal with making the player lighter or heavier. Given time, there may be focuses on making the player character magnetic in order to bond objects to him or pull him across the level to another object.

Making the player lightweight: Puzzle examples

                *Player needs to be able to fly to traverse an area

                *Player needs to roll over floor panels that are fragile

                *Player needs to pass over pressure sensors or slide past security triggered by weight

                *Player becomes lighter to avoid fall-damage

Making the player heavier: Puzzle examples

                *Using heavy weight in order to crush an object

                *Make Higgs heavier to trigger pressure pads

                *Make Higgs heavier to attract objects to himself (gravity)

                *Build up momentum to crash through a gate.

Visual aesthetic: The game’s visual theme will rely on a lot of saturated color. I am currently looking at games like Geometry Wars and Child of Eden for visual inspiration. This is because a lot of the pictures of the large hadron collider seem to have a good deal of color range and saturation. Geometry will probably be simple, a lot of spheres and cubes and floor panels. In addition to creating an interesting, catchy visual look, this can aid in the development process, since more focus can be given to physics-based coding and level design.

Programming needs:

Gravity: The primary feature that will need to be programmed in is player gravity. As stated previously, the main gameplay feature within this game is allowing the player to change his avatar’s weight in order to solve puzzles. Therefore, there will need to be in place a system that monitors the player’s current weight and how it affects the environment. As I do not currently understand the limitations of kismet, my knowledge of how to best handle this is limited. However, for right now, I can see this problem possibly being handled one of two ways. The first way is to have simple “if…then” loop checks on each object where a check would be run as the object passes over it. These checks would determine what happens when the object passes over a tile with a given weight. They would be written similar to this example:

If (object weight = heavy) then (object breaks)

The problem is I’m not sure how fast kismet runs script, so having each one of these checks on key tiles might create an issue with timing or pacing. Furthermore, this may or may not place strain on the ram if it has to keep track of all of these checks. It might be possible to minimize the stress by only running these checks when the player avatar passes over the tile.

Another way in which gravity could be monitored could be by giving an object certain strength levels and having the physics script run the check on its own. Think of this in terms of the physics based puzzles in Half-Life 2; when solving a see-saw puzzle, the solution wasn’t determined by a simple yes/no solution but by stacking objects to accumulate the right weight at one end. Not being familiar with the physics systems present in kismet, I’m not sure how effective this might be or how it may or may not bog down ram.

Progress: Ideally, passage from area to area will need to be limited until the player completes certain objectives. Therefore, one possible solution to this issue could be to run a script that activates when these situations are met, either by pressing a button or accumulating an item needed to pass. Part of this issue, however, could perhaps be alleviated via level design; a player could be disallowed entry into the next area until he completes an objective by placing that objective in the way of the player and the exit.

Lives/Respawn system: There is a possibility that the player might be able to die within this game. If death is possible within the game, then there are two primary avenues which can be used to accommodate this.

The first is a system implementing lives. The player would start with a number of lives and, presumably, after reaching the limit of lost lives, would have to suffer a penalty, either in the form of a game over or a partial game restart. If this is the case for handling this system, scripts will need to be created which count remaining player lives, run death animations (if applicable), handle “game over” events and re-set the player within the environment.

The second involves allowing death, but not placing a fixed limit on lives. Often in modern games, there is no limit to the lives players have. A life system makes much more sense within a game concerned with generating a top score. Within a puzzle game such as this, it may be more effective to simply function off of a system of checkpoints and unlimited re-spawns. If this solution is used, there will need to be script handling re-spawns and keeping track of checkpoints.

A third option would be to disallow player death altogether. Puzzles could be organized in such a way that it is impossible for a player to become trapped or “die”. The advantage is that this creates less of a scripting strain. The disadvantage could be that this might create a situation in which there exists less or no tension and extra care would need to be made to make sure there are no points within a level/puzzle where a player might become trapped.

Assets

Progression Gates: These could be actual gates through which the player is unable to pass until first fulfilling puzzle requirements. Alternatively, they could simply be obvious doors through which the player needs to pass in order to progress within the game (think the flag at the end of a Mario Brother’s map or the elevator to the next testing chamber in Portal)

Floor tiles: There will need to be a number of different flavor floor tiles. These might include…

·         Standard tiles: normal tiles over which the player can move freely. Might be colorful in order to fit into the visual theme, but most should have some kind of a uniform design

·         Fragile tiles: these are tiles the player will only be able to pass over while in lightweight mode. Will need to be designed to reflect this so that the player can take one look at them and understand what they are. Might want to consider lighter tones.

·         Heavy tiles: tiles that can only be passed over while the weight on the particle is at its highest. May be raised to look like pressure pads. Might want to consider darker tones.

·         Hazard tiles: might not even be in the final game. These are tiles that should not be rolled over. If rolled over, the player suffers some kind of penalty. Should be colored with some kind of urgent tone or have a particle effect/animation to reflect the hazard (flashing red, strobing electricity, etc)

Pressure pads: Pressure pads will come in two flavors.

·         Trigger pads: These are pads that the player wants to be able to trigger. They are triggered by the player avatar rolling over them while set in heavy mode. Will need to look appealing, but be colored/shaped in such a way that a player knows that they have to hit them while set on heavy.

·         Sensor pads: these are sort of alarm pads that go off if triggered, causing the player to suffer a penalty. They should be colored in such a way so as to discourage a player from crossing over them.

Block blocks: this redundantly named block is a cube designed to, what else, block a player’s progress. These would feature heavily in puzzles where the player needs to use extra mass to smash through obstacles in order to reach a goal.

Motes: these are smaller objects, probably spherical, that the player needs to attract to himself by switching to heavy mode, thereby giving him a gravimetric pull that draws the objects to him. Light colors, kind of cute looking.

Receptacle: bays into which the motes need to be deposited. May want to look at the various receptacles in portal

Suns/Magnets: Larger items to which the player can send himself by setting his avatar on lightweight, thus making him lighter than the sun/magnet and pulling him toward it.

Level Design

Ideally, there will be one section each designed to teach the player the different mechanics of the game and the avenues afforded to them for solving challenges. In theory, there should be a final puzzle which incorporates all or most of these concepts, but such a level might need to be postponed until a more advanced class as there might not be appropriate time for it given the current deadlines. As there should be a level or section for each mechanic, we should take into account what mechanics need to be taught.

• The player is able to shift weight
• Different weights allow the player to move to different areas
1. Lightweight allows: traversal over fragile tiles, movement over sensor panels and attraction to sun blocks
2. Heavyweight allows: breaking of various objects, putting pressure on pressure pads and attracting motes to oneself

As it stands, there could be six different segments, each designed to teach a player a specific thing.