2013/01/02

The Witness quote

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).

Jonathan Blow

Flare Game thoughts

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.

2012/12/22

I’ll be traveling over the next week for holidays. Not sure if I’ll be touching Flare much during that time. I may actually use the down time to think about plot and story for the 1.0 game.

Journey wins IGN Game of the Year

Cross-posting my thoughts on Journey from a reddit discussion.

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)

2012/12/18

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.

2012/12/17

Character Classes and Titles

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.

Attribute Level 1 Level 5 Level 9
Physical Brute Warrior Warlord
Mental Adept Wizard Archwizard
Offense Scout Ranger Sniper
Defense Keeper Paladin Templar
Physical Offense Knave Rogue Assassin
Physical Defense Squire Knight Lord
Mental Offense Slinger Striker Tempest
Mental Defense Shepherd Cleric High Priest
Physical Mental Sparkblade Battle Mage Battle Archmage
Offense Defense Watch Warden High Warden
Other Wanderer Adventurer Hero

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.

2012/12/16

Flare ponderings

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)

2012/12/14


Magic Items

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:

  • Add loot items to each enemy
  • Replace random map loot with specific loot
  • Add a solid starting set of magic items
  • Rebalance combat damage and absorption numbers
  • Rebalance level-up stats numbers

2012/12/10

Games (n.)

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.”

Also, reading more about Superbrothers led me to this great article: Less Talk More Rock.

2012/12/07

Making Loot Less Random

Almost every subsystem in Flare has been written twice: first a version that simply works, and rewritten to make it flexible for the engine. The Loot Drop system is perhaps the last major component of Flare needing this treatment.

Recently I blogged about designing items that are more interesting. As part of that work we reset most of the item list of Flare-game. The old loot drop algorithm doesn’t really play well with a sparse item list.

Today we discussed what a new loot algorithm would look like. The more we talked, the more I realized that we need less random and more planned loot. Instead of having a large amount of random, forgettable loot like Diablo, we’re going to move towards a smaller, well-crafted, memorable loot list. Some ways this will affect Flare game design:

  • Each enemy will have a small custom loot list. A Goblin Shaman will have chances to drop gold, a Mana Potion, a Rod, and maybe some pieces of mage armor.
  • Treasure chests and containers will have specific loot, and will only be opened once per playthrough.
  • We’ll put more unique items in off-the-main-path places to reward exploration.
  • Vendors will sell specific items. There will be more incentive to save up gold to buy items.
  • We’ll add more vendors in remote locations that sell exotic items.
  • When designing an item we’ll have to consider ways the player can get it. Is it a random boss drop? A specific boss chest item? A vendor item? A hidden map treasure?

Random items can be fun. They especially shine in brutally hard roguelike games, where the random items and maps create the actual fun of the game. Each playthrough depends on the hand that the RNG gods deal. A lot of that was lost in translation in Diablo. The loot there is more about addiction, about reward schedules and skinner box / slot machine / loot pinata gameplay.

But thinking about game dev this long gives me time to think about the kind of games I really want to make. For now I prefer this controlled, hand-crafted experience. The items in Flare 1.0 games will be more like the items in Zelda, or Dark/Demons Souls, or Castlevania, or Final Fantasy. There is a lot of design space in this simple implementation to create good games.

Maybe in the future Flare-engine will support more random content — maps, items, enemies, and more. I’m not going to rule out that possibility.

2012/12/02

From the Inbox

Sometimes people send me great emails about suggestions for Flare. Some are good, some not so much. I wanted to share my favorite email so far about Flare. I love that he’s so passionate about the genre and has such specific suggestions.

Things I would like to see in Flare

* A Camera Zoom In-Zoom Out Mode, if the engine can handle this.

* Hot key brings up map with icons
* Voice Dialogue humor
* Scripted Level Thresholds.
* More variety of monsters
* Levels can exceed 200 thresholds.

Strange to see an RPG with no bats.

Most RPG’s have up to 300-400 different types of monsters in their games, but Sacred II had over 1,000. That game also had a massive 22 x 22 square mile seamless loading terrain.

But Most of these Commercial RPG games seem to cap their levels and character attributes off at 99-200 with ridiculously high level thresholds.

But if you want to be unique, then if this game engine can exceed the 200 barrier (if the engine can handle it.) then it would be an RPG that would be unique.

Because its all script based, we can add more level thresholds because its a simple text file, That opens up alot of potential for further level scripting to spawn in at random stronger classes of different monsters depending on a certain level threshold that the player reaches at.

But not all the scripting for the game have been done yet. There is only about 10 monsters in the game that have been so far scripted in. But I haven’t looked at all the Tilesets yet to see just how many monsters have been done. but I will take a look.

You also need your spiders to start making HISSING noises soon as someone approaches near them.

The Gobblins need to have some voice dialouge too when they detect you are coming near them. And they need to say ‘Ow,’ start complaining when you are killing them.

So you need to bring human interaction into the game.

You also should allow your Character Attributes to be buffed up to around Level 200 if the engine can handle it.
You also should have your character flashing or charging up each time they get to a level up….

Your monsters need different behavior patterns to make the game more unique instead of the same, predictable rush and charge boulderdash behavior.

Your Map Location Box at the top right corner should be put in a circle.

There’s always the option too of using a GUI window editor to do all the work of putting down the tiles for creating new maps and the editor supporting scripting commands. I couldn’t find any editor or the map files when i looked in the game directory so the map files are probably inside the main exe.

It depends on what type of RPG you want to create. Whether you want just a small RPG, or what this RPG to be big in scope.

Making a Hack ‘n’ slash RPG is probably more easier to do because those kind of games rely alot on random seed generators for spawning in the monsters in small groups.

Even though you use tilesets, if you can script your game to spawn in different types of monsters at different level thresholds then the game would have more surprises for the player and not be so predictable with everything spawning always in the same spot.

You should beable to hit a hot key to bring up a portrait of the monster you last killed with all its stats, number of monsters killed.

There should be an option implemented where you can press with the keyboard to bring up a encyplopedia of all the monsters in the game showing
all the danger classes and stats. Have you got a graphix artist to create the portraits?

Bascially, as you can see its a lot of work involved in making a good RPG…

There were many good criticisms about flare in this email. I’m genuinely pondering some of these features for the future of the engine.

Keep the feedback coming!