Category Archives: Game design

Iridescence mobile development update

When I was at the Boston Festival of Indie Games with Iridescence, I’d tell anyone who asked about the mobile versions that they were about two or three weeks out. At the time I had every reason to believe that to be the case, but it turned out to be a little more complicated than I had anticipated.

This will be a moderately technical post, so the short version: Iridescence is still coming out on mobile devices (iOS, Android, and even Windows 8 phones), but it won’t be as soon as I had hoped.

Now onto the technical side of things.

Iridescence is written in Haxe, which is a language that aims to act as an intermediary between platforms. Instead of writing C++ for desktop platforms, Java for Android, Objective C for iOS, and C# for Windows phone, Haxe allows you to write in one language for all platforms, translating itself into the one that’s best supported by each target. On top of Haxe comes OpenFL, a framework that mimics the Flash API but has support for OpenGL and runs as a native application. A single codebase, a familiar API, and great performance? Almost sounds too good to be true.

It is.

A week before launch, I plugged in my Android tablet to get a build running. It had been my intention to have a tablet on the exhibition table so people could see the game running on a variety of platforms. I’d had it working in the past without any issues and without having to change a single line of code, so I expected it to be uneventful.

It wasn't.

It wasn’t.

I’m at a total loss to explain what’s going on. At first I thought it was just a matter of the renderer acting up, but the music doesn’t start either. Worse, I get this same behavior if the app is entirely empty. Other games work just fine, so it’s not a problem with the device. On my friend’s brand new Moto X nothing displays at all, so it’s not a matter of the tablet being below required specifications.

I’ve spoken to the OpenFL community and development team to no avail. A new beta version of the framework came out and had the same problem. Worst of all, I tried to roll back to an earlier version that had worked before and I couldn’t even compile. The OpenFL ecosystem is in a constant state of flux, with new build toolchains and dependencies popping up seemingly every time it updates, and the older (working) versions weren’t compatible with the new tools.

At this point it was time to start considering my options.

  • I could hunker down, wait for another OpenFL release, and hope that it would solve my problems.
  • Or I could bite the bullet and port the whole game back to C# (the language I wrote the original gamejam version in) and use Unity.

I’m choosing Unity. I’ll be using the Futile framework, partially because the API is Flash-inspired and will be easier to translate code between, but mainly because it’s a fully code-oriented workflow and only has support for 2D. When I first started working on the improved version of Iridescence Unity still didn’t have support for Linux and doing 2D work was a hassle. Not so any more. When I’m finished, this version will replace the current Windows/Mac/Linux Haxe-based one.

It’ll be a tough road but I’m ready to do what it takes. I leave you with the first step.

long road

Menu work

This week in development on Iridescence I’ve been focusing on menus, settings, and save data. Here’s what I’ve implemented as feedback when the player tries to open a level that hasn’t been unlocked yet. The animation is inspired by WordPress’ login window, and I think it’s pretty clear what’s going on.

1GAM 2013: Postmortem

2013 is over and, thanks to OneGameAMonth, I managed to finish 12 games over the course of the year. I wanted to talk about each one a little bit.

January — Must’ve been rats!

rats_arcadeJanuary’s game was the result of my participation in the Global Game Jam, working with Chris Logsdon and Paul Ouellette (with voice work by Mike Elser). It was a lot of fun to make despite not entirely fitting the jam theme, and its a lot of fun to play thanks to its overall silliness. I’m really happy with how well it turned out given the limited amount of time and relative complexity of the systems we were working with.

Here’s my full post on this game.

February — Humphrey’s Tiny Adventure: Remastered

htar

I’m still very happy with Humphrey. For the small amount of time I put into it, it’s one of the more polished games I’ve finished and I enjoyed figuring out ways to convey the story without any words. Despite my love for open-ended systems-driven gameplay, point-and-click adventures will always have a special place in my heart due to their role in my childhood, and I’m glad I was able to make one even as minimal as this.

Here’s my full post on this game.

March — No Other Home

dsjChris and I made No Other Home for NASA’s “Dark side of the jam” event that we attended at NHTI. It was pretty ambitious and we ended up taking a bit longer than the initial 48 hours to finish it.

Looking back on it there are a bunch of things I would change to make the gameplay feel better, but overall it’s pretty solid and I love the way the solar system looks.

April — Vanguard Charge

vcVanguard Charge was born from a combination of my frustration with the limitations of Mass Effect’s Vanguard abilities and inspiration from the results of TIGSource’s “Bootleg demake” game jam. The goal was to capture one specific element from a well-known game and present it in a way that feels like a cheap knockoff product. I only spent a few days making this and there’s admittedly not a lot going on, but it’s fun to play and that’s what matters.

