Flare

Dungeon Doors

Continuing the theme of updating the really old Dungeon Tile Set.

For the longest time I couldn’t figure out a good way (artistically and technically) to mark exits on maps. Since very early version of Flare we’ve been using these boring blue markers. The double doors are much cleaner:

I designed the doors specifically to work inside maps as well:

There are a lot of technical details behind making these doors play nicely with the tile grid. Here’s a peek under the hood:

The green dots show where the “door tiles” actually exist. Closed doors actually sit on the back edge of the tile — this helps ensure draw order is correct.

For open doors, the doors need to be drawn at the same time as the wall they’re touching for draw order to work. Because we put the doors at the grid corners, we solve this problem by actually making new Wall tiles with open doors attached.

The map event to open double doors will be a bit long (needing to modify 4 tiles and 4 collision markers), but it should look pretty clean to the player. The double doors open both ways, but the doors have to swing open against a wall (avoids collision confusion). Along with the stairs I created recently, the dungeon doors are really rounding out this tile set.

v0.17 Dates

There will be a String Freeze at the end of the day this Friday, September 21st. This means that no new or changed translated strings will be accepted, so that translators can perform their work.

If you are interested in submitting a new translation or updating an existing translation, the time to start that will be Saturday, September 22nd.

We’ll have 1 week for translations, bug fixes (there are no known bugs that require attention for v0.17), and minor art updates.

Planned release date for v0.17 is Friday, September 28th

Separate Engine and Game Repos

It’s time to separate Flare into two repos: Engine and Game. But exactly how to do that is unclear.

Apologies ahead of time: I’m going to butcher git terminology here.

We want just the engine in the current main repo. When people want to build a Flare game, they should be able to easily Fork my master repo and add their custom data to the mods folder. Projects like Polymorphable are direct forks of the Flare master — makes it easy to keep their engine up to date. But currently they have to deal with special filters to ignore all of the Flare game-data.

Should this second repo contain game-data only? Or should it be a fork of the Flare master, just like Polymorphable is (containing code and art)? I think there could be benefits to treating the Flare game exactly like any other project using the Flare engine, in that it has its own source and is often merging changes from the upstream engine repo.

Also: should we entirely prune the Flare game data from the current repo? I mean not just remove, but prune the history? If we don’t prune, anyone who clones the engine repo will get all the history of the data, which is a huge amount of data (very large image and music files). If we prune, I’m afraid of what it might do to the tag/branch/commit history of the master repo. Also, if we purged the game-data, how does that affect projects that are already forks/clones?

[–Update–]

Now I’m essentially sold on the idea of creating a flare-game fork.

The remaining question: do we just delete the flare game-data from the engine repo, or do we try to prune it? If we don’t prune, anyone cloning the Flare engine gets all the data history (very large image and music files). If we do prune, I’m not sure how it would affect existing tags/branches/clones.

[–Update 2–]

I’m creating two new repos named flare-engine and flare-game. The new flare-engine looks lean. Tags and branches didn’t make it over. If this purging works, I’m not exactly sure what to do with the old repo “flare”. Maybe update the README to note the permanent move. Maybe even delete the repo at some point in the future.

Ethics in Game Design: Respecting the Player’s Time

[Cross-post from a thread on OpenGameArt]

My opinion is going to be controversial here, but it’s worth sharing.

There are things that players love, that are addicting, but are poor game design. I think it’s borderline unethical to waste a player’s time that way.

Obvious example: slot machines. All the colors, flashing lights, sounds, random chances, etc. are perfectly tuned to addict the player. But is a player having genuine fun? They’re getting the same addicting chemical releases, but they could be doing something more enriching. Something with substance.

I decided early on to not support Lootris in Flare. That’s a term from Diablo where items take up more than one slot, and the player would often spend time rearranging their inventory to carry a few more items (stacking them perfectly like Loot-Tetris, thus the term). Some people find this really “fun”. I actually like the larger item icons for art reasons. But just because it appeals to our obsessive-compulsive personalities doesn’t mean it’s a wise thing to have in a game. If a player doesn’t have to obsessively rearrange their inventory, where will they spend time instead? More questing, more combat, more dialog — elements with vastly more substance.

