Home

2012/01/30

Wyvern, perhaps

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.

2012/01/25

EnemyBehavior

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:

  • move() // enemy changes position and facing direction
  • act() // enemy uses a power if appropriate

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!

2012/01/09

Code Diagram

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.

Flare source diagram

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:

  • wipe screen
  • perform logic on all objects
  • perform render on all objects
  • wait until 1/30th of a second has passed.

Most objects have a logic() and render() routine that handles a single frame. Parent objects call the logic/render routines of their children.

2011/12/31

Two Years of Flare

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:

  • The art was originally created for turn-based combat and tile-based movement.
  • Started as a Java applet, but I switched to C++ early on.
  • Originally named "OSARE" (open-source action roleplaying engine), renamed after a nice conversation with Richard Stallman.

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!

Version 0.16 info

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.

2012 Plans

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.

  • v0.16 "Advanced Enemies" target March 31st, 2012.
  • v0.17 "Menus Config" target June 30th, 2012.
  • v0.18 "Power Enhancements" target Sept 30th, 2012.
  • v0.19 "Alpha Polish" target Dec 31, 2012, marks the Beta feature freeze

2011/12/25

Flare v0.15.1 for Linux

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!

2011/12/23

Flare v0.15 "Translations and Mods"

Screenshots

Download
Release Notes

It's been a long road! Finally we're at the v0.15 release with a nice amount of new content. Enjoy!

  • Now using TTF for fonts
  • All game data can be overwritten/added via mods
  • Translation support for the core engine and mods
  • New Grassland tileset
  • New questing areas: Frontier and Living Bones
  • Redesigned creatures are tougher and more varied

Special thanks to the following contributors:

  • Thane Brimhall "pennomi" - Living Bones mod and plenty of code
  • Manuel A. Fernandez Montecelo - code and Debian/Ubuntu packaging
  • Igorko: code and Win build features
  • Hennr - Debian/Ubuntu packaging
  • Remaxim - composer of Magical Theme
  • Brandon Morris - steps foley, new level up sound
  • Justin Nichol - character portraits
  • Stefan Beller - Tiled flare export mod and automapping help
  • Thorbjorn Lindeijer - Tiled tileset offset feature
  • AMDmi3 - Build help
  • acieroid - Display power cooldown timer and various mouse/menu fixes

And thanks to the following translators:

  • (by) Belarussian by mikhailSaTuRn
  • (de) German by Thomas 'CruzR' Glamsch
  • (es) Spanish by Juan Pablo 'morris989' Tamayo
  • (fi) Finnish by Timo Sievänen
  • (fr) French by acieroid and Bonbadil
  • (gl) Galacian by Gallaecio
  • (ja) Japanese by Paul Wortmann
  • (ru) Russian by Sbasalaev
  • (sv) Swedish by Andreas Berheim Brudin
  • (uk) Ukrainian by igorko

(I'm sure I'm missing someone -- drop me a note and I'll add you to the list! If you'd like to list your real name instead of your github username, let me know. Also, if you'd like me to add a link to your website here or in the credits, drop me a note. -Clint)

Community Links

2011/12/19

I'll be without consistent Internet access until Wednesday night, Dec 21. I'll catch up on Pull Requests etc. then. Thanks for understanding!

2011/12/16

Font Rendering BugFix

We were seeing drastic lag when trying to render Cyrillic text (maybe any multi-byte utf8?) in real-time. After digging around and making my algorithms as speedy as I could, it's still slow. At this point I'm assuming rendering text (vector to raster) is expensive (much more so than blitting the rastered font to screen).

So the solution is to hold onto that rasterized text instead of rendering it each frame. This may sound obvious, but it wasn't an issue when we were using a bitmap font. And isn't an issue with ASCII characters and the particular font I'm using. So maybe there's still a bug somewhere, but buffering the rendered font works.

We have lots of translations rolling in (keep them coming!) so I want to make sure those users get a great experience. This tiny bug fix has turned into refactoring many menus and widgets. I don't want to drop v0.15 right after I've introduced a ton of new code. So, v0.15 may be delayed up to a week (!). The new release target date is around Friday, Dec 23.

2011/12/13

v0.15 String Freeze - Time for Translations

If you are interested in translating Flare, now's the time! There will be no string changes between now and the v0.15 release (coming soon).

Take a look at Flare's github page, inside the mods folder. Each mod can contain its own translation. Here are the five main translation files:

Flare uses a simplified subset of GNU gettext, where only simple msgid, msgstr pairs are used. Take a look at existing translation files to see how it works.

Thanks to everyone who is helping translate!

2011/12/12

Flare v0.15 RC 1

Playing on Windows? Try out the Release Candidate for Flare version v0.15.

Translations

Tomorrow (Dec 13th) there will be a String Freeze for version 0.15. If you are interested in translating the current content of Flare, please check in tomorrow for instructions.

What's Left

  • Test the encampment quest, especially out of order
  • Add new zombie death sound
  • Add new level up sound
  • Assign appropriate music to zones
  • New NPC art for important town NPCs (at least one for Martigan)
  • Update monster placement in Averguard Hold for level 3-5 range
  • Bug Fixes
  • Update the Credits page
  • Clean up the Tiled folder