3 Mini-Portmortems

Jan 27, 2012

Here are mini-postmortems on 3 team projects for which I served as a lead for code/design or otherwise primary role. I handled programming and much of the gameplay design, but was not the only designer and developed the games in collaboration with artists, writers, musicians and other designers. Full credits are available in each case in-game.

Please note that all of the games below require a modestly up-to-date version of the Flash Player (free).

Vision by Proxy: Second Edition

> > Play in BrowserTrailer Video < <

Artsy Puzzle Platformer

Released August 2011

As of Jan 2012: 2.7 million plays, won Best of SIEGE 2011 Student Showcase
[Feb 2014 update: 6.9 million plays]

VbP:SE did better than we expected, making it to the front pages of several major Flash game portals in the US and abroad. We’re currently working on a sequel (Ms Vision by Proxy) in which we attempt to address the game’s brevity by involving more character eyes. The short length of VbP:SE probably worked a bit to its advantage though, since it kept the scope such that players can get through the full game comfortably in one sitting.

Some people especially disliked the bonus levels, while other players specifically preferred those stages, both for the same reasons: they focus on platforming instead of puzzle solving. The game was short enough, all included, that players who like either were mostly able to slog through the ones they felt so-so about. In any case it worked out well having these types of stages separated conceptually as a post-story second play through, rather than forcing both level types into the same timeline. It’s a trick akin to what’s seen in Portal or Mirror’s Edge – at a much smaller scale, of course.

The game also would have suffered more from being too short if we hadn’t milked the engine, level parts, eyes, and cinematic sequences to squeeze in twice the levels. Most importantly we were able to get this increase in length without creating any new art assets nor needing to program any additional features. I just spent an extra day in the level editor churning out 9 more levels and throwing away the 6 I liked least to leave my preferred set of 3 remaining, which is a fairly common way that I like to do level design when time and tools allow it.



> > Play in Browser < <

Set-and-Play Sideview Action

Released May 2011

As of Jan 2012: 90,000 plays, 85% on Chinese web portals
[Oct 2013 update: 121,000 plays]

I feel like this game had just the right number of unit types: 11. More would have been harder to learn, and fewer would have limited depth and variety.

Early on during development we briefly explored what it would take to make a more complex and involved simulation with more detailed AI, stat, and strategy options, though we ultimately decided that something like Gratuitous Space Battles might not make sense for an in-browser gaming audience. That worked out for the best anyhow, since we didn’t have the time outside of classes during the semester to pull off something on that scale and polish. We made a lot of compromises to keep gameplay quick and to the point. In the end we made it simple and quick for players to get set up, which turned out to be vital for a game like this since trial, error, and observation is necessary to learn how each of the weapons and units work out against and alongside one another (from emergence, though, not from any contrived countering or boosting relationships).

It’s surprisingly difficult to come up with cool, non-cheesy names for futuristic military units that haven’t already been done to death. Our writer came up with excellent names for each of the units, in addition to helping us come up with a varied set of weapons and abilities and writing the opening crawl. The techno-metal track we selected from Kevin MacLeod’s Creative Commons library fit really well, but like any MacLeod music people hear the songs in YouTube videos and other games. MechWarrior 2 was a source of inspiration for us, and the song we picked has a similar vibe to Dragon’s Teeth from MechWarrior 2: Mercenaries.

Though my animation engine wasn’t particularly great, our mech artist did a really nice job with the individual mech body parts. Without cool looking mechs the game wouldn’t have worked at all. Our main UI designer wound up doing all of our final tank and plane art near last minute (not her fault – originally someone else was going to make them), and thankfully they came out distinct and recognizable despite the time limitations. Our original plans included the ability for mechs to lose their limbs during battle, as they do in MechWarrior games, which we wound up cutting since our mechs didn’t look as good without arms, and if mechs lost any of their few weapons during battle it would only drag out the endgame.

