I was the programmer for our game project, so it was my job to do all of the coding and scripting. Since I just finished off doing an ActionScript-based game in Flash, much of the Unity-flavored Javascript was familiar to me. It went fairly smoothly as far as the actual coding process, but it was a pain in the butt trying to get some of the more basic mechanics to work right. I knew what I wanted to accomplish, but having never used Unity before, it took me a while to understand the coding logic required to make that work. Unfortunately, once I determined what the structure was going to be, I ended up spending countless hours trying to make sense of the wiki and documentation/scripting reference. A piece of code would make perfect sense to me on the site, but when I tried to adapt it to my game’s variables and assets, it would not work or crash the engine. There is nothing more frustrating than taking a “guaranteed to work” piece of basic code, dropping it onto an object, and having it give you errors. The biggest problems arose from having an object turn its mesh renderer on and off with a collision event; I literally spent two afternoons trying to come up with something workable. It was only after Alex did some research and found a messaging library that I was able to get it running. I did enjoy the straighforward way that the designers of Unity have implemented scripting as far as attaching it to assets and such though; drag-and-drop application of code is really nice.

Swim! would have been a much more enjoyable project if I had known more about scripting. I could have worked faster (and been less stressed out) giving us time to do more refining. Regrets aside, Ellen’s characters fit perfectly with the aesthetic we were shooting for in the final project, and overall the game looked great.

If I had the chance to do this game over from the ground up, I would do more with the artwork and animations. The core idea of the game was pretty solid, but I think it lacked on the user experience side thanks to limited animations and simple artwork. I would have liked custom textures and prefabs, as well as programming a more accurate water texture. I would have liked to do more with the animation editor too. Overall though, I think we did an awesome job for only having 5 weeks to learn unity and build a fully-functioning game.

Reviews:

Subject Escape Final:
The game starts off fairly strong, giving the player an immediate sense of the situation and location, as well as presenting an obvious next step to get things rolling. Your descriptions were vivid, creating an engaging story that elicits a definite emotional response from the player. I experienced some technical issues about half way through the game though. After I had procured the flash drive and the note, I was unable to escape from the hallway. The room description said that the escape door was to the south, but upon looking or walking to the south, I was told that I couldn’t go that way. I found myself stuck without any clue as to where to proceed. The narrative was kind of weak as well; your descriptions were vivid enough, but I found myself wondering what the point was, short of gross-out shock value. Also, you may want to re-consider your use of the F-word in your story. IF is about story and narrative, and when I see wording like that, it’s a little like throwing a dozen animated GIFs into a slickly-produced flash website; it totally destroys the experience, making it seem like cheap entertainment instead of a carefully crafted player experience.

Who Done It:
First off, I am impressed at the degree of detail you’ve put into this IF. Around a dozen NPCs, many objects, and a whole house worth of rooms makes for a rich experience for the player. I liked how you set up the conversation system, so that it is clear what the player can and can’t say. The descriptions are concise and complete, telling the player exactly what they need to know. The world model seems very real, and the objects and characters are believable. I think the thing I had the most problem with was the sheer magnitude of your IF. You start playing, and quickly realize that you are going to have to question every NPC and examine every object in order to come to any conclusion. As it would be in real life, some conversations with characters result in little to no information, while others may give you a valuable lead. The problem is, you practically need a notebook to keep track of how everyone is related to each other and what they said when you talked to them. And, if I hadn’t of had the advantage of finding out about this in class, I would have never known that you (the player) was carrying a magnifying glass, black light and fingerprint scanner. I tried using them on a few objects, but I couldn’t figure out the exact wording to make most of them work. After about 10 minutes of playing, I was feeling incredibly overwhelmed by the sheer volume of information to keep track of.

The House:
This is the only one I managed to win. Granted, Ellen has been working on this for quite a while, but I thought it presented a concise player experience. I liked that all the objects were relevant to the story and had clear uses. The buffalo was an entertaining NPC that felt surprisingly friendly, and he served the information you needed in a very natural conversational way. There isn’t much to critique here; I found little in way of misunderstood commands and objects without descriptions. The story seemed very linear, but this may be because I inadvertently made my way straight to the quarry and immediately got trapped therein, forcing me to complete the game successfully without further exploration of the world. About the only thing that felt a little hokey was the whole “touch the jellyfish and magically be able to breathe under water”, but this is a minor issue. The swimming mechanics worked perfectly, and I really like the overall flow of the game.

