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.

2014/09/17

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!

-Clint

2014/09/08

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.

2014/07/15


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.

2014/03/05

Flare Dev Log – improvements and fixes

Justin sends in this report on Flare engine progress. As we’ve been creating and porting game data to the latest engine, we’ve cleaned up a few unhandled glitches.

The Flare devs (who are way better at C++ than I am) are also finishing up an abstraction for all the graphics handling. Flare is no longer limited to SDL1.2 — it can be ported to work with other 2D frameworks without having to gut the entire codebase.

2014/02/14


Art: Return Stones

If you’ve already played the alpha demo you’re familiar with the two-way teleporter circles used for the Warp Zone. Today I worked on an accompanying piece of art that will be used for one-way warps. As an example, you may find this stone after a boss fight and it can be used to skip back to the beginning of the dungeon.

animated glowing stone obelisk view 1
animated glowing stone obelisk view 2