May — Bit Cave

bc

Another game jam entry with Chris, this time to celebrate the revival of the Flashpunk forums. I love the atmosphere in this game. The tension between exploring further and staying alive can actually get pretty high, and the caves are unpredictable enough that even I still get lost despite having designed the system that creates them.

 

June — Gunbuilding

gb

Gunbuilding’s caption on my 1GAM profile reads “The worst misnomer of all time”, and that’s no exaggeration. As a game it’s an abject failure. The gameplay is simplistic, the visuals are terrible, and there’s no way to win or indeed any reason to keep playing. The only redeeming quality this game has is that it allowed me to put my C# port of Flashpunk through its paces and fix a ton of bugs.

Here’s my full post on this game.

July — Slide

slide_arcade

I’ve written a lot about Slide elsewhere, so I won’t go into depth about it here. This was a fun game to make because I had to think backwards in order to create puzzles, which gave me a newfound respect for mystery authors and other puzzle game designers. It was received very positively in its initial state and I’m currently expanding it for a commercial release on mobile and desktop platforms.

 

August — MicroRL

mrlMicroRL is another experiment without much in the way of gameplay. I wanted to take the ASCII aesthetic of classic roguelikes and try to make a minimalist game that felt good to play. Since the systems involved were so limited, I had to use some sneaky tricks to create situations that weren’t explicitly allowed, like having friendly monsters that healed you by dealing negative damage. Overall it’s not especially worth playing, but I’m pleased with the way it turned out.

September — SlangVN

svn

My final pure experiment of the year (yes, that is a screenshot on the left). SlangVN was a testbed for my experimental scripting language Slang, in the form of a minimalist Visual Novel engine. Technically I guess I would call this a success since the purpose was only ever to test the expressiveness of the language, but the result isn’t a game by any stretch of the imagination. The script is pretty nice though.

October/November — Color/Shift demo

csd

Part of my strategy for hitting as many platforms as possible with Iridescence (formerly Color/Shift, formerly Slide) was porting it to the Haxe programming language. This release marked the point where the port contained all the features from the original game and could make use of all the same content. I spent part of the second month porting the game to Linux, which (thanks to Haxe’s cross-platform magic) was almost entirely painless.

December — The Heroes’ Tourney (beta)

thtThe Heroes’ Tourney started in yet another game jam and has gone on to become a serious project that I’m still working on along with the other guys on my team, as well as some new talent. So far everyone we’ve shown it to has had a blast playing and we think we might be on to something good. The official website is under construction here.

 

Wrapping up…

It’s been fun participating in 1GAM, and I’m really happy with some of the games that came out of it. Looking back on it, though, I wish I hadn’t followed along so rigidly. Some of the months would have been better spent concentrating on more serious projects instead of stressing about meeting the deadline, and I felt more pressure to polish up my experimental projects to submit them where I probably would have abandoned them earlier otherwise.

In 2014 I’m going to participate more casually, following the revised rules which encourage working on fewer projects for extended periods of time. I’ve got a promising solo project and a great team project to occupy my time for the next few months. We’ll see where it goes from there.

Color/Shift input woes

When I released the Color/Shift demo, one of the main issues that were being reported was that dragging the pawns around was really difficult. This confused me as I had spent a lot of time painstakingly tweaking the controls so that sliding pieces felt natural and responsive, but it was obvious by watching people play that there was something seriously wrong. I made some changes to try to make it better, but the result was still pretty bad. The pawns would slide around loosely in any direction they wanted until crossing a grid line, at which point they would snap to an axis and move along it, It didn’t feel good, and it introduced all kinds of new problems including the possibility of phasing through objects or traveling in two directions at once. Worst of all, it still didn’t address the issue entirely.

Dwm 2013-11-11 10-21-38-83