Observatorium:
Well, this certainly was an interesting experience. I enjoyed coding with Inform7 overall, and I think it is quite a bit easier than Javascript (although the logical structure of Javascript makes it easier at times to code more complex interactions). Developing a game that is 100% artwork free took some adjusting, since nothing can be taken for granted. If an object isn’t described, it isn’t there. It was hard at times to be able to take what I was imagining and translate it into Interactive Fiction because I occasionally took for granted that the player can’t read my thoughts and imagination. I had to be very careful to remember to make sure the text in the story was describing everything I was thinking. The development process was pretty easy as far as coming up with ideas and planning out the puzzles. I like that Inform7 forces you to focus more on your narrative and make careful decisions as to if a certain item or room will be cohesive with the rest of the world model. Useless objects can become distracting to the player, whereas in a typical FPS, items with no benefit simply serve to enhance the game world. My coding to make a working elevator turned out flawless, and I was very happy with some of the more complex thing-NPC interactions (being conditional on location and such). I managed to build a working machine that had to be set correctly to unlock a door, and I somehow created an NPC that can be carried around in the player’s inventory. In playing back through my game once I had turned it in, though, I began to see some errors and rough spots I had missed before. A few of the descriptions weren’t working the way I wanted, and there ended up being a couple of objects serving no narrative purpose. Originally, I was going to have the sparkly pajamas serve as a major prop to solve one of the puzzles, but due to time constraints and coding issues, I ended up cutting it, leaving the pajamas as a comic prop. The worst error I made was that a certain description didn’t show up when it should have; this would have given the player a clear indication of the next step of the puzzle, allowing the win state to be reached without innumerable guesses at a solution. Sadly, I couldn’t get it to appear in the game, so the solution to the final puzzle is largely guesswork. There are a few other minor details that I would have liked to tweak (getting the window to respond properly to actions applied to it or giving the Gnome more interaction options), but overall I am pleased with how it turned out.

My world model is primarily designed around giving objects to an npc and reading the reactions. Because of this, I don’t have an advanced conversation system or any great number of scenery/non-interactive objects. I want the player to examine the space, locate the objects, and decide how to use them to solve the puzzle. This is exemplified by your interaction with the npc; I allow for the player to pick up and carry around the npc, as well as use it physically to complete one of the final tasks.

The parser in my IF is designed to downplay interactions that aren’t necessary for completeing the game. Descriptions are written so as to indicate what actions the player should try with the object. Everything in the world has a fairly clear use (can of beer, or stack of papers) so the actions the player would choose often give the desired results. If the player attempts to use an item in a way that would remove it from play without it completing its true purpose, the reply is written so as to indicate to the player what they should try to use it for instead. I kept the actions as straightforward as possible to minimize player frustration, and there are very few multi-item actions (such as Hit Gnome with Hammer).

My output is very straightforward as well; I didn’t have much time to mess with re-formatting printed descriptions and the like. Had I a larger game, I would have used some formatting, but I kind of like just presenting the information as the player would have seen it in real life. Again, simpler interactions help cut down on the need for visually emphasized text. I would have liked to play around with breaking up the text a bit for some of the longer descriptions of action, giving them a bit of visual appeal.

In all, I can see how you could spend days perfecting your parser and world model to allow for hundreds of actions and responses in an attempt to provide the player with a more immersive experience. However, this loses a bit of what IF is: an interactive story where you only do and see what the designer wants you to. It is limiting the experience so as to give the player a better feel for the game’s world and story. Like Emily said… if the game is about human interaction, you don’t need a realistic water simulator.

“The elevator hums to life, clattering heavily. The overhead lights flicker slowly as you pass between floors. Finally, with a dull chime, the platform stops moving and the doors rasp open.”

