Fun, and Soon
Flare gets a mention in Bart’s dev-corner post over at Free Gamer: “You don’t know it, but your FOSS game project has a deadline”. The article talks about issues with seeing a game through to completion: make the game playable early, keeping ambitions in check, living with ugly hacked code, and more. I agree with Bart’s assessment deeply and it’s kicked up a ton of thoughts about game project priorities.
Flare’s infancy
Let’s take a look back at ancient history: Flare’s v0.03 release video. This was done at the 3 month mark of the project.
Notice how the core gameplay of Flare already exists in that video. Running around a dungeon, killing zombies, getting head-explosion crits with juicy sounds, and mood-setting music. The basic pacing and animation feel for Flare proved to be fun. It was at that point I knew Flare had real potential, and the fun was there for the whole world to see.
The first 10%
A layman might look at that video and think the game was close to being complete. It’s one of the pitfalls that cause projects to fail. That vertical slice represented approximately 10% of the work needed to get Flare to 1.0.
If you have a project that takes a full year just to be playable, you probably have a project that will never get completed. It means you’ll need a decade of effort to really finish. Meanwhile you’ll be surrounded by rapidly changing technology, changes in life priorities, and steadily growing personal dev skills. Few people have the sanity and self-control to stick with a multi-year game dev project without restarting from scratch once or twice.
Here’s my completely unscientific guide to scoping a game:
| Time to playable tech demo | Time to polished finished game |
|---|---|
| Weekend game jam | couple weeks |
| Week long experiment | 3 months |
| 1 month tech demo | 1 year |
| 3 month tech demo | 3 years |
| A year or more | heat death of the universe |
Is it fun?
If you’re working on a long game project, there’s one major question: is the game fun?
You won’t know if it’s fun until it’s playable. If you wallow for a couple years making menus and random assets but never implementing the core gameplay, you don’t really know if all the effort is going to waste. In game dev it’s actually important to fail early and fail often. The sooner you know a game idea is bad, the sooner you can abandon it for the next project.
Another major benefit of finding out your game is fun to play: now it’s fun to work on. I still play Flare quite a lot because running around the world is enjoyable. I’ve put untold hundreds of hours into just playing the game. There’s no way I would have the drive to work on a game this long if it wasn’t simply fun.
Drawing a crowd
You might get some buzz if you have teaser trailers, concept art, and a forum going for your game. But if you don’t have something playable you’re just blowing smoke. A playable game draws a crowd. A playable game creates fans.
Just before hitting the 1 year mark Flare had combat, loot, leveling up, basic menus, powers, and more. It had only a few maps but some players played it obsessively. Some players sent me screenshots of their epic loot collections and proudly boasted of their 40+ hours of play time. This was at a time when all the content could be cleared in just minutes. Flare was building a strong fan base because we made it playable and fun early.
Keeping Scope
All throughout Flare’s development I always focused on whatever the next most-important feature is to be playable and fun. First combat, then loot, then magic powers, then quests and NPCs. The game world was built from the bottom up. Flare didn’t even have a Title Screen until release v0.14, which was 18 months into the project. Aggressively prioritizing milestones helps to keep the project moving responsibly.
Even when the project began I made hard choices to keep the scope possible. I decided: no multiplayer. No 3D. No scripting language. We were not going to be the One Engine To Rule Them All. We were going to do single-player Action RPGs and that’s it. If we had gone multiplayer from the beginning, I doubt we would have had something playable within the first year. There’s no way we’d be seeing the finish line by now.
Ugly Code
That v0.03 playable demo had a lot of “ugly” code. Most things were hardcoded array sizes. Magic constants were everywhere. The game only loaded zombie creatures. There was no way to enter a second map.
But none of that matters. If I instead attempted to engineer all the code into its final state, I wouldn’t have had a playable demo until years later. That’s not to say I used really terrible code — I have 20 years of programming experience and know plenty of major pitfalls to avoid. But it certainly was no shining beacon of OOP or design patterns.
And it still isn’t gorgeous code. It uses a simple object tree hierarchy. Most classes have a logic() and render(), which in turn call the logic/render of their children. No event driven system here. No MVC. No Event/Component model. In fact one of the code style principles of Flare is “Use OOP as a last resort”. There are definite cases that have arisen where we have e.g. a base class and several implementations, but those modules never started that way. We only refactor when a feature demands it.
The code is very simple, but that also makes it very easy to understand and very easy to debug. Flare has a reputation for being surprisingly stable. Any time we discover a major bug, all other development halts until the bug is fixed. After all, the game needs to continue being playable and fun for both devs and fans.
Pay for art early
Making that first playable vertical slice of code is important to find out if the game is fun. You can test this with just placeholder rectangles for art. But if you want to convince non-devs that you have a good idea, you really need that art to shine.
I worked on getting “one of everything” into the game: one tile set, one hero sprite set, one weapon, one creature. I can’t quite do everything though. I have no skills in sound or music. Luckily I found sounds from OpenGameArt and other public domain resources. For music OGA helped commission a set of 6 songs to fill out an entire game, starting with that creepy dungeon theme featured in the v0.03 video above. I also commissioned good quality icon art once the inventory menu and loot systems were in place.
If I kept using placeholder art for that entire first year, I doubt anyone would have really taken notice to Flare. Paying early for the art I couldn’t create was absolutely worth it.
I know some indie game devs are broke. I choose to work a full-time stable career (not game related) so that I can fund my game dev habit. If you simply don’t have that option, maybe you can barter for the early art you need. Code up a portfolio website for a composer or concept artist in exchange for the handful of art pieces you need to get started.
Helping Others Believe
Projects of significant scope — anything over a year to complete — are exceedingly hard for one person to manage. I basically lone-wolfed the first year of development, but early in the second year I hit a rut. But thanks to all the work I had done — focusing on playability, commissioning art, etc — I had fans. And among those fans were developers. These developers joined the project and helped keep it moving forward.
They brought expertise in that I would have not had alone. I had no plans to support game pads, or language translations, or many other features that are now important to Flare’s success. Features that were future dreams (e.g. mod support) were added in during Alpha. Even some artists have begun volunteering art (though I really like to pay artists when possible).
Other devs weren’t the only people who started to believe — we got substantial donations. The total donations to Flare to date are near $5,000 USD. All those donations so far have been put right back into new art commissions. I sometimes think of my early out-of-pocket commissions like investments: they helped grow this project and led to much larger donations down the road.
Flare’s success — external factors
Having a fun, playable demo with good art/music can get you a long way, but it’s not always enough. Flare admittedly enjoys success thanks to a few external factors. One, a resurgence in the Action RPG genre (with successful titles like Torchlight 2 and Diablo 3 coming out this year). Two, filling a niche: open source code + fast pace + diablo’s darker feel + open license art was something lacking in the Free/Libre community. Third, Blender making it easy and possible for one person to do today what it took a team of artist and render farms to do in the late 90s.
Prove it
While you can’t always control the external factors, you can set realistic goals. Build directly towards a playable vertical slice. Prove to yourself and to the world that your game idea is worth it.