Flare

Starting Small

I spend a lot of time in r/gamedev. At least once a day, some young person eager to get into game development pitches their big idea. Almost invariably, their game idea is too big.

Focus: Game or Engine?

I’m pondering the focus for the near-future of Flare. Please add your opinion to the discussion.

Code Conventions

Flare might be run a bit different than other Free Software projects. The main strange thing: there’s not an oligarchy over the project. There’s just me. I’m the lead coder and lead artist, so I make unilateral decisions.

For about the first year of Flare, I wrote 100% of the code and created 90% of the art (commissioned the rest). In the last year, I’ve been grateful to have volunteer contributions from all over the world. Even still, just over 50% of the commits to the project are mine. I’m still the arbiter of every pull request.

I listed some Code Conventions on the GitHub wiki.

I want to reiterate here the #1 rule of contributing to Flare: you must discuss any non-trivial code change with me first. Flare’s code has years of decision-making behind it and at least a year of future changes planned. I’ve had to reject really good code contributions because they don’t fit with the plan — because the contributor didn’t discuss things with me before starting.

I don’t like rejecting solid work from eager developers. I think most open source projects much prefer small, incremental patches whenever possible. And, I’m more than happy to discuss design ideas with people interested in contributing.

Wyvern posted to OpenGameArt

Check out the Wyvern at OpenGameArt.

Wyvern data

I’ve also added Wyvern data to mods/fantasycore. Try placing a “wyvern” or “wyvern_adult” on an existing map.

The large wyvern actually looks fun, but there are a couple issues. First, it’s hard to aim missiles at adult wyverns because of how high they are in the air; collision code assumes impacts happen at the ground level. We might have to tweak some code to make that feel correct. Sort of the same issue with missiles coming from the adult wyvern, but perhaps that can be fixed with different kinds of power animations.

Behavior Interface merged

I merged the new Behavior interface code from the working branch into master. A couple things were obsoleted (“patrol” code removed in favor of A*), and some things need to be re-implemented (particularly the new power triggers, which need to be addressed slightly differently anyhow).

Expect bugs at first, but the new cleaner code should allow us to easily identify and fix them.

v0.16 Release Date?

Version 0.16 isn’t ready. It’s potentially not far off though. Depending on how things go (and perhaps what gets cut), we might release a few weeks delayed. Here are the remaining must-have features:

• Flying (ignore obstacles) and Incorporeal (ignore walls) movement types
• Swooping creature base AI
• Patrolling enemy code

Wyvern with diffuse texture

Flare artist Justin Nichol has delivered the final Wyvern diffuse texture. See it in action!

I’ll be tweaking a couple of the animations (the feet need to do more than just hang there) and adding a couple (taking a hit, dying, critical death). I plan to wrap this little guy up and upload him to OpenGameArt this weekend.

Female merchant voiceover

We commissioned voiceover artist Holly Daniel to record a set of Female merchant voices. These are a great addition to the set of Male trader voices we have currently. As always, thanks to our supporters who make new Flare art possible!

Base Hero Updates (WIP)

Testing the updated Hero mesh and rig with an attack animation. The mesh has some better topology than before and still clocks in at right under 1k tris. The high-quality normal map is applied (no diffuse yet). I’m using IK solvers on the feet, which makes animating way faster and cleaner so far.

With the new character size I have to be extra cautious of the remaining working space. So the swinging animation is more “conservative” than before. The “halberd” shown is approximately the largest melee weapon that can fit in the new render area. So unrealistically oversized weapons are probably out (unless I decide to implement player draw layers in real-time instead of at equip-time).

New Commissions

Flare received a generous donation this week, so we’ll be kicking off new commissions!

The Wyvern texture commission is in the works (WIP preview), and I’ve contacted our lead sound guy to do the Wyvern sound effects.

I’ve also contacted some voice actors to do new recordings. We’re looking at getting a “female merchant” voice and some verbal cues for the hero (e.g. “I can’t do that”, or “Not enough mana”).

Art Direction

When I started Flare, it was exciting to get ANY art working in-game. I threw together models of a handful of my favorite classic creatures. The models weren’t that great, as I still had a lot to learn about 3D modeling and animation. Still, they have served well for testing Flare throughout Alpha engine development.

Now that the engine works well and has all the necessary features for making simple games, my focus is shifting. There’s no reason to keep the bar so low for Flare art.

The wyvern is the first “transitional” asset towards a much more polished game. It’s made completely in Blender 2.6. It has real textures, more frames of animation, and movement that reflects combat design. It has better lighting, and we’re taking care to avoid black shadows in the model. Animations in the Blender file are properly separated, for easy export into 3D engines. The shadow layer is rendered separately. All of these features make for a much more polished asset.

I’m pushing new art to be higher quality than the existing alpha assets. Much of the current art could be obsoleted, and that’s okay. We’ve shown what the engine can do, but it’s time to really show what the art can do.

You Can Help

I can’t do all of the art alone. When it comes to sounds, textures, concepts, and digital painting, I rely heavily on other artists.

If you’re interested in contributing your artistic skill to Flare (and to the Free/Libre game community), please contact me with a link to your portfolio.

I do sometimes accept unsolicited art contributions to Flare, and that’s great. But often there’s a specific piece of art we need now, often to move the engine forward. For these must-have pieces I like paying commissions. So far our Flare artists have been amazing and generous in kind.

If you like Flare and what it can become, please consider donating via Paypal. You won’t just be helping Flare; this project’s art can be found all over the Internet in demos, tutorials, proofs-of-concept, and more. We’re giving more than just good gameplay; we’re enriching the pool of Free/Libre art. Endless thanks to those of you who have already contributed.

