Project Summation, re-cap

I haven't really been keeping up with this blog. As of my writing this, I've already turned in the assignment and completed the prototype, at least as far as I could complete it given the time constraints. In the interests of keeping up this blog, though, I'm going to re-cap what I've been doing.


After much searching with little payoff, I decided to abandon the toggleable gravity volume idea. While I did find some forum threads where people were trying to do the same thing or something similar and while people did post a good answer in the form of Unreal script that I could copy and paste, nowhere could I find an explaination on how to alter Unreal script or where exactly to place the script after I copied it over.

I unfortunately did not come up with a solution to keeping a physics volume constantly shoving the player. The closest I could get was switching between two different physics volumes whenever the player pressed buttons to "change weight".

I did manage to figure out a way to create breakable boxes. I accomplised a simple mock-up wherein a box would be destroyed and a particle emitter would be played quickly to indicate that the box had been broken up into small pieces. I did run into an issue with this effect, however, since for some reason it did not save with the current UDK package. Due to time constraints and a lack of familiarity with the particle system, I wasn't able to encorporate the particle system into the final version of the game and had to substitute that indicator with a text notification that would tell the player that the box had been broken. It's a crude solution, but I had little else availible to me at the time.

I ran into an interesting issue with the final level. It looked like some of the elevation platform matinees weren't playing when they were supposed to after I had introduced the option to turn heavy to the player. It turns out that the problem lie in the way the button presses operated. When the player presses the "Q" key, he triggers a key button pressed node in kismet which leads into a switch node. The switch node, since it's the first time it's recieving input, outputs the first connection. When the player hits the "Q" key again to turn back to a normal weight, the switch node outputs the second connnection, which turns the player back to normal by changing an associated boolean value back to false.

This worked alright when it was just the "Q" key that kismet had to worry about, but when I introduced the "E" key as a button the player needed to use to become heavy, this caused problems. If the player hit either the "E" or "Q" keys, I designed a failsafe that set the associated booleans of the opposite value to false. Therefore, the boolean associated with being lightweight would turn off if the player was heavy. The issue in this case, though, was the toggles. A player could press "Q" once to turn lightweight, then press "E" to turn heavy. Ideally, the player should be able to turn lightweight once more by pressing the "Q" key again, but since the boolean chance relies off of a switch, pressing "Q" again just runs the script that turns the associated boolean false once more, meaning that a player will have to press "Q" or "E" twice in a row to turn to the desired weight if they're trying to change back after being heavy or lightweight. I am planning on rectifying this issue by changing the boolean check to a float value or else reconfiguring the boolean. Unfortunately, due to this issue, level 8 had to be scrapped for the time being.

I encountered another issue in level 6 in regards to the falling platforms. I had set up a kill z volume beneath the main level so that if the player fell, he would die and then re-spawn. The falling platforms are supposed to fall if the player isn't lightweight, thereby dropping the player into the kill-z volume and killing him. I ran into an issue where, for some reason, the animation to the platform wouldn't re-set after the player was killed. At first, I thought it was an issue with the matinee not rewinding, but further investigation suggested that the platform might be being destroyed when it crossed into the kill z volume. I tried to find a value in the kill z volume properties, but when I could not I instead opted to go a route similar to how I had fixed the levitating platforms not re-setting; I set up a kismet sequence where the platform's collision changed just long enough to drop the player if he stepped over the platorm while normal weight.

Not much else went wront the the levels. There was an issue with one level where I had to re-configure some tiles due to a near impossible difficulty and an issue where the player would be thrown off of the map by a physics volume if the character ever left the ground (I still have no clue how to adjust this). Also, there still exists the issue of the player "juggling" into the air when going over a levitate platform after already successfully triggering it. In the future, I'd like to fix these problems as well as add some new levels, since I feel the ones that I have so far are pretty simple. I feel like I'm just scratching the surface with the kind of puzzles I could create with this mechanic.

On another note, I think further on I should focus on more puzzles that require a player to switch to normal weight as I found some maps could be solved just by staying light the entire time. I also need to work in more maps that utilize heavyweight properties, since I was only able to create two maps and only able to use one in the final version for this quarter.

Problems and Solutions as of right now

Here's a quick review of things I have figured out how to do and things I am still struggling with.

Solved:

How to get kismet to look for a button press. Found this out a day ago. The command is under events>input. Seems to be working pretty well.

