Excellent news everyone!  After what’s felt like a very long stealthy period, I dare say the tunnel of Gimbal Cop is showing some light at its end!  We’ve been working on this project for a while now — just about two years, with some fits and starts — and the game’s passed through many phases in that time.  In this post, I’ll describe what we’ve been up to in our long dark phase, and I’ll follow up with another post about the present excitement, the private alpha stage we’re in now, and the forthcoming public alpha/beta phase.

At its conception, Gimbal Cop was on one hand an experiment in procedural mesh building (reflecting on our shelved Platformer project, Schoen came up with many insights in a less restrictive approach to mesh building and was eager to build a game around it), and also an attempt at a “quick and easy” game: in that initial form, it was an infinite procedural runner.

Branching out, diving deep

In retrospect, we should’ve polished up that prototype and shipped it before moving on to more unproven and complicated gameplay ideas — but, seeing the potential for a really interesting new kind of game, we (myself in particular, I must admit) really pushed the game towards the high ideal we’ve long dreamt about: an asymmetric multiplayer creation game.  To make a long story short, there was a lot of time spent experimenting with different ways to deliver on those gameplay goals, and at least as much time spent developing the required systems: many iterations and improvements on the mesh building technology, multiplayer and matchmaking, “3D” GUI (as opposed to Unity’s native OnGUI approach), AI, and more.  Another of those “in retrospect” realizations: we should’ve taken advantage of middleware options for many of those systems, particularly multiplayer and GUI.  Respectively, Photon and NGUI come to mind.

Throughout this long period of developing our tech and exploring the gameplay space, the experimental aspirations of the project slowly gave way to the goal that, sooner rather than later, we wanted this game to come out to and be enjoyed by the public — yet still we hadn’t found something that simply worked, in terms of connecting with people, and finding the elusive “fun.”  When we played the game, we didn’t love it, but that can often be an unhelpful test, since we’re looking at the game from zero inches away, day after day.  So we’d peddle it at demo events and conferences, and pretty consistently get the feedback of “cool, that’s a really interesting idea.. yeah, the game’s OK, keep iterating.”  Simply put, it didn’t connect with people.  Moreover, we shared their lack of enthusiasm; personally, I wouldn’t find myself playing it for more than a minute or two, and I know that if I’m not getting sucked into my own game and losing track of time, neither will anyone else.

Breaking it down

From Schoen’s earliest tests with the mesh building tech, we had played with two modes — Tunnel-style barrel-rolling controls, and freeflying controls (both for the Architect, the player creating the track) — and have always meant for a combined approach (freeflying Architect, and also twist-based racing) to be the ultimate form of the game.  But, after about a year of trying to get all of these components to fit cohesively into a single fun game, I started concluding that we’d be better off breaking the game down into its simpler constituent experiences: one mode that was a constrained racing experience, and another that was a freeflying experience, without the racing and asymmetric multiplayer elements.

I prototyped a bare-bones freeflying 3D Snake mode, and after a couple of hours of work, had a little game that I was very happy with, and found myself — and my faithful testers — getting sucked into it, playing for many runs on end, competing for high scores.  For the first time in a while, I felt like a gameplay experiment was really landing with people.  And this was also the simplest gameplay experiment we had tried since Schoen’s original racer prototype.  Yes, I suppose there’s a lot of wisdom to the common knowledge of keeping it stupid simple.

The Snake prototype was a fresh project, written outside of the Gimbal Cop codebase.  I did this because, at the time, I found experimenting in Gimbal Cop’s code to be very hairy business: it was complicated to implement a new idea, requiring edits to a wide swath of the codebase, and thus was very prone to breaking other components of the game, and would always make the codebase more convoluted.  In other words, every change, iteration, and experiment made the code increasingly messy and hard to deal with.  Something had to change to make the game more “jammable”: more inviting to non-destructive, non-cluttering, modular gameplay experiments.  I’ll write a full and developer-oriented description of the Modes framework another day, but in brief, we added callbacks throughout the game’s codebase that would let a new gameplay module easily hook into any event in the game (for example, OnRoundStart, OnArchitectTriggerEnter, OnRunnerUpdate, etc), from one centralized location.  This let us separate out the core logic that makes the game run from the gameplay iterations of any one mode.

We transposed the Tunnel gameplay, as well as some control scheme options, into their own modes, and I ported my Snake prototype to this framework, at last unifying that project and Gimbal Cop.

The next big phase came this past summer, leading up to the Boston Festival of Indie Games.  Tunnel and Snake modes were both decent, but definitely had room for improvement, and I had a few gameplay ideas in mind for both.