Inform, thus far, hasn’t been to bad to work with. Since it is based on a “natural english” coding language (and yet still acts like any other code), knowing how to set up logic statements can be frustrating; you want to tell Inform, “When the player turns the knob, the lights go on and the room is bright. Now, the monster has retreated to the closet, but has left footprints on the carpet…”. Unfortunately, it’s a bit more complex than that. Once I was able to wrap my head around how everything fit together, things have been running smoother. I was (mostly) able to get my elevator running, and all four of my walls in my main level are operational and easily inter-navigateable (if that’s a word…?). I ended up simplifying the upper level to keep the player from getting too lost. I like how easy it is to introduce new rooms and items into the game. Inform’s backend engine is pretty robust, so it doesn’t take a huge amount of work to get stuff placed. NPCs are a little more difficult to code, since all the interaction has to be thought out beforehand and explicitly coded. It was fun trying to work out giving certain items to my NPC, because he can be carried around the level. There’s a pretty nice section of code in my game that deals specifically with how the NPC responds depending on where in the room he is when you give him a certain item; it was a great feeling to hit “GO” and have it work the first time. It took me a while to understand the “before” and “instead of” commands as well. I would say that the most demanding thing so far that I’ve had to code has been getting the garden gnome to take off his pajamas and give them to the player; sounds stupid, but it took me the better part of an afternoon to get the action workable.

And so another quarter ends. I am pretty happy about how Brain Challenge turned out, but as with anything, it had its positives and negatives. Here’s my final consensus:

Our Dev Team consisted of myself, an experienced graphic designer with one class of game design under my belt, Michael (a programmer and teacher here at MCC with digital game creation experience) and Tyler (who also has graphic design experience). Despite personalities that varied greatly, we were able to work together pretty well.

The original content for the game came from a random selection of miscellaneous pieces, so we had to work with an un-planned assortment of pieces. We were allowed to make our own pieces later on in the development process, but much of the formative steps took place while we were trying to figure out how to tie license plate cards, mechanical football players and small plastic cars together into an interesting game.

What Worked:

-We were able to iterate a solid idea pretty quickly, so we didn’t have to hammer on an idea for weeks and weeks.  We didn’t need to do any major revisions to the original concept, so we had more time to work on the details and mechanics.

-We were dealt a fairly cohesive selection of pieces on the first day. We got two player tokens and a number of other miscellaneous items, but it became apparent early on that what we were working with would lend itself to some sort of inventory system. Also, the addition of a 20+ sided dice gave us some interesting creative options. Ultimately, it was this piece that allowed us to have a good number of “randomized” options without having to use multiple dice or cards.

-We worked hard to keep the mechanics for the game fun and engaging without creating some unwieldy system of items and abilities. We knew that at the foundation, Brain Challenge was supposed to be about social interaction over problems, like sitting with a friend and trying to complete a puzzle or finish a cross-word. One of the major cuts we made was the ability for the player to have a card that would give them extra abilities if the letter on their card was rolled on our 20 sided letter dice. This was a great concept, but in practice it proved to be awkward and unnecessary.

-All of us in the design team had former graphic design or programming experience, so we all understood the mechanics of game design and game artwork.

-We got some very constructive feedback after our first iteration, so by the second version, there was only minor tweaks necessary to make sure everything ran smooth. Our goal was to have a concise and easy-to play game for two people that didn’t take more than an hour to complete. Faster playtests meant more games played and more feedback from more people.


What Didn’t Work:

-We didn’t discuss much of an art direction for the content of Brain Challenge. We had a story and premise to work with, but our board style was steampunk, the pieces Monopoly-esque, and the box art and cards looked corporate-professional. It would have been good to sit down as a group and establish the visual direction we wanted to take and stick to it throughout the development process.

-Our team didn’t work together very closely, so while there was a general consensus on the direction of the game, the actual artwork and execution was a little more ad-hoc. I would have preferred that we met a couple more times to further flesh out some of the details and firmly establish the visual aspects.

-Brain Challenge has approximately zero replay value once you’ve seen all the cards. This is due to our using license plate cards as the thing to guess, but once you’ve seen them, you remember them. We tried to find a different way of running the challenge mechanic, but the ideas we came up with lost the essence of what our game was. It rapidly became unwieldy and boring, and felt more like an academic exercise instead of a game.

