Development

Earlier this summer, as the Ludum Dare video game making competition rolled around, I opted for the teamwork challenge of making a video game in 72 hours with a group. The theme was “A Small World” and my friend Michael and I decided to collaborate to produce something different with a “wow” factor.

The judging period lasted about a month, and now that the results are out I’m incredibly happy to report that our game, No One’s Planet, ranked into the top 5% out of 1841 jam entries in the Humor and Innovation categories.  I’m especially happy because although this is my 8th competition in 6 years, my day job activities are for the most part unrelated to video games. The Ludum Dare is historically prolific, with game industry veterans participating alongside seasoned indie developers and anyone with enough chops to make a game in a weekend. Given that company, I’m delighted with our category ratings (top 5%!!!!) knowing we made folks blink a bit and smile.

This summer was life-changing for me, both personally and professionally.

Professionally:

• I received even more positive feedback about my DrupalCon Los Angeles presentation on visual regression testing, including making a top 10 list.  I’m glad so many people found it helpful.
• I presented two sessions at the NYC Open Source Conference, one at the Security & Privacy Summit on mass code analysis and the other on visual regression testing.
• I gave a ton (well, 10) lightning talks at local clubs and events.
• I wrote a well-received guide on visual regression testing.
• I discovered the OKR (Objectives and Key Results) planning and reporting system is completely brilliant.
• I discovered how much I enjoy public speaking, that people enjoy my presentations, and that preparing more of them is almost certainly on the horizon.

I also wrote my first text adventure game for Ludum Dare #33!  I love text adventures. There will be more of this.

Personally, I hit one of the most important milestones in my adult life.  Back in January, I decided that I would try as many new things as possible this year and own the outcome of every attempt completely, to better work on personal growth. I discovered some good things, for example, how much I enjoy public speaking.  But I also found that a core skill I thought I had was significantly different from what I thought I knew about myself. This has become life-changing in an unexpected way, which is exactly what I signed up for, but still takes time to process.

A few weeks ago I participated in the Ludum Dare #32 game jam.  Tomorrow, the game that was created, was my sixth Ludum Dare entry and my first with a team in the 72-hour relaxed version of the jam competition.  Here’s how it turned out!

