Raptor Racers: Week 5

Progress on the game has slowed somewhat, there are random fluctuations in progress each week. Some weeks we get together, figure out what needs to be done and actually program something that sort of works. Other weeks, like this week, the whole group mainly just focuses on assignments and generally does not touch the game code or discuss much about the game.

Although comparatively, last semester the real heavy lifting started right around after midterms. The moment we were done, we went into a sort of panic, and our group meetings increased twofold, and productivity went up substantially. I have a feeling that this will happen again, as we only have pretty much 1 month and a bit to complete the requirements for our game. We only have 3 midterms to study for though, and that will put a substantially lower amount of stress on the whole group as a whole.

A new group member has also joined us a while back. This is a new unexpected twist that we will have to work around. It is quite difficult to assign tasks to this group member because a lot of context needs to be provided to him in order for him to be an effective group member. All of our group members already have specific roles that they fulfill, and adding one more group member in is giving us a more difficult time than it should.

Another thing that is giving me issues is that we definitely need to start learning how shaders work. At this point in time we have no idea how difficult they are going to be to implement. From what I hear and have researched, it could be as easy as telling OpenGL to run a separate piece of code during it's rendering stage, or as difficult as writing your own shader code that effectively simulates real world materials. It's great that various teachers are telling us to prototype and plan out before setting out to program and create art for the game. I agree, and this works well with people who already know at least some of what they are doing. Unfortunately for students, this is not the case. We are learning as we go, and we have no idea how long some aspects will take to implement, or how difficult it will be to even implement simple game mechanics (like jumping for our Raptors). This makes planning, brainstorming and idea generation in general incredibly difficult.

Raptor Racers: Week 4

The pace has definitely picked up since last week, we are having coding sessions at our group meetings which tells me we are on the right track. Even if we may not necessarily have the design of the game completely done yet, it is a good idea to start coding early. We are starting to talk about our code in more detail and depth, and I'm starting to understand more and more of the code base, and understand what needs to be improved. I've revised the animation system slightly, but I'm afraid I might have to gut the entire system and start from scratch. While the animation system Dan Cortens wrote for last semester was functional for the game and produced a relatively good looking result, the code was a little messy. Given that we were under pressure to complete the game as fast as possible, we didn't have time to make the code more efficient and neat.

Now that I am trying to add more animations to our Raptor (the ones I mentioned in week 2), I found out that the code for the animation system is not very extensible. Part of this was because my old method for animation was to spit every single frame out from Maya as an .obj file. This turned out to be 48 different .obj files for the running sequences alone (each sequence was 16 frames long). After figuring out that this was silly, I cut down the amount of files by a factor of 4. My key-frames in Maya happen every 4th frame, so it is only logical that I only export those out instead, which cuts down our loading time. The system doesn't really account for these new number of frames, not to mention it has to handle the interpolating parameters differently. For example, if the player just taps a key to turn right, the animation always finishes interpolating to the next frame before moving back (the Raptor completely swings its neck around, as if it is making a sharp turn). I want it so that the system only interpolates a percentage to the next frame, and if the key is released before it reaches it's target frame, it interpolates back to the original pose. This will make the Raptor look more natural when it is turning, or doing anything else for that matter. This way I also have much more control if I can manipulate the percentage of the animation, instead of just the next pose.

The goal for the next week or two is to have at least a working animation system, after I'm done that, it's time to implement all of the animations themselves and play around with the movement mechanics and see what feels right. After all, the animation and game play have to be matched at least somewhat or else it will look silly.

Some things that are still on our to do list: Fixing textures, lighting, figuring out shaders, completing the design, particle systems, shadows(?), and a whole bunch of other stuff. I want to make our animations as nice looking as possible before we move on to harder things that are required (mainly shaders, and other business/design docs that are requirements).

Formal Critique of Dead Space 2

