(Post written by Justin. This blog isn’t really built for multiple contributors, and I don’t know where else to indicate who’s posting.)

A web browser version of Flare had long been a distant wish. Thanks to Emscripten, such a wish has become a reality. This port is an excellent example as to why we keep Flare’s dependencies to a minimum. Just about anywhere SDL goes, we can go, too.

As for the porting process itself, I got my feet wet by first porting my own games. I then got the opportunity to help port C-Dogs SDL. One of the biggest hurdles was figuring out how to do persistent storage for save files and user configuration. There simply isn’t much documentation out there. Thankfully, I found this article, which helped immensely.

Only after porting those games did I feel confident and knowledgable enough to tackle getting Flare running in a browser. There are a few loose ends, but it works just about perfectly. I’ve hosted a copy of it here for you to try out. It’s a good way to take a look at the latest from our team without having to compile the development version from Github.


Hey everyone, it’s Justin (dorkster). Clint pointed to my blog as a venue for updates in Flare engine development, yet I’ve failed to make a post since then. Some of you have been following the forums and Github closely as development has marched on. For everyone else, allow me to showcase a few of my favorite features that have been developed since my last update.

More powerful Events

In Flare, Events simply refer to things that can happen in the game. It may be a door that moves the player to a new map. Or it could be a chest that opens and drops loot. Just about all of the player’s non-combat interactions are controlled by them. Events are nothing new for Flare, but there are some new ways for developers to use them.

The developer console has had most of its old commands replaced by the ability to execute single Event components. For example, you can send your player to the Hyperspace map by running: exec intermap=maps/hyperspace.txt. This is great for single-line Events, but we needed something for more complex Events. This is where “scripts” come in.

Scripts can contain the same content as the Events you would see in map files. The benefit is that scripts are easy to reference. We can have Powers that call scripts and even have scripts call other scripts. Some possibilities include “return” scroll items that warp the player back to the hub map, or having a Power that can make loot spawn. They can be useful for developers as well, allowing us to create scripts to reinitialize quests for testing purposes. For example, you can reset the first side-quest in Empyrean by running this in the developer console: exec script=scripts/reset_krolan.txt.

Re-thinking the Accuracy/Avoidance stats

One of the properties of Flare that didn’t feel right was the fact that attacks could entirely miss, even if the player visibly hit their target. The action-oriented gameplay of Flare does not lend itself well to having dice-rolls determine this aspect of combat. At the same time, we still wanted to use the Accuracy and Avoidance stats, as they were core to Offense (i.e. ranged) character builds.

The solution we settled on was to implement a damage multiplier to be applied when misses occur. This way there is still a penalty for neglecting the Accuracy and Avoidance stats, but attacks won’t completely miss when there is visible contact.

On the other end of the spectrum, we’ve also added support for “overhits”. An overhit occurs when the attackers effective accuracy exceeds 100%. The result is that the attacker deals a “mini” critical hit, which is defined by a damage multiplier in the same fashion as misses. This gives the player an incentive to further build their Accuracy stat, even if they aren’t getting many “missed” attacks.

No more hard-coded primary stats

The primary stats (Physical, Mental, Offense, Defense) have been pillars of Flare’s game play for most of its life. They fit well into the types of character builds we want to represent. However, we want Flare to be a platform for other game creators to make their own action RPGs. For many games, those four primary stats wouldn’t make sense.

To open up the possibilities for these games, I refactored the engine to allow any number of primary stats to be defined in a mod-able file. This will allow game creators to extend the default set of primary stats (such as adding a luck stat), as well as creating a whole new set of primary stats to fit their game.

Everything else

There’s a lot of smaller things I didn’t cover here, including stuff on the art side. Here are a few Tweets showcasing some of them:


HD art, one slice at a time

We have parallel projects going for Flare, based on the strengths that various contributors are bringing to the project. The engine is 1.0 release candidate stage, and ready for a variety of content for testing and feedback. The 1.0 content Empyrean Campaign is being built to showcase the full set of engine features. If you’re interested in creating game content like maps, creature stats, item drops, quests, now is definitely the time to get involved!

I created the bulk of Flare’s isometric art module fantasycore around 2010-2011. That’s three tileset, a half dozen enemies, and a variety of weapons and armor. I barely knew my way around Blender, and used a rough style that worked well enough for the original tiny sprite sizes. We get requests often for higher res art, but this old art doesn’t scale up well at all. I’ve been practicing my 3D modeling skills to prepare for an upgrade.

Producing high def art assets takes a lot of time and expertise and learning. It’s going to be years before we have enough HD assets to showcase every engine feature. So instead of replacing all the old art at once, we’re going to build new art once slice at a time. And each of these slices will be released as standalone, playable game mods.