I am exceptionally happy with these results. Considering the competition, being ranked in two categories with threes is a nice bonus and also a new record (Tiny’s Adventure in TV Land, my previous solo Ludum Dare #31 game, only received one three).  I also broke a new blog length record writing up the postmortem.

Between now and the next Ludum Dare I have quite a bit of work to do. It feels good to know I’m advancing as a game developer while doing it.

Last weekend I participated in Ludum Dare’s 32nd game jam. The announced theme was  “an unconventional weapon” which is fantastic and set the mood for the entire event.  I got further than I ever have in video game development and I felt great about my jam entry.

My game is called Tomorrow and it offers the player a chance to role-play a surveillance drone in a near-future San Francisco cityscape. Flying from building to building, the player must visit as many windows as possible as the game scrolls and the speed increases.  The city sunsets into oblivion if the player misses too many windows.

The initial story idea behind the game, developed with a friend, involved social issues and visiting city locations to meet people and attend events. The more the player socialized the greater the variation of responses they could face, and the fame component was intended to be the unconventional weapon. It was a hard concept to realize, and after getting stuck early on (including a short stint where the game could have been about a rubber chicken), I decided to develop the technical mechanics first and worry about the rest later.

Structurally, this jam was an also experiment for me on a few levels. I discovered a few weeks ago during the mini Ludum Dare that I really enjoyed working with different art styles that are challenging to produce during the 48-hour compo. I also missed working with a team. With all of this in mind, I entered Ludum Dare’s relaxed 72-hour jam that allows for teamwork and the use of assets created prior to the competition. A friend volunteered to produce the game’s music and help with design ideas, and I could use OpenGameArt.org for the graphics.

The engineering and software development portion of the jam went exceedingly well. For the past year I’d wanted to make a responsive game with mobile potential in JavaScript and even blogged about this here as a goal.  My previous games relied heavily on DOM/canvas and manual effects rendering with crafty.js, so switching to the Phaser framework freed me from the underlying technology. Phaser also allowed me to use a more sophisticated physics engine (it supports 4!) and to prototype more rapidly.

Phaser was also incredibly easy to learn. This was my first game produced with the framework, and I was literally cramming through tutorials the Friday night the jam started. Phaser’s community support forums and set of working demo games got me up to speed in record time and there were almost no technical blockers while developing the game. I highly recommend Phaser and I intend to use it to produce future games.

Thanks to Phaser, development proceeded rapidly, and by Saturday afternoon I had the player scrolling through a cityscape and…not much else. The next step was integrating the storyline. Since the game took place in a city I decided the player would fly through it and I used a flying rocketship as placeholder art. At this point I was hoping to finish the game that night, so creating events for the player to visit seemed too time consuming. I decided to use the windows of the city to represent locations and overlay tiles that could flash with a special effect.

I also needed a lose condition. Time, which I didn’t posess much of myself at that point, seemed to be the fastest way to do this. I made it a requirement that the player visit a certain number of windows as timed intervals increased. I wanted the game to be immersive, so I used the color of the sky as a status monitor to keep the player focused on the city.

At this point the game was looking good enough to benefit from an extra day of polish, so I decided to continue development through Sunday. I still needed an unconventional weapon (time perhaps?) and the game was far from the initial story premise. I received feedback from another friend that the game is really about drone surveillance because why else would a robot fly around and visit city windows? Hey, they had a point! And so it was.

The music production added a great amount of value to the drone premise too. Cruising around the city felt like crusing, and the soundtrack helped place the game’s setting closer to the near-future.

The final wrap-up involved quickly producing a title and credits screen to meet art licensing requirements and the game was submitted early Monday morning. It felt odd to have produced a game where the player is essentially rewarded for being a drone and doing drone-like things, but this is largely because of the time-crunch during development and the lack of a concrete ending. I think the drone mechanic has potential beyond this and I would love to use it as a storytelling mechanism for a longer anti-drone game.

Here’s a summary of what went right:

• Entering the extended 72-hour jam. This gave me time to relax and have more fun with the entry. Being able to use OpenGameArt.org during the design process upped what I was able to do and had a hugely positive effect on my enthusiasm.  It was also more fun working in a team.
• Hosting the event away from home. Being in another space improved my focus, and it was refreshing to come home and do something else away from the game during the jam.
• Developing the game with the phaser.io. The framework absolutely delivered and the tutorials and support forums were spot on every time I needed guidance.
• Making a responsive game with mobile potential. I had wanted this functionality for awhile and Phaser made it easy to deliver.

There was also room for improvement:

• Pacing myself! Being able to use external assets combined with extra time was a recipe for enthusiasm as the game became polished and took shape. It also made it easier to overextend myself. This is the opposite of what I wanted as I’ve been pretty good about taking care of myself during the 48-hour version of the competition. I felt 16 years old again while jamming, but the post-jam exhaustion is a reminder I’m no longer 16 or even 26.
• Not using all of the available time over four days. I might have been able to relax a bit more by extending my jam time into Monday afternoon and I think this would have helped with the end-game delivery and overall polish too.

For the next Ludum Dare, which should take place sometime in August, I’m definately going enter the 72-hour jam and pace myself accordingly. Phaser.io is a dream to work with, and I’m going to learn all the things about it over the next few months. I’m also thinking about partnering with an artist ahead of the competition so I can develop a jam game with custom art as well as sound. It will be interesting to see how this works out!

Finally, I’m incredibly happy how everything worked out overall. I feel significantly closer to approaching game development goals that I hope to reach over the next couple years. I’m very much looking forward to creating more games in 2015, both inside and outside of jams.

Ludum Dare #32 starts tonight and it was to be my most prepared Ludum Dare of all Ludum Dares. I had specific goals to be tracked over the previous few months, including learning how to make better music with garage band on my mac and upping my skills with open source illustration programs.

There was progress. I discovered InkScape, a free multi-platform vector graphics editor that completely replaces anything I might ever want to do with Adobe Illustrator.  Sculptris, a 3d digital sculpting tool, was also fun to play around with and could yield some interesting sprites or meshes if I produce a 3d game at some point.

There was incremental sideways progress on a few unexpected things too. I made a game for a mini Ludum Dare, which cemented my desire to get away from crafty.js and do something cool with phaser.js. This game was also my first introduction to OpenGameArt.org and the agonizing decisions that come with designing a game around the best assets I could find. I also worked on Pantheon’s Ride the Lightning game, produced with crafty.js, which was satisfying to see so many people play on April 1st.

My musical progress fared less well. I composed a few loops which sounded good enough for jam purposes, but I need to be composing every day for at least a few months to get where I want to be with the audio.  For this upcoming jam I plan to stick to generated music and bleeps or incredibly simple garage band loops if I can pull off the composition without running out of time.

I think my targets were reasonable and my progress and time management could have been a bit better. For the next few months following this Ludum Dare I’d like to have more concrete and specific goals regarding audio and visual game development.  Recently, I’ve been getting into a system called OKR, short for Objectives and Key Results,  and I think using it to help plan goal posts and milestones following this Ludum Dare could help me move forward with game development.

I’ve also thought quite a lot about goals themselves and how I feel about goal management.  It feels good to achieve goals, and I love game jams because they time box my work and force me to produce something tangible I can look at in exchange for that time. Goals themselves are less concrete, even specific ones, and I think that in a way they can become an unrealized debt to oneself.  I’m hoping the OKR system improves how I feel about them, and how I feel about working towards a goal over time while not necessarily producing something concrete from it, or at least not right away.

My goals for this weekend will be pretty simple. I have a lot of other work I need to do on top of the jam, so I’m going to do the best I can with what I have going into it. On Friday I’m going to look over phaser.js tutorials and design something conceptually fun that I hopefully won’t trip up on during the implementation. On Saturday I’ll write the code and release it and on Sunday I’ll have to cut things short and move on to another project.

I do have a self-improvement plan for the judging phase. The Ludum Dare 48 hour compo requires projects to be open sourced during the submission process. In the weeks after the jam I’m going to look specifically for phaser.js games and try to understand the implementations. I also have a friend who uses Unity and I plan to acquire at least novice level skills with the framework in order to run projects and examine workflows.  I also plan to rate as many games as I can, and I might even try streaming some on Twitch depending on the bandwidth.

After the judging closes, it will be back to another iteration of what I could have done better along with looking ahead towards any game I might make for next month’s one game a month jam. I don’t think I’m going to incorporate games themselves into my OKR’s, since I’m using the OKR system to make otherwise intangible goals more concrete.  I’m looking forward to seeing how the goals themselves progress in the system and I’ll share the progress here.

A couple of weeks ago I created an entirely hands-free pong game demo in JavaScript for the Mini Ludum Dare #58.  The theme of this game development jam was “Pong” and I gave it a new twist.

You can check out the game here.  Note you’ll need a mac laptop running chrome to play the game demo and you’ll also need to give the browser access to your microphone when you visit the page.

I first got the idea for a hands-free game after seeing implementations by Daniel Rapp that used the doppler effect to track hand motion. His work seemed like the perfect basis for a game, and what’s remarkable about it is that it works so well. I’ve left the game on by accident and watched it continue to track hand motions from someone sitting across from me after I pulled back my chair.

I put this demo together in a few hours for the Mini Ludum Dare game jam and I’d like to expand on the concept by making a more involved game in the future. From swatting flies to leveling a space ship, there’s enough here with this mechanic to be quite entertaining.

PHPUnit is one of my favorite unit testing tools and I recently needed to install it directly into a project with composer. I’m on a macbook pro running mavericks and homebrew, so I typed:

composer require "phpunit/phpunit"

Surprisingly, I got:

[RuntimeException]
Could not load package phpspec/prophecy in http://packagist.org: [UnexpectedValueException] Could not parse version constraint ^1.0.2: Invalid version string "^1.0.2"

I looked at my version of composer, installed last year probably, and it was at 1.0.0-alpha8. Aha! I thought, I will upgrade.

brew upgrade composer

This upgraded composer to 1.0.0-alpha9, but still did not resolve the error message.

Finally, the magic to get it working was:

composer self-update

The update set composer to 1.0-dev, which was enough for my composer require “phpunit/phpunit” installation command to work.

I’m noting this tip here on my blog in case anyone else finds themselves working with PHPUnit since the closure of its pear repository last year.  Composer is an awesome dependency management tool that’s a delight to use and I’m glad only a quick self-update was needed for PHPUnit.

The results are in, and I’m happy to say Tiny’s Adventure in TV Land did much better than I expected!

I’m especially proud of the 3.94 I got in the Theme category!  One hope I had from this competition was to get a 3 or higher in any category because I’ve never scored above a 2.x before. I almost got a 4 in Theme! I’m also pleased that the 3.94 score placed me at #189 out of 1365 total 48-hour compo entries.

My rank in the Humor and Mood category placed me in the upper half of the competition entries. I did slightly worse in the Overall category than the last competition; my previous game SWARM received a 2.80 rating in Ludum Dare 30.

The most informative part of this competition for me was having 55 other participants play and comment on my game, which is a new record for me.  Thank you so much!

Last weekend I created the adventure game “Tiny’s Adventure in TV Land” in 48 hours for Ludum Dare #31.  Prior to the competition I had a plan for the development methods I would use and roughly how I would spend my time.  This is a postmortem of how it went.

What went right:

• I completed the game in 48 hours!
• The thematic portions of the game were easy for players to identify.
• Improved graphics. This game was visually nicer than my previous Ludum Dare entries.
• The overall game design I came up with Friday night largely held throughout the weekend.
• Having a tested build system in place.  This made the submission hour a breeze.

What went differently than I expected:

• Dropping mobile support early. Prior to the competition I wanted to make a mobile entry, but I decided there wasn’t time to tweak a game type I was unfamiliar with.
• Time management. I’d planned to have the entire prototype finished Friday, and then iteratively polish it over the weekend. Instead, the game came together a few hours before the competition ended.

What went wrong:

• The first level was too hard.  Some players mistook the carrot as life or status indicator instead of an item to retrieve.
• I didn’t allow enough time to create a soundtrack.
• The physics were floaty.  I went with it, rather than changing it, but this limited the level design later on.

After each competition I have an idea of what I need to work on.  These are my plans:

• Practice composing music in GarageBand.  I need be good at this and have a solid workflow in place prior to the competition.
• Study photoshop techniques.  I learned quite a lot during the competition and I think I can improve even more for the next one.
• Improve my use of JavaScript 2D physics and use a better tweening solution.

Overall, I had fun participating in this Ludum Dare. I learned the most enjoyable part of the game development process for me is at the point when the game is assembled just enough to be playable. I’m looking forward to the next competition in April.

Ludum Dare #31 starts in a few days.  I’m looking forward to participating — this will be my fourth entry in the 48-hour competition over the past couple years.

I plan to create an html5/css/js game with crafty.js, photoshop, pickle for the sprites, and garageband.  I may also use a sfx generator for beeps and boops if the game is in a retro-style. I usually make retro style games, but ultimately I wait for the competition to start before deciding on a specific type.

Before each competition I make a small goal, usually an improvement or feature I’d like to attempt. For this competition I want my game to be easily playable on desktop, tablet, and mobile devices. Since this requires some knowledge going in, my plan is to spend a few hours a day this week testing the waters by playing around with crafty.js and media queries.  Now that I have a mac I can easily test with an iOS simulator too.

I’m also going to try a new schedule. Typically, I design the game Friday, implement on Saturday, and then go into full-scale-panic-mode Sunday when the previous day’s work doesn’t mesh.  This time I’m going to attempt to both design and finish a fully working prototype on Friday and then use the rest of the time for polish.