Meaning and moving on

[This is a repost from my semester project mindful xp. Please check us out and see what I’ve been up to this year!]

Last night we decided to put our 3rd game, Scott Told Himself, on developmental hiatus as we continue with different projects.

This was not an easy decision. A major component of our project with mindful xp is creating game after game in rapid succession. We’ve been working on Scott Told Himself for 10 days now. Typically we had hope to spend about a week per project, but with Scott we pushed ahead after our deadline hoping that one last major push would finish things up. Yet even with these late nights the game is still incomplete, a bunch of systems lacking any connective tissue.

With most projects it would make sense to release a prototype and move on. Especially with rapid prototyping not every game idea will work out and there are valuable lessons to be learned from every experience. With Scott Told Himself, there are a few lessons from its short development that we feel are important going forward.

Continue reading “Meaning and moving on”

Making a game in 48 hours

Earlier this month I was lucky enough to talk as a speaker at the 2nd Triangle Game Conference right near me in downtown Raleigh, North Carolina. My talk was on my experiences during rapid game development over the past year or so in a talk entitled “Short & Sweet: Making a game in 48 hours”.

Originally I had planned a more introductory sort of talk that mixed in some elements of being a tutorial. Basically introducing my audience to the ropes of rapid game development discussing planning, development tools, and other boring stuff. The day before my presentation I nixed that idea and instead went the alternate route of having a quick hits session where I basically ran through everything I’ve learned the hard way about rapid game development.

I absolutely love rapid game development. The worst part of game development for me is the moments when you’re not doing anything. Rapid game development is all about constant motion and activity; when you give yourself either 72 hours or 2 hours you barely have enough time to make the pieces fit. With rapid game development you also get exposed to certain elements of game dev such as experimentation and the experience of failure that helps engender better development in the future. It also compacts the learning curve so instead of spending two or three years of your life making mistakes you spend just a few weekends.

With that in mind the bulk of my presentation went over some “guidelines” for working with huge time constraints. I purposefully tried to avoid any “Goofus and Gallant”-type of demagoguery instead presenting them as things that worked for me for the most part which I then divided into two parts: rules that you probably should follow and rules that could probably be ignored. The guidelines I found most useful where:

1. Know your tools. Having experience with your game development toolset (including such things as programming language, your IDE of choice, graphics editing program, sound editing program, etc.) is a huge boost to successfully developing a game in a short timespan. Don’t waste your first hours learning how to setup your game to compile properly.
2. Having a plan. Even when the plan is thrown out in the first few hours it’s great to have an idea where you want to go. Here I recommend not building a 200-page game design doc, but even having a paragraph or two about theme, setting, gameplay, and characters can guide development enormously. I follow the advice of people smarter than me like Kyle Gabler who talked about building emotional targets for his prototypes.
3. Expecting plans to fail. When your initial idea fails (and it will fail) don’t panic! Failure at some point is a totally expected outcome of rapid game dev. Instead step back and figure out how you can reconfigure your game for the remaining time you have.
4. Staying on target. My way of saying don’t sweat the small stuff. When you start out don’t spend the first hours working on a finely-crafted mockup that won’t meaning anything. Work on a single element of the game at a time and don’t move on until that portion is acceptably complete.
5. Develop in tiers. A nicer way of saying that you need to be prepared to cut your game down. Be ruthless in removing flourishes from you game as the deadline nears. I envision this as a level of tiers. You have the first tier which are things your game requires to be functionally-working (like a running executable and the ability to take input), the second tier which is the stuff you most want to work on in your game (hopefully an experimental idea of some sort), and the next couple of tiers are flourishes in order of importance. Be prepared to lose all of that in your quest to come in under your time limit.
6. Steal, beg, and borrow. The final point is that in order to be successful at making games quickly you need to be willing to take what’s already done and use it. Don’t reinvent the wheel in the limited time you have, copy code from other people, copy code from yourself, take existing libraries and jam them into whatever parts of the game as necessary.

After this portion of the presentation I gave out other tips I’ve heard or followed in the past that I think aren’t as necessary as the tips above. Those include:

1. Collaborative versus solo development. In my mind having done both in short timespans I don’t think either one is an issue. Both allow different ideas and different processes to develop. Working in a team under time pressures will teach you things that you would never learn working solo and vice versa. But doing either in the end will help you become a better developer.
2. Being realistic in your targets. Another tip I followed initially and have heard a lot is being conservative in what you’re attempting to do in a short timespan. And while realistically you’re not going to accomplish 10% of what you set out to do, after some experience I don’t think aiming low should ever be an initial goal. Having ambitious targets is a great way to get started and with smart use of tiered development and being ruthless when cutting it’s something that won’t end up hurting you in the long run.
3. Developing to your strengths. The last thing that’s often repeated is developing to your strengths. If you’re a programmer then you should avoid doing something that requires a lot of art assets, if you’re an artist avoid something code-heavy, etc. But half the fun of rapid game developing is learning things on the fly, trying out new things, and even failing in the end (but at least walking away with better experience). So I now say screw this piece of advice and do what you want to do. Developing to your strength is like working out the same muscle over and over again – after a certain point it becomes functionally-useless.

I ended the presentation with a quick runthrough of a timelapse I created when doing a game in 2 hours for the site Glorious Trainwrecks. In two hours I was able to get a stupid, simple platformer up, running, and playable with graphics, sound, and menus. In order to accomplish this I had to borrow artwork, use programs like sfxr to create sounds, and lean heavily on the built-in functions of the engine (flixel) I was using to build the game. You can play the end result of this 2-hour process right now!

With such events like Ludum Dare 17 coming up this weekend it’s a perfect time to try out rapid game development for yourself. It’s a worthwhile experience that builds skill, knowledge, experience, and even character (like walking 10 miles to school in snow uphill). I highly encourage anyone with even the most remote interest in game development to try it for themselves.

Finally, thanks to the Triangle Game Conference and my audience for attending my presentation. I hope everyone enjoyed it and got at least a little something out of the whole ordeal at 10 AM that Thursday. You can download my presentation slides in PDF format here. Please note that the presentation slides is mostly non-sequitur without the benefit of the actual presentation.

Finding the soul of your game

Right now I’m nearing the end of development for Towerfall. What started off as a simple first prototype for my One Week/Game project has sorta become more involved to say the least. And at the end of development there’s still quite a few things to cross off my development checklist.

But as I look back at what I’m working on the thing that strikes me is what facets of the game I’m working on. I’m actually not spending a lot of time tweaking the gameplay or adding extraneous features. Instead I seem to be spending a lot of time on tiny details like adding a little flavor of narrative, a hint of character, some small background details, and additional ambient sounds.

On the surface what I seem to be working on is merely polish. But I don’t think that’s quite right. Polish tends to be technical and dry; it focuses on getting the proper responsive controls and making sure the game has working scoreboards and other technical details. What I’m doing might overlap with polish a little, but I feel like what I’m really doing is trying to define the soul of Towerfall right now.

I hate using a term like soul is such a nebulous way. But it feels quite apt in this scenario. Too many games now are seemingly made without reason or care. I feel that’s a huge disappointment that people can put so much work and effort into a product they ultimately care little about. I want to work on things I personally care about which is one of the reasons I became an indie developer.

But it’s not just enough to care about something I work on. I think its paramount to let players know about the passion that went into making the game. Or rather, the game should exude love and care. And to me, love and care has always been those little details in games that end up adding so much. When a developer goes the extra mile to add in something that was totally unnecessary yet meaningful. Like how the Adventure of Link contains the whole original map from the first Legend of Zelda. Or how Super Metroid has an entire side room so you can save your two alien friends during the final escape sequence. Or basically the entire game of Chrono Trigger.

Those nuances and small touches to me are demonstrative of the passion the developers had for their game. You can tell the developers truly loved making that game. It’s the soul of the game emanating through.

So right now I’m trying to find that soul in Towerfall. And hopefully if (or when) I do and you play the game you can tell the craft and care put into making it. Because otherwise what the hell am I doing making games?

The narrow definition of experimental

[Note: This blog post was revised and edited on April 21st]

One of the major perceived advantages of being an indie developer is the freedom to be experimental with one’s games. As opposed to their mainstream brethren, indie developers do not need to deal with the pressures of making multimillion dollar AAA titles that necessitate huge sales and thus need to appeal to the widest possible audience. Instead indie developers because of their small budgets are freer to be experimental and stray from the tried-and-true path.

