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.

1). Maintaining momentum

Our previous projects R-evolution and Connections were both completed within 7 days. And in both of those cases getting to the crucial tipping point of having a playable system with feedback occurred within 3 days of work. Scott Told Himself was designed with very simple systems that required a lot of scripting work. This meant that even 6 or 7 days in we had a lot of small interactive moments that never connected into a larger game. Each day working on the game without having something truly playable at the end of the night sapped a little bit of enthusiasm out of us and over the course of 10 days really drained us mentally.

Not only was there a lot of scripting to be done with the game, but we hadn’t adequately planned out how to develop for a script-heavy game. Typically in a game like this you want to develop tools for scripting early on so other people can work on scripting in parallel with general game development. However on Scott Told Himself we didn’t even have a generalized scripting engine for the first 5 days of development. And even then objects had to be placed through a tedious process of slowly rewriting both XML and code files depending on new functionality. All-in-all it lead to a mess where I as the programmer was primarily working on the game while both Dan and Felix were left with few tasks to work on simultaneously. This uneven distribution of work led to an unhealthy dev environment where I felt anxious for the amount of work placed (by myself!) on my shoulders and both Felix and Dan felt anxious because they felt they weren’t actively contributing to the game.

2). Building systems vs. moments

During the course of our project we’ve been working with this basic dichotomy of creating meaning within games either through the systems versus specific moments. Basically should we create a working game and mechanics that eventually leads to moments of meaning (or as we define it moments of introspection, reflection, and/or realization) or do we work from specific moments and try to build the game to those? With Connections we decided to approach things from the systems end and focused on modeling relationships and personalities with the hope that meaningful moments would emerge. This had its advantages and disadvantages so for Scott Told Himself we decided to determine the pivotal “moment of realization” first and build the game backwards from there.

The danger there was by working backwards and crafting the system after determining the meaning we were waiting on a lot of different development aspects to coalesce at the last minute. And while we had determined a strong moment for the game, we never really defined a good system to place around that moment. So instead of developing toward a consistent end goal we were habitually changing our dev target, adding new mechanics and features on the fly as we grasped in the darkness for a fun system. We never really got there in our development so even now we don’t feel there’s a complete system to work around with Scott Told Himself.

3). Meaning takes time

Finding meaning within a game is different than defining a new mechanic in a game. One of the most basic differences we feel is that the barometer of success between the two is wildly different. Experimental by its nature merely needs to exist to prove a point. If you’re creating a game based around a new experimental mechanic you just need to show proof that a mechanic can work, not that it does work. Anything afterwards, the playability/fun of the mechanic is icing on top of the cupcake.

With meaning success isn’t determined by attempting to convey a specific meaning, but rather success (we believe) is determined by how well that meaning was conveyed to your audience. After all anyone can say “this game is about the guilt of losing a loved one”, but actually delivering on that concept is the true determinant on how meaningful your game is. And this means that it’s not good enough to deliver a concept, we need to deliver a fully-formed game with systems and interactions that work as well as they can to deliver meaning and expression. The execution is just as important as the conceptualization with our project. What this practically means is that our game development cycles tend to be longer and more focused on polish than what you would expect compared to experimental game prototyping. We need to take longer to ensure our games are complete upon release or that meaning may not be effective in its delivery.

Coming back again

These things being said, there’s no doubt in our minds that we want to return to Scott Told Himself in the near future and hopefully figure out the specific game issues that were hindering the game. We still believe there’s a great idea and a great moment of realization we want to express. It’s not that far away from completion, but we just need to know where to take it.

More importantly though is that Scott Told Himself is the first time we ran into these problems and had to express them cogently. These problems are not isolated to Scott Told Himself, but have been and will be issues we will constantly grapple with throughout the course of our project. So in a lot of ways having an obstacle like this early on is incredibly helpful to us. Now we are able to recognize these potential pitfalls going forward and hopefully inform our future game development.

For now though, we move on to our next project. We’re going to try a different pivot with our next project and hopefully regain some of the development momentum we lost here. We have a lot to say about things going forward and things that occurred in the past.

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.

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?

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.

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.

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.

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.

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.

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]