Justin Nichol (freeforall.cc) and I are collaborating on that first slice. The first mod will be a warrior’s tale. It will focus around content for basic melee combat. Take a peek at some of the art we’re working on! A magic sword, and a work-in-progress ogre.

Magic Sword
by clintbellanger
on Sketchfab

Ogre WIP
by clintbellanger
on Sketchfab


Horde of Cuteness!

Flare artist Justin Nichol has an amazing new free culture art project live now — Horde of Cuteness!

Horde of Cuteness illustrations of story book monsters

Justin is building a collection of CC-BY-SA (Share-Alike) images especially for the free/libre game dev community. I love the way these little storybook style monsters look! One of my definite dreams with the Flare engine is to have a kids adventure game that follows the imagination of youth. These critters are setting up the perfect art style for that project.

These Creative Commons Share-Alike art packs are useful for all sorts of game projects. Check out these cards by Thane Brimhall, featuring art by me and Justin!

Tabletop game rules cards featuring Creative Commons art

Art in Flare

We’ve recently added many more styles of melee weapons in Flare’s core game data. These were commissioned by the team at Exiled Kingdoms which makes great use of lots of Flare art.

Here are the basic models for these ten new weapons. The Blender models (CC-BY-SA) can be found in our game repo here.

Rendering of ten plain martial weapons

Justin added paint-overs for nice looking icons. These are CC0 along with the rest of Flare’s icon sets.

Painted icons for the medieval weapons pack

Engine Happenings

Be sure to subscribe to Justin Jacob’s github blog for the latest developer updates for the engine! And keep an eye out for a new Flare RPG website, coming soon.


Blender scripting for Flare animations

Clint here. I’ve been away from the day-to-day Flare engine project for a while, but I’m coming back with some things to share. Just figured out an update for the main Python script I use in Blender for Flare animations.

The current alpha-demo Flare animations use a keyframe for almost every single frame. And all of the animations are mashed into one Blender action. Of the 32 frames, the first 4 were standing around, the next 8 are running, etc.

I’ve been in pre-production for HD assets for everyone to use in Flare engine. I’m starting to use different Actions for each animation, which makes working on (and exporting) animations easier to work with — as intended.

# render all animations for the named armature
# Clint Bellanger 2015

import bpy
from math import radians

angle = -45
axis = 2 # z-axis
armature_name = "FemaleArm"

# remember UI settings to restore at the end
original_path = bpy.data.scenes[0].render.filepath
original_frame_end = bpy.context.scene.frame_end

# RenderPlatform is an Empty object located at the origin
# and has the lights and cameras attached as children.
platform = bpy.data.objects["RenderPlatform"]
armature = bpy.data.objects[armature_name]

# Render all animations
for action in bpy.data.actions:

    # make this action the active one
    armature.animation_data.action = action    

    frame_begin, frame_end = [int(x) for x in action.frame_range]
    bpy.context.scene.frame_end = frame_end

    # Render in all 8 facing directions
    for i in range(0,8):

        # rotate the render platform and all children
        temp_rot = platform.rotation_euler
        temp_rot[axis] = temp_rot[axis] - radians(angle)
        platform.rotation_euler = temp_rot;

        # set the filename action and direction prefix
        bpy.data.scenes[0].render.filepath = original_path + action.name + str(i)

        # render animation for this direction

# restore UI settings
bpy.data.scenes[0].render.filepath = original_path
bpy.context.scene.frame_end = original_frame_end

I use this script in a Blender file that I call my render mannequin. It has a blank copy of the base hero body with a transparent masking material. All the game’s animations are already set as Actions. The lights and cameras are ready and attached to an invisible swiveling RenderPlatform at the origin.

To use the file to render a piece of armor, I would link the armor from the blender file where I created it. Then attach it to the mannequin’s armature. Running the script results in rendering every frame of animation, for every animation, for all 8 directions the character can face. The files are named like “[Action][Direction][Frame].png” e.g. Running40008.png.

I’ll explain more about how all this works soon. Still figuring it out myself. This creates a lot of images (256 of them at least) that need to be combined into a sprite sheet. That can be done in a simple batch/shell script and ImageMagick. And, that same script should copy the result right into my flare testing directory. Once I have all that clockwork correct, I’ll share all those files and include a tutorial.

The goal I’m working towards is setting up an asset workflow. I’ll be working on a piece of armor, and it’s close enough that I want to test it in the engine. Open up the mannequin file, append the new armor, and run the magic script. Then after a short rendering break it will be ready to wear and test in the Flare engine.


