Color/Shift demo

Since Slide originally came about as an entry for OneGameAMonth, I thought it would make sense for me to release the Colorshift demo as one as well!

iconWindows iconNG Get it now!

This is an early release that doesn’t add any additional levels beyond those included in Slide, so if you’ve played it already there won’t be a lot more to see here besides a bunch of bugfixes and some polish to the core mechanics. I’m still working on adding a bunch of extra features, like drag-and-drop support for custom levels and a menu to replay puzzles you’ve beaten already or resume where you left off.

I’m working on native builds for Mac and Linux, but for now non-windows users can play in a browser at Newgrounds.

Please let me know what you think! I’m still in heavy development and I’d love to incorporate your feedback and criticism.

What’s in a name?

I’ve heard it said that it’s easier to name something before it even exists than to try to sum a thing up into a name after the fact, and I believe it. For nearly every game I’ve ever made, it seems like naming the darned thing is the task which takes the longest to complete.

Slide was an exception to this. I had the name picked before I made my first commit to the source repository, and it remained throughout the entirety of development. When I released it there was no other game by that name anywhere on the internet. I was feeling pretty good about it.

Yesterday I went to make an IndieDB profile for the remake. I created a boxshot image, collected screenshots, entered all the required information…and pressed submit.

  • There is already a game listed with the name Slide on Indie DB.

Tragedy!

I checked out the conflicting entry and came to the realization that, while I had become attached to the name “Slide” in reference to my own work, it really wasn’t a great fit as it described only the most basic mechanics. In this new game, the core mechanics are all about puzzles based on ice sliding in classic Zelda and Pokemon games. It obviously has a lot of polish and has likely been in development for a while, so even though I had technically released my game first I didn’t want to be “that guy” and ask that it be taken down.

And so began a frantic day of brainstorming as I tried to come up with a new name before the rapidly approaching OneGameAMonth deadline of November 4th.

Fortunately this all has a happy ending. The name I chose (with the help of some good friends) is Color/Shift, and I’ve retroactively renamed it in all my posts about this new release. Not only is this new name more tightly related to the core mechanics overall, but it’ll also help me distinguish between the original prototype and the new commercial release. All’s well that ends well. 🙂

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!

Humphrey’s Tiny Adventure: Remastered

Last year I participated in my first game jam with Ludum Dare #23. The result of those 48 hours was Humphrey’s Tiny Adventure, which I’ve written about previously. I was really proud of what I was able to accomplish, but there was a lot that I wanted to do with the project that I didn’t have time for. I didn’t include any sound or music, and I didn’t have anyone test it before release, so I never had the chance to get feedback. I recently decided to give Humphrey a long-overdue makeover for one of my entries in OneGameAMonth.

Over the past three weeks I’ve rewritten every piece of code in the game. Looking back at the original code, I’m literally terrified at the prospect of dealing with it. For the most part the gameplay is nothing complex, so I was able to build on the engine I wrote for Hypothermia. I created a data-driven cutscene scripting system using Slang, which I wrote about here. This was immensely helpful both in terms of writing reusable code and iterating quickly on the way each scene played out.

I’ve also redone almost all of the artwork. The art in the original version of Humphrey was composed entirely of large colored squares. This was mainly due to time constraints; the abstract style allowed me to spend very little time on each asset while still conveying the desired meaning. For the remake I did away with this restriction, and I’m very happy with the results. As usual, I used Inkscape for all the art.

Finally, this release includes a fantastic soundtrack by Chris Logsdon. It was composed specifically for the game, and you can download it here in high quality for the price of your choice.

Download the game here! I’d love to hear what you think of it!

Must’ve been rats!

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.

Download here!

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.

What went right

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.

What went wrong

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!

Hypothermia — Experimental Gameplay challenge

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.

First Ludum Dare — post mortem

humphrey

(This was originally posted on the Ludum Dare compo blog, for competition #23 “Tiny World”)

I’ve known about Ludum Dare for a few years now, but every time it came around I would end up having too much to do in real life to participate. This time I was finally able to get involved, and it was one of the best things I’ve done in a long time, resulting in Humphrey’s Tiny Adventure, a point-and-click adventure game. Here are a few lessons I learned along the way.

Do as little brainstorming as possible

I knew from the beginning that I wanted to make an adventure game. At 9:00 PM the first day, the theme was revealed and we were able to get started. I spent 15 minutes sketching out some basic ideas and then got right to work. Not everything I wrote down made it into the final game, but it allowed me to get started quickly and add details as I went along, instead of trying to develop a complete design doc or storyline.

 

Get all your tools and libraries ready to go beforehand

This is a bit of a no-brainer, but I thought it was worth mentioning For this project I used FlashDevelop for my IDE, Inkscape for graphics and Chronolapse for screencasting. Since all three of those are necessary to get started, it wouldn’t do to have some programs downloading after the compo officially started.

 

Pick an art style that you can produce quickly

I’m mainly a programmer, and while I am capable of creating some reasonably impressive vector art, I certainly can’t pump out high-quality assets fast enough to make it a viable option for a game jam. I decided on an art style that consisted only of colored rectangles, which allowed me to keep my art simple, uncomplicated, and abstract enough that realism wasn’t a concern.

 

Use release-quality art early on

Chances are if I started out using placeholder art I would just continue using it until I ran out of time. Creating final art assets in the beginning helped me have a feel for how much work it would be to bring the project to completion.

 

Use version control

If you aren’t using version control already, start now. The first thing I do when I start a new project is create a new local Mercurial repository, and it’s saved me many times in the past. Using version control can save you if you mess up your project too badly, or retrieve old versions of your files if you decide that the first iteration of your player class is the better one.

 

Record a screencast

Keeping a video running of my work helped to keep me from getting distracted. If I wanted to update my progress on twitter, I had to open up Chronolapse and pause the capture, and even that small amount of required action was enough to keep me from constantly tabbing over to check my email.

 

Take breaks and get enough sleep

Whenever I came across a tough problem or design decision, I got in the habit of getting up from the computer and making myself a hot cup of tea. As much as it might seem like it’s necessary to spend the entire 48 hours in your computer, the best thing you can do for yourself is to take it easy. If you overwork your brain you won’t be able to think clearly and therefore won’t be as productive as you could be.

 

I think that’s about it! I had a blast participating, and I’m definitely planning on doing it again. 🙂

GruePunk

One of my two assignments for the first week of my game development class was to create a “Choose your own adventure” game. The result was GruePunk, a first-person adventure based on Zork (playable version here). I’ve been trying to figure out an elegant way of embedding the .swf in my website but I can’t seem to make it work and look right at the same time, so you’ll just have to grab the file from the Bitbucket link.

I’d literally never touched a line of ActionScript in my life until three days before starting the project. The week it took me to finish it was exhilarating, if only for the pace I put myself through. While there are many things about ActionScript that differ from C++ in a good way (function pointers in particular are a thing of beauty), there are many that I dislike, and quite a few that had me hung up for hours until I figured out what was wrong. Still, the fact that I learned an entire new language in a week is something that still makes me all kinds of happy.

What are you waiting for? Go get the source or play the game!