I think wasting a player’s time is a “cardinal sin” of game design. Perhaps I have the luxury to believe that because I’m not trying to addict people to my game, or make a living off some free-to-play model. I just think it’s unethical, and I wish we could break gamers of bad habits. We shouldn’t be tempted to pour 1000 hours into our favorite game, collecting every item and unlocking every achievement. That player could be experiencing new games instead, new core gameplay with nice substance.

I don’t plan on supporting Achievements in Flare. I think it artificially extends a game’s playtime, when a gamer could be out enjoying other things (games or otherwise). I don’t plan on supporting New Game+ modes either — again, artificially extending a game. How about we have games that are a few rich hours and done.

I don’t begrudge games that do Achievements and New Game+, as I can ignore those options easy enough. But if a game’s design is up to me, I really enjoy trimming the fat.

Dungeon Stairs

I’ve been planning several key additions to Flare’s core tile sets — we want game designers to have the proper assets to create interesting maps.

This weekend I created these Dungeon Stairs:

Here are some various thoughts on creating these.

Inspiration

It took me forever to decide on a style for the stairs. I need to get into two habits to fix this. One is fearlessly doodling — in the age of Ctrl-Z it’s intimidating to put pencil to paper and commit something. I need to get over that and sketch way more. Really if I want to improve as an artist I should pick up sketching every day.

Second, hunt down reference material. It’s not automatically infringement to take inspiration from history, from architecture, even from interesting concepts of other artists. I need to start collecting more reference material. I have a couple folders of inspirational images for future works (lots of old ruins, and lots of armor designs) but I should expand on that. Maybe even pick up some coffee table books. Perhaps start poking around concept art communities online.

Modeling

I told myself recently that all new models I create should be of a higher standard — able to be used in 3D games, even if I only need them on a small scale. That didn’t work out here. I finally gave in and took shortcuts for good reasons. Most 3D games can’t just take any old stairs and slap them into a game. Stairs, more than most other world objects, are tied very closely to game/engine design. Step sizes have to match animations. Stair height depends on the size of floors. In my simple 2D game I have none of those concerns, so making a complete 3D model would be impossible without proper spec.

After giving in to sloppy modeling, I actually landed upon some new techniques. Notice the brown wall of the stairs. It’s basically a flat polygonal area with a simple texture on it. But I’ve added highlights in the form of random bricks poking out. These are resized cubes with the back face removed, using the same texture as the wall, and placed near the wall (not actually attached in a manifold way). By varying their placement and thickness, it gives the impression of an interesting unfinished wall. It’s a nice effect that requires very little modeling time. It might even work in a 3D game asset, unless a particular engine requires manifold structures.

Design

The size and layout of the stairs has a mechanical purpose. In Flare the hero’s position is a single 2D point — the hero doesn’t have a thickness/radius when it comes to collision. So you’ll notice that walls tend to take up half of a tile instead of going entirely to the edge. This visual trick looks good and keeps collision code very simple.

So when designing the stairs, I finally realized that I needed to account for this wall-edge gap in the design. I decided the stairs needed to take up a 4×4 tile area. This contains a 1-tile perimeter that is “Wall collision” to the engine, except for a 2×1 tile area that is the stairs entrance. That 2×1 area is where the teleport event goes. Because I’m using whole tile collision, it’s important for these large tile sets to play nicely with the tile grid and with player expectations.

The look and feel of the stairs is simple, but evolved into a happy accident. I wanted that archway under the stairs, but after adding the prison bars it really gave the piece that “dungeon” feel to match the tile set. The hanging chains add to the theme as well.

Notice the top of the up-stairs is slightly brighter than the floor tiles. The bottom of the down-stairs is darker. These are point lights in Blender added specifically to make them stand out from surrounding tiles. The down-stairs tile uses a “negative” light which casts darkness. It’s one of those neat shortcuts possible in 3D modeling that doesn’t happen in real life lighting.