Planning flare-game content milestones

I’ve settled on the basic main quest and world layout for flare-game. If you want to read a FULL OF SPOILERS and likely to change rough idea of what we’re making: wiki page for World Layout.

This plan makes the most out of the fantasycore art set. Replacing individual parts with better quality or more ambitious content will be much easier if we work together on a starting point.

I’ve outlined 36 maps that follow the proposed main quest line. Included is general idea of what tile set and enemy types appear on each map. Listed at the bottom is the flow of the main quest through these areas.

Now we have a skeleton idea of a full flare-game, and I’m hoping you’ll work with me and the team to fill in the content. Here are the upcoming task milestones for flare-game, in the approximate order they need to happen:

1. Encounter Design

We have fantasycore enemies built already, but some will need tweaking to fit into the final level ranges of this plan. Now is the time to design new enemy types (mostly reusing old art) based on the map populations. Also, we’ll combine these enemies into interesting encounters that fit the feel/story of the maps.

Example: map 2-1 will contain goblins but the map will transition into undead. It’s also described as a swampy area. Maybe some goblins closer to the undead areas use diseased weapons. Can we make a goblin that throws skeleton heads, which roll forward bouncing (can it slightly change angle each bounce?). After we get a few enemy types sketched out, we’ll think of good goblin-undead combo encounters. Consider how we can use map areas as combat arenas, and design the maps to help these combo encounters more fun.

2. Map Design

This is an Action RPG — let’s make interesting fights and then build great maps that support those fights.

Contributors can start by creating room/area sketches. The ones we’ll focus on first are the combat arenas that hold the good encounter ideas. This lets us start scripting those encounters right away (and tweaking enemy numbers based on playtesting).

We’ll connect the best sketches into maps. We’re aiming for a low number of maps, but I want each one to be ambitious. Each one can be big enough for an internal quest or two, unlockable shortcuts, side and looping paths. Each map should feel like a full level in its own interesting ways. Getting to the next level/map (and getting to respawn in that new map) should feel rewarding. Judging by the alpha demo maps, an ideal average size for one map’s area should be about 128×128 tiles.

3. Equipment Design

We’ll be filling out and reworking the item list to support the kinds of player builds we want to encourage (and use ourselves). We can brainstorm by picking a character class archetype and work out a list of upgrades that would be satisfying for such a character’s playthrough.

Some equipment will be enemy drops, some will be found in treasure chests/troves, some will be quest rewards, some will be sold by vendors. The equipment designers will have to determine where to place items. They’ll work with the map designers to plan treasure areas and with the encounter designers to plan loot and player vs enemy power balance.

4. Story Design

We have a decent main quest idea that’s a setup for a common/classic story. But the specifics aren’t written yet. Why does the character go through this quest? Does she/he even know why? Who helps along the way, and for what benefit? Who misleads along the way, and to what end?

Keeping in mind, this is an action RPG where story should not get in the way. Story should be lightly woven into the enemies, encounters, items, maps, quests, etc. After enough of the map is planned out, we can ask what compelling stories fit the template.

5. Additional Asset Design

We’ll know exactly which assets are missing or placeholders to finish the game. I don’t expect we will make an entire new tileset, but we may add a few tiles to the current ones. We may add a few creatures and several more armor/weapon options.

There are a few things I haven’t mentioned yet, but will come. We can completely redesign the power trees and classes. We can change the level scaling, and give multiple points to spend per level. We can update sound effects and spell art.

Let’s keep the focus on completing one game though — we (and the players) will have MAJOR temptation to replace the rough parts of the game. The community can help us polish the game once we give them a game that’s worth polishing. Let’s deliver this core game in the simplest way possible, and get both the engine and the game off to their 1.0 release party.

If you are interested in helping us design or build anything I’ve listed above, please comment below and mention ways you’re interested in contributing!



Medieval Weapons Sound Effects

With Flare we’re getting by on art that we make ourselves, commission in small pieces, or reuse from the Creative Commons art community.

Want to support Flare in a big way? Along with supporting an untold number of future game projects? Check out this Kickstarter project to record medieval combat sounds.

The license for these sounds will be CC0 (essentially Public Domain). It will be amazing to have a free asset library like this. They’ve already hit their funding goal, but more support will mean a wider variety of sounds in the set.


Bloom experiments

I wanted to add a bit of bloom post-processing to see if it makes the shiny metals pop. Compare to the animation in the previous post which doesn’t have this added.

This kind of effect might normally be added with a shader. But for our simple 2D engine (with fixed perspective) I can bake these kind of effects directly into the sprites.