Dead Space 2 is a sci-fi survival horror game that is developed by Visceral Games and published by Electronic Arts. The player takes control of Isaac Clarke, a former space engineer in the 26th century who is now a mental patient. Imprisoned on The Sprawl, a dense urban city on Titan (Saturn's largest moon), Isaac must escape death and dementia in time to destroy the marker responsible for the necromorph outbreak.


Main 4 elements

 Story

To give a brief context of the story: Isaac wakes up in an insane asylum and is being interrogated. He has flashbacks of his dead girlfriend who was serving on the ship called the USG Ishimura. We are informed with her video log that Isaac encouraged her to serve aboard the Ishimura, where a horrible outbreak of necromorphs killed the entire crew. She then commits suicide at the end of the video log. This feeling of guilt is the main driving force that pushes Isaac on to continue the fight against the most recent necromorph outbreak. He isn't exactly mentally stable, as his hallucinations sometimes try to forcibly make him commit suicide.  These apparitions act as a mirror, where by observing them we get a glimpse into Isaac's perception of other characters, particularly his dead girlfriend. I feel that this is a very effective way of developing a character without using dialogue, as visual and auditory cues give you some feedback about Isaac's insanity.

At first, it isn't known how, or why a necromorph outbreak is happening which gives a sense of mystery around it, and at the same time a sense of confusion. This approach to storytelling sometimes feels cheap, because you tossed right into a dark and empty world without being given much context. The reason why this applies especially to this game is because Isaac is located inside of a once-sprawling metropolis which is now devoid of life. If the outbreak happened moments ago, where did everybody go? Where are the civilians and other members of society who were going along in their daily lives? There is no way an evacuation could have happened that quickly in a place that huge. I found this rather confusing, and every time I looked out the window to see an entire cityscape of well lit skyscrapers, all with no signs of life in or around them. Perhaps this was the intention, but again, the player needs to be provided some sort of context to compare his/her current state to. An example would be looking out the window to see chaos emerge from around your surroundings, as evacuation dropships scramble to shuttle people out of the vicinity. To follow up, in a later scene, the outside world would be shown as devoid of life, and only you are left behind to face the menace.

I doubt the city would look this intact if it was inhabited entirely by necromorphs.

The story is the main driving force of the whole game, and the player always wants to know what's going to happen next. There are unexpected betrayals by a few NPC's, and the fact that there are so few other people you can actually interact with, this does impend a desperate will to survive.

The NPC's never actually fully interact or help you in any way, except with a few scripted sequences. There is a certain encounter that you actually get to see them physically, rather than by your RIG communicator (it provides visual data of the speaker on the other end). By doing this, the story does teach you to be more of an independent player, because companions definitely make the scene a lot less terrifying if you have someone by your side. However this does feel like a cheap shot at some points, if Isaac is really just an ordinary engineer, then how come there are barely any other survivors? Surely the security personnel were actually trained in combat, and have heavier body armour than Isaac.

In video games the player is usually a very powerful entity to be reckoned with, but most games don't bother explaining why this particular person is so good at what they do (Ex. Gordon Freeman, you are an MIT graduate, how does theoretical physics translate to exceptional physical ability?). I feel as if Dead Space 2 somewhat falls into this trap. Isaac is supposed to be a 43 year old systems engineer, but somehow feels as if you are some sort of trained biological hazards soldier. This isn't a gamebreaking story loophole, but it does raise a lot of questions later on in the game. Particularly when you are caught by surprise by at least a couple dozen soldiers trying to kill you. You manage to escape and shut off the power, causing necromorphs to break into the facility. But those dozens of armed men can't deal with a few necromorphs? Isaac alone must have taken down an entire town's worth of necromorphs throughout the course of the game.

In conclusion, the overall story was of a cinematic quality, and we see a pretty dramatic character change in Isaac towards the end. The ending was put together in a satisfying way, and even added a bit of comical relief by mimicking the ending of the previous game, but with less horrifying results. Overall, it is an interesting experience that shines light onto the human psyche, and explores themes of loss, fear and acceptance.

Aesthetics


The visuals in Dead Space 2 always have a moody and atmospheric feel to them. Lighting is the key component of creating atmosphere in a horror game. To create a sense of dread, or fear, the lighting designers have manipulated light in such a way that it is either your 'friend' or your 'enemy'. In many scenarios, well lit rooms are a welcome sight when you've been in dark corridors, being ambushed by monsters. Softer, warmer colours are used for 'safe' areas,  as the light bleeds on to every surface, revealing that there are no threats in this room. Other more hostile rooms are harshly lit, creating long ominous and looming shadows that envelop the room, as if trying to swallow you whole. The colour of the light has an 'industrial' feel in more hostile areas, giving off a cold, unforgiving feeling to the atmosphere.

Sometimes the lighting is purposely absent, gone entirely so the only thing you see is whatever your flashlight illuminates. This amplifies the intensity in the scene, as you are usually swarmed with monsters shortly after.


Creating atmosphere can't be done by visuals alone, but a good sound design philosophy can have just as much impact as visuals. Dead Space 2 certainly does not lack in the sound department. Every single room has some sort ambient sound, there is always a hissing of gas, crackling electronics or even whispering voices. This makes the environment feel alive, and at the same time feels as if it is dying. You can really get a sense of damage when walking by and hearing lots of electricity sparkles, metal groans, shards of broken glass under your feet, and litter being kicked around on the floor. 

Comparatively, the various shrieks and groans the necromorphs produce have a certain chilling quality to them. If you are exploring a room, certain sounds can sometimes be mistaken for a low hiss or growl of a necromorph, which always keeps you on your toes. However, a lot of the monsters do sound similar. With a few exceptions, the distinctions between the different monster types can only be differentiated by visual cues.


Monster designs in this game offer a certain disturbance to them once that you realize they entirely consist of morphed human beings and body parts. It's not just your typical 'zombie' look either, they have all sorts of mutations and horrifying modifications done to the original host body.

I noticed though that this monster design philosophy is a common occurrence in triple A horror titles. I feel like this is a compensation for giving the player weapons. Once you give the player a means of defeating his foes, a very large chunk fear is lost. This empowers the player, and makes him/her feel less vulnerable, and in turn makes the player less fearful of the environment. In contrast, a game like Amnesia: the dark descent has absolutely no means of defeating your foes, and this certainly intensifies the fear tenfold, which is horror done right. However, the actual game isn't that fun after the first playthrough. Dead Space 2 approaches horror with guns blazing, and by the end of the game, instead of feeling fear, you are slightly annoyed by the occasional monster or two.



The environment itself is an empty place, and devoid of life, but the designers made sure it feels like it had a history. Shopping malls have all sorts of garbage laying around on the floor, store lights and advertisements are still on. There is a scene where a surgery was abandoned halfway through, and you have to help the patient free. You can also feel a sense of damage when walking around infested areas. Some doorways are lit on fire, walls have massive holes in them, wires are hanging out and sparking in every which direction.


The art assets and visual effects are fantastic, and very highly detailed. There are also a very large variety of effects, one of the cooler ones that I distinctly remember is that once you enter zero-G, you could actually see blobs of liquid and all sorts of particles floating around, suspended in the air. Little things like that really immerse you in the environment, and really feel as if you are there.


What increases immersion further is lack of any sort of 'menus' and GUIs (besides the pause menu of course). All the information you need to know are neatly visualized on Isaac's suit itself. His health appears as a tube on his back, and the stasis meter is right beside it. When reading your weapon, the current amount of ammo is shown holographically on the weapon itself. The crosshair is represented by blue laser pointers. Nothing feels out of place, and every piece of information the player needs to know is presented in a very believable way. Even the inventory screen is projected in front Isaac, and as the player makes selections, Isaac's head looks at the item. Again, it's the small things like that that really show the amount of effort that went into the development of the game.

An example of Dead Space 2's GUI in gameplay

Mechanics


The main gameplay mechanic revolves around dismemberment. You will waste a lot of ammo simply trying to shoot necromorphs dead. In order to effectively take down any creature, you have to dismember it to make it useless. This holds true for smaller and larger monsters alike, and even Isaac himself. In various execution moves that the enemies can achieve on you, Isaac is usually torn apart limb from limb, which is sort of a twisted sense of irony.

If a monster grabs you, tapping the action button will break you out of the hold. If you are low on health, then you are out of luck.

The camera, inventory, shop and aiming mechanics are inspirations that heavily remind me of Resident Evil 4. The mechanics play, and feel very similar in these games, but it is not a bad thing. Dead Space 2 takes, and improves upon mechanics encountered in Resident Evil 4. For example, the movement of the character feels a lot smoother, and more fun to control. The various weapons you have at your disposal also feel smoother and more natural to aim.



The tools at your disposal are various industrial machines, and one military grade assault rifle. Each weapon has a primary and an alternate fire. Both types of firing mechanisms consume from the same pools of ammo, which handy because your inventory usually can only hold a limited amount of items. A lot of the tools strangely seem to be almost too useful for dismembering limbs. It is never really explained in gameplay how these tools are actually useful for the engineer. For example, what exactly is the line gun used for? It fires a wide beam of plasma, and is almost too suitable for dismembering limbs.

Another strangely suspicious 'industrial tool' is the detonator, where it shoots a proximity mine on the floor (alt fire disables the mine). What use would a proximity mine be to an engineer? It's more of a military tool if anything. It would be nice if instead of collecting schematics for different weapons in a random order, you would find them in sequence. Once you buy the weapon, you would have to solve a puzzle that teaches you how to use the weapon correctly. Before I provide an example, I'm going to change the mechanics of the detonator slightly. Instead of laying down a 'proximity mine' the detonator would instead remotely detonate the mines (as the name suggests). Place a mine anywhere you want by pressing the primary fire, and you could put down as many as you have ammo for. Tap the alt-fire button to detonate the first mine in the sequence, or hold to detonate all mines. If you want to acquire your mine back, just walk up to it and press the action button to pick it back up into your inventory. This now mimics a useful tool for a miner, or an engineer by resembling either TNT to blast apart rocks, or a demolition tool. When the player acquires this weapon, there could be a small puzzle, like blasting apart obstructing debris for example. It could be placed in such a way when detonating the mines right away would be a poor idea, like in an elevator shaft. Let's say it is zero-G and an elevator is blocking your way up the elevator shaft. To get rid of it, you need to blast apart the emergency brakes in order to make it mobile, and attach a thruster rocket to the bottom to move it out of the way. This simultaneously gives the player a context for the weapon/tool to be in existence, and teaches the player the mechanics of the weapon, so that they can use it against the enemy correctly later on.


Speaking of puzzles, these are usually there to break pace from the constant anticipation and fear, with something that is engaging and usually less threatening. The actual puzzles themselves usually only utilize the stasis feature of the suit, where any object/enemy is slowed down significantly, or kinesis, where you can pickup objects from far away with a bolt of energy. There are some that also use a thruster rocket, where when it can be attached to various objects. Most of these puzzles are fairly obvious and don't require much timing/thought. It would be nice if the puzzles incorporated the use of your industrial tools to solve it, like in the example above. Of course ammo would have to be provided somehow in case the player has trouble figuring it out.

Sometimes a hacking mini-game is also used in puzzles

Another neat feature is that the player can use environmental hazards to defeat his enemies. There are stasis and explosive canisters that can be thrown at enemies using kinesis. There will sometimes be a pane of glass that can be shot in order to create a vacuum. The resulting force sucks everything out of the room, and this can include you if you don't shoot an emergency switch in time which activates a door shutting mechanism. If you don't do it in time, the door will crush you, providing a trade-off to using this environmental hazard.


The resource systems in this game are fairly standard, and don't offer too much in terms of innovation. The player has health, stasis and air. Stasis is used to slow down objects/enemies, which can be useful when getting swarmed by monsters, and air is used to put a limitation on the time a player has by putting him/her in a vacuum. The suit provides you with a limited amount of oxygen, where usually at the same time you have to solve a puzzle or run to an adjacent room that contains air. Health is pretty self explanatory.


There is a standard concoction of items that can be found lying around either in the open, hidden in a crate, or inside a monster (pops out after defeating it). Usually it's things like health packs, ammo, power nodes (used to upgrade your armour and weapons), schematics (used to 'invent' new things to buy), and credits. Schematics are neat because in order for you to buy anything at the shop, you have to have a schematic for it first. The shop 'downloads' it, and presumably makes it for you right there on the spot. This encourages players to explore, as they are usually hidden out of view or in hard to reach areas. Credits are a pretty obvious resource that player usually scrounges for, especially on higher difficulties where items are less likely to be found or dropped by monsters.


Overall, the mechanics of the game form a simple system that complements itself well. There is a lot of room for improvement in terms of player experience, puzzles and minor issues with the weapon sandbox design. Otherwise it is a solid experience that can hold its own against other major triple A action/horror titles.



Technology

Dead Space 2 is available on the PC, PS3 and Xbox 360, and from the looks of it, it continues to push the boundaries of what consoles and modern PC's can accomplish. Lots of shader effects, particle systems, dynamic lighting and other technologies are implemented. The lighting effects are phenomenal, and a dedicated lighting team was used to specifically light every scene the player encountered in the 12-hour single player mode.

To get a better grasp of what the lighting is like in Dead Space 2, here is a perspective from the dev team themselves:

 

Raptor Racers: Week 3

Work on the game has been going very slow, actually, I don't think there has been any progress since last week. We only had 1 group meeting since the last blog entry, and not much has happened since then. There is a haunting reminder in the back of my head to take more of a look at the existing code base and start adding on to it, eventually I hope to always have the most updated code on my hands.

The reason behind this is mainly our group's agreement that we have to get all (or at least most) of our assignments out of the way before we start to systematically tackle each requirement for our game. It is nice to have homework that isn't individually due to a specific date (like for this class), because this gives us the flexibility to finish them as soon as possible. Unfortunately that can't really be the case for any other class. Graphics, Sound, Accounting and Business for Games all require us to have specific knowledge to complete the required assignments. Various assignments keep popping up every week that surprisingly consume a lot of each group member's time. But we'll try to get most of them out of the way, and start to worry more about our implementations for the game.

The plan is to fix up, and in some cases re-implement semester 1 features and work more on the actual game play aspect of the game until the end of February. Things like improving how the animation system reacts to player input/game world, doing proper collision, proper texturing techniques, proper lighting, fixing the skybox so it isn't stretched to hell, fixing up Raptor textures, etc. It is important that we at least finalize the design and start to realize the limitations we have to work with by the end of February. In some cases, certain game play features might conflict with other parts of the game (Ex. what if our collision system can't handle jumping?). That is our goal for now.

After February we will hope to have learned some intermediate computer graphics knowledge (shaders, texture and lighting effects etc.) to start working on implementing them. This also goes for practicing how to use FMOD with our game, and how to use the FMOD Designer. Sound is the only thing that I have almost no knowledge of. All other fields I at least was curious about learning in high school (and apparently did a decent job at), same goes for the rest of my group mates. We need the time to practice how to record/implement sound into our game properly. This will most likely consume most of our time in March, and hopefully by the end of march we will start to polish features we implemented earlier in the month.

As for April, we will be mostly busy with meeting requirements for this class, and preparing our presentation for Julian's class. I don't think we will have much time to polish our game in this month, but this will have to see.