Raptor Racers Week 10

I skipped week 9 by accident, but there has been quite a bit of progress since I last posted. The animation system is mainly done, and looks a lot smoother because I cut out the 'secondary Pose' and interpolating parameter entirely. It was not needed at all, and the animations actually look smoother and work better without it, especially transitions from pose-to-pose.

Now, with lots of help from Brent Cowan (our Graphics TA), I've developed a proper cel shader which looks totally awesome! Cel shading tutorials online (like lighthouse3D for GLSL) also helped, and provided me with information and know-how to understand how a cel shader does what it does.

Above is an image contrasting my shader vs OpenGL default lighting. There are actually 2 separate shaders working to achieve this effect.

 The first shader is a shader that does the outlines. The shader file itself is actually very, very simple. All it's doing is moving a vertex along the normal to 'fatten' the model. I'm telling OpenGL to disable lighting (so that it's one solid colour), and to cull faces that face the camera, as opposed to away from the camera before the shader is actually used. The back-face colour is what makes the colour of the outline, the shader can take that as a parameter (colour) and also line width. That way, we can have different line thicknesses and colours for each object, or even a different state of the same object.

This would be something like a 'selected' effect

The second shader takes care of the lighting, and actually draws another teapot inside the 'fattened' version. Depending on the angle between the normal and the light, the shader just clamps diffuse/specular (etc.) values in a certain range. This can be done for a variety of light types, not just diffuse.

Diffuse + Specular cel shading

Small white highlights for something shiny (like a robot raptor!).

'Glassy' + Diffuse + Specular

 I'm not sure what the glassy effect would be used for, but I modified Brent's code for edgeGlow and fillLight to be cel shaded. It's there if we need it. All of these effects are under the lighting shader. Our game can pass a parameter to the shader and tell it to use/not use different effects (diffuse is required, obviously).

The darker areas look a bit gray due to the ambient value, I'm not sure if either looks better.

Without the ambience, the black outlines blend into the teapot, so we're going to stick with ambience for now.

Raptor Racers: Week ... 8? I think

Wow, it's been quite a while since I last blogged, I guess my excuse would be midterms and my internet being out for two weeks, but mostly it's just me forgetting. Anyways, let's get down to business.

I remember mentioning a while ago that I wanted to implement a better animation system in our game that can support multiple blend poses (secondary and primary poses), and for the most part, I am done this system now. It works fairly differently than what we had implemented before. What happened earlier is that all the animation system would do when called is set what the next pose would be, and let the drawing function for each raptor determine the actual positions of the vertices & normals that correspond to the model. Each raptor would call this drawing function one at a time, and all of the code used to be in main, and it looked fairly ugly. The new system takes up a bit more memory, but I hope it proves itself to be more useful and flexible down the road. This new system, first of all, cleans up all of the animation code out of main, and in a special function in RaptorClass that gets called by the player and each raptor AI. I have an OCD-like tendency to clean up main as much as possible, and seperate everything into classes. Unfortunately this is a luxury when trying to code something up really fast, and this is the reason why our original animation code was all over the place. RaptorClass also recieved a couple of new member variables. One of which is fairly huge, which is an ObjLoader object. There are several huge arrays for storage of vertex/normal/texture information, and I'm not sure why they are this way. Apparently messing with the max values completely screws up our texturing, and sometimes our normals. I have a suspicion that not all the arrays need to be that huge (10,000+ max size!!!), and that only one array needs to be big enough to store all the information related to faces. I don't know though, I'd have to bring this up at the next group meeting. The other variables are pretty insignificant, and are just integer values.

One new function was written to take care of just the interpolation. The theory is that instead of drawing the object as soon as you interpolate it (our old system), you do all of the blending in one place multiple times to achieve in-betweens of different poses and store that in memory. All you'd have to do in the render function is just to draw the information that is in the variable stored in the RaptorClass (our new system). I'm hoping this will be somewhat more efficient, because the actual math is all being done in one place, and in bulk, separate from the drawing.

A pretty significant downer I did not anticipate though, is that when blending multiple poses together the latest pose often takes precedence. This produces a result that looks almost exactly the same as the previous animation system. Maybe it's just the way I'm blending, because the theory sounds to be correct.

I may tweak the code in the future for the animations to be more dynamic. Right now, I'm going to try to focus more on shaders, getting a proper HUD to work, our very simple 'level creator' or maybe trying to fix textures (using PNG's instead of BMP's due to size issues).

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.

Raptor Racers: Week 2

Progress on the game has been going fairly slow, as our group has had relatively unproductive meetings in terms of content output. However, we did talk about concepts and the future of the game itself. As usual, I was tentative to have my 'head in the clouds' (as Lindsay put it) when it comes to thinking of different game ideas and what we want to accomplish for this semester. In retrospect, yes, most of my ideas were too far fetched. Having different kinds of raptors have special abilities (each requiring their own animation to use, sometimes even a particle system) would've been neat. They also could've had their own individual textures/addons (mainly feathers). Maybe I'll just save these for another post.

Since the group is in general confusion, and now working on their own thing (mainly assignments for other classes), I have decided to focus on animation. Our raptors need an animation for jumping, getting hit by something, breaking (as in, losing speed, and not literally breaking in half), and it is my job to start making them all in Maya. My philosophy seems to be to create more poses and utilize them as much as possible along with the few cycles that we have. Something like a crouching pose blended with the running pose to give the effect of preparation for a jump. That same pose can also be used when the raptor lands. The animation would start out 100% on the crouch pose and gradually let off until the raptor is running again. Or when a Raptor is running and grazes an object. It would be nice if the raptor actually reacted in some way, like getting hit. The reaction would be blended differently depending on how far in the object went. Maybe that's a bit too much, I guess speed could be a good parameter, but I'm not sure. I'll have to play around with the numbers and see what looks right. Hopefully things will turn out looking relatively smooth in the end.


I guess this is also the time to mention that our team has scrapped the idea of having skeletal animations in our game as of last meeting. It was deemed to be too much work for the payoff. The final product was going to look exactly the same anyway, so we decided that we shouldn't spend our precious time doing it. I think we would rather have various shader effects/sound to be in our game and relatively polished, rather than something that no one will be able to tell is in the game (unless we told them). I feel like having something other people can look at and be in awe is more important than a technical detail that only a few people will be impressed about (that is even if they find out).

10 Min exercise

The game chose for this exercise is Crackdown for the 360

When I first started to play this game, I was introduced to a fairly lengthy comic-book style introduction sequence, explaining that the police have formed something called the 'agency' and I was one of their prototype agents. The city is in a state of war against crime, and I am some sort of super cop fighting against the bad guys. There are three major 'kings' or lords that control 3 major gangs that I am supposed to eliminate, but in order to get to them, I have to eliminate their generals first. The narrator then told me that he is my only friend, which was kind of odd, since I am on a police force full of people who are supposed to be trying to help me...

Anyways, the game starts and I am in a cylindrical garage of some sort. The narrator was talking, but I was busy trying to figure out what each of the buttons did rather than pay attention. Since the game kind of dropped me in this place randomly with no pre-cursor as to who I actually am (character wise) or where I am.

Looking around felt very rigid, and the running looked kinda goofy, but the animation for jumping looked cool. I noticed now that the game uses a cel-shaded look, and figured that the physics aren't really meant to accurately reflect real life.

Right as I got the hang of the movement controls, I heard the narrator say something about a car, so I ran around looking for a vehicle and found some police cruisers. Where to go wasn't really mentioned, so I started do drive to the nearest gate. The narrator said that this area is 'too dangerous' for me, and this happened with the next gate. I guess this was intentional? Was it foreshadowing the dangerous road that lay ahead of me? Or was it my own fault for not knowing where to go?

The gate opened up, and now I am driving at full speed in a tunnel, presumably to the surface. It's lit like a cartoony racetrack, with strips of neon lights at the sides of the walls. I'm following the contours of the track, and I am beginning to get the hang of driving, and it seems pretty fun. The car is responsive, although the camera sometimes gets in the way. I was about to go off of a jump at the end of the tunnel, but a pop-up stopped gameplay and fed more story to me. Something about my next target, or who I'm supposed to kill. This broke the flow, especially right as I was about to go off of a jump.

After the pop up vanished, and I landed the jump, I saw something purple on my mini-map in the lower left. I assumed this is where I was supposed to go. The narrator has just told me I need to take back some sort of weapons cache. So I start driving in that general direction. Without knowing it, I apparently entered some sort of race, and upon realizing this, I immediately drove in the direction of the white icon on the mini map, where my destination apparently was. Go figure.

Getting to my destination, I saw some sort of shootout between the cops and the gang members, but not knowing the combat controls I kind of ran around unproductively and took potshots at them by pressing the right trigger. I learned that the left trigger was lock on, which made aiming significantly easier, but also felt kind of cheap, because it does all the aiming for you.

The gang members eventually fell, and I had to get up to the balcony they were shooting from. Conveniently the architecture of the building kind of looked like giant stairs, and that the supercop I was playing as could conveniently jump just as high as each step.

At the ledge there was an orange marker, when I walked in, a UI popped up, asking me whether I wanted to re-fill my ammo, or travel to another part of town. I chose the former option, and continued on with my mission. Trying to jump off, I accidentally pressed one of the bumpers, which caused my character to throw a grenade off the building. Hearing screams down below, I was fairly sure I killed a couple of civilians... Oops.

The car I entered in this fight was gone, and I took some random hunchback that was parked nearby and drove around pointlessly until the 10 min timer went off. I think I managed to get some gang members killed, but I probably terrified the civilians more than anything.

Some games just miss the point

Introduction

Eve online is my chosen game that I found not to be fun, and I think is one of the more boring games I have played for a number of reasons. I'm going to be mainly discussing the poor choices of interface design and game play design that were used, as there are many.

To give a brief description of the game, it is an MMO where players pilot spaceships in a massive galaxy, where each star system of the galaxy is an actual space that can be visited. There is a space for newer players in the center of the galaxy to learn how to play the game, and how the game world works. This space is protected by Police like vessels that enforce the rules. On the fringes of the galaxy, the space has no laws, and players are free to do whatever they want.

Players can pick what race they are, this has an impact of where you start in the galaxy and what types of ships are available to you. This is really only for style, as different ship types are the same throughout the different races (small & stealthy, big guns, drone carrier etc.). You can bother customizing your character (the pilot) but this is pointless, as nobody really sees your character anyway, and only sees the ships you pilot. The ships all look the same though, you can add different guns on to them, but their appearance mainly stays the same. So you essentially just blend in with a lot of the other players who are relatively in the same position as you (ex. newbies who are just starting out). 

Once you actually start playing, there are your generic "go here and kill this" quests for 'agents' that you can do. The game provides back story for them, but there are mainly only a couple of different types. Once you find a mission you can do, then you're all set, killing things in video games is usually a fun thing.

Usually, but not when the UI looks like this

 Seriously, not only do the little window boxes and the many different icons look like they belong in an excel spreadsheet, the actual combat is mind-numbingly boring. To give perspective, you're supposed to pick a target from that giant list to the right, click on it, and press a few buttons to make your guns fire. That's it. That's all of the combat in this game. You don't aim anything, you don't control anything, hell, you can't even move. You can tell your ship to be a certain distance away from somebody, but that's just hacking it. So to sum the combat up: you click a few buttons, and sit there and watch. If part of your exciting combat system is 'waiting for something to happen', then I think you've got a problem on your hands.

It would help if the things you're shooting at were actually visible in some way. Enemies are represented by their name, and a red cross icon to tell me that they are hostile and put inside a giant list. Yeah sure, there are icons on the screen too, but that's just making the problem worse. Now you've got a cluttered up visual space with a bunch of icons that are supposed to mean something, in a screen space which already consists of the oh-so-fun looking windows forms. The problem is that nothing that I am doing feels relevant in any way. Sure a text box can tell me that I've hit something for x amount of damage, but I don't get to see the results of my actions.

Reminds me of a text adventure

I could also talk about mining, but that is even worse than combat. Your ship just goes up to an asteroid and fires a laser for 20 minutes. You get to see a number go up next to an icon of some type of ore, and that is the extent of mining. Sure the time may be exaggerated, but that is certainly what it feels like when you're doing absolutely nothing. They could have at least added a mini-game, maybe scanning one, and if you find a rich chunk of an asteroid you get to blast it with your mining laser or something.

Mass Effect did it, and it worked fairly well

The rest of the game is like this too. All of the interactions with the game are done in these odd looking blue-grayish forms. I get that it's supposed to be 'space age', and try to look futuristic, but 'bluish-gray' doesn't really convey that well. Some of the options actually have windows 'folder' icons instead of something relevant.

No really, I am not kidding.

It could have been a picture of a drone, a hangar bay, a door, anything but a folder. It's as if they forgot they were making a game. There are lots of instances of this, which completely breaks immersion, because this just screams out loud "you are just sitting there in your chair clicking buttons" when you're supposed to feel like you're in a game world.

It makes me sad though, because I really want to enjoy this game. The concept speaks to me. I would love to be in control of a spaceship, being a part of a massive world out there that is ripe for exploring. It's just that a lot of the UI and other design issues are such glaring flaws that I can never get into this game, the fun of that concept is just sucked right out, and I can't bear to play this game any longer.

Fun that stands the test of time

Introduction
 
'Master of Orion', created by Simtex Software, released in 1993, is my chosen game that definitely deserves to be put in the spotlight as one of my favorite (and obviously fun) games to play. Despite the game being almost as old as I am, and lots of other brand new and shiny video games out there today, this game still finds its way to my computer screen every once in a while. Something magical about it just keeps me coming back, and I have a creeping suspicion that this happened entirely by accident, as I am usually not a huge fan of slower paced strategy games or older strategy games in general.

The graphics aren't great, but still pretty impressive for 1993.

 

To give a brief description of the game, it is a 4x (explore, expand, exploit, exterminate) turn-based strategy game that is set amongst the stars. The game starts by letting the player choose what size of galaxy he/she wishes to play in, the difficulty, and number of opponents then picking a race to play with (each with their own game play bonuses). In the first turn, the player is given a half-developed home planet, and a colony ship to boot. The goal of the game is to ultimately be the 'master of Orion', or for a better choice of words, master of the galaxy. How you achieve that goal is up to you, as there are lots of different ways to achieve victory. 

The reason why I like this game is almost entirely because of the game play mechanics it employs. The game play offers a very good balance between structure and randomness, and does not let micromanagement get in the way of making important and often game-progressing decisions. The design hits that sweet spot where there is just enough elements for the player to manage that he/she does not feel overwhelmed by all of the game's elements at once. A lot of older (and even newer) 'civilization/sim' games are guilty of violating this, where a new player is apparently supposed to have taken an entire course on just how to navigate the UI.

Providing Structure

 

At the start of each game, Master of Orion gives a player a crash-course in its UI system. Simple text boxes explain what each of the menu options do, what buttons do what, where to find certain menus, and most importantly, why certain numbers appear where they do, and what they mean. The buttons are also laid out in a way that the most important button (Next Turn) is at an intersection of two different 'strips' of information. The vertical being planet info, and horizontal being game play feature info. The eye can easily glance up or to the side after clicking the next turn button to start planning what to do for the current turn. I feel that even simple things like this can go a long way to help ease in players into your involved and complex strategy game. After all, you can't use a feature if you don't even know it exists.

 

 

Higher difficulties do not bother with displaying this info to you however.

After the player has learned his/her way around the UI, the fun begins. The key here is that this game allows you to manage multiple star systems very easily by means of different 'ratio sliders'. Most other strategy games have players running chores, making them navigate from town to town to make sure everything is going the way they want to. This game on the other hand abstracts this out into something very simple. Just set a few progress bars to tell the planet what needs to be done, and then go on your way. Even new colonies will automatically flourish into useful assets to the empire without the player's intervention. However this does come with a trade off, while letting systems automatically develop is nice, the player can usually bring the colony up to full speed much more efficiently. For example, a player should often send colony transports to new found colonies to help them develop faster. Non-tended to colonies will get basic industry up and running, and having the population to man it. After that is done, they will default into producing research points for your empire. The player has to specifically tell planets to produce ships, or develop defenses. If you want the colony to develop defenses, or build factories, or produce your starships, all you need to do is set a slider. 

 Easy and simple, this allows the player to focus on developing higher level strategies without too much micromanagement in the way.

With the town management neatly abstracted, it is time to focus on how your towns play into the big picture. Each planet has a production level, which it can use to either help research, or build ships/defenses. Now, research is structured in a similar way to planet management. There are 6 sliders that represent 6 different areas of study. The total amount of research points from all of your planets are divided depending on the sliders. If you are falling behind in a certain field of study, or simply need a technology from a field of study, just increase the slider. Only 1 slider can ever get 100% of the research points, so it is up to the player to decide which technologies they want the most.

 This screen also provides information on the various technologies you have researched, the last entry is one that is currently being developed.

Here I have accumulated enough research points to discover this technology, and this message pops up in game play automatically.

 

 

 After a discovery, the player tells the scientists what to focus on next. Notice how at the end of the description the research points required are shown. Simple and easy, no need to worry about micromanagement.

 

When the player is happy with their tech level, they usually start designing ships to defend their planets and invade the AI opponents. There are no pre-set units in this game. Every star ship is designed by you. This aspect of the game is my favorite. Here is where your effort and research becomes something tangible. The player puts personal investment into the designs, and thus feels more involved in the game world.

 

 Here is a design for one of my ships. The design menu is intuitive, and the design options are extensive. You can even give a custom name for this ship class.

 

 

Now the player needs an enemy to fight (or befriend, it's really your choice). The computer AI manages to effectively be good competition to the player. It makes all the same choices you do, and even makes it's own designs of ships to counter yours. A neat touch is that every race has it's own happy/neutral sound theme and an angry theme, depending on what you were discussing with them.

 

 The races screen, a quick look at what your relations are to other AI players. Me and my opponent do not see eye to eye at the moment...

 

 

Adding Randomness 

What separates this game from the others for me, is the way it adds a certain randomness to the game play that is worth playing over and over again. Every time you start a new game world, every planet location and type is generated randomly, so exploring never feels old. Some planets offer bonuses, like being rich in minerals to mine to boost production, others offer special artifacts that benefit your research. Other planets may not be so desirable. Some are hostile and you need to develop special technologies to land on them. And one star in particular is in every map, and hold lots of technological secrets should you ever land there, but is guarded by a powerful and ancient machine that you fleet needs to defeat first.

 

Another aspect of randomness being added into this game is the type of enemy you will encounter every time you play. The computer only has 8 or so races to choose from, and on top of that, they can have different personality types that influence the way the progress though the game. Militants often build large fleets, and research weapon technologies, Diplomats usually trade with other species and are more inclined to enter non-aggression pacts with you. Each personality type can also have a suffix, such as 'pacifistic' or 'xenophobic' that adds further depth to the AI players. This also defines how aggressive they are, or whether they are wary of other alien species etc.

 

 

 My opponent happens to be a 'xenophobic diplomat'. I guess that explains why he hates me.

 

Sometimes, random events happen in the game, which either help you or an AI player, hinder your progress or add an interesting touch on game play. For example a single extra-galactic life form can come into your galaxy at any moment, and they are usually bad news, that is unless they happen to spawn in your opponent's corner of the map. They are powerful 'ship' that can wipe out entire fleets and level colonies in a blink of an eye. Or a wealthy merchant can donate to either yours or an AI opponent's cause. These events are designed to keep you on your toes, and always be thinking of the strategy you are employing.

 

 

 I got lucky here! Yes, that is a news robot.

 

Little bits of ingenuity like this is what makes me come back to this game. Master of Orion doesn't necessarily contain the traditional type of narrative that is found in today's games. Rather, the player forges his/her own story in the process of playing the game. Each event that happens is what happens in your narrative. There are small explanations of back story in the technology descriptions that help your mind fill in the gaps.

 

This kind of simple and easy to use design, coupled with a very unpredictable world is what keeps me coming back to this game. No 2 games unfold quite the same way, and there is always a unique story to tell after you have won or lost a game. This is why this game is still on my computer even after almost 17 years after release.