-Despite the funky premise, the game really doesn’t engage the player into the story and character. There is this strange disconnect between the narrative of the story and the player’s experience. I think the game is fun as an interaction, but the story could be completely changed and it wouldn’t affect the play experience.

In all, I had a lot of fun with this project. I would have preferred a slightly more interesting selection of pieces and boards, but what we had worked together really well. This was a great exercise in creative problem-solving and imagining interesting stories and content on the fly.

I really enjoyed playing these educational/interactive episodes. I think it was a great idea to require interaction with the piece in order to glean the information; it feels more like reading a magazine (with lots of pictures and examples) rather than a textbook.

Anyway, as far as the episodes themselves, I thought they all delivered their content solidly without being boring or confusing. The third episode was a lot of fun (I think that’s the first actual tag game I’ve played on the computer…). I definitely agree that the more abstract the character, the more the player can identify with it; however, I don’t think it’s the rule. Honestly, while playing through the Half Life 2 series, I felt incredibly immersed (so much so that when a major character was killed, I actually felt a moment of sadness) even though the character you’re playing as is a clearly defined individual who has an entire story and history attached to it. I don’t like it when a game casts you as some major hero who acts quite unlike you would during cutscrenes, but otherwise does your bidding. It pulls you out of the experience, becoming more like a movie rather than a personal event. Same thing goes for control of your character; third-person games annoy me because it’s like you’re operating a puppet in this virtual world, whereas first-person adventure games are incredibly engaging because you feel like it’s actually you experiencing everything that’s happening.

The second episode was a little tedious with the game. The first two were fine, but after that it just kinda got annoying; I was there to learn, not figure out some easy yet lengthly game with little to no point other than progressing the lesson/story. It is true that players often trial-and-error their way through video games; I can’t remember the last time I bought a game and immediately sat down to read the manual. Reading that is usually an extra treat after you’ve played through stuff for a while… a novel way to discover a few other bits and pieces that you may have missed in-game (or the odd key command that would have made things much easier… it took me until the end of Half Life 2 to discover that there was a Sprint button).

I decided to work with one of my favorite games, Halo. The embedded narrative is pretty minimal; you know that you are a supersoldier fighting an alien race bent on destroying humanity (Cliche’d? Yes. Oh well. I like the game anyway). Past that, you get most of the story by playing through. As things progress, you learn some of your background, the series of events that kicked off the game, and what you need to do to get yourself out of the predicament you’ve been thrust into, along with a lot of intrigue and adventure during that time. The designers at Bungie decided to use the typical cut-screen to communicate the bulk of the narrative, with in-game dialog and events filling in the rest. You discover most of the information through Cortana, the ship-board AI who acts as your navigator. It’s a brilliant idea, really. You have the AI because you are protecting it from the aliens, but it gives a perfect excuse to have some way of feeding you vital information without some omniscient floating text pointing the way. The story of the first Halo largely revolved around a mystic theme, as you are exploring an ancient weapon/construct, trying to discover its purpose. There are many unanswered questions relating to function and purpose, but this helps the experience feel more realistic. This is also reinforced by everything from the title (“Halo”) to the level design (lots of huge interior spaces that resemble ancient architectural conventions) to the music (very atmospheric and dark/mysterious). Even though there is a good portion of the story that isn’t revealed until later installments, the first episode did a great job of drawing you into the mystery surrounding the existence and power of the ring world you’ve landed on. Even after having played the entire game as many times as I have, there are still little bits of narrative that I catch each time.

Well, I only got around to playing For A Change the first week because frankly, I was so mezmerized that I wanted to explore it as completely as possible without being rushed to play any of the others. As a completely irrelevant side note, I found the choice of color a bit reminiscent of the BSOD. Anyway, at first, I quite liked it. The wording was was cryptic, but poetic. Having never played an IF game, it was pretty entertaining to type “go south” and my character would then move in that direction. While I was playing, I copied down some of the more entertaining answers to some of my commands:

