Free/Libre Action Roleplaying Engine
Last weekend I went on a short trip to New Orleans. Along the way I got some really great game design ideas. There’s nothing like visiting an “unusual” culture to spur new ideas.
Notes to self:
The wings can get a bit funny but they’re decent enough for most practical poses.
Having fun with the low poly wyvern. With every new model I create, I learn just a little more about effective poly use and edge flow. I still feel like I’m stumbling around (and sometimes getting lucky). Example: here most of the limbs are six-sided (hex cross section), and I’m just figuring out that extruding two quads is an easy way to connect a new six-sided limb. I like the way the edges came out on the face in particular. I took care to use quads everywhere so that I can try some sculpting later.
Current poly count: 431 quads (862 tris). I’m guessing with the wings it’ll end up in the 1500 tri area. I might create an optional non-manifold “trim” mesh for stuff like horns and teeth, all those close-up details that don’t particularly matter for my game.
Next up is making the wings. It’ll be an interesting challenge to make sure the wings fold, stretch, and flap correctly.
[–Update–]
Got the low-poly wings done. The “skin” part of the wings are single-face thick and have some tris, for better shading. The model is currently 1508 tris total.
I’m still not sure how the wing armature is going to work out. I might be experimenting with weight paints.
By request of a community member, I’ve added a Paypal Donate button to the sidebar. I also created a Donation Info/Log page to document where the money goes.
Regarding Flare’s funding: so far most of Flare has been a volunteer effort from myself and many contributors across the world. On occasion I have paid commission works out of my own pocket — for music, art, or as bounties for code features. Flare is not a commercial project. All of the code and art is generously Copyleft licensed for the benefit of the entire Free Gaming community.
I work full-time, and Flare is something I contribute to on nights and weekends when I can. I don’t expect to personally make profit from Flare. So any donations we take in will go towards improving Flare. For now I’ll use my personal discretion in where to spend Flare’s donations (mostly commissions for new art or code). If we ever get to a point where that’s a lot of money, I’ll turn to the Flare community for guidance.
Thanks to any of you who are interested in donating! Your donations tell us that you like the project, and that you want to see it succeed and grow.
Congrats to Justin Nichol, who has finished the Creative Commons Fantasy Portrait Marathon! Soon all 30 portraits will appear as NPC options in Flare.
[–Update–]
All portraits now on OpenGameArt!
To break past this EnemyBehavior code, I think the best course of action is to make a new creature that requires new code.
I’ll start working on a “wyvern” creature type. Sort of a small flying dragon. Ideally, this creature will move in arcs and attack while moving forward. These simple changes in movement will require new behavior code. Once we see the new code, the EnemyBehavior interface should become more evident.
I’ve been thinking about the EnemyBehavior interface and it’s tricky. I’m trying to plan for several future enemy types, but not having those spec’d out makes it hard to design the interface. Ideally, I’d code up a few very different kinds of enemies and then figure out their common interface.
Most likely an EnemyBehavior base class will have these functions:
Enemy position, animation frame, and power usage would be public. Most other behavioral variables could be private, allowing completely different “black-box” implementations for creatures. E.g. some creatures might follow specific patterns (think Mega Man boss) instead of taking random %-based actions like the current creatures do. Even the enemy’s “state” could be done inside the behavior object, as it should be irrelevant to the rest of the game (as long as state and animations are sufficiently decoupled).
When finalized, I’d like there to be several base enemy behavior types. Imagine a Melee type, a Ranged type, a Flying/Swooping type, and several boss types. There will be many configuration options to build a variety of creatures within each type. To add a completely new type (e.g. to design a unique boss unlike any existing creatures) would require adding a new behavior implementation in C++. Though this should be extremely rare, only for ambitious projects that are already content with hacking around in the source to do new things. Great new fan-made behavior types could be contributed back to the main Flare code base.
This is the main feature we want for v0.16 (now that A* and enemy spawning are complete). If you have ideas for enemy behavior types, or interesting pointers for implementation, drop me a note!
I drew up a quick diagram of how Flare’s code is structured. This mainly shows parent/child/sibling relationship of the main objects. Not all objects and relationships are shown, but this should give you a rough idea of how the game is structured.
Before we reach Beta there will be just a few more classes added. At that point I’ll make an interactive diagram that explains how all the moving pieces work together. Here’s a quick rundown:
Flare’s timing is frame-based instead of ms based, capped to 30fps. This is fine for the low demands of old 2D sprites, and for a single-player game. The main game loop is a typical 2D game loop:
Most objects have a logic() and render() routine that handles a single frame. Parent objects call the logic/render routines of their children.
If you check the archives you’ll see that Flare v0.01 was released on Jan 1, 2010. That means I started work on Flare a bit over two years ago. Have a nostalgic peek at the v0.01 preview video.
Interesting historical notes about this project:
Two years is a hell of a time for one person to work on a project. Even after greatly narrowing down the project scope (2D, no multiplayer, static maps, etc) it’s still a frighteningly huge project. I wouldn’t have made it (sanity intact) this far without help from many contributors. Thanks crew!
v0.16 “Advanced Enemies” will be devoted to making enemies better all around. Contributor “nojan” has already added A* pathfinding, the first major new feature for enemy AI. Try the latest master branch, you’ll find that enemies handle obstacles much better now.
Next task we’ll want to tackle is allowing powers to spawn enemies. The actual code shouldn’t be too bad; it’s mostly a matter of adding new art. Most creatures will get a spawning animation. Perhaps I’ll start with the Antlion, get it burrowing out from the ground. We’ll add map events where antlions burst up all around the hero. We’ll add Queen antlions that summon hatchlings as a ranged power. Once all that is acceptable, I’ll work on spawn animations for the other creatures.
Finally, the major work in v0.16 will be separating my messy tangle of Enemy::logic code. Enemies will gain base types that explain their basic movement/behavior. The starting types will be melee, ranged, and flying. We’ll probably also create one “boss” type to demonstrate how new one-off behaviors can be added by modders.
Time permitting, here’s how I’d like to see Flare shape up in 2012: a release every 3 months while we march towards Beta.
I’ve tagged v0.15.1 especially for Linux users. It fixes a couple issues (build flags, random enemy groups) that weren’t an issue on Win or OSX. Those of you working on packages: thanks for your work!