Download Media Create Donate Forums

Windows OSX Linux

Additional builds on these platforms thanks to volunteers/fans:

amiga os arch linux Debian FreeBSD Haiku openSUSE Ubuntu

2017/09/05

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

2016/10/16

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:

2016/06/05

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

2016/04/12

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.

2015/06/07

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
        bpy.ops.render.render(animation=True)

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