When there’s only a few units left in a well-matched battle it can be kind of suspenseful… but it mostly just highlights the weakness and inaccuracy of my AI. In my defense, for about half of the project we had someone else onboard specifically to focus on AI programming, though on account of outside obligations he wound up parting before really getting started. That type of uncertainty is simply a risk of making hobby/extracurricular videogames, since we have no pay nor course credit to offer. The core gameplay still works with the mostly functional AI I stitched together.

We were considering having multiple rounds per configuration, with players able to make changes to their AI or weapon settings between rounds but not to which vehicles are included, but I’m glad that idea didn’t make it. Part of the fun is quickly mixing up fresh scenarios, and being forced to watch a poorly chosen team lose again and again would be rough. The single round simplicity of our matches and how quickly they can be set up even made it possible for Henry and I to play indirectly via Facebook:

The team had a bit of back and forth about whether the players should be able to do anything during the match. Proposals included pressing a key to time deployment of a second wave of units, using the mouse to fire an orbital super weapon, toggling some AI variables, or directly controlling a lone commander unit. In the end we went with pure spectatorship, with shared camera control, which has a very different feel than being involved during the action by prolonging a sense of hope rather than demanding constant focus. Although we added little smoke and sparks to damaged units, we opted to leave precise vehicle health bars out of gameplay, partly for the uncertainty that their absence adds to excitement. Being able to identify the clear winner well before the end of the match, which could have messed up the experience, is much harder to do reliably since it’s unclear how many more hits the units left on the field will be able to sustain.

Huge robots walking past one another mid-battlefield just looked wrong, and combined with their slow speed we couldn’t get away with it as we did with the tanks and jets. Instead, we programmed the mechs to stop and fight toe-to-toe with one another until one or the other exploded. All three mechs also have a special mech-vs-mech melee attack implemented: the humanoid walker slashes with the energy sword (instant kill to any unit), the chicken walker kicks, and the spider performs a stomping action.

We didn’t mean to make melee so rare as it came out, that happened only by late accident while trying to patch up other tuning imbalances. These attacks played a pretty pivotal role in the first build or two we released, with matches often coming down to mechs destroying each other point blank in the middle of the stage. The inevitable melee gave extra importance to fielding a humanoid walker. In later tunings (including the current version, 1.04) we improved the weapon accuracy for most units, decreased mech armor slightly, and increased the effectiveness of machinegun usage between mechs at medium range. These changes combined to make mech melee virtually never take place, though technically it’s still there and will happen if matches unfold in a sufficiently peculiar way.

In hindsight, a way to save a launch team configuration for more rapid experimentation in sandbox would have been nice. Not only would it help players experiment faster, but it also would have made testing and iterating on game balance easier for us.


Zylatov Sisters

> > Play in BrowserTrailer Video < <

80’s-ish Arcade Action/Platformer, designed for shared screen co-op

Released Dec 2011

As of Jan 2012: 130,000 plays
[Oct 2013 update: 300,000 plays]

Unlike most other games that I’ve worked on, after finishing work on this I still really enjoy playing it.

As an experiment in modular game design to help reduce overhead Zylatov Sisters was successful in producing a good amount of variety and giving a number of beginning developers in our videogame development club a mix of experience. (I’ve previously written HGD entries about our process, and also some of our design decisions)

Many players are finding it unacceptably difficult, though we understood from the outset that we wanted to make a game with pinball or classic-arcade pacing: constant vulnerability, typically 1-3 minute sessions after a modest amount of practice, and replaying to earn increasingly higher scores. Further, we knew that the usual in-browser gaming audience might not necessarily go for this type of structure since it’s an outdated taste. Players widely accustomed to videogames that are designed to be plowed through by persistence are presented here instead with levels that aren’t meant to be consistently completed.

There’s also a steep learning curve in that the arena-nature of each level means it’s hardest right when each stage begins, when all enemies are still alive. Start the round carefully enough to survive and aggressively enough to cut down some of the horde, and with the remaining lives the odds of survival within that level improve considerably. Fewer enemies left in a stage also makes it easier to retrieve gun/item boxes, which can help improve survival odds for the start of the next level.