I put some effort in to make the steps irregular. Some are moved out of position, a couple are broken, some have a worn off edge. I’m still learning these techniques via trial and error. Next time I think I need to go way further in adding lots of wear and tear onto models like this.

Once again I used pdtextures.blogspot.com for the textures — it’s a resource that keeps on giving. I’ve uploaded the Blender model to OpenGameArt under the CC-BY-SA license. Enjoy!

Bastion

This weekend I was tempted to run out and purchase Guild Wars 2, but decided to stay in and give some love to my Steam library instead. In particular, I finally took the time to play through most of, and finish, Bastion. I realize I’m late to this party, but I’m going to gush on it anyway.

Art

The goddamn art. Jen Zee’s work is incredible. This is one of the few times in my entire life that I’m sad to be partially colorblind — if the game is already lush and beautiful as I perceive, I can’t even fathom what it really looks like. Action RPGs definitely don’t need to be dark/gothic to be compelling.

There were about three moments during my playthrough where I fell off an edge because it looked like solid ground, but was actually some taller object further away. For the most part they did a good job of making the active areas brighter than the inactive places. I found myself having to pay attention in some twisty areas to determine what was floor.

I like the art tricks used with The Kid. Because he generally always looks the same (same face/hair, same clothes) most of the animations had to only be pre-rendered once. Notice how the weapons are stowed away for many of the animations — there’s no real need to render every weapon for every animation. This makes logistics far easier, and it’s less painful to introduce new animations. They can introduce one “falling asleep” animation which doesn’t need to include every face/race/gender/weapon/armor combination. If you’re out there dreaming of creating a 2D RPG, seriously consider having a fixed main character and what that can do for your art workload.

Story

The Narrator does a superb job of telling the story of Bastion. His voice, and the character, absolutely oozes with style. Importantly, he informs the player of the story without interrupting the action. Normally direct exposition is a bad idea in games (and movies, etc) but the way it’s handled here has great charm. The Narrator is also used efficiently to remind the player of game mechanics — at one point he reminded me that I wasn’t using my special skills. In a single playthrough I didn’t find the voice repetitive, which was a great surprise.

While the Narrator spells out the details of the story, the overall story is told in every scrap of art and every note of the soundtrack. I love the Mementos in the game — mostly random items that have a little story attached. I’ve had plans for a while to use memento items as collectables in Wandercall. Games like Dark Souls put even more emphasis on item lore, with nearly every individual item forming a puzzle piece to the entire world.

In the most emotional scene in the game, the player still has some control. I have a lot of respect for this, instead of e.g. putting the player in a cutscene. I believe mechanics like this are one reason why games have greater potential for emotional impact to the audience than most other storytelling media.

The player doesn’t actually need to know any of the story to get through the game. That’s a trend in many successful action RPGs, at least ones that I’ve enjoyed. Not to say that deep dialog or developing relationships can’t be in RPGs (they absolutely shine there), but on the action end of the spectrum we can have great games that keep it simple.

Gameplay

The combat itself is pretty fun. At first I worried that it felt a bit too slow or sluggish, but that’s mostly alleviated by the roll maneuver. And combat definitely didn’t feel slow, especially during the dream/memory sequences.

I enjoy that each creature is weird (not an orc in sight) and serves a unique gameplay role. Well, for the most part — each creature seems to have several subtypes that change up the way they attack. Sometimes I wasn’t quite sure which version I was dealing with until their first attack, but I think that’s completely acceptable (it’s quite true for my game). I really like the enemy health meter display; it blends so well that I actually didn’t notice it until halfway through the game.

I love several mechanics of the combat; some seem to be quite popular in action RPGs. Systems that have an active block button also tend to reward the player for a Just-In-Time block. In Bastion it damages the attacker (even on ranged attacks!!). In Dark Souls it’s a parry/riposte mechanic. I really should look into adding just-in-time blocking to Flare.

I love how the game mixes melee and ranged combat well. Even several of the melee weapons could be used in ranged attacks. There were several mechanisms to balance the effectiveness of ranged weapons, particularly timers to aim and reload. The “perfect shot” mechanic is another example of great gameplay — using time to add depth to maneuvers, rather than adding more buttons.

