On June 11, 2010, I released my first indie game, Legend of the Rune Lords, on Xbox Live Indie Games. LotRL is a short role-playing game featuring many of the trappings of full RPGs: stat-driven combat, leveling, multiple characters, and a cutscene-driven story. While hardly a great game, I think that it stands as a good example of what a determined (or at least stubborn) individual can accomplish in their spare time even while crunching at their day job.
Development of Legend of the Rune Lords started in January 2010 as a challenge to myself to complete a game from scratch in 2 months. The reason I decided to limit myself to 2 months was because I decided to enter the game into Microsoft’s Dream.Build.Play competition, the submission deadline of which was in early March. The game was actually an entry in the Old Spice Challenge portion of the Dream.Build.Play competition, so “Legend of the Rune Lords: The Quest for Runic Magia” actually started life as “Legend of the Spice Lords: The Quest for Olde Spice”.
As you may guess from the name change, Legend of the Spice Lords did not win the Old Spice competition. Unfortunately, I found out later that the .ccgame package I sent to the contest judges did not start up properly, disqualifying LotSL from the competition. It was a bit disheartening to not be able to even make a proper showing at the competition, but I didn’t give up. After a month off the project and then a month of de-Spicing and bug fixes, the game was reborn as Legend of the Rune Lords.
Then, after 2 months back-and-forth through playtest and peer review, Legend of the Rune Lords was finally released to the world on Xbox Live Indie Games.
What Went Right
- Using TorqueX: Given just 2 months to make the game, using an existing game engine was a no-brainer. In this case, I went ahead and invested in an indie license for TorqueX 2D. TX2D provided a base level of functionality that allowed me to start putting my game together immediately instead of losing valuable weeks writing base level content and scene graph handling. Having a level editor is always a plus.
- Tight Schedule and a Solid Deadline: Nothing motivates someone like an incoming deadline. Building the game for Dream.Build.Play was almost an excuse to make sure LotRL got finished. In the past, I’d had the bad habit of starting projects and tweaking them forever without ever getting closer to finishing them. Using Dream.Build.Play as an external pressure source forced me to surge ahead even when my natural urge would have been to stay and tinker a little more.
Another benefit of setting the strict deadline is that I could tell my wife exactly when my feverish late night coding sessions would peak and, more importantly, when they would be over. Knowing that she wouldn’t be losing me every night indefinitely, she was very supportive. The night before the contest deadline, as I was gearing up for a long night of trying to squeeze in the last missing parts of the game, she was the one who put on a pot of our best, strongest coffee for me. It that isn’t love, I don’t know what is.
- Have Sprites, Will Travel: With the super-tight deadline, I knew I didn’t have time to negotiate with artist’s for custom spritework and I certainly didn’t have the skills myself to produce attractive art myself in any suitable timeframe. Luckily, I was able to find several free-to-use collections of graphics from Lost Garden (from the guy who did the art for Tyrian!) and Reiner’s Tilesets. If it weren’t for their generosity, this game would have never happened.
- Scope Control: The tight schedule forced me to cut early and often. I ended cutting a lot of features that I would have considered must-haves under different circumstances. Some of the cuts, like an inventory system, ended up making LotRL a much sparser affair than it might have been, but their inclusion would have likely made an already short game even shorter.
- Dirty But Not Too Dirty Code: I love to engineer my code. UML and use case analyses make my day. There’s nothing better than designing a robust solution to a programming problem then coding it and just having it work. But it’s also time consuming and is possibly overkill for a lot situations. Because of the NaNoWriMo-esque, get-er-done mindset of the project, I allowed myself to break a lot of my engineering and coding rules. Hard-coded values. Code copy-pasting. Inefficient code. They were all over the place. But, the game worked.
Now, I did make sure to not lose all my discipline and applied coding best practices to the most important parts of my code. I basically applied the 80/20 rule. The 20% of my code where the player spent 80% of their time got the most software engineering love.
I also made very agressive use of asserts all across my project to test parameters and return values. Naturally, the vast majority of the asserts never tripped (a good thing), but those that did let me find potential crash and data corruption bugs as early as possible and I’m certain saved me from some potentially very time-consuming debugging at the end of the project.
- Playtesting with the Creator’s Club: Submitting Legend of the Rune Lords to playtest was incredibly helpful. The community of fellow XNA developers are extremely engaged and well-informed. Their advice and constructive criticism allowed me to find a lot of bugs that I had missed. Also, using their feedback, I was able to figure out where to concentrate my remaining development time to have the best overall effect on the game.
What Went Wrong
- Using TorqueX: Using a third-party engine has its ups and downs. TorqueX is no exception. There were times when I cursed TX2D’s limited animation implementation. Tweaking data for hours only to find out that there was a bug in the underlying engine is never fun. I go deeper into my experiences with TX2D in a another article.
- Platform Feature Handling: I’ve developed for the Xbox 360 before. I know from experience how many things can go wrong when implementing support for the 360’s full spec of multiple profiles (online-enabled and otherwise), storage devices, and the exception cases that come up when people rip out Memory Units or change their profiles mid-game. So, of course, I did my homework and created a stable and consistent framework for handling the Xbox 360’s various platform features.
No, of course not. I put it off until the end of the development, hacked it together as quickly as possible and had lots of nice little bugs to keep me company. Maybe next time….
- Too Much Music: Finding music to license for Legend of the Rune Lords was too much fun! The site I used, NeoSounds, has a wide selection of background music and picking the right music really charged me up to finish certain parts of the game just so I could listen to the music in-game ASAP. I actually had battle music playing during combat before there were any graphics ready (I had a text-based place-holder showing all character stats and taking combat inputs.)
The problem, of course, is that I went a little overboard. I couldn’t stop myself from licensing music and promptly found myself having spent more than 4 times my original music budget. Yikes!
- Too Random: I’ve always been strangely enamored of the “fistful of dice” systems used in the old versions of FASA RPGs like Shadowrun and Battletech. Basically, as your skills got higher, each point would give you an extra die to roll which means you have an extra chance to roll higher than a target number. After you roll your dice, any die that is higher than the target number is considered a “success”. The more “successes” you have, the better the result. There was always something viscerally satisfying about using a skill that was so leveled up that you needed to use two hands to roll all the dice involved.
Spurred by my infatuation, I implemented something similar in LotRL instead of going with a typical attack-minus-defense-plus-a-little-randomness approach. Unfortunately, I didn’t think through the consequences of this action. The old FASA system was notable because it introduced an extremely wide range of outcomes. It was often possible to get catastrophically successful or fatal results off of the same stats. This works in games like Shadowrun or Battletech where any thug with a gun, no matter how low his stats, is a potentially fatal threat. In a game like LotRL, it made the outcomes of combat far too arbitrary. The same enemy who was a push over in an earlier fight would cream the player in the next battle. I ended up doing a fair bit of tweaking (and a bit of cheating) to bring the range of outcomes in combat within a more acceptable range of variability, but I probably should have scrapped the system outright.
- Late in Becoming Active in the Creator’s Club: I didn’t really start engaging the Creator’s Club community until I was ready to playtest and preparing for peer review. I wish I had participated on the site earlier. If I had done some playtests or reviews before submitting my own game, I would have had first hand experience with most of the common pitfalls with game submission and not have had to run into them myself. Also, since the peer reviews are a purely community driven, building up a reputation as a helpful member of the Creator’s Club will probably help you get through the submission process faster as more people will be inclined to take the time to review your game.
Where to Now, Rob?
At this point, I have yet to turn a profit of Legend of the Rune Lords (I’m getting close though! Kinda…), but creating a game for Xbox Live Indie Games was totally worth it. Putting myself under such a strict deadline encouraged me to try problem solving techniques I wouldn’t have otherwise considered. Working with the community of game developer’s in the Creator’s Club is a real pleasure and a great way to learn.
I will definitely be creating more games for XBLIG in the future. Next time, I hope to make a game that I won’t feel the urge to qualify with a statement like “pretty good for something made in a few months.” There’s a lot of room for quality on XBLIG and I plan to be there.
Legend of the Rune Lords
Available on Xbox Live Indie Games for 80 MS Points ($1)
Platform: Xbox Live Indie Games
Release Date: June 11, 2010
Number of Developers: 1
Development Time: 3 months + 2 months playtest