On My Mind is a game that I made for January’s Experimental Game Project theme, “100 Things.” I had been wanting to make a meditation-based game for a while, and felt that I could combine three goals in one: participating in the EGP, making a meditation game, and learning the game engine LÖVE.
I fit the game into the “100 Things” theme by having 100 thoughts going through my head. The thoughts are largely representative, albeit sometimes in an abstract way, of thoughts that might go through my head.
For the gameplay, I didn’t want to have much of a goal, nor have the player actually “win,” because awareness meditation is not about calming the mind nor focusing on anything specific; rather, it’s just about being aware. I tried to have the gameplay reflect this concept… I had to balance actually having interaction with penalizing the player for too much interaction, and at the same time trying to keep the game from being too frustrating. If you win the game, the man on the screen smiles; if you lose, he frowns because he has become “too distracted.”
LÖVE turned out to be pretty darn cool. It has limitations that a more complicated game might run into, but worked great for me. The biggest hurdle for me is that the LÖVE documentation is not that great, and the forums are very difficult to search, with terms like “audio” being cut from the search because they are “too common.” One thing that I like about the engine is that it’s cross-platform, so I was able to make a Windows and Mac version. Unfortunately, to distribute a stand-alone application you have to package the entire LÖVE application with your game, which gives the end user a security warning on Windows and a much larger than necessary file for Mac users.
What went right:
- Development time. The amount of time allowed for EGP theme games is 7 days, and that’s about what it took me. At least half of that time was used in creating the art assets.
- Frustration, or lack thereof. I haven’t received a lot of feedback, so I could be wrong about this, but I think I found the right amount of negative response to player actions so that they lose the game very quickly and realize that their strategy didn’t work, and once they learn the mechanic, the game gets slightly harder but not hard enough that they’ll lose.
- Sound effects. Aside from the occasional glitch (that I blame LÖVE for), I’m very satisfied with the audio, I think it helps to add a layer of calm and contentment.
What went wrong
- Missing thoughts. I chose to use photographs instead of drawing the thoughts because I assumed it would take less time. The initial list of thoughts that I came up with turned out to be difficult to take photos of, and I struggled to come up with the last few photos, so some of them are kind of lame. For instance, there is both a photo of a snow-covered branch and also an image of a snowflake. Ideally, there would have been greater diversity.
- Length. It takes about 5-7 minutes to beat the game, which is a long time considering that once you figure out how to play, it’s the same thing over and over. The thoughts are not quite entertaining enough to look at that they will keep most people’s interest, so to actually beat the game requires commitment. The easiest way to solve this would have been to cut back the number of thoughts, but that wouldn’t have fit the “100 Things” theme.
Is a “clash” of heroes like a “murder” of crows?
Having finished playing M&M:CoH, I now present the following Do’s and Don’ts, which I have compiled in order to apply them to my own game designs; if the reader also benefits from my efforts, so much the better. (note: I have only played the single-player campaign.)
DO apply a simple gameplay mechanic in varying ways throughout the game. The concept of the battle system is very simple, yet it must be applied differently for each character’s units and for each boss battle. For example, Godric’s units are so slow that a defensive strategy is almost a necessity, whereas Fiona’s units are so fast, weak, and expendable, that offense is usually the best defense.
Another example, many of the boss battles require you to hit moving targets, instead of being able to advance across any section of the battlefield — suddenly adding timing and targeting to battle, yet without continually ramping up complexity throughout the game.
DO use your assets in multiple ways. I’m talking specifically about the Puzzle Battles here, which use the same basic battle framework but have completely different goals: instead of trying to reduce your opponent’s health to zero, you have to knock out all of your opponent’s units within a given number of moves. This works well for two reasons. One, it is a completely different challenge, while still being familiar to the player. Two, the lessons learned from these puzzles can be directly applied to the main game. It is similar to advanced combat training in disguise.
DO allow for multiple successful strategies. In general, I tended to choose the fastest units and attempted to maximize bonuses for attacking with many units at the same time; I could have instead chosen to use the more powerful units, been a little more patient, and hit for massive damage in one shot; I’m sure there are many others.
DO allow your players to level grind, without making it a necessity. I wandered around fighting random battles three times, twice to perform sidequests (bounties) and once because I thought I needed to be stronger for the final boss (which, it turned out, I didn’t). All random battles are avoidable simply by pressing the B button.
DO allow players to skip random battles. This is a cool enough feature to be mentioned twice.
DON’T have your least interesting and slowest-playing level be last. Nadia, the last character that you play, has two abilities. One, her “special” ability, is really only useful in the final boss battle — this differs from the other characters, who all have very useful special abilities throughout. Her second ability is not battle prowess; it is not related to kicking ass and taking names; it is the sometimes annoying ability to not die. Her units are exceptionally unuseful when attacking the opponent. They do excel at destroying or otherwise rendering useless the opponent’s units. Anti-unit power MINUS anti-opponent power means that you don’t lose and you don’t win. I submit that there may be strategies one could employ that would provide a different experience, and by the end of Nadia’s campaign I was able to speed up combat a little bit. But it was like eating a box of donuts, where the last donut is the most stale and least enjoyable. I have two thoughts on how this could have been done differently. Instead of “not dying,” Nadia’s units could have been strong in countering other unit’s moves, so that Nadia would have been weak unless played very specifically, in which case, she would be effective. That is already the way her boss battle plays out. Another option would be to allow the player to choose, after Anwen’s campaign, the order in which the character campaigns are played. This could have been done with a slight reorganizing of the script, and may have alleviated some of the frustration due to personal choice: if I reach into a box of chocolates and pull out a Pumpkin Nougat, it’s better than if someone else knew the flavors and chose that one for me.
I enjoyed M&M:CoH and I hope to see more puzzle/RPG* hybrids in the years to come.
*I’m using the colloquial term for “RPG” that might be more appropriately defined as “inventory and experience point management.”
[video]
Considered to be one of the best games of 2007, Portal has received good review after good review for its originality and excellence in level design. And now that I’ve finally gotten around to playing it, I can see why — it’s a great game. Obviously I haven’t been playing a lot of games in the last two years, and this may put me in a somewhat unique position to point out some game design lessons to learn from ways that Portal could have been even better.
See, there are a number of things that bug me that seem to be so ubiquitous that they don’t even get mentioned anymore. One big one is expecting a game with a 3D engine to be a little bit of everything. For instance, God of War does not need a “walking along tiny planks” section. Gears of War does not need a driving mission. Geisha of War does not need a stealth section. (okay, I made that last one up… sounds like a cool game, though.) If a game’s engine does certain things well and other things not-so-well, best to stick with the things it does well and leave out the others.
Portal has a unique gameplay mechanic that could have easily carried the game on its own, especially with such great level designers. Instead, we have two mechanics that probably should never have been a part of the game. Object manipulation is one of the weakest parts of most 3D engines… unfortunately, there are a number of objects that can — and in many cases, should — be picked up. Boxes need to be carried and placed on switches, which could have been done very simply: you pick up a box, it has a direct relationship with your virtual body. Instead, there’s this crazy magnetic thing going on to try to explain why boxes that you’re carrying are sometimes close, sometimes far away from you; they get stuck on doors and walls, sometimes you randomly drop them, and you can sort of throw or drop them and sort of not so much except when you don’t want to. It makes sense to have something other than you be able to go through the portals, and that’s fine, the physics engine handles it great. But what is up with 3D games and terrible object manipulation? Leave it OUT if it doesn’t work.
Another unneccessary element in Portal is platform jumping. “But John,” you say, “there wasn’t any platform jumping in Portal! You must be thinking of Flinging, one of the cool portal-related mechanics.” Ah, not so! There were a number of times when you were required to jump from platform to platform. And these actually worked okay. What annoyed me was a specific level… let’s just say it was somewhere before the end of level 19…. I spent almost as long on this one level as I did playing all of the rest of the game combined, because I thought that I needed to jump somewhere and it turned out that jumping was not the solution. I assumed that the reason that I was always either short of the jump or way past the jump (an odd situation to find myself in) was because of 1. my inability to master jumping and/or 2. poorly executed platform jumping mechanics. #2 is so common that I assumed eventually I would get lucky and land on the platform I thought I needed to go to. As it turned out, that was the wrong solution to that particular puzzle, and I now believe that those jumps were put there to screw with me and throw me off the scent of the actual solution. I appreciate the game screwing with me in a setting like this, it seems very appropriate; but to do it with a mechanic that is traditionally very weak in a first-person-perspective 3D game just drives the point home that platform jumping in other games sucks.
One more thing I’d like to bring up that many game designers can learn from is Checkov’s gun. Checkov was a playwright who believed that if you show your audience a gun onstage, it should get fired sometime during the play. Otherwise, it is just distracting your audience from what you wanted them to experience. How does this relate to Portal? Early levels in Portal are very sparse and (aside from the cameras) have nothing extra lying around. Later on, you begin to explore areas that have junk lying around: clipbaords, chairs, bolt cutters. Okay, so what’s the problem? These objects would be in this environment, so it adds to the realism, right? No. These objects should have been static, unmoveable scenery. The ablity to pick something up suggests that it might be useful, and serves only to take the player out of the experience. There were two instances when this really hit me: One, when I encountered a chain-link door locked with a padlock. Picking up a pair of bolt cutters from an adjacent room yielded no result whatsoever. Sure, in this game we don’t pick things up with our hands, we use some kind of crazy magnetic thingy, so of course we wouldn’t be able to use bolt cutters on a padlock. DUH, right? Um, sure. Whatever. Two, I was able to pick up and place a chair underneath an opening that I was trying to jump into, but couldn’t quite make the jump. It turned out that I needed to use a box, no bigger than the chair I was trying to use, to stand on to make the jump. So the lesson here is: your players will try to solve puzzles with anything that you give them. It’s okay to screw with them, but make sure that it’s intentional.
None of this keeps Portal from being an excellent game. Rather, such a good game allows these very common pests to rise to the surface… hopefully I’m not the only one who noticed them, and today’s developers are working to eradicate them.
“People with day jobs don’t have eyes like that.” — pixelvixen707, describing Jason Rohrer’s “passionate eyes.”
I finally got around to playing Ico. It is a beautiful, beautiful game. Yes, it has pretty graphics, the controls are about as tight as 3D platformers get, etc etc…. what really strikes me about this game is a rare quality — so rare I can only think of one other game that does it off the top of my head — where the game as a whole has one single consistent emotional thesis.
I will explain further.
The other game like this is God of War. God of War is about one thing and one thing only: rage. Every slash of your blades, every battle cry, every bloody dismembering explosion maintains that theme. And I say “your” blades, because the game does a good job of creating agency and immersion; Kratos responds faithfully to your button presses, and the audio, visual, and vibratory feedback are near-perfect.
Ico has similarly excellent audio, visual, and vibratory cues. Ico’s theme takes more than one word to sum up, but it has the same singularity of purpose. Ico is about rescuing the damsel in distress. If you could physically pick up this game’s concept you would literally get “rescuing the damsel in distress” residue all over your hands. Other games may have you rescue a princess or something like that, but this is different… I can imagine the creators of Ico sitting down together and going “Okay, here is what this game is about. Let’s take a look at our gameplay, characters, and art, and strip away anything that doesn’t support the theme.”
The damsel in question needs to be led around by the hand through the entire game. What kind of crazy gameplay mechanic is that? Yet it works. It works really really well. Not only must she be led, but her animations are perfectly dependent and vulnerable as she stumbles or reaches out for your hand or shrinks away from danger.
Meanwhile, our hero takes the rescue theme to another level by being rather unqualified for the job, running around frantically and swinging a piece of wood at giant flying shadow-creatures who are trying to steal the princess away for unpleasant purposes. This point is driven home by audio cues of quickened footsteps and gasps of breath, and animations that showcase his lack of proficiency with a weapon. If he were more powerful and everything were made to look easy for him, it would be less of a heroic act and would have less of an impact.
The plot, told almost exclusively through three cutscenes, is like a fairy tale shell around the chocolately wish fulfillment of saving the girl. The premise is stripped to its bare essentials, with just enough background and imagery to make it clear what’s going on, and letting your imagination fill in the details.
Ico is not one of the greatest games. The puzzles are simple and cliché, and serve mainly to create tension between providing an escape route and protecting your charge. Rather, Ico is one of the greatest game experiences. For a game to deliver such an unadulterated experience is quite an accomplishment, and is something that the greatest writers, painters, filmmakers, and musicians hope to achieve. Bravo to the development team, may we all learn from their creative success and make our own artistic contributions to games.
The last few hours that I worked on this project were juggled around family time, holiday cooking, and chasing around (and being chased by) my two-year-old niece. I was able to download the Scratch software on a borrowed computer as well as an image editor with which I changed the colors of the “enemy” snowsuits.
In trying to simplify the user interface as much as possible, I removed almost everything from the typical “heads up” display. Instead of an “ammo” count, there’s a pile of snowballs in the corner. Instead of a health meter, the screen gets progressively bluer, as a sign of how cold you are. Your score isn’t displayed until the game over screen. I really like the way this worked out, especially the health status. The gameplay itself, which involves a lot of ducking behind your fort, is more of a simulation of a snowball fight than your typical point-and-click shooter, and I like that aspect of it, even though as a game it might not be as fast-paced and fun as other shooters. I wasn’t out to make a popular game, I was out to see how Scratch worked.
I tweaked the timing of the “enemy” movements until I was pleased with it, and then uploaded it to the Scratch website, upon which…. it crashed Firefox. It was also crashing Safari. Updating Safari seemed to help, and it works fine for me with Windows XP. My code wasn’t perfect, and there were a number of things I could think of that could contribute to a crash (audio handling being first on the list), it would have taken me a while to figure out what was the problem. I found out that a lot of what people upload doesn’t work from the Scratch website and you have to download it. I can live with that.
The final result:
I’m satisfied with the way it came out. It feels pretty solid to me. Even though it took me three times as long as I first predicted, 24-or-so hours to make a simple, fleshed-out game is pretty darn good. I’m not satisfied with the display of games on Scratch’s website; the player is buggy, and it’s not easy to find a game amongst the many, many, many uploads. Scratch is not going to be a game development solution for me, but I will probably use it to make super-quick prototypes, and I’m going to pass on its existence to the people I know who want to make games in their spare time.
You can see the finished game here: http://scratch.mit.edu/projects/natures_work/817332
After Day One I was busy for two days. When I started back up I didn’t track my progress as well.
My first priority was creating enough art and sound assets, temporary or otherwise, to be able to finish the coding. I wanted to finish this game before I lost enthusiasm for the project, and the next day I was going to be driving to my sister’s house for a few days, so any work I did on the project after this day would have to be done on someone else’s laptop.
When working on a game I like to get the music done and in-game pretty early, in order to test and make sure that it isn’t going to drive me crazy if I hear it over and over. I wanted the background music to be reminiscent of Vince Guaraldi’s Peanuts Christmas music. Reason is my go-to software for quick MIDI-based compositions. I loaded up a piano and, utilizing my training in jazz piano, stitched together some Guaraldi-sounding melodies. I accidentally stumble across some chords that are much to slow but that I like for the title music. In order to help prevent music burnout during gameplay, I comp three different melodies to the same chord progression, each about 30 seconds long, and set up a loop within the game that will randomly choose which piece to play next. As much of my background is music-related, this was the easy part of the project for me.
My roommates left the apartment to go to dinner and I took advantage of the relative quietude (I live next to a freeway) to record the sound effects. I wasn’t going for perfection here, and not only that, but I had forgotten that I had swapped SD cards between my Roland R09 digital recorder (my go-to device for quick-and-dirty recording) and a camera, leaving me with only 64MB of space, or about 5 minutes at the lowest resolution I was willing to go. (I knew that Scratch was going to compress the heck out of all of the sounds anyway, so I wasn’t too concerned about quality.) As it turned out, I emptied and filled the card about three times. Five minutes is not a lot of time when you are trying to record taunts, snowball impacts, and other such sounds. I used an actual winter coat for coat-related sounds; packing snowballs was squishing cornstarch with a spoon; and snow scatter explosions turned out to be a small bag of nutritional yeast, I think. (I tried out a lot of different substances, so it could have been puffed rice or oatmeal.)
And now it was on to the art. Of all the skills required to make a game from scratch, I’m weakest in this department. I will hopefully find an artist that clicks with me sooner rather than later.
Non-game-related side note, yet relevant to the game creation process: not only was I traveling the next day, so was my girlfriend. She would be going away for the next few weeks, so we wanted to get together before she left. I also wanted to get this game done ASAP. There were some misunderstandings, I brought my work over to her apartment because I thought she was going to be packing and we could hang out while we were both working. Had we both communicated better and earlier we might have prevented some of the drama that was created. As it turned out, we worked things out, but it’s clear that defining boundaries between work and our relationship is going to be something that’s going to come up again soon. And now back to the development proper.
There are four more-or-less identical “enemies” in this game, and I figured if I could make all of the art for one of them, I could use that temporarily for all three and use it as a template for the other there, altering the art while I was away. I’m not a huge fan of drawing with a mouse, so I borrowed a Wacom tablet from my roommate. It was my first time using a tablet, and it was a really awesome experience. All those years of doodling in high school helped me out here and I had my art assets — neutral, taunt, ready to throw, throwing, hit, snow forts, snow balls — done in maybe five or six hours. I really wanted to get this game done before I left, so I pulled my first all-nighter in a long time. I watched the sun rise as I added the code to make the animations and sounds play. Right around 8AM, the latest I could work (I still had to exercise, shower, and pack before leaving at 10AM), I finished the code. The timing of events would still need to be tuned, and the enemies all had the same art, but the code was done; I had been working on the project for about 20 hours, in total.
8:00AM — A phone call and my alarm wake me up simultaneously, unaware or uncaring of the fact that I had stopped watching classic science fiction television only a few hours before. Abruptly, a game design springs fully formed into my head. Not a world-changing, deeply philosophical game; rather, a game simple enough to finish quickly and complex enough to get me back into practice.
As I go through some morning rituals (making breakfast, brushing teeth, etc) I’m buzzing with anticipation. It’s been over a year since I created a game, and it’s been too long.
9:00AM — George Winston begins to play the music of Vince Guaraldi; it is appropriate accompaniment to the snowball fight simulation I’m about to make. Scratch (http://scratch.mit.edu) has finished downloading and I’m ready to try it for the first time. Its interface looks very similar to the Sims Carnival Creator, which I’m very familiar with from my time developing games for that site. (http://www.simscarnival.com/people/sparks_gently) I’ve decided to give myself the day — about 8 hours — to develop this game. That’s not a whole lot of time; the graphics may wind up being very simple. If they are the only thing missing, I’ll allow myself a few hours in the future to update them.
10:30AM — I switch to Ghost in the Shell soundtracks. It’s time to get serious!
1:00PM — Despite a number of distractions (pleasant as they may have been, like finally introducing my roommate to the I Ching) the game is coming along nicely. Scratch has a few annoying limitations but I’m finding ways around them. The main gameplay elements are in place, snowballs are flying and win conditions are already implemented. The next big step is adding animations and other graphical niceties.
3:30PM — First real snag. The code that worked hours ago seems to have stopped working; when I attempt to set X and Y values for an object (a snowball, in this case) the X value catches but the Y value remains what it was. Grr.
3:45PM — Problem fixed. While cleaning up some code, I accidentally mixed around some less-than and greater-thans.
5:15PM — Calling it a day. Majority of gameplay is complete. Art, sound, and music didn’t get tackled today; this project may take another full day to finish.