A while back I wrote a simple post with instructions on how to put together some simple AI behaviors in Unity. This is shocking to me in a lot of ways, but my web provider keeps suspending my account because this project gets too many downloads. So I moved the file to Dropbox so that iPage will hopefully stop taking down my website. All of the links should be updated now, and the project should be available once again.
I know that I’m totally late to the party when it comes to GitHub, but I finally spent some time this weekend learning about the technology and I think it’s absolutely awesome. I’m disappointed in myself that it took this long, but better late than never I guess. I love pushing the social aspects of open source development, and I’m a fan of anything that makes contributing to these projects easier. GitHub seems like a great implementation, and a solid step forward.
I’ve already put one of my old projects up there (https://github.com/spgar/Progress), and I’ll be putting a bunch more up in the future.
I got my first game programming gig in May of 2003 at Blue Fang Games (RIP). I left the game industry in 2012 after the death of 38 Studios (RIP). That means I programmed games professionally for just under a decade. That’s a long time, I must have learned something right?
Here’s a list of some things I’ve learned off of the top of my head:
SYSTEMIC: Problems are systemic
I’ve worked for a number of different companies, and have seen the same pain points crop up again and again all over. Different people, different products, different publisher, different console, different target demographic, different management different companies… same exact problems.
I think this means that a lot of the difficulties and pain faced when trying to ship a game are largely inherent to our current understanding of the development process, and don’t generally reflect the implementation details in particular. Different management teams can help or hurt a bit here and there, but it takes a ton of effort to truly fight the system.
BLAME: Be careful with the blame game
Related to SYSTEMIC above, it’s often very tempting to throw blame around from your personal viewpoint. “If person X hadn’t done Y then everything would be perfect!” I’ve personally been guilty of this type of thing in the past, but in retrospect it was never really productive at all. Most of the time the person easiest to blame is just a symptom and not the actual underlying problem.
Publishers are the #1 most blamed entity in game development, listening to some people you’d think that everything to ever go wrong in every game’s development is the fault of the publisher. Now I’m not saying that publishers are blameless (the developer-publisher relationship is completely degenerate), but they are too easy of a target. I’ve worked on several projects with no publisher at all, guess what? All of the problems that people on past projects blamed on the publisher were still there.
Blame, blame, blame.
MISTAKES: I make tons of mistakes
Programming is really hard, and I make tons of mistakes. I think everyone does, but a lot of people don’t seem to want to admit it (consciously or subconsciously).
As a programmer, the counterattack is to use the computer to help you catch your mistakes. Aggressive use of unit tests, static code analysis, interactive testing, etc. These can help to catch a lot of the mistakes I make before they get out into the wild and cause other people pain.
In the past I have been surprised many times by programmers who do not take full advantage of these resources, especially on projects with full testing frameworks.
Here’s a conversation that should never happen:
Developer A: “Hey, when I boot up the game everything crashes immediately. I’m pretty sure it was your change c12345 that caused it.”
Developer B: “That change shouldn’t have caused a crash.”
Developer A: “Did you try launching the game?”
Developer B: “No, it shouldn’t be causing a crash.”
Here’s another conversation that should never happen:
Developer A: “Hey your change c12345 is breaking this unit test.”
Developer B: “Hmmm… I’m not sure why that change would break that test.”
Developer A: “Did you run the tests?”
Developer B: “No, it shouldn’t break any tests so I didn’t bother.”
These are pretty much word-for-word conversations that I’ve actually had. My advice is that instead of thinking hard and theorizing about if a change will crash the game on boot or break a unit test, just launch the game and run the tests.
Also to be clear, I’m not saying that I’ve never caused a crash or broken a test before – but I can say that I’ve always at least put in a decent effort to make sure that I’m not checking in code that’s going to break the product for everyone.
SCHEDULES: It’s hard to get value from a schedule
Creating accurate schedules is extremely hard, and they’re often wrong. The best explanation I’ve seen for why is this post here. In my experience this is sort of just the reality of the situation: making schedules is hard and time consuming, and they’re usually not very good or accurate. It’s a bummer.
Even with all of this effort going into creating a schedule, I haven’t really worked on a project where the schedule was used to make important decisions or really taken seriously at all. Most often a lot of energy went into creating a schedule, and then everyone would just sit around and get frustrated as we fell behind without really doing anything about it.
Actually, something was typically done about it: initiate crunch mode. Then we would just fall farther behind. More on that later.
FEATURES: Lots of features will be cut, even if nobody will admit it
Related to SCHEDULES above, cutting features seems to be one of the most difficult thing to make happen in any game development process. Nobody ever wants to do it, it’s like pulling teeth! But here’s the thing: Features will be cut. Has a game ever shipped with every desired feature? You can either proactively cut features and craft your game accordingly, or you can try to do everything and run out of time.
If you run out of time, then you have just cut a bunch of features at the absolute worst possible time: the end. The earlier you can cut features, the better. Every feature cut makes all remaining features a bit easier to implement. Less interaction between features means less complexity. Every cut feature helps defines the possibility space of your game, and the earlier this happens then the earlier you can enhance the positive aspects of your product.
I have found that deciding what not to do is incredibly productive.
TEAM: Multidisciplinary teams are interesting
One of my favorite parts of working in the game industry was the multidisciplinary nature of the development team. There are few jobs in the world where you can regularly work together on a daily basis with programmers, concept artists, animators, musicians, authors, screenwriters, producers, level designers, and system designers.
I always loved this aspect of the job, but it does bring a bunch of potential challenges. Crossing the divide between disciplines isn’t always easy, and it often leads to conflict. One thing I frequently noticed is conflict arriving over vocabulary. A programmer is trying to work something out with a designer and argues using ‘programmer vocab’, the designer doesn’t understand completely and gets totally defensive, the discussion goes nowhere. One piece of advice I can give when working with other disciplines is to be very careful with vocabulary, I’ve found that things go a lot better when everyone understands the words involved.
REWRITE: Don’t be afraid to rewrite
Making the decision to rewrite a system or feature shouldn’t be taken lightly, but it can be the right thing to do. There’s nothing worse than dumping time week after week into a system that hasn’t been designed correctly and needs a rewrite. I find that sunk costs are often overvalued, and the word ‘rewrite’ is frowned upon. Make an honest assessment of the situation and decide what the best course of action moving forward is. Don’t get defensive, don’t be upset that it wasn’t done right the first time – make the best decision for your product.
Rewriting isn’t something that is always done to major feature/systems, smaller code refactors are often just as helpful. Related to MISTAKES above, I often find that my initial code implementation wasn’t so great in retrospect due to unexpected usage patterns, changing surrounding code, or whatever. When I’m evaluating potential solutions to a problem, I always include “How easy will this be to refactor?” in my heuristic. Chances are it’s not the ideal solution and I’ll want to refactor it at some point in the future, so the easier the better.
Go forth young Jedi and refactor.
CRUNCH: Crunch is poison
Crunch is a horrible practice, and a terror that is damaging the game industry. The culture has been poisoned, and the antidote is nowhere in sight. Sadly, I don’t think the antidote is even really wanted.
Maybe things are different for other disciplines (art, QA, whatever), but as an AI programmer I really feel the effects. Programming is extremely difficult, and when I’m not at my best I just can’t really do it. I’ve been in ‘death march’ scenarios before, seven days a week, 100 hours per week. Not surprisingly, my production just bottoms out. Every day that passes I accomplish less and less. I get frustrated that I’m not accomplishing much, and as a result I end up sad and frustrated. The next day I accomplish even less. It’s horrible.
There are countless studies that show that crunching doesn’t increase software engineering productivity, and all of my anecdotal evidence points in that same direction. One incident I’ll always remember from early in my career is staying at work until 3AM with two extremely smart engineers working on a problem together. We came up with a great solution and went home to crash, feeling very proud of ourselves. I came in the next day and realized within 5 minutes that our solution was terrible and would obviously never work. Sure things like this also happen during ‘sane’ development hours, but during crunch it seems to happen constantly.
I honestly think crunch is now a non-starter for me. Moving forward I just can’t be involved with an industry where crunch is such an ingrained part of the culture. Since leaving the game industry I’ve had actual NIGHTMARES about being back at a game company, crunching.
SADNESS: I don’t want to do this anymore
As a child my dream job was game developer, and I really sculpted my early life to make it happen. Everything worked out according to plan, but fast forward ten years and I don’t want to do it anymore As I get older I guess I value different things. Stability is more important to me. I’m sick of every company I join ending up on life support within a few years. A lot of the cultural aspects that appealed to me as a younger man just don’t appeal to me as much.
There are lots of positives about the game industry, but for me the scales have tipped too far in the other direction. I still love working on games, and I think I’ll always be involved in some degree on a hobby-level, but unless there’s a major shift in the industry I don’t think I’ll be back professionally.
I guess that’s enough for now. I have plenty more to say, but it’s a beautiful day and I want to get out there! Maybe I’ll follow up with a second post at some point.
Everything that I have posted on this website is the results of work that I have done for fun, as a hobby. Any sort of payment is flattering, but totally unnecessary. I update so infrequently, and can’t really supply daily support with my schedule, so I’d feel uncomfortable even putting up a donation button or something similar.
If you use something on here and feel the desire to make a donation, then please find someone in your life who needs something and buy it for them instead. Or find a charity that speaks to you and give some money to them. Or you could donate to One Fund Boston. Something bad happened in Boston recently, and money is being raised to help the people affected. This is something very close to me.
Again, I’m flattered but it’s not necessary!
PS: I can’t believe it’s been a year since I updated this website! A busy year, hopefully I’ll find time to make something new soon.
Almost a year and a half ago, I wrote up a small Unity3D project that demonstrated a few basic AI behaviors (patrolling, wandering, following). You can check it out here. I get more emails and questions about that simple project than anything else on this website – I guess simple projects that demonstrate the basics of game AI are something people are interested in!
Anyway, this project had a major problem – the sample NPCs didn’t deal with changes in terrain height well (or at all). This has been bugging me for a while, but I haven’t had a chance to fix it until tonight. Check out the project page for a new version, complete with NPCs that don’t burrow into the ground at the first sign of a change in the y-value of the terrain underneath their feet.
I always try to keep my eyes open for interesting game-related research happening in the academic AI world, and this week a project called ANGELINA is getting a lot of people excited – myself included.
Michael Cook is a PhD candidate at Imperial College in the UK, and has been working on designing an AI that can design games. This is a topic I find fascinating, and something I’ve actually messed around with personally in the past – but never really had the free time to pursue on any sort of deep level. It’s fantastic to see that someone is working on this problem legit, and I can’t wait to see where he takes this in the future.
I’m particularly excited about the fact that the output of his research is an actual product that people can play with, interact with, and think about. A lot of game-related research stops short of taking this step, and it really raises the barrier of entry for a dude like me. I’ll definitely be playing close attention to ANGELINA moving forward!
I got a message from SonicViz recently that they used my Progress framework in their new game: Chordskilz! I was pretty psyched to hear from them, I always love to hear when someone is able to use the code that I put up on this blog.
Chordskilz is “… a music game designed to give you a total active listening workout in a core area of music ear training: Harmony, or chord recognition.” If music is your thing, check it out!
In the early 90s I was a small child OBSESSED with Magic: the Gathering. I played it for the first time at boy scout camp, and it was pretty much the greatest thing I had ever experienced. After learning about the game, I immediately set out to create my own card game. I’ve always loved making games even more than playing them, and card games are relatively easy to make: come up with a sweet idea, grab a stack of index cards, railroad some people into playtesting, and you’re good to go.
The results were, unsurprisingly, horrible. At ten years old and lacking anything resembling design sensibilities, the deck was seriously stacked against me. On top of that, I was so obsessed with Magic that anything I made was basically just a bad version of my new favorite game. My favorite aspects of Magic were the strong distinction between colors, deck construction, and the land mechanic to represent resources. All of the games I made had something resembling each of these aspects, and were just terrible. Eventually I realized that Magic was already a good version of Magic, so I’d need to think of something pretty different. I can remember two specific games that I made at this point.
At first I thought it would be cool to make a cooperative game where players shared a deck, had to work together to survive, and each had a secret goal as a win condition. It was sort of like Munchkin, except way overcomplicated and with secret, randomized win conditions instead of ‘reach level 10′ for everyone. I think the idea here was pretty decent, but the game balance destroyed the experience. The majority of test games were just not fun, players were generally far too powerful/weak and I wasn’t able to get it right. It was also way too obvious which ‘secret goal’ players had based on how they played the game. DudeX doesn’t want to spend any gold? He probably has the ‘collect 500 gold’ win condition. Also, it was possible for everyone to lose if the players wiped, and this happened too often.
The other card game I can remember making around that time was called Upgrade. When I saw the Experimental Gameplay Project theme for November (Upgrade), I wanted to reproduce that game as best I could. I no longer have the original game (index cards), but I still remember it pretty well. Back then, one of the constraints I was tied to from being a Magic fan is that different cards have to cost different amounts (roughly) based on their power level. I can remember deciding to make a game where each player just played one card per turn. Based on my previous efforts, I also knew that I wanted to make something much simpler than what I had been working on. I was already starting to learn that complexity was a killer. Upgrade was the result, and it was the first card game I made that I thought was actually halfway decent to play. I was really into Civilization and SimCity around that time, maybe there was some influence?
I’ve done my best to reproduce it here, you can download it in a PDF. Just click the image below. Print it out, cut up the cards. Shuffle up, and play. There’s a sheet of rules. It’s all pretty simple. If you want to be super fancy, you can print the game on nice card stock or something.
Download the PDF here or click the image below.
This is not exactly the same Upgrade I made way back when, but it’s not off by a lot. The rules are very close, and the action cards are probably at least 75% the same (in functionality, not in name). The original version didn’t have any artwork – my wife was kind enough to whip some images up for me to use on this version. We played a bunch of test games, and actually had fun – so maybe someone else out there will have fun with it too. I only really tested this with two players, but it should theoretically work ok with three or more.
I used index cards and the Magic Set Editor (with a modified Dvorak theme) to develop this game. I was planning on adding ‘flavor text’ to the products, but was busy with holiday stuff and never got around to it.
Feel free to send me ideas for cards, balance suggestions, etc. I had a lot of fun working on a non-video-game game for the EGP. The next time I’m at my parents’ house I’m going to search my old bedroom and hopefully find Upgrade in its initial form. If I manage to track it down, I’ll make a comparison post.
Thanks for reading!
Here’s one of my favorite little pieces of game AI wisdom from Jeff Orkin:
There is no point in spending time and effort implementing squad behaviors if in the end the coordination of the A.I. is not apparent to the player. The squad behavior layer gives us an opportunity to look at the current situation from a bird’s eye view, where we can see everyone at once, and find some corresponding dialogue sequence. Having A.I. speak to each other allows us to cue the player in to the fact that the coordination is intentional.
Vocalizing intentions can sometimes even be enough, without any actual implementation of the associated squad behavior. For example, in F.E.A.R. when an A.I. realizes that he is the last surviving member of a squad, he says some variation of “I need reinforcements.” We did not really implement any mechanism for the A.I. to bring in reinforcements, but as the player progresses through the level, he is sure to see more enemy A.I. soon enough. The player’s assumption is that the next A.I. encountered are the reinforcements called in by the previously speaking A.I., when in reality this is not the case.
Wherever possible, we try to make the vocalizations a dialogue between two or more characters, rather than an announcement by one character. For example, rather than having the A.I. cry out in pain when shot, we instead have someone else ask him his status, and have the injured A.I. reply that he’s hit or alright. When the A.I. are searching for the player, rather than having one A.I. say “Where did he go?”, we can have two A.I. in conversation where one asks the other if he sees anything. The other A.I. may respond with a negative, or call out a known or suspected position.
We also use dialogue to explain a lack of action. If an A.I. taking fire fails to reposition, he appears less intelligent. We can use dialogue to explain that he knows he needs to reposition, but is unaware of a better tactical position. The A.I. says “I’ve got nowhere to go!”
A gamer posting to an internet forum expressed that they he was impressed that the A.I. seem to actually understand each other’s verbal communication. “Not only do they give each other orders, but they actually DO what they’re told!” Of course the reality is that it’s all smoke and mirrors, and really all decisions about what to say are made after the fact, once the squad behavior has decided what the A.I. are going to do.
— Jeff Orkin from Three States and a Plan: The AI of F.E.A.R
I always love to hear about little smoke and mirrors tricks that developers can use to make players believe that AIs are doing more advanced things than they actually are. The technique that Jeff describes here is one of my favorites – it adds so much depth without really adding any depth at all.
While playing games for fun, I’m often on the lookout for examples of this. Recently I was playing RAGE and listening to the AIs yell at each other during combat. At one point one of them yelled, “He’s flanking us!” Maybe technically I was flanking them, but at the time I was running around in a circle like an idiot trying to get a swarm of dudes off of me. I was firing constantly and throwing out grenades and stuff. I wasn’t doing anything resembling strategy or tactics, I was just in complete desperation survival mode.
This dialogue was really disruptive for me as a player, and totally took me out of the gritty wasteland combat and into ‘trying to figure out the smoke and mirrors land’. I think maybe it’s a good lesson to keep in mind moving forward: if you’re going to use dialogue to enhance your AI, be careful about having NPCs TELL the player what he/she is doing. Because the player KNOWS what they’re doing, and if the two don’t match up then it can seem very out of place. It’s a major breaker of the ol’ suspension of disbelief.
To be fair, if that dude had said – “Finish him off, he’s flailing around like a moron!” I would have been VERY impressed.
I always find the process of writing a postmortem to be useful, and I wanted to do one for The Fifth Zombie. My buddy Greg did all of the art for this project, and he’s never made a game before this one – so I thought this would be a good opportunity to do something a little unique.
So here’s a ‘conversational postmortem’ (AKA GMail chat session) between Greg and I discussing The Fifth Zombie’s development process. It’s totally candid and casual, enjoy!
Steve: So the normal format for something like this is pretty straightforward: what went right, what went wrong. I think it’s probably a lot more interesting to hear what you are thinking, especially since you’ve never worked on a game before.
Greg: Well, I’ve wanted to be involved in video games since I was a kid.
Steve: Why are you chatting me from two separate windows simultaneously?
Greg: Sorrryyyyyy… Reemiiiiiixxx. Ok, we good?
Greg: Ok. So, I’ve wanted to be involved in video games since I was a kid. But seeing as I have zero working knowledge, it never really seemed likely. So when you brought up the idea for The Fifth Zombie i was pretty jazzed.
Steve: Yeah the hobbyist video game world is pretty sweet now, honestly. There’s tons of available tech to make whatever you want. I would have KILLED for this stuff as a kid. I had to spend all of my time screwing around with DOS mode 13h.
Steve: The problem I have with these small games is I can do anything on the tech side, but when it comes to anything artistic, I am beyond horrible. Seriously – find a good artist and tell them to draw the worst thing they can imagine. Guaranteed I can top it, effortlessly.
Greg: haha, I loved your placeholder art. That squiggly zombie was incredible.
Steve: Sadly, that zombie is probably my finest work.
Greg: Yeah, and I have only been drawing on the computer for a little while, so I think it took the right project for us to work together. The ‘Story Game’ theme and storybook idea just fit.
Steve: There aren’t a whole lot of game types that we could have just jumped in and made with our exact skillsets, right? Storybook game is pretty much the only one.
Greg: The fact that we couldn’t really do animation was pretty limiting, but worked for the theme.
Steve: Hey, I made that page turning animation.
Greg: You made that?
Steve: It probably took me longer to make that than to make the whole rest of the game.
Greg: The game really wouldn’t work without it. We needed to literally TRANSPORT people to a world where they were reading a book.
Steve: I had visions of this really sweet page turn animation, like a classic Disney movie intro or something. Reality hit that vision pretty hard.
Greg: Yeah, well I had some pretty sweet visions too… that didn’t work out. I had a ton of fun drawing for the game, but it was just super rushed.
Steve: Probably our biggest mistake was only leaving two days to make the entire game.
Greg: haaha yeaahh. If anyone is working on a game, I would not recommend taking that same month to apply to grad school.
Steve: Solid advice.
Greg: I thought i had it pretty under control, and then I wrote a list of what art I actually needed to deliver. This was two days before it was due, and I immediately thought: “there’s no way”.
Steve: I think your art turned out pretty awesome, but the quality level pretty clearly dropped as the end of the project approached… and your carpal tunnel set in.
Greg: At 2 a.m when my wrist felt like it was going to break off… not so smart.
Greg: It’s funny you say that, because some of my favorite art is the later stuff. The simpler it got, I almost enjoyed it more.
Steve: Which were your favorite 2 or 3 drawings? I really liked the grave scene, the death at the Forgotten Cave when sneaking out, and the hero sleeping in his bed.
Greg: I think the fat zombie was number one for me, he was just a lot of fun to draw. Originally all the zombies were going to look the same, but with different colored shirts – we had discussed Ninja Turtle colors. But then you brought up the idea of a fat zombie, and it just made so much sense.
Greg: I’d love to know his back story. Was he fat before he became a zombie? Or is he a brains glutton?
Steve: Dude needs to get on P90X or something. Drop a few pounds, get back in the hunt.
Greg: Seriously. That’s why in the scene where you get eaten outside the cave, he is the last one in line. He is too fat to catch up.
Steve: That’s one thing I wish we had done a better job of: giving each zombie some kind of perceivable backstory. More personality. The fat zombie is great, but the other 3 are totally generic.
Greg: Yeah, for sure.
Steve: That was really a script problem from the start.
Greg: I think with a few subtle changes we could have added a lot of character. Maybe one has a Starbucks uniform?
Steve: We should have made one of the zombies totally obsessed with Van Halen. You can defeat him with power chords. The Axe of Destiny turns out to be a sweet guitar?
Steve: We also could have done more involved battles than just ‘brass knuckle smash’ or ‘sword stab’ or whatever. There were a few things in there to make it interesting, but they were pretty bland overall.
Steve: We should have had the battle with the fat zombie end with you tricking him into eating himself, like Pizza the Hutt.
Greg: I think stuff like that could have added a lot. I think the zombie encounters in general could have been a lot better. We had originally talked about them being these intense scenes where they would slowly start communicating with you. And then eventually you get to the fourth zombie, and it’s more of a conversation than a battle. But obviously with 2 days to go we just winged it.
Steve: Yeah, the biggest problem with the script is that we never really iterated on it before trying to crank out the entire game. I had the basic idea, which I thought was pretty cool. And then I wrote up a rough draft in like an hour… and that’s pretty much what we went with.
Greg: I think we just kind of assumed it would write itself as we went
Steve: There’s a good lesson takeaway: Things do not write themselves.
Greg: I think next time we would write a much more compelling script, and build the game around that. We need an actual script that’s good, not just a good high level idea.
Greg: Then there’s the intersection of story/art/game. Take the Revolver of Truth for example: You loved the idea of a revolver, as did I. But I could not, for the life of me… draw a revolver.
Steve: Yeah, I posted a link to the game on the Unity forums – one of the first dudes is like: “Just have to point out that the Revolver of Truth is obviously a pistol, and not a revolver. I thought there would be some special meaning to this later, but I couldn’t see any. Am I missing something?”
Greg: haha, I thought that too!
Steve: I did too, but I was hoping that nobody would notice.
Greg: The only way I drew the gun that’s in the game is that I literally held my Glock in my hand and took a picture.
Steve: You held your what in your hand?
Greg: My glock.
Steve: Even though the art didn’t fit ‘revolver’, Glock of Truth just sounded so wannabe gangsta to me. Instead of high-class, dignified zombie slaying. It was the lesser of two evils.
Greg: Yeah, revolver art would have worked so much better. Although I challenge anyone to draw a revolver free hand.
Steve: Let’s have a revolver drawing competition, I bet I can take you.
Greg: I’m sure you can. Mine looked like an umbrella.
Steve: I guess the lesson there is that people always will notice those little inconsistencies, and inconsistencies can really take them out of the experience. Even if it’s an experience about a little kid battling 5 zombies, consistency is super important.
Greg: Yeah, I think if you make a world you need to stick to that world and its rules, or else you risk taking people out of it.
Steve: No doubt about it.
Greg: Like you said… it’s a game about a kid killing zombies. But I felt like if we had made any sort of pop culture references, or mentioned anything in our world it wouldn’t have worked. In my mind this village was a Dragon Quest village on some island in the middle of the ocean. The only thing on the island is the cave, the lake and the town.
Steve: I think that’s the safe play, but some quirky stuff from our world ‘slipping’ through can be really interesting: like the idea that one of these zombies used to work for Starbucks, or that his favorite song is Runnin ‘ With The Devil. Killer guitar on that one.
Greg: haha, yeah that’s true. Little connections here and there can be pretty sweet.
Steve: That’s kind of why we went with this: “… the year was 1998″ intro, right? To give some of that weird “long time ago in a galaxy far, far away…” feeling.
Greg: That’s true, I kind of forgot about that.
Steve: Like maybe this really happened in our world somewhere, but maybe not. Maybe it happened in some other world a lot like ours.
Steve: I do love the idea of these little microcosm worlds, where literally the only thing in existence is an island, 10 people, and a cave.
Greg: Yeah… I kept imagining the beginning of a ENIX RPG.
Steve: I always think about game ideas along those lines. Like that UFO game – it’s just a man, a camera, and a lake.
Greg: There’s also disappointment . Don’t forget disappointment.
Steve: Yeah, there was also sadness, loneliness, etc.
Greg: It’s a minimalist game world where you really have to fill in the cracks and gaps.
Steve: I guess those are the real important parts of the experience.
Greg: When you give the gamer so little, those universal emotions help keep them in it.
Steve: I think the ending of the Fifth Zombie turned out pretty well, but the beginning wasn’t so hot. I wish we had worked on helping the player care about the family more.
Greg: Yeah, if we redid the game I think we would focus much more on the story and the player’s connection with the characters. And WAY more choices. I feel the experience could have been much deeper if we added a lot more things to do, which obviously we had to cut due to time.
Steve: Yeah, plus maybe some choices that weren’t instant dead ends. That was the original idea, but time struck us down.
Greg: I guess that’s the number one thing I took from this experience: time. Make sure to spread out your work.
Greg: I had a great time working on this, and it was awesome to have a hand in making something that people can actually play and experience. It’s a really cool feeling. It’s so much more of an experience to me than reading a book, or looking at a picture.
Steve: For me, the bottom line is that I just really like making things.
Greg: It was a great experience that really showed me I have so much to learn, and a lot of practice ahead. But it was so much fun, I’m ok with that. Not everything you make is a masterpiece, it will never turn out exactly how you want it. All you can do is learn at each step and apply that knowledge to your next project.
Steve: It sounds kind of weird to say, but I generally have way more fun making games than playing them.
Greg: I think that’s pretty sweet. Sometimes I will sink a couple hours into a game and afterwards think: “I gained 1400 XP… but what did I really do? I gained nothing”. At least making something, you will always have it to remind you of the work you put in.
Greg: I love looking at things I was drawing even a year ago, and wonder: “Who was that person?”
Steve: It’s a major bummer when you play a game for a while and afterwards you think, “All I did was push buttons for an hour.” Sometimes it’s awesome, but a lot of the time it’s just pushing buttons.
Greg: Yeah… that’s why something like a Team Ico game will put me back into the “game crazy” mindset. They are such an experience I don’t feel guilty… I feel like maybe I’ve been reading a good book, or been at an art exhibit or something. They’re good on so many levels I can actually justify not doing my homework and playing them instead.
Steve: There are still plenty of games that I feel worthwhile playing. Even something like NHL 12, which is not an artistic masterpiece. We play that all the time, but it’s more of a way to hang out with our friends than anything else.
Greg: Yeah for sure. Look at how much more we’ve gotten together since we started playing NHL. We share this thing, its pretty special. Not to mention the accomplishments.
Steve: I mean we scored 7 goals in a single game. That’s something to take to the grave.
Greg: I’m a changed man now. I feel like I will be telling my kids about that game someday.
Steve: Well, this seems like probably a good place to wrap this up?
Greg: Sounds good.
Steve: In conclusion: pace yourself, keep your game world consistent, actually write the story, and GO BRUINS!
Greg: GO BRUIIIIIIIIINS… and TIME!