Often I’m brainstorming about the high level content of Flare — especially the basic story that will tie the game together. I recognize that Flare isn’t going to be heavily story driven. It’s an Action RPG after all, without even the conveniences of e.g. dialog choices. Spinning a valid story first then plugging in dungeon romp gameplay isn’t as easy as I first thought.
I’m starting to think about the content in a different way. We’ve created a lot of core assets and features to make a game, and it would be really great if we could give all of those assets and features a time to shine. This feels like a bottom-up approach to content design — look at the small pieces available and think of ways to combine and showcase them. This way of thinking is probably common for puzzle games where it’s good to exhaust the unique ways each element can be used. But can this approach be used to make an Action RPG?
Tile Sets — for each tile set, consider unique-feeling thematic areas that can be created from the base tiles. Focus on creating distinct shapes per map and vary the mix of tiles used in each. It’s important to add landmarks so maps are memorable. Interesting maps will give us strong ideas about world flow and enemy placement.
Enemies — for each base enemy type, consider all of the common fantasy variations of that creature. Also consider how powers and stats can combine to create unique enemies that serve a specific battle role. Interesting enemies could have entire maps, quests, and items created around them.
Items — for each item, consider how it should be acquired. Bought from a regular vendor or some remote craftsman? Reward for killing some fiend, exploring a side area, or completing a quest? Great items may give us ideas on new quests or bosses.
Stats — for each bonus stat, consider a place for it to shine (and to be weak). Prominent example: make sure we have extensive areas where elemental resistance is all but required to survive.
Flare’s engine is close to the feature-completeness line. The features we worked on for v0.18 affected flare-game in a few fundamental ways:
Changed from 4 to 10 equipment slots
Changed from highly random items to a smaller, more memorable item list
Adding more armor slots means more absorb, so damage and health has to increase across the board
With items no longer being mostly random, items need to be specifically placed on enemies, in loot containers, or on vendors.
Some of the core decisions about a game’s flow depend on these changes. Right now flare-game’s alpha demo is obsolete. It might be possible to rework those old maps and retrofit all the new data into them, but it would be a significant amount of work for that alpha demo’s final release.
Meanwhile the engine code for v0.18 is essentially ready. It could use more testing with real content/data but the major features are implemented. v0.18 is also the last scheduled Alpha Release. v0.19 will include the remaining features we want for Beta and for 1.0.
If v0.18 is the last alpha release, it does make sense if we update the alpha_demo one final time. Here’s what we’d need to do:
Set new damage and absorb on all new items
Set new damage and health on all creatures
Place all new items in the game (on creatures, containers, or vendors)
Update all containers to open-once logic
Add item descriptions to many new items (if possible)
Playtest a lot. All these new numbers won’t magically balance, they’ll need several iterations.
The alternative would be to just create new content, which would later be candidates for final release content. One reason this may make more sense is that the flow of the game content is much more important when it’s not driven by random items. As an example: we’d want early quests to reward items that are useful to low level players (magic swords/staffs/bows). We’d want to place interesting optional items in side quest areas. It’s easier to do that deliberately when creating maps instead of trying to retrofit them into the old maps.
Either way a full game release on the v0.18 engine is a ways away due to the amount of content work needed. Here’s one decision I’m not sure about: should I tag the engine as v0.18 so that we can keep working on the next features? I’d say yes, except there are specific expectations from downstream repos. Many flavors of linux are packaging flare-engine and flare-data separately. If we just update flare-engine it actually won’t work well with the old data. If we don’t really want the v0.18 code to be released yet, it makes sense if we hold off on tagging it.
What I may do is move the goalpost slightly for v0.18, so the code can continue while we work on release content. The main feature left for Flare 1.0 is cutscene support, and I think it’s something we can implement now. I’ve commissioned Flare artist Justin Nichol to work on some digital paintings that will serve as intro cutscenes for the Flare world. The cutscene system will likely also be used for displaying in-game credits.
So I have a lot of content to hammer out no matter what route I choose. Should I create the beginning of a new adventure, with maps designed for the new itemization? Or should I clean up the old demo and get something out a bit sooner, but perhaps messier?
I am participating in One Game A Month (along with a ton of other devs) during 2013. Flare will still be my main focus, and some of the games I make will use Flare.
I’ve been having some decent ideas lately, plus some that have been on the to-do list for a long time. I can’t sleep so I’m writing these down. I want to share my first solid game idea:
Don’t Ride Your Bike On The Highway
When learning to ride a bike growing up, there were a series of rules I had to follow. Early on (tricycle days) it was: don’t go on the road. Then when I first got a real bicycle I had to stay between the two nearest light poles. Finally I was allowed to roam the neighborhood as long as I didn’t take my bike on the highway.
During those days my brothers and I rode around the neighborhood nonstop. We had to be back home before dark, and night officially started when the power lights came on. During that near-dusk hour we would visit as many friends as possible. Often we would trade (borrow temporarily) toys with other kids, or return toys previously borrowed. I want to relive those days. One of my games this year will be riding a bicycle around the neighborhood I grew up in.
Milestone 1 of the game will be getting the bicycle movement working right. I’ll probably use arrowkeys or WASD to do full bicycle movement: up/W to pedal once, down/S to brake, A/left to veer left, D/right to veer right. The camera will stay fixed, so it will kind of be awkward to steer — hopefully emulating the feeling of first learning how to ride. Throw in some simple sound effects and I think this could feel really solid.
Milestone 2 of the game would be drawing the map and adding basic collision. It’ll probably be simple and tile-based. I will recreate my basic neighborhood, but a bit simplified and stylized. At this point it should be simple fun to cruise around a map on bicycle, and maybe that will be game enough.
Milestone 3 would add a Punish Meter, and would really give the game its namesake. There will be zones where you are not supposed to ride a bike, especially along the highway. But also: not in other people’s yards, not near cars or houses, etc. Riding somewhere that you’re not supposed to be makes the Punish meter fill up. Crashing a bike (into a ditch, or street sign, or parked car, or house, etc) will raise the Punish meter significantly. Riding the bike after dark is also forbidden (start racing home once you see the power lights turn on!). Maybe the game ends when you fill up your punish meter, or maybe you’ll just get an earful when you finally do get back home.
Milestone 4, something I may do post-release or as a follow-up game if the above is fun, is adding the toy-trading system. Part of the goal while you’re out will be to stop at houses that have kids your age and try to trade toys with them. You take 3 toys from your Toy Box before leaving the house (starting the level), which are randomized. Some toys may be more desirable than others — more kids want the NES cartridge than the bag of marbles. Trade for better toys to get more points. Also don’t forget who you borrowed certain toys from, because you have to return them next stage.
This is all terribly self-indulgent, I know. But it’s going to be fun to me. Hopefully someone else will relate.
Since Braid I have viewed programming as mostly pragmatic: I know what I want to do, and I know what kinds of things I have to type in to make it happen, but for the most part, the interesting mental challenges are in design, and programming is rote execution. Once you have enough programming experience, I think 95% of writing a big program is like this. There have been a few times during The Witness when I spent significant effort solving technical problems where I had no idea what the answer would be in advance, like with the terrain manipulation, but even in these cases I treated the technical development in a very pragmatic way: the goal was to get something that is good enough for current needs, not to design a shining jewel of an amazing technical system (back when I was a younger game programmer, I was trying to make amazing technical systems all the time, and it came at the cost of actually getting games done).
I’ve been working on some Flare-Game maps. The tools are good enough now that I can easily make and easily discard maps. I’m trying various layouts to test what’s fun, compared to the kind of games I really want to make.
So there’s the desire to create several similar games. I can have one very linear deep dungeon romp like Diablo 1, where all there is to do is just dive deeper until the Big Bad at the end. On the other hand, there’s also the desire to create a game with a nice interconnected open world — story progression wouldn’t matter as much, instead there would be small quest chains to uncover but mostly just random places to have fun.
Thematically there are various stories I want to tell. I want to tell a story about the fall of human civilization and fighting back against the wilderness. I also want to tell a tale about exile and discovering who you are.
Mixing gameplay styles and story themes seems tough. But I think it’s doable in a highly moddable game like Flare. I need to think about one overarching world/theme, and find places to plug in new adventures and campaigns.
My girlfriend isn’t a gamer. I’ve only ever seen her play New Super Mario on DS (her kid sister and I both have it). I don’t think she’s even touched a controller with an analog stick before trying Journey. She played through it and loved it. She’s even mentioned wanting to play through it again some day.
I don’t shy away from challenging games (Super Meat Boy, Dark Souls are some of my recent favorites), but I still deeply appreciate how simple Journey is. From a gamedev perspective Journey does a great job of showing possibilities of what video games can be:
Good games can be short.
Good games can be easy, even playable by non-gamers.
Good games can tell a story without using words.
Good games can be emotional and beautiful
Good games can be peaceful (not using violence as a core mechanic)
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
Week long experiment
1 month tech demo
3 month tech demo
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.
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.
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.
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.
Flare doesn’t use a strict class system. On character creation there are five choices for starting class, but these are essentially default ways to buy level 1 equipment, attributes, and powers:
Brute: +1 Physical, starts with Dagger and Blood Strike
Adept: +1 Mental, starts with Wand and Shock
Scout: +1 Offense, starts with Slingshot and Piercing Shot
Keeper: +1 Defense, starts with Wooden Buckler and Heal
Wanderer: no points spent, starts with extra gold
I’ve intentionally renamed these starting classes to reflect a low level of power. I’ve gone in and created three entire tiers of titles that reflect the power a character gains as she grows.
In addition there are two end-level titles. At level 12 a hero would have three attributes maxed and receive the title Master. At level 16 a hero would have all four attributes maxed and receive the title Grand Master.
I earnestly think Flare is going to be something special one day. I appreciate everyone who is sticking around during Alpha, and especially the crew who is working on new features.
If you also believe in the future of Flare — as an open source iso-action engine — maybe you have the means to donate. I want one day to provide a vast collection of matching isometric resources to use in developing interesting RPG tales.
FLARE already IS something very special. The music? Sublime. The art? AAA. The community? Engaged. A shining beacon of OSS. (@McFunkypants)
We’re working on adding a core set of Magic Items to Flare’s fantasycore data set. The goal is to create unique-feeling items that have distinct names and flavor text. Also we’re expanding the variety of passive bonuses so that there’s not a lot of overlap between items.
v0.18 Engine progress
The main features for v0.18 are near completion. We’ll be adding some more Effect types (see Magic Items above) and cleaning up any bugs we find along the way.
Because of the nature of v0.18’s inventory and item changes, we’re still a long way from having Flare Game data ready for a playable release. The original plan was to get v0.18 out this December. We may go ahead and tag v0.18 on the Engine side and continue working on game content. Some things that need to be done to bring the game back to expected quality:
Over the last couple weeks I played through Dear Esther and Superbrothers: Sword & Sworcery EP. Both enthralled me.
I can understand why some people wouldn’t like these. I can even understand why some people question whether these are games. I had a different reaction: these made me think “wow, video games can be this too.”