This was never meant to be a commercial game though, so we felt ok with simply making the game that we wanted to play.

Our decision to make any level equally eligible for selection as the first level gives the game variety for a high level of play and makes it easier for students on the team to show their work to peers. We also randomize which level shows up first, so that every player gets a slightly different first experience. However the lack of any intro, tutorial, or beginning level(s) served to further alienate players that found the game too difficult at first. We perhaps ought to have at least picked out a few of the easiest levels, and made the first level upon game start randomized from between those instead of all maps.

We also received frustrated feedback about the game’s default controls, which we set with co-op in mind. Even though the controls can be reconfigured from the main menu, relatively few people seem to be taking advantage of that. We perhaps should have gone with our original plan of using different default key mappings for single player vs co-op play, which we strayed away from late in development from fear that doing so would throw people off when trying co-op. Supporting that decision would also require a slightly different menu system, which we didn’t have time left to do late in the schedule. Unfortunately some players are finding the single player controls needlessly cramped, then simply quitting forever before either trying co-op or realizing that the controls can be easily reconfigured.

In other words: fully reconfigurable controls cannot make up for default controls that people don’t like. Especially with a free game, people have no investment in making the experience work for them and can easily switch to something else, so if they don’t immediately like the default mapping it’s over – player lost.

On the plus side, more so than the other games I’ve mentioned here, people that do like this game seem to be returning to play it semi-regularly. That makes sense given the arcade model we were trying to emulate. By comparison though, it doesn’t really make much sense to play VbP:SE more than once, and MechStrike‘s novelty and mechanics favor head-to-head play but don’t offer much single player replay.

Our inclusion of co-op only support weapons worked out well for two-player, but may have strained our single player weapons offering a bit by comparison. We partly mitigated this by the three types of special weapons that can appear for getting a 5X or higher multiplier. However because it takes a bit of practice and luck to earn those, they don’t do much to help first impressions. The two-player support weapons can be really powerful for assists if used effectively with the other player’s help, though here again, tuning the game to keep those co-op weapons from being overpowered rendered single-player even more unforgiving.

Co-op also lets players revive one another indefinitely. As long as at least one player remains alive and can find a chance to either finish the current level or kneel briefly by the fallen sister, it’s possible to just keep going. Two experienced players working together can go on a roll for quite awhile, which in light of the game’s harsh difficulty can be especially rewarding.

The aftermath stat and throwaway “award” screens (GoldenEye 007 style) worked well for giving players a moment to reflect on each round. Without them I think a hard jump from game over right back to level select menu would have been too jarring.

Outside testers really helped out a lot near the end of the project. I put out a call via Facebook and Twitter, and also had a few classmates try it out in person where I could more easily observe and ask questions. It led to some important spot fixes to several stage layouts/assets, tweaks for more responsive controls (running then turning used to slip much more, as if on ice), and focused us on which wish list items were most important to implement with the time we had left (including saving high scores locally and the option to customize controls).

One of our members oversaw narrative design in addition to helping out as another technical game designer/artist. That can be a tricky role to play on a project that aims for an mid-80’s action arcade aesthetic, but he understood from the outset that the goal was low-fi retro, and he was flexible to the specific needs of the project. Since the genre is pretty light on written text outside of the intro (which players of this sort of game tend to skip anyhow), he instead improvised other ways to help establish the game’s atmosphere: recommending the game’s main font, drawing the title screen background to set the mood, and authoring his levels with a deliberate progression.

Our team members making chiptunes for this project really shined (several of them don’t have online portfolios yet, though one does), pulling off a Castlevania/MegaMan-ish vibe pretty well in a number of tracks. I’ve been enjoying the soundtrack separately from the game. Tying specific songs to each stage helped give each level a consistent personality, beyond what feel we could achieve through changes in layout, tile art, and enemy/item/spawn placement. The best way to browse the game’s music and see who’s responsible for each track is to play Zylatov Sisters and scroll around on the level select screen.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.