grab spinster — the spinster is, and remains, where it is
eat guidebook — That’s plainly inedible
hello — hello
take toolman — the toolman is not yours
jump (off of the tower flagpole) — that would be suicide
take flagpole — the flagpole isn’t going anywhere, and you don’t want it to
give stone — (to yourself) you juggle the small stone for a while, but don’t achieve much
jump — your altitude quickens and gradually declines

I found my way around well enough, but after a while, I began to get frustrated, mostly because I had no visual reference for how the area was layed out or what the object looked like. For example, upon finding the lie opener, I had no idea how to use it, and when I would type “use lie opener” it wouldn’t recognise the command. I finally had to read through the hints section to discover how to use the objects I had grabbed. Even after reading that, I realized that I wouldn’t have ever guessed to do what they suggested.

UPDATE: I played through Dead Like Ants, and I think I actually like For A Change better. Sure, it was easier to understand navigation with DLA, but after being abruptly eaten, I found the experience disappointing at best. It felt like your movement was far too “fated”, and it seemed like everybody in the story treated you like a little kid who didn’t know anything.

I like the mechanic of IF, as it forces you to use your imagination. I found that the mental image that For A Change painted was great, abeit somewhat surrealist. However, the amount of information you lose by not having visual reference is enough to make the experience frustrating at best. If there were some way of combining the concepts of IF (like what was done with Myst) with the graphic power and interactibility of of the modern FPS, it would make things a lot more fun.

Hmmm… I actually managed to get through the whole thing without looking at the help. Honestly, I liked it. It had a very poetic and artistic quality to it. While it may be considered a flash “game”, I think it would be closer to a story (although a story could be considered a game…). It’s like interactive poetry.

At first, it’s kinda frustrating, because it’s this cutesy little game, but you have no idea of how to play it. However, once you get the hang of it, it’s pretty enjoyable. I feel like there was more to the story though… the bit that they give you in the game works and works well, but part of me wanted more.

Today I Die uses words as actual pieces of the game, both using their meaning to guide the player, and having the physical effect of being available for manipulation. As Chris said, they are keys that fit into the linguistic locks of the game, much like puzzle pieces.

Elrod suggests that other gamers are approaching Today I Die like most other goal oriented games, where the requirement is to beat the game, and the player must deal with the constant risk of failure. However, he suggests approaching it from a more exploratory direction, where the point is to discover, not conqueror.

I would say it’s still a game, since one can define a game as simply interactive entertainment without real-world consequences. I’d say this falls squarely into that category.

Corvus considers the piece to be more of a poem, which is exactly what I thought of it as.

Most of the games I’ve done so far would not fit this styling, since they are predominantly objective-based and competitive. You would pretty much have to design the game from the ground up if you want to make it a predominantly exploratory. I’m not sure that this would work as well for multiple players, since this idea of poetic experience seems to work best when taken at an individual’s preferred speed, since each person is going to derive a different experience every time.

So we’re in the middle of Snow-pocalypse 3… I think it’s about time we stopped with the snow. Seriously. However, for something completely non-weather-related, I give you Blog Assignment 2:

Our game (as is) is strictly 2 players. Varying that in any way would largely just be incompatible with our current rules. However, if we worked with it, there might be a way of working as two teams of players. For instance, in 2 vs. 2, one team member could be responsible for completeing brain challenges and the other for strategizing movement and combat. We might be able to even re-write the brain challenges so as to involve both team members. I think that any number of players past 2 on a team would make it boring and unwieldly. A second variation, which would probably work even better, is to have an unbiased 3rd player who controls the “globals” of the game. For instance, they could be the one who conducts the brain challenges, or maybe influences player movement or fighting. You would still have the one-on-one interaction of the original idea, but you open up a lot of opportunities for variation by giving a third person the ability to influence game play.


It is mostly a competitive game, using a mixture of mental skill and strategy to accomplish the goal. As I said, it is pretty much impossible to do teams of people, because the system would be cumbersome at best. The upside to a one-on-one structure is the game tends to move rapidly and keeps both players on their toes. However, it also becomes much like a ping-pong match, losing the social dimension you get with team play or multi-player structures.