Yet the popular definition of experimental indie games over the past few years has seemed to become narrower and narrower. When the subject of experimental games is broached successful titles like Braid and Portal are quickly brought up. And these games and their brethren have come to define experimental. Games that are primarily built around a single novel mechanic (or as some may deride a gimmick) are the new flavor of experimental.

Steve Swink (of various indie fame including the game Shadow Physics), himself a presenter at the last Experimental Gameplay Workshop, has also thought about this increasing calcification of experimental and wrote a blog post about it. In it he comes up with his own loose definition of this definition of experimental.

[Experimental] meant finding a unique, promising mechanic dealing with spatial perception, imaginary physics, time manipulation, or some combination of the three and trying to squeeze all the possible interesting permutations of interactivity out of that one unique mechanic. Time, space, sound, color, structure. The criteria seems to be innovation as a mind-expanding riff on physics, and the games can almost always be seen as an attempt to answer one or two interesting questions as fully and satisfyingly as possible. And then culling the cruft.

In particular 2009’s Experimental Gameplay Workshop seemed to have a number of games that fit this definition. Games like Closure, The Unfinished Swan, Miegakure, and Swink’s own Shadow Physics are all based around a single novel mechanic. The innovation in these games is discovering this novel mechanic and playing with variations and permutations of it.

This is not to criticize any of those aforementioned games (in fact having played a number of them they’re all fun and interesting titles). The structure of these games (and other experimental titles like it) is a natural result of the particular innovations they focus on. Games where a unique mechanic takes center stage are often best-served dishing up challenges in this bite-sized format to fully explore said mechanic.

In addition to natural design output there are more pragmatic reasons for creating experimental titles in this fashion. Despite being free to be experimental and innovative, even (most) indie developers still need to think about the bottom line a little bit. Wholesale experimentation with a game can often be tricky and lead to disastrous development experiences. By constraining the experimentation to a single mechanic the developer can help limit some of the riskiness inherent in trying new things. This also ties in well with the smaller budgets and smaller development schedules often associated with indie games. Sometimes all a developer has is the ability to develop a single novel mechanic and properly focus on it. Finally, even in indie games there is some bias towards emulating previous hits. Past experimental indie successes have followed this popular mold and developers are often inclined to emulate the same approach.

But while these reasons might help explain the current definition of experimental games it still doesn’t alleviate a growing sense of dissatisfaction that experimental can – and should – encompass much broader things. The cancellation this year of the Experimental Gameplay Workshop at GDC is a sign of this dissatisfaction. Both as developers and players we’ve been too quick to constrain what experimental can be.

Instead of looking to past experimental successes for guidance we should instead think about experimental a little differently. Games like B.U.T.T.O.N. and Chris Hecker’s SpyParty (which has been presented at the Experimental Gameplay Workshop in the past) that focus on much on interactions outside of the game as those in the game are experimental in a way that’s not just a new time-manipulation mechanic exploited over a series of puzzles.

But really the arguing of what’s regarded as experimental right now is beside the point. I’m not arguing really for a redefinition of experimental, but rather not to let the popular view of experimental hinder the future development of new, interesting, and experimental ideas in games. Games already are oft-criticized for relying too heavily on mechanics and structures that have been in place since the first arcade machines started bleeping blooping. And we shouldn’t let experimental games go down that same path.

Gamma4 entry for all!

[The following is reposted from my other blog for the One Week/Game Project where I’m attempting to work on a new game very week for the entire year. You can read the original post here.]

The first public release of my week 3 game for One Week, here is Monster Monster Monster Party Party Party.

Click here or on the image to play!

Monster Monster Monster Party Party Party was created for the Gamma4 competition. The main constraint for the competition was to create a game that utilized only a single button. Here spacebar is used to play the entire game. When holding down the spacebar monsters will turn invisible and be invulnerable to tanks and helicopters. Timing your invincibility right also gives you the power to destroy the military.

I really enjoyed the artwork I created for the game with the stark colors and angular designs. I had a real blast designing the monsters and one of the things I wished I had more time to play around with was the idea of changing scales for the game (going from a single monster on the screen to up to 20 monsters at its most zoomed out). It’s an game mechanic I think that has a lot of interest and something I would want to explore in a future title or iteration of MMMPPP.

Steal this game idea!