I’m impressed that so much of the game options were done through the town. The game doesn’t need an Inventory button because there’s a building where you can switch out equipment. Same with passive bonuses and weapon upgrades. Impressively, they even managed to create Achievements and Difficulty as in-game locations. These are gradually revealed to the player (starting players aren’t overwhelmed with options), and it’s expertly integrated with the story (the hero is fighting against a cataclysm by rebuilding a tiny town).

The game gets by without a quest system. There’s the overarching “gather X MacGuffins” theme, but the player never really has to choose which objective to complete next. I always had 1 or 2 next maps to explore if I wanted some action, or I could fiddle with options in town, or practice weapons at one of the weapon challenge maps. The Narrator adds some purpose and context to the story maps once you arrive, but mostly that’s just flavor. I find this interesting. It doesn’t seem like a player can really get “stuck” or forget what to do next. There’s always just the next dreamlike area to explore.

Impressions

I admire the game quite a bit, and I plan to return to try NewGame+ at some point. After hearing other people talk about the game, I’m a bit surprised at how light the story is. The game had a strong impact on me, but it didn’t require a ton of story details to get there. I’m also surprised at how long the game was, in that it’s longer than I expected. I put the game down a while back, hoping to savor and stretch out the experience — but turns out I was only about 10% through the main story. I want to take Bastion as a challenge, and make Flare and (especially) Wandercall better games for it.

The art of removing features

Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher.
(Antoine de Saint-Exupéry, Terre des Hommes, 1939).

[It seems that perfection is reached not when there is nothing more to add, but when there is nothing to subtract]

Besides just keeping the scope reined in, I may actually be eyeing places to remove code for Flare. I believe it’s better for the life of the project (and any games that use it) if everything is as simple and essential as possible.

Making Omelets

There’s an English idiom: “you have to crack a few eggs to make an omelet”. It means that to make something, often it requires destroying something else.

We’re doing heavy refactoring of the Flare engine right now. Part of that is breaking things in some places to improve them elsewhere. Just a heads-up for people who play Flare directly from the master source on GitHub:

• We’re seeing a higher number of bugs than usual (Flare is usually pretty solid). Many of these are known temporary side-effects from major refactoring. But feel free to send any issues to the team in case we don’t know about it yet.
• Your save game isn’t safe! Example: soon we’re going to change the inventory size from 64 slots to either 48 or 32 slots. You might lose items when this change happens. While we’re still in Alpha anything is subject to change, and preserving save game data isn’t the top priority.
• All this work and very little new content! I know. Engine changes are happening at a rapid pace right now. The closer the engine gets to Feature Freeze (Beta), the better tools we’ll have to create final campaign data.

What kind of work are we doing? Most of the engine has gotten a “second pass”. Think of Flare v0.14 as the first “rough draft” of the entire game. Since then we’ve been making everything more flexible: replacing arrays with vectors, moving options to config files, and optimizing various routines. A few main components are still due some changes, and a couple new core features remain:

• New system to handle buffs/debuffs. Their effect, duration, name, icon, and visual display will all be defined in config files. These may end up being new Power types, or separate Effect types (the structure is undecided at this point).
• New system to handle cutscenes. These will be more for chapter interstitials and game beginning/endings. They’ll start by using static images with captions and background music.
• The loot system will get significant refactoring. If we decide to combine base items and affixes at runtime, the loot system will get a complete rewrite instead. Undecided yet which route we’ll take.
• We’re actively working on the equipment slot system. We’ll probably add gloves, boots, helm slots and make them appear on the character when equipped.

Tile Set improvements

The current 3 tile sets will get some love and polish before we start making final maps. If you have ideas on what tiles we can add to these sets, please share them!

Playing

On my lunch break. I’m sitting down just to play Flare for the first time in a while. And hey: it’s pretty fun.

My favorite thing right now (I can’t help it) is that now so much is configurable. If while I’m playing I don’t like something, I tweak a config file value and relaunch the game. Kudos to the Flare crew, who are doing lots of tedious work to whip the engine into shape.