Tunnel’s “first” iteration (in the new Mode system at least) had the Architect player manually switching tracks, each of which had different droppable obstacles and path-following projectiles for the Architect to use to impede the Runner players.  In theory all these ideas sound cool (or at least they do to us), but in practice, asking the player to think about which track they want to be making, and which obstacles they want to drop and when, was asking too much — and probably most of the problem is the interface.  On mobile, the Architect player is controlling the path with the twist of the device, and then has three on-screen buttons, each of which pops up a small menu, to control track type, obstacle choice, and projectile choice.  Then the the player drags and releases on the screen to actually place that obstacle or projectile.  So yeah, it was asking a lot of the player, and understandably didn’t click.  The interface makes arguably even less sense on a screen with a mouse, since you’re using the mouse to drive, and also to pick things out of the menu (you can hold a modifier to not listen to mouse input on the track, but that’s contrived).  Long story short, the interaction was far too messy, and in need of further refinement and steamlining.

Jamming out

So I tried a second iteration of Tunnel, where both the Architect and Runner players pick up goodies in the environment (floating in space for the Architect, sitting on the track for the Runner) which immediately fire a projectile towards the other player, and spawns into an obstacle when it gets there.  In other words, the Architect grabs a pickup and instantly fires a projectile down the path, which waits until it’s close the the lead Runner, and then bursts into an obstacle on the track.  The Runner does the same: grabs a pickup and instantly fires a projectile up the track, which flies past the Architect and bursts into an obstacle in the that player’s path.

Around the same time, I was also experimenting with a second iteration of Snake mode.  The first is fun but felt too boring to me, and I thought that the environment was in major need of rethinking: instead of just being in a semi-random asteroid field, there should actually be a level to speak of.  This idea is a fundamental shift in the way we’d been approaching Gimbal Cop’s environment throughout the project: we’d been attempting to go fully procedural with the environments, wanting to make a decently interesting infinite space environment.  After a number of attempts at making that work, we all started to realize that making an interesting procedural environment is much, much harder than making an interesting static hand-authored environment.

With the new iterations of Tunnel and Snake ready for some feedback, we prepared for FIG (the Boston Fest o’ Indie Games), where we’d get to try our latest ideas out on some real folk.  With just a few days left before FIG, Danger started trying out Oculus Rift support in the game.  We’d known since we first heard about the Rift that we’d want to support it in Gimbal Cop, and with some of the recent changes to the game, it felt like it might actually work pretty well.  He got the Rift integration solid within a few days, we tried it out — and we were blown away.  I had been actively thinking about (let’s be honest: obsessing over) the Rift while prototyping Snake mode, knowing that being able to look around with your head would add a major dimension to the game.  Still, I underestimated what an excellent fit the game and device were for each other (we’ll make another post soon with our full findings on working with the Rift and VR game design).  We decided that we’d show off VR mode at FIG, and Danger and I both arrived with our devkits in tow.  We were wondering before the show if there’d be any other VR games there; after all, the Rift is a pretty huge rage in the indie gamedev world, including the Boston indie scene, probably most notably with Dejobaan and Owlchemy’s AaaaaAAaaaAaaaculus!  As it was, nobody else turned up with VR games, so of course we were swamped all day by people waiting to see the fabled Rift — and, hopefully, at least a bit, they could also enjoy our game!  In fact, people really enjoyed the experience, and we got lots of great, almost entirely positive, feedback on the game itself.

On the flipside of those good vibes, we found that, even with a captive audience of people waiting to play the VR Snake mode, people by and large weren’t interested by the Tunnel mode experience, which we were also running at the booth on multiple networked mobile devices.  A few people got into it for a while, but the vast majority of people gave the ‘ol “cool idea, but I’ve played enough now, thanks,” and one little kid had a very sad moment with it (lesson learned: make sure nobody has the experience of picking the game up, being confused, and quickly getting a giant “YOU LOOOOOOOOOOOSE!!!”).

Coming out of FIG, the message was very clear to me: Snake was in a good state and close to leaving the incubator, and Tunnel still has work to be done if we’re going to get that ambitious mode working the way we think it can.

Back to the now

That all brings us more or less to the present.  In the name of being at least a little bit coherent, I’ll make a second post about what we’re working on right now and what comes next.  Here that be.

I hope that this long, long-winded post has broken the ice of our stealth mode, has told you, the curious longtime Defective fan, what we’ve been doing with ourselves.  I don’t want to get too far ahead of ourselves here, but methinks we’re ready to be a little less stealthy going forward 🙂

~ by Jono on November 12, 2013.

Posted in News, RL happenings