Copying another game has been a time-honored tradition in game development. You can go all the way back to the beginning where Pong beget numerous Pong rip-offs, Space Invaders lead to Galaxian, Pac-Man lead to Devil’s World, and Mario/Sonic lead to a bazillion different mascot platformers to see the proud tradition of stealing game ideas. And stealing game ides exists for a good reason; game design is often an iterative process and it’s cool taking a neat game mechanic borrowed from another game and tweaking and expanding it on your own. Without such liberal uses of copied game design the evolution of certain genres would have never happened.

Yet two separate games/incidents have brought this practice of borrowed game design to the forefront of discussion. First is the release of EA/Visceral Games’ “adaptation” of Dante Alighieri’s Inferno (unsurprisingly) called Dante’s Inferno which is heavily-inspired by the God of War series. And second is the now-pulled iPhone game Trundle which noticeably lifts a lot of influences from the Nicalis/Nifflas’s unreleased WiiWare title Night Sky.

With Dante’s Inferno its clear that in many ways this is an original game. No one would ever confuse the aesthetics of Dante’s Inferno with the God of War series. The setting, the graphics, the visuals and sounds are all completely their own. The thievery in this instance is one of gameplay. Every review of Dante’s Inferno has unquestionably noted the same thing: outside of a few minor tweaks to the combat system Dante’s Inferno fundamentally plays the same as God of War. From control layouts to action combos to even the same annoying button-mashing necessary to perform minor tasks it becomes evident that Visceral Games goal with Dante’s Inferno was to ape God of War.

And for this sin Dante’s Inferno is being punished by the game media. Both the negative and positive reviews for the game have commented on the lack of originality of Dante’s Inferno and this more often than not has helped sour the reviewer on the game as a whole. It’s one thing to copy another game, but to copy and not surpass the original as Dante’s Inferno seemingly does makes the transgression that much worse. And while big-budget titles in recent years haven’t been known for their desire to push originality and innovation the shamelessness of Inferno’s copying seems to be a step too far for even the most cynical player.

While the connection of Dante’s Inferno and God of War is mostly beneath the surface the case of Trundle and Night Sky is about copying what’s on that surface. While the gameplay of both Trundle and Night Sky are quite similar the base premise of platforming with a rolling ball is one that isn’t original or unique by any measure. It’s the effect of combining similar gameplay with obvious stealing of the unique visual style of Night Sky that makes the thievery by the developers of Trundle clear.

Understandably there has been a bit of an uproar over the entire affair. Indie games are also in a bit of a unique situation here. It’s not unheard of indie games to borrow concepts and mechanics from other indie games (think of how many physics platformers or bullet-hell games exist). But to steal another game so directly and especially when the theft is perceived to be taking away the livelihood of a very popular indie figure once again is a step too far. Even the Mobile Bros. – the developers of Trundle – seems to have realized so and have since pulled the game from the App Store and released it again with modified visuals.

With both of these games it’s clear that gamers and developers can only tolerate so much unoriginality before rebelling. It’s not that stealing game ideas is bad by itself as many of the best games in the industry at one point or another started off as clones. But at a certain stage during development they went above being a mere clone and took those stolen ideas and made them their own. With the backlash its clear both Dante’s Inferno and Trundle never took that extra step.

Living the App Store dream

If you want a clear picture on the life of an app in the App Store you could do worse than read Noel Llopis’s blog post on the 9-month saga of Flower Garden. It’s a story full of ups and downs and various travails complete with handy charts and graphs to illustrate his point.

Noel hits upon a certain point midway through the post that I feel is pretty important. At the end of last year with sales declining again after one last attempt to extend the game he ponders if he should move on at this point.

You’d think that I would give up at this point, wouldn’t you? And I don’t say that with pride. I mean, it probably would have been smarter to quit a long time ago. But somehow, every time I was ready to move on, something else would come up that would entice me to try something else with Flower Garden.

The beauty of releasing a game online for the web or on the App Store is the ability to continue tinkering your game far past the initial release. Finding that secret sauce or right combination of gameplay and content and stickiness that attracts people to your game can often be quite difficult and take countless iterations to successfully find. In the story of Flower Garden so far it finally seems like Noel/Snappy Touch has found that balance. Oftentimes its not the best idea that wins, but the one with the most dogged determination to continue going on.