Yuck. :(

I let it be and moved on to other things, planning to come back to fix it later. There was probably a little bit of hubris involved, if I’m being completely honest with myself; if I didn’t have a problem controlling the game, other people shouldn’t either, right?

A few days after leaving the issue behind, I was working on my laptop (most of Color/Shift’s development has been done on my desktop computer) and suddenly started having the same problem as my testers. Pawns were moving sideways when I wanted to move up, and sometimes they wouldn’t even move visibly before smacking into a wall to either side. What was going on?

As best as I can figure, the input issues had to do with the sensitivity of the mouse being used for control. My desktop has a high DPI gaming mouse with the sensitivity cranked way up, and my wireless mouse and laptop trackpad are much less precise. Armed with this new information, I set about making things right.

angle0

Here’s a visualization of the way I’m handling input now. When the user presses the mouse button, the pawn remembers where the pointer was when it was pressed. In the image above, it’s right in the center of the piece.

At this point, no dragging is actually done yet. The mouse must move 7px in any direction before the pawn will move at all; this is represented by the circle cutout at the center of the transparent fans.

When the mouse has moved far enough from its original position, its angle to that position is checked. If the angle is within 30° of an axial direction, the pawn is then allowed to move on that axis. If not, no movements are made.

angle1

The angle is relative to the mouse click position, so it’s possible to start the drag by clicking anywhere.,

I still need to stress-test this to make sure it works for everyone, but it feels much better with all of my mouse devices and I have yet to move a piece in a direction I didn’t intend since improving this mechanic. Feedback is important! Listen to your testers!

 

7dfps 2013: Raycaster update

Progress on my raycaster for the first few days of the 7dfps challenge was really good. The geometry renderer was a ton of fun to work on and came together nicely. I played around with shaders for the first time ever and added a cool pulsation to the saturation of the colors that felt great, and Chris made a great background track that exactly fit the fast-paced arcade-style action we were envisioning. Everything seemed to be on track.

By the final day of the competition I had spent three days struggling with the math behind adding sprite rendering so my maps could contain objects besides wall cubes, and there was no way I was going to finish the project on time. Without support in the engine for multiple wall textures or world objects, there was really no possibility of making an actual game. Despite this, I’m still happy with the way the week turned out. I didn’t even start until almost two days after the challenge began, and I got my first taste of 3d programming. It was a lot of fun, and I’ve been working on the engine on and off ever since with the idea of using it in some future game jam or next year’s 7dfps.

moreart

An interesting glitch from when I was trying to add support for multiple wall textures.

 

barrels

Early sprite rendering.

 

barrelwoah

In order to allow walls to occlude sprites, they have to be drawn one column at a time after doing a depth test to see if a wall has been drawn closer to the camera. Something went wrong here.

 

zbuffer

This is a little better; the portions of each barrel that’s shaded pink is supposed to be skipped due to being behind a wall. It’s not working quite right yet though.

 

The last image shows my current progress. There’s still a long way to go before it’s feature-complete, but I’ll be shifting my attention off of this for a while to focus on my other projects.

7dfps 2013 : Writing a raycaster

When the first 7 day FPS challenge was launched in 2012, I remember wishing I could participate but knowing full well that I didn’t have the skill to make anything of it. I’d never done any serious 3d programming and had no experience with the asset pipeline required for a 3d project. I decided I’d learn how to use a simple 3D engine in my free time over the following year and participate next time.

Well, it’s one year later, 7DFPS is back in business, and I still have no experience in any of the above areas. I had already resigned myself to missing out again, but I happened to stumble across this article on writing a “pseudo-3d” engine such as is used in Id Software’s early games, including Doom. I decided to give it a shot. Here’s my progress for the first two days.

1

The first step is figuring out where the walls are. The above screenshot shows that not happening.

 

2

A bit of an improvement.

 

yays

Wall segments are being drawn, but in completely the wrong places.

 

omgyays

Segments are now positioned correctly. I changed the texture to a standard pink/black checkerboard for debugging, but it isn’t showing up right. In addition, the perspective is “fisheyed”, causing curved lines at the periphery of the field of view.

 

nofish

Better.

 

perfect

The elusive “perfectly textured wall” in its native environment.

 

sexyhotness

Some awesome modern art I created while trying to fix textures.

 

textures

The final result as of this writing. At this point the engine is basically done and I can get to work on some gameplay.

Slide

My OneGameAMonth entry for July is a puzzle game called Slide.

You can download the game here. The music is from the amazing General Fuzz’s album Miles Tones, which you can download for free on his website.

I’ve never made a puzzle game before, so this was a great way to broaden my horizons. It turns out that coming up with puzzles is really, really hard at first. If the systems of the game are straightforward it can be difficult coming up with problems that don’t have immediately obvious solutions, but a puzzle game with opaque mechanics is never fun to play. Eventually, the process clicked and I was coming up with puzzle ideas faster than I could open a new level in the editor (the vast majority, alas, never made it past their first iteration before being scrapped).

Since the mechanics in Slide are pretty simple (strictly speaking there are exactly three of them), designing levels was all about challenging the way the player would . It was really interesting to think about what the obvious move in a certain scenario would be, and then subvert that idea and require a move that was slightly different in order to solve it. I still remember playing Rush Hour at the age of 12 or 13 and suddenly having the realization that just because a piece could be moved all the way to the other side of the board, in some cases it was necessary to stop one square short. Most of the levels in Slide are based on this kind of approach; get the player used to behaving in a certain way, and then introduce a situation where that behavior won’t result in the desired outcome after all.

Of course, in order to be able to solve a puzzle one must first understand the systems involved. Slide’s tutorial follows my design philosophy of teaching through curiosity; when shown a screen that is empty save for an interesting or out-of-place item, the player will eventually be drawn to that item and will try to interact with it. This kind of exploratory learning is something I try to encourage in all my games, and I think it is especially suited to puzzle games.

There’s no clear point where Slide’s tutorial actually ends; after a certain point it simply stops introducing new systems. I didn’t want to communicate to the player at any time that there was no more to learn, because a puzzle game can only last as long as it is able to expand on itself in interesting ways. I had originally planned to ship the game with a minimum of 25 levels; it ended up having only 16, and I think that 16 was enough. I might come back and add some more someday, and I included the Ogmo editor project file with the release bundle in case anyone else feels like creating some of their own, but I’m satisfied with the final count. I feel that going further would have resulted in the inclusion of a bunch of levels that rehashed old mechanics and added nothing new to the experience.

When I started work on this project I had no idea what it was supposed to end up like — my entire plan consisted of the words “puzzle game” and “colored squares”. Fortunately the design seemed to flow naturally as I worked, and I’m very happy with the way it’s turned out.

If you liked the game, or if you created a level and want to share it, please let me know!

I’m an international superstar

Of all the games I’ve made so far, Hypothermia has seen the most success. I somehow managed to get reviewed by both Indie Impressions and IndieStatik shortly after release, which drove a lot of traffic to my site that I just wouldn’t have had any way of attracting otherwise. I check back on the download counter every now and then and it’s fun to see that it’s still being downloaded over six months after I released it.

Today I did a search to see if there was any coverage I had missed out on and found this:

http://www.bilibili.tv/video/av441497/

Someone from China did a Let’s Play of my game.

This is the best feeling in the world.

I know how to count to three in Chinese, and that’s about it. Watching this video was really interesting for me, because even though I didn’t understand his words I could still tell what he was feeling as each phase of the game played out; worried tension as he got close to losing, and then surprised relief as he finished the game and got the good ending. It really makes me happy that I was able to create something that someone from a totally different culture could enjoy and relate to.

When I design games I try to use as few words as possible while still conveying the story. I like my games to be accessible to as wide an audience as possible; particularly one that might not be able to speak English. Baseborn and Humphrey’s Tiny Adventure were both designed in this way, and I’m while Hypothermia’s two endings each have their fair share of text, the rest of the gameplay didn’t rely on any dialogue. Until today I’ve never had the kind of reach where this kind of accessibility mattered, but this makes it all worthwhile.

Game design by necessity

I started work on a game called Gunbuilding about a week ago with the purpose of stress-testing #Punk, a C# port of Flashpunk that I’ve been developing. Nothing puts a framework through its paces like using it for a game jam, and if nothing else I ended up fixing a lot of bugs that would have inevitably bitten me later on. On the downside, though, my idea for the game changed drastically to fit inside my schedule, and I’m not thrilled with the way it came out.

If you want to play it, go here.

The first thing to go was the mechanic that gave the game its name. I created a system that assembled bullets by passing data through a set of components that could be swapped out at any time. In theory, this could have allowed for a crazy number of combinations, resulting in bullets that homed in on enemies and spawned others to ricochet around after impact. The system technically works as it is, but I didn’t have time to create more than one component for each category. I’d like to explore this type of system again in the future, though; it seemed like it had potential to be a lot of fun.

The next feature to be cut was the enemy AI. I’m pretty happy with the way my little guys hop around (the quadratic curve movement system they use was one of the first holdups I encountered), but they don’t do anything to avoid each other and always ended up clumping together into a group as they moved towards the player. As a solution (though at the time it was a joke) I made them explode when they touched each other, and then made that explosion chain to other nearby enemies. The chaining was super simple and easy to do thanks to #Punk’s extensive message broadcasting capabilities, and it turned out to be a lot more fun than the approach I had been using, so in one sense I’m glad I ran low on time to implement the rest of the game systems.

The last thing I didn’t have time for was to put any effort into graphics. Everything in the game is made up of colored squares, with the  exception of a grass tile I used for the background and a tiny image for the particle effects. I generally try to prototype with as few art assets as possible to avoid getting stuck perfecting them before any gameplay is in place. In one sense that worked out this time — I can’t imagine what else I would have had to cut had I spent all kinds of time on art early on — but I feel like shipping the game in such an incomplete state is a real shame.

Overall I’m disappointed with the way the game turned out, but this was never about the game. I’m pleased with the number of bugs I was able to fix in the framework, and that was the whole point anyway, so I’d call this experiment a success.