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.
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’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.
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.
Chris 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.
Vanguard 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.
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.
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.
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.
MicroRL 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.
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.
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.
The 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.
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.
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.
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.
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.
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!
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!
This past weekend I participated in the Global Game Jam with Chris Logsdon and Paul Ouellette. The theme was “heartbeat”, so we made a stealth game called “Must’ve been rats!” in which you have to search for a briefcase containing a beating heart so you can escape in a heart-powered elevator.
Overall I’m pretty satisfied with the way this jam turned out. We had a lot of fun designing the gameplay and systems, and the game is feature complete despite having only one level at the moment. Even after testing and debugging for 48 hours straight I still enjoy playing the game, which feels like an accomplishment of its own. Still, it’s not a game jam if you don’t make some stupid mistakes and learn a few things, so here are my Things That Went Right and Wrong.
Flashpunk
At this point I can’t imagine using anything but Flashpunk for my game jam needs. Paul was able to pick it up fairly quickly, despite the fact that he hadn’t used it at all until a few days before the jam. Chris and I have used it a number of times, and even so we both found new features that we’d never known about. The API feels complete and intuitive, and it seems like there’s a function or class for everything we could ever need.
Systemic design with message passing
We designed our base engine as a set of systems that communicated with each other indirectly through message broadcasting, instead of directly through function calls. This allowed us to focus on programming the rules of the game world instead of specific interactions between different entity types. Even though getting each system working correctly was a challenge, adding new rules and rule responses is quite simple.
Data-driven workflow
We did all of our level design using Ogmo Editor, and as usual it served us well. Since we used a tileset for our levels’ art and a grid for collision and pathfinding, I modified my OgmoWorld utility classes to automatically import each of these types automatically and take advantage of FLAKit‘s live reloading capabilities. These changes will be included when I get around to officially releasing OgmoWorld.
Systemic design with message passing
Yeah, I know this one is in both groups. That’s deliberate.
Despite the fact that message passing is really cool and allows for some interesting emergent interactions, it’s not a good fit for everything. One example of a poor application is updating each enemy with the player’s position. My solution was to broadcast a message that told the player to report back with his position. This was slower and less elegant than searching the world for the player instance, and I wish I had realized that sticking rigidly to message passing was a bad approach.
Preconceived ideas
Chris and I had decided we wanted to make a stealth game before the jam started. Even though we didn’t do any kind of brainstorming beforehand, that decision still limited our ability to be creative with our interpretation of the theme. Fortunately we still managed to stay in scope and get the game to feature-complete, but I still wish we had come into the jam without any plans.
Overall, I’d call this Game jam another success. Make sure you play the game!
One of recent experiments in game development has been to orient my workflow away from code and towards data. When I use Flash, I’ve started using Ogmo Editor to design my levels, XML to handle settings, and Slang to handle game logic whenever possible. As a result, a lot of the code I’ve written recently can be easily reused across projects, and my classes are systemic and steer clear of situation-specific behavior. It’s been quite fulfilling and has done wonders for my iteration time; the focus on data instead of code means that I can take advantage of live-reloading for nearly every aspect of development. It’s not uncommon for me to work for an hour without ever closing my game, as I can simply reload all assets and data with the press of a button.
Today I’ve been working on Humphrey’s Tiny Adventure: Remastered, a post-compo version of my first 48 hour game. There are a number of places in the game where I need to set up events on a timeline, which I’ve done a few times already (see here and here), and each time I used some variation of traversal over a queue of function closures. While this approach worked well enough, it was tedious to set up and a pain to debug, not to mention the fact that it was anything but systemic. The most criticized aspect of the Ludum Dare version of Humphrey was that the intro cutscene was too long, and I agree. I think I knew that even before I released the game, but there was no way I was diving into that code to change it.
For Humphrey: Remastered, I was determined to achieve the same type of event scheduling in a data-driven way. Thanks to Slang, I was able to do just that. Here are the scripts for a scene I’ve been testing that involve two actors; Humphrey and Abe. This won’t be in the finished game, but it’s a good demonstration of the system’s capabilities.
action {
print "start"
delay 3
done
}
action {
print "after delay"
give-cue "humphrey done"
done
}
action {
print "start abe"
done
}
action {
await-cue "humphrey done" {
print "got cue"
done
}
}
Actions are called sequentially by the actor that the script is attached to. Each action block defines a set of statements that will be run as the events are executed. Calling done moves to the next action, and delay causes the actor to stop executing actions for the given number of seconds.
The give-cue and await-cue functions allow actors to pass messages between each other. In the above example, Humphrey give a cue to tell that he’s finished a set of actions, and Abe, who has been waiting for that cue, executes his final action in response.
There are only a few control functions involved, but so far the system has proven to be very powerful, and more than capable enough for the needs of this project. With the addition of message passing and response, specialized actor classes will be able to define custom behaviors while allowing the system to remain pure.
I’m quite happy with the way this has turned out. It’s fun to experiment with what can be done with Slang even in its current, quite minimal state.
Update: Hypothermia is now available on itch.io!
For the last few days I’ve been participating in the Experimental Gameplay challenge, a monthly game-making competition. The only rule is that you can only spend a week on your entry, so on December 1st I sat down and started crunching on a game for the chosen theme, “Temperature“. The result is Hypothermia, a first-person point-and-adventure in the style of Templar Studios’ Mata Nui online game. You can download it here.
This is the first game I’ve made that used Slang for scripting. Nearly all gameplay code is written in Slang, and it was incredibly helpful. Instead of making changes in AS3, recompiling the game and testing, I was able to hot-reload script files with FLAKit and see the changes instantly.
In addition, I used Ogmo Editor to set up entities in the scenes. I’ve never used it myself before, and I wish I had started sooner. With the help of the OgmoWorld and XMLEntity classes I wrote, I was able to load entities from Ogmo levels automatically with barely any prep work involved. And, once again, FLAKit’s hot-reloading allowed me to modify the levels and see my changes instantly.
Using Slang and Ogmo together allowed me to use a much more data-oriented approach to development than I’ve been able to in the past. This greatly decreased iteration times and allowed me to get scenes finished faster. In many cases I was able to work on the game for upwards of ten minutes without closing it once.
As usual, I used Flashpunk as a flash framework and Inkscape for graphics. The source code (as well as the original SVGs for all the art assets) can be found on the project repository in Bitbucket.