Doing retro right (and wrong)

Retro revivals are a hot commodity right now. With the advent of digital download services like Xbox Live Arcade, PSN, and WiiWare opening new opportunities for publishers to create games an incredibly popular option has been to mine the back catalogs of games with new old-school renditions of classics. Capcom started the trend with the high watermark of Mega Man 9 and other companies soon followed like Konami with its ReBirth series (Gradius, Castlevania, and Contra) and Hudson Soft with its lineup (Adventure Island, Bonk, and Captain Rainbow) with varying levels of success.

The best of these games such as the aforementioned Mega Man 9 succeed by attempting to distill the retro game down to its core. In 9 this was done by taking Mega Man back to the bare basics of his abilities: Mega Buster, jump, and defeating Robot Masters. There were no slides, no charged shots, and no Proto Man (for the most part). Outside of a few additional flourishes like screws for the in-game shop it was as close to a direct sequel of Mega Man 2 in terms of gameplay evolution as imaginable.

But removing gameplay by itself shouldn’t make a good (retro) game. After all by themselves none of these additions made the core Mega Man gameplay terrible. In fact both slides and charged shots are effectively used by the optional DLC character Proto Man with nil effects on the quality of the game. So why did these gameplay removals become the example of addition by subtraction?

If you ask Mega Man fans, the original series of Mega Man 1-6 on the NES went downhill due to an increasing focus on gimmicks over genuine interesting gameplay. Chalk it up to running out of ideas after so many iterations or bored developers, but its undeniable as the series went on the weapons and designs of the Robot Masters became focused on one-note throwaways, the level design grew sloppy from overuse of additional gameplay tweaks like Rush’s add-ons, and the series went into a tailspin of sorts. After a break of nearly 15 years Mega Man 9 represented a renewal of sorts. And by removing those gimmicks and tweaks there was an opportunity to tailor the levels entirely to genuinely exciting gameplay built from the core foundation. Because the levels of 9 can be played entirely without those gimmicks and additions the design is solid, fun, and in classic Mega Man.

Which brings us to the discussion on hand. The first real information about the latest game in the Sonic series arrived today and Sega will be attempting to take the retro revival route like many others. And for good reason as Sonic is perhaps the character in most need of a decent revival at this point. Sonic post-Genesis has been on a continual decline towards irrelevance and its only been the goodwill efforts of other developers outside of Sega who have managed to keep the blue hedgehog with some semblance of dignity (Smash Bros. Brawl being perhaps the best game with Sonic in past years and being developed primarily by Nintendo).

So with Sonic 4 here’s hoping they stick to their proclaimed mantra of momentum over speed and exploration over races. Looking back at some of the classic maps from the heydays of Sonic gives you a sense that Sonic was never truly about getting from point A to point B. The levels are often sprawling endeavors that require equal parts speed with patient exploration. In these classic Sonic games going fast was never as important as knowing where to go fast and where to stop and slow down. It’s this quality that hopefully Sega can emulate for a successful retro revival.

So even if they include minor things like Dr. Eggman over Robotnik or green eyes vs. black or even the a homing attack as long as they nail the core level design Sonic can finally be Sonic again. That core level design built upon solid principles of skills that define the venerable blue rodent for so much of our childhoods.

A post-GGJ 2010 status report

One Week/Game is a side project I’ve been trying to get off the ground this year. The premise is that I attempt to build a game of sorts every week throughout the entire year. As you may tell by glancing at the site, the start has been a little on the slow side.

That being said this past weekend with the coincidence of both the Global Game Jam and Gamma 4 submission deadline I imaged to create a game in under 48 hours. Even more happily the game (Monster Monster Monster Party Party Party) even managed to vaguely be about deception and is playable using only a single button!

I managed to have enough time to complete a game largely because our local Global Game Jam site was marred a bit by weather issues. I’m responsible for organizing the local site for the Triangle area and inclement weather prevented our awesome hosts Icarus Studios from staying open during the weekend. Thankfully the participants were motivated enough to stick together and still develop 7 games over the weekend in spite of these issues. Definitely check them out and the other games from the Global Game Jam. Over 4000 people and 942 games can’t be wrong!

[Image not from a game from my site, but depict1 by Kyle Pulver from Retro Affect]