Toggling between physics volumes. I've found that if you use a dynamic physics volume, it is possible to toggle them on and off. Did a test today where I toggled between two different physics volumes with two different keys, switching them on and off. This will be very useful in the future when it comes to switching between the different physics dependent on player weight.

Altering player speed. Kinda solved. The method I'm using has to do with triggering a console command within kismet that alters player movement speed. The issue I have with this solution, though, is that it only seems to work when the game type is set to deathmatch. For my final game, I'm going to need this to work with a custom game type.

Texture effects. So far, I'm getting the kinds of texturing effects I want for the prototype.

Third person camera. Kinda solved. Need to look at the tutorial covering how to set one up

Unsolved:

Toggling gravity. Gravity is not a toggle-able physics volume as it is. Searching seems to indicate that there's ways to create custom physics volumes, but I don't know enough about Unreal script to enact such a solution.

Physics volumes only affecting a player once they move. I've discovered if a player turns a physics volume off, stands still and then turns it back on, the volume only affects the player when they move. I'm worried this could ruin immersion when it comes to the fan puzzles as the player might accidentally come to a stop while in an area where the fan should be pushing back on them.

Breakable boxes. Partially solved, though I'll have to review how it's done.

The problem with fans and physics volumes

In the prototype on which I am currently working, I've been running into an issue with the "fans" in the level. What I need them to do is push the player into the air and hold them levitating for awhile, bobbing the player up and down a bit automatically without the player having to hit buttons.

At first, I attempted to solve this problem with physics volumes. I had used these to pretty good effect before in regards to fans pushing the player off to the side while they tried to navigate through a level. Unfortunately, physics volumes seem an imperfect solution. While they make it very easy to alter a player's trajectory, they aren't good for pushing a player automatically since, it seems to me, the player needs to jump into the air first or make some kind of movement within the physics volume in order for the volume to push the player up. This issue remained even after I made sure the option to have physics enable as soon as the player touched the volume was turned on. I had this same issue with a gravity volume; while the way a gravity volume floats a player around is very useful, it doesn't seem to kick in unless a player first jumps. Since I'm going to be disabling the jump function for the final version of the game, this is a big problem.

Moreover, neither of these options really "juggle" the player. The physics volumes can push the player up and let them float back down, but they don't seem to continuously push the player up like the way they'll continually shove the player to the side when the player is walking. I'm guessing this has to do with the physics volume needing the player to move in the Z direction in order to push him in that direction.

After a bit of thinking of other ways around the problem, I've come to what I consider a pretty clever solution. What I'm going to do is place an invisible platform over the vertical fans in the levels. These platforms will have a rapid up and down animation attached to them which will play continously. When the player steps onto a fan platform, they'll be juggled up and down seeimgly by the force of the fan alone.

In order for this to solve my problem, I'm going to need to learn how to switch between animations depending on if the player is set to different weights. I've got a loose idea about how to do this at the moment. I'm guessing that I'll need to have different matinees for however many different animations I'll need for a vertical fan in a given level (three at most), each triggered depending on player button presses.

Week 4 summary

Not much progress was made on the actual level for this week. Instead, I reviewed some basics of Kismet in  preparation for the coding I will have to do in order to pull off some of the actions required for the prototype. I also learned a bit about physics volumes and can confirm that it looks like I'll be able to use them in order to accomplish the bulk of what I need for the prototype.

Right now, however, I'm caught between several different solutions. For some of the levels, the player will be able to change the weight of the avatar, which is effectively the main puzzle-solving mechanic for the game. In order to accomplish this, though, I'll need to determine how to handle switching between different physics volumes. The best option currently is to construct different sets of physics volumes and then set each of those to activate/deactivate at the player's command, giving the illusion that the player is changing rather than the player's environment.

Week 3 Summary

For this week, I was tasked with creating sample geometry for my game. In order to keep things simple, geometry for Higgs-Boson comes mostly in the form of square tiles. The decision for this is twofold; first, it allows me to create simple geometry for quick testing and, second, using the square tiles is a viable approach for the final game, given the visual aesthetic I'm going for. In theory, I could be able to use all or most of the current substitute geometry, but with different textural choices later down the line.

Some sample geometry as it appears within UDK

I also constructed maps for the majority of the levels that will be featured within the game prototype. Below are a few sample maps.

Due this week were simple level layouts within UDK. While I did not complete all of the levels, much like with laying out the maps, I did manage to complete the bulk of the planned levels.

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.