EnemyBehavior

I created a “behavior” branch in git for hacking away at the Enemy class logic. A creature “Has-A” behavior so the EnemyBehavior object is a component of Enemy. Encapsulation is a bit messy because the Behavior needs to access much of the data in Enemy, but that can be cleaned up as the final form emerges.

The interesting WIP stuff is in the new BehaviorStandard.cpp which will replace much of the current Enemy::logic() routine. Previously all sorts of movement, logic, animation, etc. was stuffed into one large switch statement. In the new implementation I’ve broken these out into three internal functions: check Power use, check Movement, and process the current state. It reads much better so far. I’ll be adding new variables that matched old states to collapse some of the implementation.

Wyvern Texture

We’ve commissioned Justin Nichol (Flare portrait artist) to create a solid Wyvern texture. The texture and model will be released CC-BY-SA 3.0 on OpenGameArt. We’re able to afford this commission thanks to Paypal donations from community members like you.

0.16 Plans

Our ideal release date for v0.16 (March 31) is coming soon. Time is getting away from me due to lots of other life things going on. Absolutely no worries though — progress will come when it’s ready. If we slip the release date or push some features until later, that’s okay. Creating games (just like playing games) ought to be fun. Let’s have fun.

Features

Remaining things to implement, and their priorities:

Patrolling and Wandering Enemies – Patrolling seems easy to implement (a list of waypoints, a pause duration for each waypoint). Wandering could be just walking in a random direction, rather than moving towards a randomly-chosen destination. Not a very high priority (can always be added later), but if it’s easy to implement then we should get it in for 0.16.

Large Enemy Movement – Currently enemies are all a single “pixel” (really, map unit) when it comes to collision. We could support larger enemies by allowing a collision radius. Doesn’t matter to me if the enemy’s collision is circle-shaped or square-shaped; whichever is easier to implement should be fine (probably square). We should add radius (default 0) to the current MapCollision routines. Unless the algorithm is way more expensive than the current case, then we can create new routines for these cases. Not a high priority because we currently don’t have large creature art.

Flying/Incorporeal Movement – High priority. All movement routines should add bool flying and bool incorporeal parameters, or have new functions for these options. This affects the line-of-movement check, the A* pathfinding algorithm, and the line check routines in MapCollision.

Behavior Interface – We’ll have to break a lot of code to get this working, so I’ll need to create a branch. It’ll start simple — all we might need is a constructor that gets a pointer to the parent Enemy object and a virtual public logic() that is left up to the implementation. First I’ll refactor the current Enemy logic into this setup. I don’t expect the interface to be pretty right away; the starter implementations might have a lot of repeated code. We’ll do proper factoring if we have time.

Swooping Creatures – An essential feature for v0.16. For the Wyvern I’ll experiment with multiple movement speeds, moving while attacking, and incremental turning. I see the Wyvern using a slower “hover” speed while idle and when using pathfinding, and using a faster “flight” speed when there are no obstacles to deal with. The base class Entity will get a turn_towards() routine that works similar to face() — the difference is that turn_towards() is a 45 degree change in direction while face() is an instant pivot to the final direction. I might rename “dir_favor” to “turn_delay”, and possibly introduce multiple values for different movement types, e.g. “turn_delay_walking” vs. “turn_delay_running”.

Bugs

The only pressing bug is the one where the default joystick could be an hdaps sensor. For that we’ll just disable joysticks by default.

Miscellaneous

I might move Animations back to being frame-based rather than ms-based. I like working and thinking in frames. Putting milliseconds in the data is fixing a problem that we’re not trying to solve.

I want to add an “active” frame to animations. Right now we assume that the middle frame is the active frame for attack animations, but it doesn’t always have to be that way. When I say “active frame” I mean the frame where the Power/Hazard is generated. This will give us more flexibility in animation design. You see already with the Wyvern that I’m using far more frames of animation for attacks. This is to give room for actual combat mechanics: attack wind-ups to give players time to block/dodge, attack follow-throughs to give players time to counterattack/punish, etc.

It might not make it into this release, but I want to add a “poise” stat. If an entity takes damage that is lower than their Poise, they don’t perform a “take damage” animation. Melee characters with heavy armor will be less prone to being stun-locked. I’d also like to add optional poise to attack moves — some creatures should have heavy attacks that can’t be countered mid-swing. The goal here is to punish players who swing wildly instead of waiting for the correct opening to make an attack.

Game Data

The main new game art is the Wyvern. We’ll add a few Wyvern groups to corners of current maps.

If we get Patrols working, we’ll put a few patrolling creatures in the current maps. Nothing fancy, we’ll just put some existing guards on waypoint routes.

We’ll avoid having lots of new strings this release. We might have a few new creature names, that’s about it.

Wyvern data added

Some WIP Wyvern data has been added to Flare’s “fantasycore” mod. It’s not finished, but it’s useful to test the current animations. Try adding a new Wyvern to an existing map to see how they look. Note the “damage” and “death” animations aren’t created yet and there are no sound effects yet.

Creating this Wyvern has taught me a lot, but the most significant lesson: Improving at art is always going to be incremental. Even though I have a ton more experience that went into this model, it’s still just barely better than my previous art. I’m becoming more critical about my use of textures, animations, and lighting. The wyvern definitely needs a real texture, maybe even some trim on the model (spikes/hair/scales).

So the only way I’m going to get my game looking as good as I really want: create new art often. It’s going to be a gradual climb; there’s no shortcut to being good at creating game art.

Wyvern Animations

Experimenting with Wyvern animations.