My April One Game A Month game is complete! It's called Heroine Dusk. The sun hasn't risen in days and creatures are swarming towards human civilization. You're a serf who takes up arms agains the darkness.
I recently approved code (contributed by Ryan Dansie) that adds basic Minions support in Flare. This will allow Flare games to have summonable creatures, tamed enemies, or simple allies.
This may be the last major new game feature I approve for Flare 1.0. Wow!
Not to say that we won't be adding/improving features. One of our major goals probably for version 0.20 is making all the menus work fully on systems with no mouse/pointer. And there will be smaller game features that make it in, but those will mostly be expanding existing features -- like adding new item bonus types, or adding new spell types.
But the bulk of the remaining code work for 1.0 is cleanup. Refactoring some parts to make more sense. Hardening input file handling and adding more helpful error logs. Naming and comment consistency. That kind of thing.
Everything is coming together for the Flare engine. It's an exciting time, and there's so much to do! If you are interested in helping in any way let us know.
- Beta Engine tasks
- Convert internal map units to floats
- Cutscene additional cleanup
- Consider minions feature
- Input file standardization pass
- Flare-Game tasks
- Create new logo
- Create new website
- Launch name branding
- Map and quest design for Act I
- Create reference wiki pages for all data file types
- Create example maps for DevLab
- Create longer, friendly content-creation tutorials
- Core Art
- Test updated lights/colors for all three tile sets
- Create one alternate of each existing set
- Render HDCore data
- Create set-pieces useful for Flare-Game
- Add additional tiles to make the sets more flexible
Change in the flare-game repo
We made a big change to the flare-game repo today, hopefully to help distributors/packagers in the future.
The repo at https://github.com/clintbellanger/flare-game no longer contains source code. It only contains the mods (and supporting data sources) for the actual game.
If you're playing flare-game from the latest sources, you'll now need to pull from flare-game for data and flare-engine for sources.
We suggest that a similar separation be used when distributing Flare in software repos, starting with the upcoming version 0.19. First the flare-engine repo is the bare-bones engine, and then flare-game which relies on the engine repo. Other games, like Polymorphable, can also be distributed this way (package just the game mods and set flare-engine as a requirement).
Flare v0.18 Released
- 10 Equipment Slots, up from 4 (and easily configurable)
- Starting "Class" choice (beginner's power/item kit)
- Environmental/Ambient Sounds on maps
- Much improved handling of Animations, Effects, and Sounds
- New Powers: Stealth, Traps, Thrown Weapons
- New Item Bonuses: XP gain, Gold Find, Item Find, and more
- Improved support for various input devices
- Two new starting quests
- Implement avatar layer composition and configurable slots (Igor Paliychuk)
- Allow low quality (no alpha) textures for gameplay art (Igor Paliychuk)
- Add support for font styles (Justin Jacobs)
- Introduce AnimationManager and use it for existing animations (Stefan Beller)
- Make buyback price the same as sell price (Justin Jacobs)
- Remove many warnings from static code analysis (Stefan Beller)
- New starting class system (Justin Jacobs)
- Allow assigning titles based on xp, primary stats, or campaign status (Matthew Krohn)
- Powers can require HP and optionally kill the caster (Matthew Krohn)
- Add on-hit, half dead, and dead power triggers (Justin Jacobs)
- New EffectsManager to handle buffs and debuffs (Justin Jacobs)
- Add support for Passive Powers (Justin Jacobs)
- Add "XP Gain", "Gold Find", "Item Find" bonuses (Justin Jacobs)
- Support granting multiple stat/power points per level (Justin Jacobs)
- Standardize init lists for classes (Stefan Beller)
- Add on_clear map event type (Justin Jacobs)
- Add flavor text option for item tooltips (Clint Bellanger)
- Convert MenuCharacter to stat listbox (Justin Jacobs)
- Allow bonus max HP/MP percentages (Matthew Krohn)
- Implement per-enemy loot tables (Justin Jacobs)
- Add Stealth bonus effect (Justin Jacobs)
- Standardize sound effect loading function (Stefan Beller)
- Add internal utility functions (Piotrrak)
- Support NPC and map events based on hero level (Stefan Beller)
- Allow Accept key to interact with the environment instead of clicking (Justin Jacobs)
- Mouse emulation mode (Justin Jacobs)
- Add default names for portraits to help keyboardless systems (Justin Jacobs)
- Add --game_dataflag for setting a user-defined PATH_DATA (Justin Jacobs)
- Introduce SoundManager for centralized sound handling (Henrik Andersson)
- Add game_prefix to segregate save games and config files for mods (Henrik Andersson)
- Add NPC Action Menu for NPCs with multiple discussion topics (Henrik Andersson)
- Add location-based sound volume (Henrik Andersson)
- Implement enemy style loot tables for map events (Justin Jacobs)
- Make the local data folder prevail over installed ones (Yohann Ferreira)
- Rendering optimizations (Stefan Beller)
- Allow config file durations to be specified in frames, ms, or seconds (Henrik Andersson)
- Fix LMB ignoring locks in some situations (Joseph Bleau)
- Add cooldown_hit duration to prevent stunlock (Joseph Bleau)
- Add status-based trader stock (Justin Jacobs)
- Allow equipment bonuses to be applied while transformed (Justin Jacobs)
- Handle fuzzy matching in translation files (Henrik Andersson)
- Add item count ranges for loot tables (Clint Bellanger)
- Don't allow dead hero to trigger map events (Justin Jacobs)
- Add additional cppcheck flags to the .travis.yml file (Hans Joachim)
- Clean up BOM from the languages.txt file (Hans Joachim)
- Updated equipment from 4 slots (weapon, offhand, body, artifact) to 10 slots (head, body, hands, legs, feet, weapon, offhand, ring, ring, artifact)
- Added chainmail and mage armor (Clint Bellanger)
- Clothes icon paintings (Ben at CrowLine Studio)
- Mage, Leather, Chain, Plate icon paintings (Justin Nichol)
- Ring art (Clint Bellanger)
- Iron Buckler shield (Clint Bellanger)
- Animal Figurines (Clint Bellanger)
- Abandoned Tower art and quest line (Stefan Beller)
- Mineshaft Longsword quest line (Justin Jacobs)
- Beginning of new item list (Clint Bellanger)
- Environmental Sounds on existing maps (Henrik Andersson)
- New powers: Stealth, Caltrops, Bear Trap, Dagger Throw, Axe Throw (Clint Bellanger)
- Czech by Nikita Vanku (Zaraka)
- Norwegian Bokmal by Hans Joachim Desserud
- Polish by Pawel Puszczynski
- Many thanks to the other translators who sent in updates
Flare is made by a lot of great people. Tremendous thanks to everyone who makes it possible. It's hard to keep track of everyone with a project of this size. If you have been accidentally omitted from the credits list, let me know and I'll add you right away!
A Note on Save Files
Note that Flare v0.18 isn't set up to load save files from previous versions. With the armor slots changing so drastically it required recreating most items. You still may want to back up your existing save files if you're attached to those characters. But we expect players to start new characters in v0.18.
Downloads courtesy of SourceForge
- Flare v0.18 for Windows (zip)
- Flare v0.18 for OSX (dmg)
- Flare v0.18 for Linux (sources with cmake, tar.gz)
v0.18 Gameplay Video
Have a tour of the new v0.18 features while you download. Turn on annotations to see my developer notes. Watch at 720p!
v0.18 Release Candidate
I'm putting this link up temporarily for testing. You are welcome to try it. If you get any issues while playing send them to the Issue Tracker.
Flare v0.18rc for Windows (link removed)
Thanks for helping us test the release candidate. I've removed that link. The official v0.18 release files will be up soon.
String files update for bug fixes
Today I approved an update of the translation files related to various bug fixes -- our extraction script had some errors, and some engine data wasn't being properly formatted for translation.
The .pot files were recreated and the .po files for each language merged for these changes.
If you're actively working on a translation, this may affect your work. Our apologies -- we try to avoid this after a string freeze. This doesn't affect many strings in total. There are a couple ways you can move forward:
- Send us your .po file and we'll merge in the updated messages
- Run a msgmerge on your end with the new pot file
- Work with the updated .po file and copy your work over
Here is the exact msgmerge command we use:
msgmerge -U --no-wrap <name_of_.po_file> <name_of_.pot_file>
Besides splitting armor into more slots, we've also added additional armor tiers into Flare v0.18. This new Iron Buckler accompanies the chain mail set (both requiring Defense 3).
- 512px diffuse, normal, spec maps
- 716 tris
Animal Figurine Artifacts
I finally finished up this set of four animal figurines. In Flare these are powerful artifacts that add +1 to a core attribute -- often letting heroes use equipment or powers beyond their current skill. I also added a splash of paint markings one each one that basically fits the theme of that attribute.
- Bear Figurine (red paint) grants +1 Physical (aka Strength)
- Owl Figurine (blue paint) grants +1 Mental (aka Intellect)
- Cat Figurine (yellow paint) grants +1 Offense (aka Agility)
- Turtle Figurine (green paint) grants +1 Defense
In my imagination, these sort of serve as "spirit animals" to the heroes in the Flare universe. I like the feeling that they're simple, almost like children's toys -- which sort of gives them their power. I drew inspiration from the game Zen Bound 2 when thinking of these.
How the icons look in-game at fantasycore size and the upcoming hdcore size.
Flare v0.18 ready for Translators
The string freeze is now in effect for Flare v0.18. This just means that we won't change any displayed text between now and the v0.18 release at the end of March. This gives translators two weeks to create and submit updated translation files.
I've created a very basic Tutorial page on Translating Flare.
Contact me if you have any questions. Also, if you're editing an existing translation, be sure to contact the previous translators to make sure they're not already working on it.
I'll take translations up until the end of the day on March 29th. Once it's March 30th everywhere on the globe I'll begin packaging Flare for various platforms. Thanks for helping!
Flare v0.18 String Freeze and Release Target
The deadline to get string changes into Flare (and flare-game data) is by the end of the day this Friday, March 15th. Starting on Saturday we'll openly invite translators to work on and submit updates. I'll post instructions here Saturday on how to help with translations.
We're aiming for the end of the month, Sunday March 31st, as the release date for Flare v0.18. This is when the v0.18 tag is applied and Win + OSX binaries are released on this site. Updates to other repos will follow shortly after, thanks to our great volunteers and fans.
The Ranger tree got a new power this week: Stealth. We created it by abusing the "transform into a creature" code. It's a great demonstration of how flexible the game can be just through the data.
While stealthed you can either leave stealth or use a Sneak Attack -- a high-crit melee attack: animated gif of stealth and sneak attack on a goblin
Stealth is created as an enemy with unique art and several passive powers that work together. These passive decrease your threat range, decrease your movement speed, and increase your crit chance. Additional passives are used to trigger a countdown stealth timer and to break out of stealth when attacking or attacked.
I'm working on a new set of maps that I hope to include in v0.18 (and will grow later). These maps are in a new mod called Dev Lab. It's an in-game tutorial with demo maps to show how to get started with modding. Advanced maps will show interesting ways to use creatures, events, traps, items, and powers to create unique experiences. Edit the Dev Lab maps directly in Tiled to see the code behind all the tutorial demos.
We think these in-game modding tutorials will be more engaging than articles or videos (and those can come later). Hopefully the Dev Lab will help people who enjoy playing Flare get into modding Flare.
Flare v0.18 is my March One Game A Month goal.
We've made tremendous progress in the engine since the last release. Version 18 will represent the final Alpha of the game. Flare v0.19 onward will be Beta for the engine -- a freeze on new features so that we can focus on making content and games for Flare 1.0!
Here are the target dates.
- March 15th: Feature and String Freeze
- March 30th: Release v0.18
Book of Lost Lore
My February #onegameamonth project is called Book of Lost Lore. It's a chapter of interactive fiction (much like Choose Your Own Adventure). The story is that of an aspiring adventurer in a dangerous fantasy world.
My main gamedev skills are programming first and 3D modeling second. This project uses neither of those. Instead it's basically all writing. I'm not great at writing so this was good practice that I'm hoping to put towards Flare.
If you're out there and aspire to be a game designer/writer but you have no programming or art skills: here's an example of a game type you can make on your own, right now.
I want to send out special thanks to catch the bear (Matthew Ohlendorf) for allowing the use of his songs from the album "down to sea in ships". I've been listening to his work often this month and it only felt right to put his music directly into the book.
Flare article at LinuxExpres
I found this great article about Flare by Pavel Petřík at LinuxExpres (Czech). It's a surprisingly in-depth look at an earlier version of Flare. If you've discovered Flare through this article, welcome!
We're still working on v0.18 data and features. I think we'll find a cut-off point soon and announce a potential release date. It will be the final "alpha" version of the game. After that we'll be in internal Beta.
Henrik has added a SoundManager class to Flare. This helps us streamline all sound effect loading/playing internally, and forces more consistency on data files. Next on that front we'll be sifting through the code for "hardcoded" sound effects and moving those to config files.
I've been working on models for some new Artifact trinkets. These will be animal carvings that grant +1 bonus to a core attribute.
- Bear Figurine +1 Physical (represents strength)
- Owl Figurine +1 Mental (represents intelligence)
- Cat Figurine +1 Offense (represents agility)
- Turtle Figurine +1 Defense
Here's a peek at the work-in-progress artifacts:
A small data change I did today is providing a purpose for gems. Now gems retain 100% of their value when selling. The gems represent denominations of gold: Sapphire 100g, Emerald 200g, Ruby 500g, Diamond 1000g. I've placed one of each gem on Kenrik the trader in the main town. Now players can buy gems as a way to save money to the Shared Stash (and prevent extra gold loss upon death).
Polymorphable wins a prize for the Liberated Pixel Cup!
From the LPC results announcement:
Last but not least is our secondary prize for teams. Laurelia's Polymorphable Citizens comes in as an impressive single-player RPG. The game makes use of a modified version of the FLARE engine (if you haven't seen FLARE, well you should, because it's an incredibly impressive project… really great if you like dungeon crawlers). The game doesn't play like FLARE though; for one thing, instead of being an isometric game like FLARE, it has all the Liberated Pixel Cup look to it. And it works great! The game has a good story and some neat features. And as the title suggests, the game makes interesting use of a lot of transformation: in order to succeed in your task, you have to switch between the powers of various creatures!
It's an interesting game, and has a good sense of story and adventure, and cool to see the FLARE engine being put to different use. Check it out!
Wow! High praise for Polymorphable and for Flare as an engine. Congrats to Matthew Krohn and Thane Brimhall who created Polymorphable for the LPC. And additional thanks to these guys for all they've done to improve the core engine.
Using item flavor to tell stories
In text adventure games of yore, game designers couldn't rely on images to communicate each item to the player. Instead it was common to Inspect an item to get a textual description of it.
In fantasy there's a common trope of mystical magic items with hidden names or powers. In The Hobbit, Elrond recognized the Elvish weapons Orcrist, Glamdring, and Sting and explains the stories and powers behind them. In Diablo, the mage Deckard Cane identifies magic items for the hero. In D&D there is a traditional magic spell that can reveal the properties of enchanted items.
This combination of game mechanic and fantasy tradition is still evident in games today. Many fantasy games include a "Flavor" description of objects or powers. By "Flavor" I mean text that is about story and color, not about specific game mechanics. We see this distinction clearly in Magic: The Gathering where flavor text on cards is in italics to denote that it isn't part of the card's actual game rules.
In video games, sometimes these descriptions merely detail the item itself -- physical details that aren't obvious from the icon or 3D model, or a more creative explanation of its in-game function. But creative game writers use item descriptions to tell more about the game world. Items can refer their areas of origin, or to a famous former owner, or to an historical event.
The recent games Demon's Souls and Dark Souls use item descriptions masterfully. These games have very little exposition and dialog but still manage to convey rich, deep worlds. Items actually tell much of the story; their flavor texts hint at the larger world that can't be seen. This is especially effective in Action RPGs where a player doesn't need to be bogged down by heavy dialog or told a long story. Curious players who crave story can read all the item descriptions and discover (or infer) the larger game world at their own pace.
I've been so influenced by the Souls games that I want to do the same for Flare. I'm doing it in a backwards (I think) way though. I'm not a writer; I don't have a volume of creative notes about the world that Flare takes place in. Instead I'm creating item descriptions that I feel are resonant, and sort of building/discovering the world as I go.
Because I'm not a writer this task is turning out to be far more challenging than I expected. Good flavor text needs to be concise -- one or two lines at the most. It should lend the feeling to the game world, so I'm trying to avoid overt pop culture references or too much breaking of the 4th wall (though other games with different tones can and do include those things). Finally I need to mind the fine line between pretentious and boring. But my goal is to have every item tell a tiny story.
Items in progress
Effect: this weapon deals double damage to Undead
Flavor:When the Warpriests of Sceleris began their mercy killings, they used these morning stars on the most faithful parishioners first.
This was the first item I created in this new style. Here the item hints at a historical event in the game world -- some undead outbreak. I particuarly like this text because of the oxymoronic nature of the terms: "war priest", "mercy killings", etc. It heavily implies the event was not a clear cut "good". Holy men butchering villagers to stave off an undead plague is a moral quagmire.
It may be that such an event is cliche. I'm reminded of Arthas' purging of Stratholme in Warcraft lore. But we're not forcing the player to dwell on the event -- just giving them a taste and letting them fill out the details themselves.
Originally I used the phrase "Warpriests of Sceleria". I changed it after making the next item, as you'll see.
Effect: you loot more gold from defeated enemies
Flavor:"In Lower Sceleris there is honor among thieves. Everyone else is a mark.
There's no set place in the game named Sceleris, not yet anyway. This just implies somewhere in the game's world there is such a place, and it is probably a hive of scum and villainy.
When naming "Lower Sceleris" I needed a fantasy name that sounded like a dangerous area or city. I started with "Sceleria" only because it had an interesting fantasy sound. By luck I found out that the similar form "Sceleris" is actually a Latin word that has something to do with crime or villainy. The player probably won't know that, but it's a nice touch of flavor. Adding "Lower" pushes the idea that it's a lesser or poorer part of town.
I like the flavor implication that there may be a Thieves' Guild operating in Sceleris. Action RPGs aren't usually the kind of game that needs political intrigue or guilds, but it makes an interesting backdrop nonetheless. It also makes an easy opening for quest lines or NPCs later.
Boots of Speed
Effect: you run faster
Flavor:These enchanted boots are prized possessions of Courier guildsmen.
I must have been intrigued by the idea of guilds, because I outright named one in the next item. A Courier guild is great in a dangerous fantasy world. Or at minimum it gives some grounding to fetch/delivery quests that are easy to implement.
I had been playing with the phrase "prized possession" when writing up several items and decided I needed a good spot to use it. It makes a lot of sense here -- running quickly means you can avoid danger and deliver items more efficiently.
This also opens up easy places to award the treasure -- slap it on a dead body along with some other package. Now there's a story in the environment instead of explained in words. And perhaps the hero can take the package to its destination.
Effect: small bonus to magical power
Flavor:The secrets to harvesting Yggdrasil twigs are known only to traitorous dryads.
This item didn't need to be some majestic artifact; just a nice "my first magical equipment" for mage characters.
This flavor continues my theme of favoring dark and twisted stories. I enjoy the idea that evil tree spirits are trading away parts of the World Tree for personal gain. Every twisted reference we drop into the game adds to the setting and atmosphere.
The Yggdrasil is a Norse reference, but I think it's obscure enough to pass here. I was concerned whether people too familiar with Norse mythology would find the reference silly. But fantasy already borrows so heavily from old mythology that it's probably fine. If it really bugs me later I can just rename the tree.
Effect: small bonus to melee combat
Flavor:The workmanship on this blade appears hurried, as if forged under the fever of vigilance.
Here's an item description that mainly details the history of this single item. Some lawful person, or possibly a vigilante, crafted this weapon to fight the chaos. It doesn't say whether it was used in self defense, or as a makeshift badge, or to slay criminals, or to fight some abstract cause. Any of those options are possible and that makes the item interesting.
The name of this item is almost anachronistic -- sounds more like an Old West revolver than a dagger. But I like that feeling; I want the settings of the game to almost feel like the frontier West. In future games based on Flare I plan to experiment with more overt anachronistic stories.
I'm mainly writing out this blog to meta-think about the strategies I'm using to come up with flavor texts. Here are some options I'm seeing just in these first few items, plus a few more thrown in that I want to use later.
- Reference to a historical event
- Reference to a historical person or previous owner
- Reference to location (region, city)
- Reference to factions or organizations
- Physical or usage detail of the item
- History of how the item was made
- Set up a quest or game event?
Hopefully this out-loud thought process is helpful or insightful to someone else. I'm trying to get better at various facets of game design and writing definitely isn't my strong suit. Side note, I'm considering creating a text-heavy One Game A Month entry for February for more practice.
Bicycle - One Game A Month project for January
It's the end of January and I've finished up my first One Game A Month project. After slashing and postponing many features I've settled on a simple toy that I rather enjoy.
Bicycle is a simple game about riding a bike. I recreated a simplified, stylized version of the neighborhood I grew up in. There are no real goals to the game besides the ones you set for yourself. Just ride around, do laps, take shortcuts, time yourself, or explore.
Two very different shooters
Part of telling a good story is knowing what stories have already been told. I don't play as many games as I did in my youth, and back then I didn't have a critical eye towards analyzing game stories. I'm trying to fix that by playing more games and write my thoughts about them.
I finished two games recently that have basically opposite reactions to shooting people: Saints Row the Third and Spec Ops: The Line.
Before going in, some background: I very rarely play shooter games. Before these games, probably the last one I finished was Borderlands 1. Before that maybe Ghost Recon, about ten years ago. So I'm terrible at shooting games. In both Saints Row and Spec Ops I turned the difficulty down to the easiest level.
Lately my tolerance for game violence has been getting lower. I purposefully don't include human enemies in Flare and I'm even uneasy about sentient neutral creatures like Goblins and Minotaurs. It's just easier to swallow violent gameplay when it's against hordes of undead or demons instead of wiping out entire tribes of regular dudes. So I was curious to see how I'd react to the gunplay in these games.
This is also in the wake of the Connecticut Shooting and endless online debate about the affects of guns and video games. I don't have much to say on these larger issues, just noting that they do temper my reactions to these games in some way.
Spec Ops: The Line
Immediately after finishing this one I devoured Killing is Harmless - A Critical Reading of Spec Ops: The LIne. And then I had several uneasy days while this game knocked around my head.
Right from the beginning I felt a bit out of place. I'm already not at ease shooting people, so I started questioning everything that was happening the first time I had to use my rifle. I had an idea of the story and questions the game was setting up though, so I forced myself to play through the game -- even though the game outright asks the player why they continue to play.
I'm especially intrigued by Brendan Keogh's analysis of how these games usually make us "other" the enemy. Because they're usually not American/Western, they're automatically outside our Monkeysphere. To introduce US soldiers as the main enemy was jarring and made the game even harder to play. Then the later reveals that these soldiers were only trying to help really stabs at the heart.
I also really like the themes of interventionism here. Three separate groups -- the 33rd, the CIA, and the Deltas -- all show up to Dubai trying to help. But the game shows us in a vivid way: showing up with guns to create order isn't going to be a simple solution. It's an effective way for a video game to convey a fictionalized version of what actually happens "out there".
The contrast between Dubai's rich architecture and interiors and the brutal desert and gunplay is stark. It's an interesting thought that civilization is always teetering on the brink of collapse. It also plays on the concept that capitalism isn't some magic cure that makes places automatically good.
The transformation of the main character is handled incredibly. By the end of the game the "hero" looks and speaks like a monster. Keogh notes that at that point he's on the same level as other game heroes e.g. in Gears of War -- brutish and bloodthirsty. Games like to assume that a character can be so horrific and still be heroic; it's honestly great to see Spec Ops take a darker and more serious tone.
Saints Row the Third
On the complete opposite end there's Saints Row. It's a lot like Grand Theft Auto but takes itself much less seriously (which works in its favor).
In this game you play the leader of a group of international superstar criminals -- complete with clothing lines and energy drink commercials. There's essentially no consequence for mowing down pedestrians; sometimes the characters even applaud you for it. But the game is so completely over the top, so unabashedly violent and flashy, that none of the violence can be taken seriously. None of the deaths here felt anything like the ones in Spec Ops.
The game welcomes violence so much that it's actually tricky to play the game safely. I opted for a main car that was on the slow and safe end because I never felt comfortable just thrashing through the streets over people an cars and lamp posts.
I ended up spending a lot of my time on character creation and wardrobe options. I've been doing 3D armor in separate equipment slots in Flare so it was interesting examining the methods they use here. I like the variety of clothing options even though it served no practical gameplay purpose. I may experiment with Flare games in the future where armor is more about style and less about defensive values.
Most of the story was over-the-top and kinda fun. I thought the voice acting of the main crew was great. There's this incredibly good character-building moment where you're just driving to the other side of the city and the two main characters are singing along with the radio. Completely unnecessary but an interesting break between ridiculous violence; it served to almost humanize the characters. It reminded me of the "Royale with Cheese" scene in Pulp Fiction.
I thought the ending was handled especially well and ended up being more thought-provoking than expected. You're given a choice to save a friend on one end of the city or get revenge against one of the main bad guys at the other end. I chose to save the friend which gives kind of a happy, playful ending -- the two remaining big bad guys leave and the Saints go back to being entertainers. I watched the other ending on YouTube. There you're given the chance to kill both big bad guys. It's a very violent, vengeful, serious ending but requires the player to let friends die. The vast differences in the tones of these endings -- silly and peaceful vs. vengeful and bloody -- says something interesting about the players on both sides.
Either way, by the end I was getting headshot streaks and not batting an eye. Not sure what that says about me. I think I will take a break from shooters for a while.
Often I'm brainstorming about the high level content of Flare -- especially the basic story that will tie the game together. I recognize that Flare isn't going to be heavily story driven. It's an Action RPG after all, without even the conveniences of e.g. dialog choices. Spinning a valid story first then plugging in dungeon romp gameplay isn't as easy as I first thought.
I'm starting to think about the content in a different way. We've created a lot of core assets and features to make a game, and it would be really great if we could give all of those assets and features a time to shine. This feels like a bottom-up approach to content design -- look at the small pieces available and think of ways to combine and showcase them. This way of thinking is probably common for puzzle games where it's good to exhaust the unique ways each element can be used. But can this approach be used to make an Action RPG?
- Tile Sets -- for each tile set, consider unique-feeling thematic areas that can be created from the base tiles. Focus on creating distinct shapes per map and vary the mix of tiles used in each. It's important to add landmarks so maps are memorable. Interesting maps will give us strong ideas about world flow and enemy placement.
- Enemies -- for each base enemy type, consider all of the common fantasy variations of that creature. Also consider how powers and stats can combine to create unique enemies that serve a specific battle role. Interesting enemies could have entire maps, quests, and items created around them.
- Items -- for each item, consider how it should be acquired. Bought from a regular vendor or some remote craftsman? Reward for killing some fiend, exploring a side area, or completing a quest? Great items may give us ideas on new quests or bosses.
- Stats -- for each bonus stat, consider a place for it to shine (and to be weak). Prominent example: make sure we have extensive areas where elemental resistance is all but required to survive.
Flare alpha vs. beta
Flare's engine is close to the feature-completeness line. The features we worked on for v0.18 affected flare-game in a few fundamental ways:
- Changed from 4 to 10 equipment slots
- Changed from highly random items to a smaller, more memorable item list
- Adding more armor slots means more absorb, so damage and health has to increase across the board
- With items no longer being mostly random, items need to be specifically placed on enemies, in loot containers, or on vendors.
Some of the core decisions about a game's flow depend on these changes. Right now flare-game's alpha demo is obsolete. It might be possible to rework those old maps and retrofit all the new data into them, but it would be a significant amount of work for that alpha demo's final release.
Meanwhile the engine code for v0.18 is essentially ready. It could use more testing with real content/data but the major features are implemented. v0.18 is also the last scheduled Alpha Release. v0.19 will include the remaining features we want for Beta and for 1.0.
If v0.18 is the last alpha release, it does make sense if we update the alpha_demo one final time. Here's what we'd need to do:
- Set new damage and absorb on all new items
- Set new damage and health on all creatures
- Place all new items in the game (on creatures, containers, or vendors)
- Update all containers to open-once logic
- Add item descriptions to many new items (if possible)
- Playtest a lot. All these new numbers won't magically balance, they'll need several iterations.
The alternative would be to just create new content, which would later be candidates for final release content. One reason this may make more sense is that the flow of the game content is much more important when it's not driven by random items. As an example: we'd want early quests to reward items that are useful to low level players (magic swords/staffs/bows). We'd want to place interesting optional items in side quest areas. It's easier to do that deliberately when creating maps instead of trying to retrofit them into the old maps.
Either way a full game release on the v0.18 engine is a ways away due to the amount of content work needed. Here's one decision I'm not sure about: should I tag the engine as v0.18 so that we can keep working on the next features? I'd say yes, except there are specific expectations from downstream repos. Many flavors of linux are packaging flare-engine and flare-data separately. If we just update flare-engine it actually won't work well with the old data. If we don't really want the v0.18 code to be released yet, it makes sense if we hold off on tagging it.
What I may do is move the goalpost slightly for v0.18, so the code can continue while we work on release content. The main feature left for Flare 1.0 is cutscene support, and I think it's something we can implement now. I've commissioned Flare artist Justin Nichol to work on some digital paintings that will serve as intro cutscenes for the Flare world. The cutscene system will likely also be used for displaying in-game credits.
So I have a lot of content to hammer out no matter what route I choose. Should I create the beginning of a new adventure, with maps designed for the new itemization? Or should I clean up the old demo and get something out a bit sooner, but perhaps messier?
One Game A Month 2013
I am participating in One Game A Month (along with a ton of other devs) during 2013. Flare will still be my main focus, and some of the games I make will use Flare.
I've been having some decent ideas lately, plus some that have been on the to-do list for a long time. I can't sleep so I'm writing these down. I want to share my first solid game idea:
Don't Ride Your Bike On The Highway
When learning to ride a bike growing up, there were a series of rules I had to follow. Early on (tricycle days) it was: don't go on the road. Then when I first got a real bicycle I had to stay between the two nearest light poles. Finally I was allowed to roam the neighborhood as long as I didn't take my bike on the highway.
During those days my brothers and I rode around the neighborhood nonstop. We had to be back home before dark, and night officially started when the power lights came on. During that near-dusk hour we would visit as many friends as possible. Often we would trade (borrow temporarily) toys with other kids, or return toys previously borrowed. I want to relive those days. One of my games this year will be riding a bicycle around the neighborhood I grew up in.
Milestone 1 of the game will be getting the bicycle movement working right. I'll probably use arrowkeys or WASD to do full bicycle movement: up/W to pedal once, down/S to brake, A/left to veer left, D/right to veer right. The camera will stay fixed, so it will kind of be awkward to steer -- hopefully emulating the feeling of first learning how to ride. Throw in some simple sound effects and I think this could feel really solid.
Milestone 2 of the game would be drawing the map and adding basic collision. It'll probably be simple and tile-based. I will recreate my basic neighborhood, but a bit simplified and stylized. At this point it should be simple fun to cruise around a map on bicycle, and maybe that will be game enough.
Milestone 3 would add a Punish Meter, and would really give the game its namesake. There will be zones where you are not supposed to ride a bike, especially along the highway. But also: not in other people's yards, not near cars or houses, etc. Riding somewhere that you're not supposed to be makes the Punish meter fill up. Crashing a bike (into a ditch, or street sign, or parked car, or house, etc) will raise the Punish meter significantly. Riding the bike after dark is also forbidden (start racing home once you see the power lights turn on!). Maybe the game ends when you fill up your punish meter, or maybe you'll just get an earful when you finally do get back home.
Milestone 4, something I may do post-release or as a follow-up game if the above is fun, is adding the toy-trading system. Part of the goal while you're out will be to stop at houses that have kids your age and try to trade toys with them. You take 3 toys from your Toy Box before leaving the house (starting the level), which are randomized. Some toys may be more desirable than others -- more kids want the NES cartridge than the bag of marbles. Trade for better toys to get more points. Also don't forget who you borrowed certain toys from, because you have to return them next stage.
This is all terribly self-indulgent, I know. But it's going to be fun to me. Hopefully someone else will relate.
The Witness quote
Since Braid I have viewed programming as mostly pragmatic: I know what I want to do, and I know what kinds of things I have to type in to make it happen, but for the most part, the interesting mental challenges are in design, and programming is rote execution. Once you have enough programming experience, I think 95% of writing a big program is like this. There have been a few times during The Witness when I spent significant effort solving technical problems where I had no idea what the answer would be in advance, like with the terrain manipulation, but even in these cases I treated the technical development in a very pragmatic way: the goal was to get something that is good enough for current needs, not to design a shining jewel of an amazing technical system (back when I was a younger game programmer, I was trying to make amazing technical systems all the time, and it came at the cost of actually getting games done).
Flare Game thoughts
I've been working on some Flare-Game maps. The tools are good enough now that I can easily make and easily discard maps. I'm trying various layouts to test what's fun, compared to the kind of games I really want to make.
So there's the desire to create several similar games. I can have one very linear deep dungeon romp like Diablo 1, where all there is to do is just dive deeper until the Big Bad at the end. On the other hand, there's also the desire to create a game with a nice interconnected open world -- story progression wouldn't matter as much, instead there would be small quest chains to uncover but mostly just random places to have fun.
Thematically there are various stories I want to tell. I want to tell a story about the fall of human civilization and fighting back against the wilderness. I also want to tell a tale about exile and discovering who you are.
Mixing gameplay styles and story themes seems tough. But I think it's doable in a highly moddable game like Flare. I need to think about one overarching world/theme, and find places to plug in new adventures and campaigns.
I'll be traveling over the next week for holidays. Not sure if I'll be touching Flare much during that time. I may actually use the down time to think about plot and story for the 1.0 game.
Journey wins IGN Game of the Year
Cross-posting my thoughts on Journey from a reddit discussion.
My girlfriend isn't a gamer. I've only ever seen her play New Super Mario on DS (her kid sister and I both have it). I don't think she's even touched a controller with an analog stick before trying Journey. She played through it and loved it. She's even mentioned wanting to play through it again some day.
I don't shy away from challenging games (Super Meat Boy, Dark Souls are some of my recent favorites), but I still deeply appreciate how simple Journey is. From a gamedev perspective Journey does a great job of showing possibilities of what video games can be:
- Good games can be short.
- Good games can be easy, even playable by non-gamers.
- Good games can tell a story without using words.
- Good games can be emotional and beautiful
- Good games can be peaceful (not using violence as a core mechanic)
Fun, and Soon
Flare gets a mention in Bart's dev-corner post over at Free Gamer: "You don't know it, but your FOSS game project has a deadline". The article talks about issues with seeing a game through to completion: make the game playable early, keeping ambitions in check, living with ugly hacked code, and more. I agree with Bart's assessment deeply and it's kicked up a ton of thoughts about game project priorities.
Let's take a look back at ancient history: Flare's v0.03 release video. This was done at the 3 month mark of the project.
Notice how the core gameplay of Flare already exists in that video. Running around a dungeon, killing zombies, getting head-explosion crits with juicy sounds, and mood-setting music. The basic pacing and animation feel for Flare proved to be fun. It was at that point I knew Flare had real potential, and the fun was there for the whole world to see.
The first 10%
A layman might look at that video and think the game was close to being complete. It's one of the pitfalls that cause projects to fail. That vertical slice represented approximately 10% of the work needed to get Flare to 1.0.
If you have a project that takes a full year just to be playable, you probably have a project that will never get completed. It means you'll need a decade of effort to really finish. Meanwhile you'll be surrounded by rapidly changing technology, changes in life priorities, and steadily growing personal dev skills. Few people have the sanity and self-control to stick with a multi-year game dev project without restarting from scratch once or twice.
Here's my completely unscientific guide to scoping a game:
|Time to playable tech demo||Time to polished finished game|
|Weekend game jam||couple weeks|
|Week long experiment||3 months|
|1 month tech demo||1 year|
|3 month tech demo||3 years|
|A year or more||heat death of the universe|
Is it fun?
If you're working on a long game project, there's one major question: is the game fun?
You won't know if it's fun until it's playable. If you wallow for a couple years making menus and random assets but never implementing the core gameplay, you don't really know if all the effort is going to waste. In game dev it's actually important to fail early and fail often. The sooner you know a game idea is bad, the sooner you can abandon it for the next project.
Another major benefit of finding out your game is fun to play: now it's fun to work on. I still play Flare quite a lot because running around the world is enjoyable. I've put untold hundreds of hours into just playing the game. There's no way I would have the drive to work on a game this long if it wasn't simply fun.
Drawing a crowd
You might get some buzz if you have teaser trailers, concept art, and a forum going for your game. But if you don't have something playable you're just blowing smoke. A playable game draws a crowd. A playable game creates fans.
Just before hitting the 1 year mark Flare had combat, loot, leveling up, basic menus, powers, and more. It had only a few maps but some players played it obsessively. Some players sent me screenshots of their epic loot collections and proudly boasted of their 40+ hours of play time. This was at a time when all the content could be cleared in just minutes. Flare was building a strong fan base because we made it playable and fun early.
All throughout Flare's development I always focused on whatever the next most-important feature is to be playable and fun. First combat, then loot, then magic powers, then quests and NPCs. The game world was built from the bottom up. Flare didn't even have a Title Screen until release v0.14, which was 18 months into the project. Aggressively prioritizing milestones helps to keep the project moving responsibly.
Even when the project began I made hard choices to keep the scope possible. I decided: no multiplayer. No 3D. No scripting language. We were not going to be the One Engine To Rule Them All. We were going to do single-player Action RPGs and that's it. If we had gone multiplayer from the beginning, I doubt we would have had something playable within the first year. There's no way we'd be seeing the finish line by now.
That v0.03 playable demo had a lot of "ugly" code. Most things were hardcoded array sizes. Magic constants were everywhere. The game only loaded zombie creatures. There was no way to enter a second map.
But none of that matters. If I instead attempted to engineer all the code into its final state, I wouldn't have had a playable demo until years later. That's not to say I used really terrible code -- I have 20 years of programming experience and know plenty of major pitfalls to avoid. But it certainly was no shining beacon of OOP or design patterns.
And it still isn't gorgeous code. It uses a simple object tree hierarchy. Most classes have a logic() and render(), which in turn call the logic/render of their children. No event driven system here. No MVC. No Event/Component model. In fact one of the code style principles of Flare is "Use OOP as a last resort". There are definite cases that have arisen where we have e.g. a base class and several implementations, but those modules never started that way. We only refactor when a feature demands it.
The code is very simple, but that also makes it very easy to understand and very easy to debug. Flare has a reputation for being surprisingly stable. Any time we discover a major bug, all other development halts until the bug is fixed. After all, the game needs to continue being playable and fun for both devs and fans.
Pay for art early
Making that first playable vertical slice of code is important to find out if the game is fun. You can test this with just placeholder rectangles for art. But if you want to convince non-devs that you have a good idea, you really need that art to shine.
I worked on getting "one of everything" into the game: one tile set, one hero sprite set, one weapon, one creature. I can't quite do everything though. I have no skills in sound or music. Luckily I found sounds from OpenGameArt and other public domain resources. For music OGA helped commission a set of 6 songs to fill out an entire game, starting with that creepy dungeon theme featured in the v0.03 video above. I also commissioned good quality icon art once the inventory menu and loot systems were in place.
If I kept using placeholder art for that entire first year, I doubt anyone would have really taken notice to Flare. Paying early for the art I couldn't create was absolutely worth it.
I know some indie game devs are broke. I choose to work a full-time stable career (not game related) so that I can fund my game dev habit. If you simply don't have that option, maybe you can barter for the early art you need. Code up a portfolio website for a composer or concept artist in exchange for the handful of art pieces you need to get started.
Helping Others Believe
Projects of significant scope -- anything over a year to complete -- are exceedingly hard for one person to manage. I basically lone-wolfed the first year of development, but early in the second year I hit a rut. But thanks to all the work I had done -- focusing on playability, commissioning art, etc -- I had fans. And among those fans were developers. These developers joined the project and helped keep it moving forward.
They brought expertise in that I would have not had alone. I had no plans to support game pads, or language translations, or many other features that are now important to Flare's success. Features that were future dreams (e.g. mod support) were added in during Alpha. Even some artists have begun volunteering art (though I really like to pay artists when possible).
Other devs weren't the only people who started to believe -- we got substantial donations. The total donations to Flare to date are near $5,000 USD. All those donations so far have been put right back into new art commissions. I sometimes think of my early out-of-pocket commissions like investments: they helped grow this project and led to much larger donations down the road.
Flare's success -- external factors
Having a fun, playable demo with good art/music can get you a long way, but it's not always enough. Flare admittedly enjoys success thanks to a few external factors. One, a resurgence in the Action RPG genre (with successful titles like Torchlight 2 and Diablo 3 coming out this year). Two, filling a niche: open source code + fast pace + diablo's darker feel + open license art was something lacking in the Free/Libre community. Third, Blender making it easy and possible for one person to do today what it took a team of artist and render farms to do in the late 90s.
While you can't always control the external factors, you can set realistic goals. Build directly towards a playable vertical slice. Prove to yourself and to the world that your game idea is worth it.
Character Classes and Titles
Flare doesn't use a strict class system. On character creation there are five choices for starting class, but these are essentially default ways to buy level 1 equipment, attributes, and powers:
- Brute: +1 Physical, starts with Dagger and Blood Strike
- Adept: +1 Mental, starts with Wand and Shock
- Scout: +1 Offense, starts with Slingshot and Piercing Shot
- Keeper: +1 Defense, starts with Wooden Buckler and Heal
- Wanderer: no points spent, starts with extra gold
I've intentionally renamed these starting classes to reflect a low level of power. I've gone in and created three entire tiers of titles that reflect the power a character gains as she grows.
|Attribute||Level 1||Level 5||Level 9|
|Mental Defense||Shepherd||Cleric||High Priest|
|Physical Mental||Sparkblade||Battle Mage||Battle Archmage|
|Offense Defense||Watch||Warden||High Warden|
In addition there are two end-level titles. At level 12 a hero would have three attributes maxed and receive the title Master. At level 16 a hero would have all four attributes maxed and receive the title Grand Master.
I earnestly think Flare is going to be something special one day. I appreciate everyone who is sticking around during Alpha, and especially the crew who is working on new features.
If you also believe in the future of Flare -- as an open source iso-action engine -- maybe you have the means to donate. I want one day to provide a vast collection of matching isometric resources to use in developing interesting RPG tales.
FLARE already IS something very special. The music? Sublime. The art? AAA. The community? Engaged. A shining beacon of OSS. (@McFunkypants)
We're working on adding a core set of Magic Items to Flare's fantasycore data set. The goal is to create unique-feeling items that have distinct names and flavor text. Also we're expanding the variety of passive bonuses so that there's not a lot of overlap between items.
v0.18 Engine progress
The main features for v0.18 are near completion. We'll be adding some more Effect types (see Magic Items above) and cleaning up any bugs we find along the way.
Because of the nature of v0.18's inventory and item changes, we're still a long way from having Flare Game data ready for a playable release. The original plan was to get v0.18 out this December. We may go ahead and tag v0.18 on the Engine side and continue working on game content. Some things that need to be done to bring the game back to expected quality:
- Add loot items to each enemy
- Replace random map loot with specific loot
- Add a solid starting set of magic items
- Rebalance combat damage and absorption numbers
- Rebalance level-up stats numbers
Over the last couple weeks I played through Dear Esther and Superbrothers: Sword & Sworcery EP. Both enthralled me.
I can understand why some people wouldn't like these. I can even understand why some people question whether these are games. I had a different reaction: these made me think "wow, video games can be this too."
Also, reading more about Superbrothers led me to this great article: Less Talk More Rock.
Making Loot Less Random
Almost every subsystem in Flare has been written twice: first a version that simply works, and rewritten to make it flexible for the engine. The Loot Drop system is perhaps the last major component of Flare needing this treatment.
Recently I blogged about designing items that are more interesting. As part of that work we reset most of the item list of Flare-game. The old loot drop algorithm doesn't really play well with a sparse item list.
Today we discussed what a new loot algorithm would look like. The more we talked, the more I realized that we need less random and more planned loot. Instead of having a large amount of random, forgettable loot like Diablo, we're going to move towards a smaller, well-crafted, memorable loot list. Some ways this will affect Flare game design:
- Each enemy will have a small custom loot list. A Goblin Shaman will have chances to drop gold, a Mana Potion, a Rod, and maybe some pieces of mage armor.
- Treasure chests and containers will have specific loot, and will only be opened once per playthrough.
- We'll put more unique items in off-the-main-path places to reward exploration.
- Vendors will sell specific items. There will be more incentive to save up gold to buy items.
- We'll add more vendors in remote locations that sell exotic items.
- When designing an item we'll have to consider ways the player can get it. Is it a random boss drop? A specific boss chest item? A vendor item? A hidden map treasure?
Random items can be fun. They especially shine in brutally hard roguelike games, where the random items and maps create the actual fun of the game. Each playthrough depends on the hand that the RNG gods deal. A lot of that was lost in translation in Diablo. The loot there is more about addiction, about reward schedules and skinner box / slot machine / loot pinata gameplay.
But thinking about game dev this long gives me time to think about the kind of games I really want to make. For now I prefer this controlled, hand-crafted experience. The items in Flare 1.0 games will be more like the items in Zelda, or Dark/Demons Souls, or Castlevania, or Final Fantasy. There is a lot of design space in this simple implementation to create good games.
Maybe in the future Flare-engine will support more random content -- maps, items, enemies, and more. I'm not going to rule out that possibility.
From the Inbox
Sometimes people send me great emails about suggestions for Flare. Some are good, some not so much. I wanted to share my favorite email so far about Flare. I love that he's so passionate about the genre and has such specific suggestions.
Things I would like to see in Flare
* A Camera Zoom In-Zoom Out Mode, if the engine can handle this.
* Hot key brings up map with icons
* Voice Dialogue humor
* Scripted Level Thresholds.
* More variety of monsters
* Levels can exceed 200 thresholds.
Strange to see an RPG with no bats.
Most RPG's have up to 300-400 different types of monsters in their games, but Sacred II had over 1,000. That game also had a massive 22 x 22 square mile seamless loading terrain.
But Most of these Commercial RPG games seem to cap their levels and character attributes off at 99-200 with ridiculously high level thresholds.
But if you want to be unique, then if this game engine can exceed the 200 barrier (if the engine can handle it.) then it would be an RPG that would be unique.
Because its all script based, we can add more level thresholds because its a simple text file, That opens up alot of potential for further level scripting to spawn in at random stronger classes of different monsters depending on a certain level threshold that the player reaches at.
But not all the scripting for the game have been done yet. There is only about 10 monsters in the game that have been so far scripted in. But I haven't looked at all the Tilesets yet to see just how many monsters have been done. but I will take a look.
You also need your spiders to start making HISSING noises soon as someone approaches near them.
The Gobblins need to have some voice dialouge too when they detect you are coming near them. And they need to say 'Ow,' start complaining when you are killing them.
So you need to bring human interaction into the game.
You also should allow your Character Attributes to be buffed up to around Level 200 if the engine can handle it.
You also should have your character flashing or charging up each time they get to a level up....
Your monsters need different behavior patterns to make the game more unique instead of the same, predictable rush and charge boulderdash behavior.
Your Map Location Box at the top right corner should be put in a circle.
There's always the option too of using a GUI window editor to do all the work of putting down the tiles for creating new maps and the editor supporting scripting commands. I couldn't find any editor or the map files when i looked in the game directory so the map files are probably inside the main exe.
It depends on what type of RPG you want to create. Whether you want just a small RPG, or what this RPG to be big in scope.
Making a Hack 'n' slash RPG is probably more easier to do because those kind of games rely alot on random seed generators for spawning in the monsters in small groups.
Even though you use tilesets, if you can script your game to spawn in different types of monsters at different level thresholds then the game would have more surprises for the player and not be so predictable with everything spawning always in the same spot.
You should beable to hit a hot key to bring up a portrait of the monster you last killed with all its stats, number of monsters killed.
There should be an option implemented where you can press with the keyboard to bring up a encyplopedia of all the monsters in the game showing all the danger classes and stats. Have you got a graphix artist to create the portraits?
Bascially, as you can see its a lot of work involved in making a good RPG...
There were many good criticisms about flare in this email. I'm genuinely pondering some of these features for the future of the engine.
Rings part 2 (Art Preview)
- gold ouroboros ring
- gold and emerald ring
- silver and sapphire ring
- silver and diamond ring
The rings are now available at Open Game Art - Ring Set - Precious Metals (CC-BY 3.0)
The Practicality of CC-BY-SA for Game Art
I've been going back and forth on some thoughts about Creative Commons licenses for games, especially free/libre games. With license choice there tends to be a divide between ideals and pragmatics. Here's a link to discussion on Open Game Art.
Let me preface by saying that I think the GPL is a great license, and copyleft is an interesting concept for building community art.
Usually when I release art I choose CC-BY-SA as the license. I'm starting to question whether that's practical for several reasons.
First, I assume many projects have to just ignore CC-BY-SA art when browsing OGA. Many of our personal FLOSS games have CC-BY-SA art, but outside of our circles it's probably not very common.
Second, it's really unclear what the license protects. It's probable that derivative works only applies to that piece of art, and not the rest of a game's art. So game engines can likely load CC-BY-SA and proprietary art at runtime. I have no clue what that means for screenshots or video capture of the game engine's output.
Third, I had this magical idea that my art would be easily reused in FLOSS games, and perhaps I could license the art to other games. But there are few existing FLOSS games that already match the genre and art style I'm creating. So I'd see a much wider audience outside. In the past I've given an extremely permissive commercial license for my art -- the game owes a small one-time royalty if the game ever grosses $X. It's just rare for any game to make money though. I haven't made a cent from these arrangements, which isn't a big deal for me. I have had good donations though from people using my art.
So I'm really tempted to start releasing everything CC-BY. I figure attribution is an acceptable requirement.
I'm interested in hearing more perspectives. If you use OGA to find art resources: do you have to ignore CC-BY-SA for your project? Do you find attribution too confusing still?
For artists who submit to OGA: ever released CC-BY art that was remixed/updated and the artist did not release those updates? Ever had CC-BY art end up in a wildly successful project with no return thanks? Anyone else make the transition from CC-BY-SA to CC-BY only?
I'm not trying to convince others what they should choose -- I'm mainly thinking about my own art and what my goals are. Making money? Wide Reuse? Remixing? Each goal has a preferred license.
This is only a concern for a tiny community, I'd imagine. The Share-Alike license seems to fall short for games. Maybe if my art were a more of a 3D game-ready quality I'd prefer proprietary licenses. Maybe if SA was "viral" like the GPL it would be better for copyleft enthusiasts.
I've gone in and updated most of my art licenses on Open Game Art to CC-BY 3.0, except where they contain art from another SA source.
Rings (Art Preview)
Working on some 3D rings to use as inventory icons. I have plans for about 8 rings, but I may add more as I get good ideas.
- silver ring with a celtic design
- gold wrap ring
- steel signet ring
- gold ring with teardrop ruby gemstone
Several Blender techniques make these easy to create. First there are the Spin and Screw tools. Just create the cross-section of the ring shape and spin it in a 360 degree circle to create the full ring. The screw tool was useful in creating the gold wrap ring, as I was able to twist the ring just the right amount to get the correct shape.
Next is the Warp Transform -- I created the celtic pattern and ruby ring cutout on a flat model first, then warped it around the centerpoint of the ring. It's definitely the way to go when modeling an intricate pattern on a perfect cylinder.
Finally the models use Reflection Maps which give the metals a nice shiny look even though there's no actual environment to reflect. I'm using public domain landscape photos from Burning Well for the reflections. I'm using a desaturated image for the gold reflections so that the blue sky doesn't create an unexpected green tint.
New Icons and Items
I just pushed an update to flare-game that adds new icons and resets the entire items file.
Fair warning: All your delicious loots will disappear if you update from flare-game! This is basically a point-of-no-return for save game files. And expect more disruption to come as we start building final game data.
The item file has been stripped down to the bare necessities. We're going to test the most basic items before adding back magical items.
The icon atlas has a new layout. It's organized according to what I expect we'll need to finish flare-game and add a bit of variety for modders.
Soon I'll be adding test Absorb values to the new armor pieces. This will greatly increase the total absorb amount available to heroes. Because of this, we'll have to also increase damage across the board. It'll just take some playtesting to see what feels fair and what feels like solid progression.
Slowly we'll introduce unique magic items. As we do so, we'll be adding any necessary bonus-handling code to the engine.
Now that armor is divided into more slots, we need to introduce new icons to represent all those pieces.
The leather chest and steel chest are carried over from the previous icon set, which were made by Blarumyrran. The new cloth set icons are by Benjaim Schram of CrowLine Studio. The new mage, leather, chain, plate icons are by Justin Nichol.
These icons are now released Public Domain (CC0) at OpenGameArt.
Have item ideas for Flare (the game)? Share them in the comments.
Rather than give the same mundane stats to each item slot, I'm leaning towards having an item slot affinity. Boots will tend to have bonuses that affect movement. Example ideas:
- Boots that grant increased movement speed
- Boots that halve all movement impairment durations (stun, immobilize, slow)
- Boots that halve threat range of enemies (sneaking/stealth boots)
- Boots that grant water walking
- Boots that grant limited levitation (movement across water or pits)
- Boots that grant jumping
- Boots that allow movement across ice (or fire, or acid)
- Boots that allow limited teleport
- Boots that grant haste on cooldown
- Boots that grant a significant dodge bonus (+avoidance)
Some of these would be harder to add than others, but let us devs worry about that. Better to get interesting ideas than to be concerned about any limitations.
Some sample item slot guidelines. These aren't hard set rules, and may overlap some with other slots. The general rule: if the total item (description, name, bonus) is awesome then it's all good.
- Hands slot for attacking, combat, dexterity, manipulation, luck, rogue type bonuses
- Chest slot for defense, health, faith type bonuses
- Leg slot for endurance, stability, storage, possibly movement bonuses
- Head slot for intelligence, focus, disguise, illusion, vision type bonuses
- Weapons for various attack statuses
- Shields for elemental defenses, missile defenses, etc.
- Rings as catch-all various usages
- Artifacts may be reserved for on-use items or major quest type items
Throughout the day (week?) I'm going to add some of my ideas to this post.
- Gloves that increase gold found (thief gloves)
- Gloves that increase crit chance (duelist gauntlet)
- Gloves that increase item pickup and interaction range (mage sleeves, flavored as telekinesis cantrip)
- Gloves with high absorb, low requirements (bracers of defense)
- Gloves with +melee damage (gauntlets of titan strength)
- Gloves with +ranged damage (sniper gloves)
- Gloves with +magic damage (archmage sleeves)
- Gloves with MP restore after kill
- Gloves with HP restore after kill (bloody mail gauntlets)
- Gloves with high bonus accuracy
- Pants that increase MP regen (mage skirt)
- Pants that increase HP regen (bloody mail greaves)
- Pants that reduce bleeding duration
- Pants that reduce poison duration
- Chest that increases maximum MP (mage mantle)
- Chest that increases maximum HP (bloody mail cuirass)
- Chest with high avoidance bonus (cloak of displacement)
- Chest with healing bonus
- Helmet that detects invisible enemies (assuming we add invisible enemies)
- Helmet that detects enemies through walls (assuming we start hiding enemies that aren't in line of sight)
- Helmet that reduces all power cooldowns (mage hood)
- Helmet TBD (skull helmet)
- Helmet TBD (creepy mask)
- Helmet TBD (crown)
- Ring that increases experience gained (signet ring)
- Ring that increases chance of finding items (scavenger ring)
- Ring that increases resistance against one element
- Ring that increases resistance against all elements
- Ring that increases absorb (ring of defense)
- Shield that reflects missiles (mirror shield)
- Shield that hurts attackers (spiked shield)
- Shield that stuns attackers
- Shield with high elemental defense (one for each element)
Work in Progress: Items
With the additional inventory slots we added recently, we'll have to change the scale of most of the combat numbers. Each individual piece of armor can have an absorb amount so the overall numbers need to be higher.
I'm going to switch over to a stripped-down item list so we can figure out what numbers work best. We'll have to do some playtesting and number tweaking with the base values before we add magical items back into the mix.
Some of the old equipment might not come back. Keep this in mind if you're attached to a current save file. It's necessary progress -- something we have to do now in Alpha while we still can.
Items that are interesting
When we reintroduce magic items, we will be focusing on fewer but more interesting magic items. Current flare items are mostly not very interesting -- they boost a single "random" stat. I'd prefer if magic items each had a strong niche bonus instead. Then we give these items unique names and flavor text to further make them feel special.
A typical current flare item:
Shortsword of Destruction
Increases crit by 4
An example equivalent upcoming flare item:
Deals double damage to Undead
When the Warpriests of Sceleria began their mercy killings, they used these morning stars on the most faithful parishioners first.
Powers, Hazards, Effects
We have evolved an interesting system for handling martial and magical powers in Flare. I want to talk about what's going on under the hood -- it's a major focus of the new code features for v0.18.
Powers cover a wide variety of events -- everything from melee attacks to magic missiles to drinking potions. Anything that can be slotted to the Action Bar is a power. But powers are just the definitions of what you can do; once you actually perform a power something new is created -- there are two instance types for powers called Hazards and Effects.
Hazards are usually attack powers manifest on the battlefield. They have a danger area (often a point and radius) that is collision-detected against potential targets. Hazards are classified by their movement type: fixed position, missiles, ground repeaters, etc. The "Shock" spell is a missile hazard that is dangerous until it collides with an enemy or a wall. The "Swing" melee attack is a fixed hazard that is dangerous for a single frame, in a small area where the hero is facing. Currently we sometimes use Hazards to display animations on the battlefield that aren't actually "hazardous".
Effects are powers that are attached to (and affecting) an entity on the battlefield. This power usage is a new to the Flare engine for v0.18. Self-cast buffs like Shield or Warcry are effects that attach to the hero. Attacks that cause debuffs to the target are now also handled via Effects -- the Freeze spell applies a Slow after-effect. Multiple versions of an effect type can be active at once, each with a distinct animation. Example (though we don't have these animations built in yet) -- you can be Immobilized by a Bear Trap that's visually attached to the hero, and also Immobilized by an Entangling Roots spell that's also visible on the ground. The power icon associated with each Effect is shown in the active buffs/debuffs HUD menu.
In summary: Powers are definitions of what can be done. Effects are power-instances attached to an Entity; they can be self-cast, or can be an after-effect of an attack Hazard. Hazards are power-instances that live on and collide with battlefield entities.
Because all these are different states of a basic Power, it's now much easier to expand powers to add new types or variations.
Future Flare project: realism vs. style
First, have a look at these potion renders. It's fun to mess around with higher quality art that could be used in later games:
Though this work is fun, it's making me seriously think about realistic graphics in games. I think games aim for realistic art run the risk of either (A) taking way too much time/effort/funding to get it right or (B) suffering from a lack of art direction. Not to mention the related effects of "Uncanny Valley" -- as art approaches realism our brains only focus on the missing details.
I've been wanting to start creating sets of "realistic" isometric tiles at 1m scale, to be highly reusable in free/libre projects. But will that actually be useful? Is it a foolish goal? Should I find a distinctive art direction and make tiles that have a specific style instead?
If I create an open spec for more artists to add to the collection, is it easier for artists to match a realistic or an abstract style? I assume that an abstract style may mean a lower bar of expertise, if it's all about lower detail.
I was thinking it might be interesting to add Tarot Cards to some kinds of Action RPGs -- maybe as collectables, or quest items, or spell components. Rather than commission a set, I found this old Public Domain set from the 1700s. They're awesome and creepy! I cleaned them up a bit and uploaded them to OpenGameArt.
Isometric Tile tutorial series
I have one popular tutorial on how to render Isometric Tiles using Blender. But it really is an intermediate level tutorial. There's much to learn/teach about isometric tiles everywhere from the beginner to expert levels.
I'm going to create a series of tutorials about isometric tiles, which culminate in how to make entire tile sets for Flare.
The first addition to this series is this new Introduction to Isometric Tiles. It's very beginner level stuff about the hows and whys of isometric projection.
Art Preview: Health Potion
Future Flare projects will feature greatly increased art quality. Here's a preview of the current and future Health Potion.
OpenGameArt seeking Drupal/PHP code volunteers
Much of the success of Flare is thanks to the community at OpenGameArt. Bart K (OGA founder/admin) has put out a call for code contributions to the site. If you have PHP and/or Drupal experience and want to help the Libre game/art community, get in touch with Bart!
Early Estimates vs. Where We Are Now
Time for a brain dump. Get ready for some rambling!
Dig through the archives and you'll see we had grand plans for this stage in the project. A year and a half ago we thought we'd be releasing Flare-Game around now. But here we are, facing the last few Beta Engine releases and no final game yet.
So what happened between now and then?
That early estimate wasn't crazy. On July 7th, 2011 I released Flare v0.14. It contained the Title screen, Load Game screen, New Game screens. It wrapped up the core Flare game into a tidy package that felt close to feature-complete. Many things were hardcoded, there were no mods or translation support, but it was on its way to becoming a game.
It was that mystical "First 90%" turning point for the project. I figured we'd be freezing features shortly after (around Q4 2011) and churning out art to whip out a very simple game (Q4 2012). A year to make a short game (5 hours content) didn't seem crazy when we already had about 2 hours of game.
All that juicy engine stuff -- modding, configuration, etc -- could come later when we made game #2. So I estimated we'd soon be shifting towards making game art and wrapping up a very simple Flare 1.
Go with what you've got
Around that time several great programmers joined the volunteer effort to help Flare (and kept joining through 2012). Meanwhile I'm still the primary volunteer artist, and art isn't easy for me (I'm a coder by trade).
When you have a team of 3-4 eager coders but only half an artist, what do you do? Keep coding of course. v0.15 was all about Translations and Modding support. Not strictly necessary if the goal is to just make one game, but good for the future of the engine. Actually the mods and translation stuff had turned out awesome; if you've ever tinkered with the files you see what potential the engine has. Just take a look at Polymorphable to see how far the engine can go.
Just make a game, stupid
Here's not-really-a-secret: I like writing low level game code. I get genuine pleasure from writing map display code or collision functions. Starting Games is damn near a lifelong hobby of mine. Usually it's not with the intention of actually making a game. Writing little game loops is a simple way of clearing my head. Tiny tech demos are perhaps the most fun part of "game dev" for programmers.
I still constantly create tiny game-like experiments. I can point to several I've done during Flare's development. Here's a Vertical Shooter experiment (playing with movement inertia, bullets, and star fields). Here's a Karma Slot Machine because I wanted to learn HTML5/canvas/js and I've always wondered how to match internal randomness to the reel displays. And here's an Office Chair that you can pilot with arrowkeys for no good reason.
This is the stuff that's fun to me. Some of you like playing games, I like writing game-like code. It's a very happy side effect that Flare is shaping up to be a full game. It gives me good justification for spending all this time on engine tinkering. So when the focus of the Flare project shifted from "make a game now" to "make the engine flex and grow" I wasn't sad.
I actually have completely Finished and "released" two games before. Both were when I was a teenager and had those magical summers with no school and no work. I uploaded them to local BBSes and shared them with friends, but each one was maybe played by a dozen people total. They were primitive but full games. The first was called "Knight's Quest" (very original); it had a simplified first-person "Eye of the Beholder" style display and turn-based combat. The second game "Hack" (also super original) was an overhead game with playstyle kinda like Gauntlet. Both were written in QBasic around 1996-97. Both are lost to time, I think.
Then college. And working life. Throughout that time I made dozens of tiny demos or experiments but never full games. If my goal was "make games!" I'd be horribly disappointed in myself. But that wasn't my goal for years. I'm warming up to the fact that Flare will allow me to possibly actually make games.
So why now? What's the motivation to take Flare all the way to releasing a real game? Damn if I know right now. Let me ponder and get back to that.
Reality checks and renewed timelines
Can't stop the engine momentum now. I'll be scope-checking it soon, but I think it's under control. A lot of Beta cleanup has made its way into Alpha work, but that's okay -- it's all safely happened in parallel to other engine work. When we finally get to Engine Beta we'll have a specific set of core tasks: input file validation, error/warning message standardization, any remaining config file standardization, and documentation. We'll probably be declaring Engine Beta very early in 2013.
I've been working on more art. For the rest of 2012 I'll continue to enrich the current art assets. Around the time we reach Engine Beta the core art assets for Flare should be near ready. I've said such things before and been off target, so take it with a grain of salt.
Getting a new artist on board could help. It's hard to find a volunteer that can match Flare's middling quality. Most artists can't afford to work for free, and I completely respect that. Maybe with more donations we could commission some pieces to help the game move forward. Until then there's just me doing most of the models and tiles. Here's a short list of what I want to get done to finish up the "fantasycore" set of art.
- Dungeon tile set additions -- rubble, furniture, torture devices, better pits, traps
- Cave tile set additions -- mining lifts, bridges, pits, better water, crystal formations, egg sacs, exits
- Grassland tile set additions -- more set pieces, houses, better water, flora variety
- Possibly new animations for the male hero
- At least two new shields, one new endgame armor, a few new weapons
- New icons to match all the new equipment
- New icons for the new powers
- Several new reusable NPCs (should be easy with mix and match and recolored armor)
- New and updated power art
- Consider whether to add new base creatures
That's a good chunk of art, but not insurmountable. I can handle most of it. What I can't do well is the painterly equipment icons (see the current style done by Blarumyrran, similar to the Wesnoth icons). I'll have a learning curve with new power art (how to make better fire? How to make good "swooshes"?) but I can probably pull it off.
Shutting up now
I forgot what I was talking about. I just needed to write down all these thoughts so they'd stop banging around my head.
Oh yeah, timeline estimates vs. where we are now. We're having fun now! And staying incredibly busy. Instead of having a primitive game by now, we have a nice engine. And we'll have a nicer game for it. As long as we're making some progress and not drifting from our original goals (end up with a nice engine; make some games along the way) I think we're in good shape.
Mage and Chain
With multiple equipment slots implemented it's hard not to make new armor styles. I added two essentials: full set for Mage and Chain
Each of these, just like the old armors, are now broken into slots: head, chest, hands, legs, feet. Mixing and matching is satisfying; I tried to make the general styles compatible so that any equipment combination looks interesting.
It now takes me about 8 hours to create a new set of armor, start to finish for two genders. That's in this very low fi style where textures aren't really needed and the rig is already fully animated.
HadiDev on Reddit asked about how I create the sprite layers and handle z-order. I posted a brief overview of my workflow. One day I'll have a tutorial on how to make new armor for Flare. I'm still figuring out the process myself!
Equipment Slots continued
Here's a screenshot of the new Inventory screen. (compare to the old layout)
I separated the old armors into these individual slots. Here's a mockup of the female character equipping slot pieces individually:
Several cumulative code changes are going to allow us to add new equipment slots to Flare.
The current visible equipment slots:
- Main hand (swords or staffs)
- Off hand (shields or bows)
- Body (full body armor)
The new visible slots will be:
- Main hand
- Off hand
- Feet (boots up to the knee)
- Legs (waist down to the knee and optionally lower)
- Hands (gloves up to the elbow)
- Chest (upper arms, torso, optionally lower)
- Head (neck up)
Also we can add a few non-visible slots where items can be equipped but they aren't displayed on the hero sprite. Probably we'll do:
- 2 Ring slots
- Artifact slot
Maybe we'll do more, but that brings us to an even 10 slots.
Bugfix release v0.17.1
If you upgraded to v0.17 from v0.16 and had trouble continuing your save games, this minor release should help.
- Instant-sell items now go to the vendor Buyback tab
- Disable New/Load buttons if there is no story mod loaded
- Prevent crash when binding higher number mouse buttons
- Prevent crash when loading a map with missing layers
- Add helpful tooltips when play buttons are disabled
- Removed -flto compiler flag from default build script
If you installed v0.17 completely new, you can probably skip this update.
After you update, you may have to enable the alpha_demo mod. I've done this by default in the new Windows build. To do this, go to Configuration, Mods tab, and enable "alpha_demo".
Notes for Builders
If you've been building previous versions of Flare for some platform or operating system:
You can create your entire package from the flare-game github repo. The flare-engine repo is mainly for people who want to fork and build a completely new game.
v0.17.1 patch coming
We're working on an update that will fix the issues with using old save games and settings in the new version.
If you want to play now, here are two things to try:
- When you run the game, go to Configuration -> Mods and enable the mod named "alpha_demo"
- Find your save files and edit them. If you see a line that says "spawn=spawn.txt,0,0" just delete that line and save.
If these steps don't work for you, there may be something else we need to patch! Please email me your save game and I'll use it as a test case. clintbellanger at Google's popular email service.
Flare v0.17 Released!
Flare is charging through the remaining Alpha engine work, taking us to this latest and greatest v0.17 release.
- All menus now easy to mod/reskin!
- New Powers tree with traditional tabs and spendable points
- Shared Stash! Collect epics, hoard resist gear, or buff your new characters
- Warp Zone -- fast-travel map to get around the alpha demo campaign
Extended Release Notes
- Code Features
- Menu for showing buffs/debuffs (Justin Jacobs)
- Add Texture Quality option (Justin Jacobs)
- Add item categories for loot tables (Stefan Beller)
- Refactor HP, MP, XP into generic stat bar class (Justin Jacobs)
- Convert remaining arrays to vectors where possible (Stefan Beller)
- Various refactoring, optimization, cleanup (Stefan Beller)
- Move menu options and layouts to config file (Justin Jacobs, Igor Paliychuk, Stefan Beller)
- Move various magic numbers to config file (everyone)
- Refactor Powers Menu to tab/tree/points style (Igor Paliychuk)
- "I shouldn't be coding at 3:30 AM" (Clint Bellanger)
- Refactor menus to use base class for placement/size/etc (Justin Jacobs)
- Powers that spawn multiple enemies (Matthew Krohn)
- Add Shared Stash (Justin Jacobs)
- Add a Buyback tab to vendors (Justin Jacobs)
- Allow NPCs to heal the hero during dialog (Igor Paliychuk)
- Configurable font colors (Justin Jacobs)
- Allow enemies to wander in an area (Justin Jacobs)
- Enable scroll wheel in some widgets (Justin Jacobs)
- Add on_load map event type
- Don't load sound/music if the volume is 0 (Stefan Beller)
- Added pixel-precision to clickable tiles (Justin Jacobs)
- Made equipment slots configurable (Igor Paliychuk)
- Made bonuses work on any item type/slot
- Map Rendering optimizations (Stefan Beller)
- Animation refactoring (Stefan Beller)
- Sprite sheet packing and utility (Stefan Beller)
- Add support for item sets (Igor Paliychuk)
- Add optional Fringe and Foreground tile layers (Matthew Krohn)
- Add load screen to map transitions (Justin Jacobs)
- FPS display option (Igor Paliychuk and Justin Jacobs)
- Configurable buff/debuff animations (Justin Jacobs)
- Split flare into two repos: flare-engine for core upstream dev, flare-game for the actual game
- Support multi-line text in our GetText implementation (Gallaecio)
- Updates to GetText data extractor (Chris Oelmueller, Justin Jacobs, Igor Paliychuk)
- Remove corpses after a fixed amount of time, for performance (Justin Jacobs)
- Optimize text display in several places (Justin Jacobs)
- Art Features
- Use full alpha transparency for the hero art
- Updated Tiled files to use v0.9 features
- Added spike traps
- Added double doors, stairs, and bones to the Dungeon tile set
- Added ambient sound near braziers
- New 320x240 downscale mod
- Added a default mod (engine translations and barebones UI)
- Added Teleporter art and a warp zone map
- Added a lifesteal melee attack, a manasteal magic attack, and a rapid fire bow attack
- Updated floors on all the old dungeon maps
- Updated Liberation Sans font to 2.0
- Greek - Yannis Anthymidis
- Italian - Giovanni Dalla Torre
- Dutch - Bas Doodeman
- German - Chris Oelmueller
- Galician - Gallaecio
- Russian - Sergey Basalaev
- Finnish - Timo Sievänen
- French - Morgan Strauss
In the News
- Flare Released on Desura (Desura)
- Flare: a Free Open Source RPG with Tons of Potential (PC Gamer)
- Flare is a Free, Open-Source RPG for the PC (Kotaku)
Huge thanks to the core programming crew for v0.17 - Igor Paliychuk, Justin Jacobs, Stefan Beller. These guys are all the momentum behind the project right now.
Special thanks to all the bugfixers, bugfinders, translators, and players for making this possible.
Dungeon Tileset comparison
Lately we've been overhauling the classic Dungeon Tileset (which I started making 3 years ago!). I think the difference shows. Here's a v0.15 screenshot vs. a v0.17 screenshot of the same location.
I started F.L.A.R.E (Free/Libre Action Roleplaying Engine) 3 years ago to create a great Action RPG engine that's completely open source. I've long been a fan of games like Diablo and wondered why there wasn't a free game like that with a great modding community around it. I'm a software developer by trade and I had just learned enough 3D art to get myself in trouble, so I started on this ridiculous quest to make a completely free action RPG.
Instead of trying to make an engine that does it all, I decided early on to just try making games. If I reused as much code as possible for each game I'd end up with a highly moddable engine that does one thing well: Action RPGs. But I set some limits early on so that I could actually manage to finish anything: no multiplayer, no realtime 3D. So far that decision has paid off -- three years in and the engine is very close to feature-complete Beta.
Along the way I had a team of amazing volunteers and freelance artist join the team. It's no longer a solo effort by far; this crew has helped push Flare well beyond what it would be at this stage. The engine has been translated into over a dozen languages. It's been ported to many operating systems and even some handheld devices. It's already got a total-conversion game called Polymorphable.
We're still in Alpha and it shows. But we have a ton of momentum. Flare v0.17 is scheduled to come out this Friday. The engine will be very close to Beta at the end of 2012. During 2013 we'll move beyond the current alpha tech demo and create a great classic-style RPG. And we have great plans for the future of Flare.
And you can help. If you like Action RPGs, free/libre software, or Creative Commons art, we'd love to have your support. Use this form to contact me directly.
- Developers: check out flare-engine on GitHub. Create a fork! Drop me an email if you have feature ideas or a task you'd like to work on.
- Artists: check out flare-game on GitHub. Just as with the code, we have a high standard of quality for Flare. Send me a link to your portfolio if you're interested in helping out.
- Translators: we welcome translations of the engine (top priority) or the game data.
- Patrons: you can support Flare through donations which we use to commission new art. All of the art for Flare is also released on OpenGameArt under copyleft-friendly licenses (CC-0, CC-BY, or CC-BY-SA) for use in other projects.
Most of all, thanks for playing. It means a lot.
Flare lead developer and technical artist
Continuing the theme of updating the really old Dungeon Tile Set.
For the longest time I couldn't figure out a good way (artistically and technically) to mark exits on maps. Since very early version of Flare we've been using these boring blue markers. The double doors are much cleaner:
I designed the doors specifically to work inside maps as well:
There are a lot of technical details behind making these doors play nicely with the tile grid. Here's a peek under the hood:
The green dots show where the "door tiles" actually exist. Closed doors actually sit on the back edge of the tile -- this helps ensure draw order is correct.
For open doors, the doors need to be drawn at the same time as the wall they're touching for draw order to work. Because we put the doors at the grid corners, we solve this problem by actually making new Wall tiles with open doors attached.
The map event to open double doors will be a bit long (needing to modify 4 tiles and 4 collision markers), but it should look pretty clean to the player. The double doors open both ways, but the doors have to swing open against a wall (avoids collision confusion). Along with the stairs I created recently, the dungeon doors are really rounding out this tile set.
There will be a String Freeze at the end of the day this Friday, September 21st. This means that no new or changed translated strings will be accepted, so that translators can perform their work.
If you are interested in submitting a new translation or updating an existing translation, the time to start that will be Saturday, September 22nd.
We'll have 1 week for translations, bug fixes (there are no known bugs that require attention for v0.17), and minor art updates.
Planned release date for v0.17 is Friday, September 28th
Separate Engine and Game Repos
It's time to separate Flare into two repos: Engine and Game. But exactly how to do that is unclear.
Apologies ahead of time: I'm going to butcher git terminology here.
We want just the engine in the current main repo. When people want to build a Flare game, they should be able to easily Fork my master repo and add their custom data to the mods folder. Projects like Polymorphable are direct forks of the Flare master -- makes it easy to keep their engine up to date. But currently they have to deal with special filters to ignore all of the Flare game-data.
Should this second repo contain game-data only? Or should it be a fork of the Flare master, just like Polymorphable is (containing code and art)? I think there could be benefits to treating the Flare game exactly like any other project using the Flare engine, in that it has its own source and is often merging changes from the upstream engine repo.
Also: should we entirely prune the Flare game data from the current repo? I mean not just remove, but prune the history? If we don't prune, anyone who clones the engine repo will get all the history of the data, which is a huge amount of data (very large image and music files). If we prune, I'm afraid of what it might do to the tag/branch/commit history of the master repo. Also, if we purged the game-data, how does that affect projects that are already forks/clones?
Now I'm essentially sold on the idea of creating a flare-game fork.
The remaining question: do we just delete the flare game-data from the engine repo, or do we try to prune it? If we don't prune, anyone cloning the Flare engine gets all the data history (very large image and music files). If we do prune, I'm not sure how it would affect existing tags/branches/clones.
I'm creating two new repos named flare-engine and flare-game. The new flare-engine looks lean. Tags and branches didn't make it over. If this purging works, I'm not exactly sure what to do with the old repo "flare". Maybe update the README to note the permanent move. Maybe even delete the repo at some point in the future.
Ethics in Game Design: Respecting the Player's Time
My opinion is going to be controversial here, but it's worth sharing.
There are things that players love, that are addicting, but are poor game design. I think it's borderline unethical to waste a player's time that way.
Obvious example: slot machines. All the colors, flashing lights, sounds, random chances, etc. are perfectly tuned to addict the player. But is a player having genuine fun? They're getting the same addicting chemical releases, but they could be doing something more enriching. Something with substance.
I decided early on to not support Lootris in Flare. That's a term from Diablo where items take up more than one slot, and the player would often spend time rearranging their inventory to carry a few more items (stacking them perfectly like Loot-Tetris, thus the term). Some people find this really "fun". I actually like the larger item icons for art reasons. But just because it appeals to our obsessive-compulsive personalities doesn't mean it's a wise thing to have in a game. If a player doesn't have to obsessively rearrange their inventory, where will they spend time instead? More questing, more combat, more dialog -- elements with vastly more substance.
I think wasting a player's time is a "cardinal sin" of game design. Perhaps I have the luxury to believe that because I'm not trying to addict people to my game, or make a living off some free-to-play model. I just think it's unethical, and I wish we could break gamers of bad habits. We shouldn't be tempted to pour 1000 hours into our favorite game, collecting every item and unlocking every achievement. That player could be experiencing new games instead, new core gameplay with nice substance.
I don't plan on supporting Achievements in Flare. I think it artificially extends a game's playtime, when a gamer could be out enjoying other things (games or otherwise). I don't plan on supporting New Game+ modes either -- again, artificially extending a game. How about we have games that are a few rich hours and done.
I don't begrudge games that do Achievements and New Game+, as I can ignore those options easy enough. But if a game's design is up to me, I really enjoy trimming the fat.
I've been planning several key additions to Flare's core tile sets -- we want game designers to have the proper assets to create interesting maps.
This weekend I created these Dungeon Stairs:
Here are some various thoughts on creating these.
It took me forever to decide on a style for the stairs. I need to get into two habits to fix this. One is fearlessly doodling -- in the age of Ctrl-Z it's intimidating to put pencil to paper and commit something. I need to get over that and sketch way more. Really if I want to improve as an artist I should pick up sketching every day.
Second, hunt down reference material. It's not automatically infringement to take inspiration from history, from architecture, even from interesting concepts of other artists. I need to start collecting more reference material. I have a couple folders of inspirational images for future works (lots of old ruins, and lots of armor designs) but I should expand on that. Maybe even pick up some coffee table books. Perhaps start poking around concept art communities online.
I told myself recently that all new models I create should be of a higher standard -- able to be used in 3D games, even if I only need them on a small scale. That didn't work out here. I finally gave in and took shortcuts for good reasons. Most 3D games can't just take any old stairs and slap them into a game. Stairs, more than most other world objects, are tied very closely to game/engine design. Step sizes have to match animations. Stair height depends on the size of floors. In my simple 2D game I have none of those concerns, so making a complete 3D model would be impossible without proper spec.
After giving in to sloppy modeling, I actually landed upon some new techniques. Notice the brown wall of the stairs. It's basically a flat polygonal area with a simple texture on it. But I've added highlights in the form of random bricks poking out. These are resized cubes with the back face removed, using the same texture as the wall, and placed near the wall (not actually attached in a manifold way). By varying their placement and thickness, it gives the impression of an interesting unfinished wall. It's a nice effect that requires very little modeling time. It might even work in a 3D game asset, unless a particular engine requires manifold structures.
The size and layout of the stairs has a mechanical purpose. In Flare the hero's position is a single 2D point -- the hero doesn't have a thickness/radius when it comes to collision. So you'll notice that walls tend to take up half of a tile instead of going entirely to the edge. This visual trick looks good and keeps collision code very simple.
So when designing the stairs, I finally realized that I needed to account for this wall-edge gap in the design. I decided the stairs needed to take up a 4x4 tile area. This contains a 1-tile perimeter that is "Wall collision" to the engine, except for a 2x1 tile area that is the stairs entrance. That 2x1 area is where the teleport event goes. Because I'm using whole tile collision, it's important for these large tile sets to play nicely with the tile grid and with player expectations.
The look and feel of the stairs is simple, but evolved into a happy accident. I wanted that archway under the stairs, but after adding the prison bars it really gave the piece that "dungeon" feel to match the tile set. The hanging chains add to the theme as well.
Notice the top of the up-stairs is slightly brighter than the floor tiles. The bottom of the down-stairs is darker. These are point lights in Blender added specifically to make them stand out from surrounding tiles. The down-stairs tile uses a "negative" light which casts darkness. It's one of those neat shortcuts possible in 3D modeling that doesn't happen in real life lighting.
I put some effort in to make the steps irregular. Some are moved out of position, a couple are broken, some have a worn off edge. I'm still learning these techniques via trial and error. Next time I think I need to go way further in adding lots of wear and tear onto models like this.
This weekend I was tempted to run out and purchase Guild Wars 2, but decided to stay in and give some love to my Steam library instead. In particular, I finally took the time to play through most of, and finish, Bastion. I realize I'm late to this party, but I'm going to gush on it anyway.
The goddamn art. Jen Zee's work is incredible. This is one of the few times in my entire life that I'm sad to be partially colorblind -- if the game is already lush and beautiful as I perceive, I can't even fathom what it really looks like. Action RPGs definitely don't need to be dark/gothic to be compelling.
There were about three moments during my playthrough where I fell off an edge because it looked like solid ground, but was actually some taller object further away. For the most part they did a good job of making the active areas brighter than the inactive places. I found myself having to pay attention in some twisty areas to determine what was floor.
I like the art tricks used with The Kid. Because he generally always looks the same (same face/hair, same clothes) most of the animations had to only be pre-rendered once. Notice how the weapons are stowed away for many of the animations -- there's no real need to render every weapon for every animation. This makes logistics far easier, and it's less painful to introduce new animations. They can introduce one "falling asleep" animation which doesn't need to include every face/race/gender/weapon/armor combination. If you're out there dreaming of creating a 2D RPG, seriously consider having a fixed main character and what that can do for your art workload.
The Narrator does a superb job of telling the story of Bastion. His voice, and the character, absolutely oozes with style. Importantly, he informs the player of the story without interrupting the action. Normally direct exposition is a bad idea in games (and movies, etc) but the way it's handled here has great charm. The Narrator is also used efficiently to remind the player of game mechanics -- at one point he reminded me that I wasn't using my special skills. In a single playthrough I didn't find the voice repetitive, which was a great surprise.
While the Narrator spells out the details of the story, the overall story is told in every scrap of art and every note of the soundtrack. I love the Mementos in the game -- mostly random items that have a little story attached. I've had plans for a while to use memento items as collectables in Wandercall. Games like Dark Souls put even more emphasis on item lore, with nearly every individual item forming a puzzle piece to the entire world.
In the most emotional scene in the game, the player still has some control. I have a lot of respect for this, instead of e.g. putting the player in a cutscene. I believe mechanics like this are one reason why games have greater potential for emotional impact to the audience than most other storytelling media.
The player doesn't actually need to know any of the story to get through the game. That's a trend in many successful action RPGs, at least ones that I've enjoyed. Not to say that deep dialog or developing relationships can't be in RPGs (they absolutely shine there), but on the action end of the spectrum we can have great games that keep it simple.
The combat itself is pretty fun. At first I worried that it felt a bit too slow or sluggish, but that's mostly alleviated by the roll maneuver. And combat definitely didn't feel slow, especially during the dream/memory sequences.
I enjoy that each creature is weird (not an orc in sight) and serves a unique gameplay role. Well, for the most part -- each creature seems to have several subtypes that change up the way they attack. Sometimes I wasn't quite sure which version I was dealing with until their first attack, but I think that's completely acceptable (it's quite true for my game). I really like the enemy health meter display; it blends so well that I actually didn't notice it until halfway through the game.
I love several mechanics of the combat; some seem to be quite popular in action RPGs. Systems that have an active block button also tend to reward the player for a Just-In-Time block. In Bastion it damages the attacker (even on ranged attacks!!). In Dark Souls it's a parry/riposte mechanic. I really should look into adding just-in-time blocking to Flare.
I love how the game mixes melee and ranged combat well. Even several of the melee weapons could be used in ranged attacks. There were several mechanisms to balance the effectiveness of ranged weapons, particularly timers to aim and reload. The "perfect shot" mechanic is another example of great gameplay -- using time to add depth to maneuvers, rather than adding more buttons.
I'm impressed that so much of the game options were done through the town. The game doesn't need an Inventory button because there's a building where you can switch out equipment. Same with passive bonuses and weapon upgrades. Impressively, they even managed to create Achievements and Difficulty as in-game locations. These are gradually revealed to the player (starting players aren't overwhelmed with options), and it's expertly integrated with the story (the hero is fighting against a cataclysm by rebuilding a tiny town).
The game gets by without a quest system. There's the overarching "gather X MacGuffins" theme, but the player never really has to choose which objective to complete next. I always had 1 or 2 next maps to explore if I wanted some action, or I could fiddle with options in town, or practice weapons at one of the weapon challenge maps. The Narrator adds some purpose and context to the story maps once you arrive, but mostly that's just flavor. I find this interesting. It doesn't seem like a player can really get "stuck" or forget what to do next. There's always just the next dreamlike area to explore.
I admire the game quite a bit, and I plan to return to try NewGame+ at some point. After hearing other people talk about the game, I'm a bit surprised at how light the story is. The game had a strong impact on me, but it didn't require a ton of story details to get there. I'm also surprised at how long the game was, in that it's longer than I expected. I put the game down a while back, hoping to savor and stretch out the experience -- but turns out I was only about 10% through the main story. I want to take Bastion as a challenge, and make Flare and (especially) Wandercall better games for it.
The art of removing features
Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.
(Antoine de Saint-Exupéry, Terre des Hommes, 1939).
[It seems that perfection is reached not when there is nothing more to add, but when there is nothing to subtract]
Besides just keeping the scope reined in, I may actually be eyeing places to remove code for Flare. I believe it's better for the life of the project (and any games that use it) if everything is as simple and essential as possible.
There's an English idiom: "you have to crack a few eggs to make an omelet". It means that to make something, often it requires destroying something else.
We're doing heavy refactoring of the Flare engine right now. Part of that is breaking things in some places to improve them elsewhere. Just a heads-up for people who play Flare directly from the master source on GitHub:
- We're seeing a higher number of bugs than usual (Flare is usually pretty solid). Many of these are known temporary side-effects from major refactoring. But feel free to send any issues to the team in case we don't know about it yet.
- Your save game isn't safe! Example: soon we're going to change the inventory size from 64 slots to either 48 or 32 slots. You might lose items when this change happens. While we're still in Alpha anything is subject to change, and preserving save game data isn't the top priority.
- All this work and very little new content! I know. Engine changes are happening at a rapid pace right now. The closer the engine gets to Feature Freeze (Beta), the better tools we'll have to create final campaign data.
What kind of work are we doing? Most of the engine has gotten a "second pass". Think of Flare v0.14 as the first "rough draft" of the entire game. Since then we've been making everything more flexible: replacing arrays with vectors, moving options to config files, and optimizing various routines. A few main components are still due some changes, and a couple new core features remain:
- New system to handle buffs/debuffs. Their effect, duration, name, icon, and visual display will all be defined in config files. These may end up being new Power types, or separate Effect types (the structure is undecided at this point).
- New system to handle cutscenes. These will be more for chapter interstitials and game beginning/endings. They'll start by using static images with captions and background music.
- The loot system will get significant refactoring. If we decide to combine base items and affixes at runtime, the loot system will get a complete rewrite instead. Undecided yet which route we'll take.
- We're actively working on the equipment slot system. We'll probably add gloves, boots, helm slots and make them appear on the character when equipped.
Tile Set improvements
The current 3 tile sets will get some love and polish before we start making final maps. If you have ideas on what tiles we can add to these sets, please share them!
On my lunch break. I'm sitting down just to play Flare for the first time in a while. And hey: it's pretty fun.
My favorite thing right now (I can't help it) is that now so much is configurable. If while I'm playing I don't like something, I tweak a config file value and relaunch the game. Kudos to the Flare crew, who are doing lots of tedious work to whip the engine into shape.
Map on_load events
I've added a new event type "on_load" that is automatically executed (if campaign requirements are met) when the map is loaded. I specifically needed this to make discovered teleport waypoints remain active. But it'll have plenty other uses: e.g. we can make the Averguard Temple door stay open, or we can make bosses no longer respawn.
Soon I'll be pushing up a prototype of the waypoint system. There will be a new Warp Zone map that takes the player to different areas.
Here it is, at least for the Frontier maps. There's a waypoint in Frontier Outpost, Ancient Temple, and Ydrakka Pass.
Teleport Circle WIP
Going with a simple stone design. I'll add runes on top of it (glowing and non-glowing versions). In game these will take up a 2x2 tile area.
This might be the style we go with for Flare's fantasycore.
It happens to all hobbyist game devs -- life gets in the way. But I'm bouncing back soon. I've finally finished moving in (well, 99%) to my new apartment. Easy walking distance to my office!
I need to get back into art mode. Some new planned engine features are being held back due to lack of assets. This is my list of high-priority to-do assets:
- Teleporter circles (active and inactive)
- Dungeon exits (doors and stairs)
- Cave exits (doors and stairs)
- Trap art (sawblades, darts, fire jets, caltrops, bear trap)
- Chainmail armor
- Full Plate armor
- Kite shield
- Tower shield
Community Spotlight: Polymorphable
[Polymorphable is the first released total-conversion mod/game for Flare. Here's a plug and some great background info from its creators. -Clint]
On the eve of her 16th birthday, Polymorphable's protagonist, Daphne, unwittingly unleashes an ancient evil on her town. It is therefore her responsibility to make things right, and discover a little about herself, her parents, and her village along the way. The primary game mechanic is centered around the FLARE transform power - as she progresses through the game, Daphne acquires four transformational talismans, to turn her into a bat, snake, ghost, and the powerful Juggernaut. Each has it's own special abilities, to fly, pass through fire, spit acid, or strike down a screen full of enemies, and is necessary to progress through the dungeons. The dungeons currently include a cavern, a volcano, a haunted castle, and a snowy peak (it's amazing how much geography there can be around one single village!). In total, there's probably about an hour worth of gameplay here right now, but the modularity of FLARE make it easy to expand that content, and plans are already being hatched for it. Maybe in a couple of years we'll have content to last for twenty hours!
Polymorphable (full name Laurelia's Polymorphable Citizens) is a coming-of-age adventure game designed for the Liberated Pixel Cup contest. The mechanics take from the FLARE engine, the level design is inspired by the first Zelda, and the narrative genre derives from SNES JRPGs like Dragon Quest and Secret of Mana - a young girl, just coming into arbitrarily-defined adulthood, discovers she has a destiny to fulfill.
Along the way, making/modding this game, I've had a chance to really get a feel for the FLARE engine - I came in after the 0.15 release on the Ubuntu app store, and then made a small mod with a few npcs, a couple quests, and some modded enemies. After asking some rookie questions, and receiving some great answers, I felt a little more comfortable with the engine. When Thane Brimhall asked me to work on Polymorphable for the LPC with him, I jumped at the chance.
And man, I obsessed over that for a month. Nothing really brings the power of the FLARE engine to light like trying to design a whole new game from the ground up - and whenever I see more features being added in FLARE, I start trying to think of the new possibilities they unlock. It's also exposed a lot of the ways that FLARE can be improved for modders, which has probably generated a ton of work for Clint and the FLARE dev team. I think that the best advice I can give modders is to try and insert as much as you can into every aspect of your own mods - it's the best way to learn how to leverage all that the engine can do! I think it also offers me a chance to give (hopefully) constructive feedback to the FLARE team as to what works, doesn't work, and could be added to enrich the engine. I know several features got fast-tracked or added by two amazing FLARE devs, Justin Jacobs and Igor Paliychuk, so that we would be able to make the game we wanted.
Overall, I cannot thank FLARE enough for making something so flexible and powerful!
written by Matthew Krohn
I've been quite interested in the LPC ever since it was announced, and since I'm a long time fan and dev of Flare, it seemed natural to want to figure out a way to use the game engine I was comfortable with. Most of the work I did on Polymorphable actually happened before the coding portion of the event started. Key components I worked on included creation of the new UI widgets and adding orthogonal tile support to Flare's map renderer (and fixing associated bugs).
Once the coding portion rolled around, we were armed with new art and a shiny new map orientation. I created the first tileset and built out Laurelia, the city Daphne lives in. But after that, real life came into play, and I was pretty much out for the rest of the month. I was really impressed with the amazing efforts surrounding the project! Matthew Krohn, Justin Jacobs and Igor Paliychuk really picked up the ball I dropped and cranked out a great game.
Naturally, with only a month of work put into it, there's a few places that are rough around the edges, but I'm amazed that a good story-driven game can be produced in such a short amount of time. We plan on enhancing Polymorphable over the coming months and years to make it into a polished (and longer) game.
The real amazing thing behind Polymorphable and the Flare engine that deserves recognition is the flexibility that it grants game-makers. At first glance it's unlikely that players would ever realize that Flare and Polymorphable run on (99.9%) the same code base. Hopefully, this will open the floodgates for many more Flare-based games in the years to come.
written by Thane Brimhall
Community Spotlight: Stefan Beller
Stefan's a major contributor to the Tiled map editor and helped us early on with the Flare exporter. He's taken that Tiled expertise into Flare, where he's optimized the main map rendering routines by orders of magnitude. Here's more about Stefan!
1. Where are you from and what do you do?
I am from North Rhine-Westphalia/Germany and currently I am studying computational engineering master degree. During my studies I learned to like and love free/libre software.
2. What's your dream game?
I really like games having a good atmosphere such as Gothic 2. Also I like hack and slay such as Diablo 2. The one thing which kept me at playing D2 was the fact that you never knew if you had the best items. Hint: See current discussion about flare items/loot
The same applies to Gothic 2, you always found out another way to handle some quest, sometimes you could see it was unintended by design ;)
3. What drives you to contribute to Flare?
The graphics and art. Flare is very promising specially at the art, so I can try to help out at other requirements to be done to make it a great game. So as of now I did not contribute new features, but rather fixed bugs and rewrote subsystems for speed.
4. Any advice for people who are interested in making games?
- Start small.
- Don't loose motivation even when you're stuck at a hard problem, but rather
- Discuss with others. Better yet:
- Join existing projects/communities.
5. Are you involved in any other interesting projects?
Originally I started contributing to The Mana World, which is a MMORPG, but I don't like playing quests made by myself on maps made by myself. So I switched to the supportive projects in the background, such as the Tiled map editor, which is also used by flare developers. That's how I actually got in contact with flare iirc.
Community Spotlight: Justin Jacobs
Justin has been an incredibly valuable contributor for Flare -- he's been a major driving force keeping the pace up on the project. His code quality is impeccable -- I read his pull requests diffs not looking for errors, but to admire his work. Honestly.
1. Where are you from and what do you do?
I'm from central Massachusetts, USA. I'm currently unemployed, but my last job was in IT.[Seriously? Someone hire this guy. --Clint]
2. What's your dream game?
That's a tough question. There's so many great games that I'd love to see more of. If I had to narrow it down, it'd be a tossup between: a side-scrolling Metroid on the same level as Super Metroid; a top-down Zelda on the same level as Link to the Past; or revive Westwood from the dead and make Nox 2.
3. What drives you to contribute to Flare?
I love video games, but I also use Linux. Unfortunately, those two things have always been a bit like oil and water. In my search for games to play on my system, Flare stood out to me. Not only was the gameplay fun, but the presentation as a whole felt of a high quality. My will to contribute to Flare is driven by my desire to see an already promising looking game get that final bit of polish. Plus, just contributing to a free software project is a big self-esteem boost.
4. Any advice for people who are interested in making games?
I'm probably repeating what many others have said, but start small. Games are very complex, and can require knowledge in a lot of different areas. If you can manage to get a simple game together (even a Pong clone will do), you'll have a good idea of what it takes to create a game. Find a small open-source game you like and dig around. See why other programmers do things the way they do. If you feel very ambitious, try to fix something that might be wrong with the game. My initial contributions to Flare were small. But as I got more comfortable with the code, I was able to contribute bigger and better things.
5. Are you involved in any other interesting projects?
I spend most of my time on Flare, but occasionally I'll work on some stuff of my own, all of which I host on my Github.
When will we be able to see a new Flare The Game?
We're very close to having all engine features in place -- just a few more months and it'll be "feature complete". Then the engine enters Beta stage where we'll fix bugs, make more things configurable, add lots more error messages/checks, etc. Some of the remaining engine-level features. We should have these features done before the end of the year:
- Buff/debuff renderables handling
- Passive powers
- Configurable damage types
- Loot table restructure
- Cutscene support
We're in planning stages right now for the final game. I'm working on art for some new game features (traps, teleporters, etc) and we're going to create test maps that demonstrate how all these features work. Armed with those tools, we'll start creating final maps and quests probably next month (September 2012).
The new engine features for v0.17 are basically done now. That went way faster than expected (thanks especially to dorkster and igorko!). So I haven't figured out the new time line yet. I'm pondering September 1st for a v0.17 release. And we should start seeing final content shortly after that.
The Flare crew has been working hard on making all the menus configurable. Now it's much easier to change the layout of any of the menus or add a completely different art style.
Also we're working on two new UI mods. one is called "default", shown here. It is a bare-bones mod that serves as a good clean slate for total conversions. Also it's always enabled; so if you disable all mods, you can still get back into the config menu to turn mods back on.
The second mod is named "320x240" and pushes the UI scale down to that minimum size. This mod serves as a starting point for people who want to port Flare to devices with small displays (below 640x480 in size). We're creating an equivalent game data mod that makes the base tile size 32x16 and scales all the art down 50%. These mods combined should help Flare reach all sorts of devices. We're still working out kinks with this mod but it's helping us find hardcoded or incorrect values in various menus.
RMS discusses Steam on GNU/Linux
I'm back from vacation! I didn't have reliable internet access last week, so if I've missed an important email please resend. Thanks.
Over the last week the crew has been working at making Flare's menus highly configurable. We're working to make the entire interface reskinnable. We're working on the ability to change the menu art, rearrange or hide elements, and move the menu positions on screen.
We're taking a solid first attempt at it, but in the future we'll be refactoring even more code to allow detailed customizations. I want modders to be able to change icon sizes, create more equipment slots, and create full power trees all from config files.
Flare The Game
If you're a player (and not a modder), the real fun stuff is coming soon. I'm working on some new art assets to fill out the existing core set. Some things I'm putting together now:
- Trap art (spikes, spinning blades, darts, fire, etc)
- Teleporter art (waypoints to get to town and back)
- Improved map transitions (e.g. stairs and doors in the Dungeon tile set instead of the blue planes)
- New weapons, armors, shields
Community Spotlight: Justin Nichol
Before Double Fine opened the Kickstarter floodgates on the game dev world, Justin Nichol ran a successful campaign for creating Fantasy Portraits for Flare. Since then he's contributed excellent concept art and model textures.
1. Where are you from and what do you do?
I'm from Southern California. I'm an aspiring entertainment designer and illustrator. I'm also a free culture advocate, game designer, community organizer, amateur coder and fitness buff.
2. What is the first video game you remember playing?
It sounds cliche, but I think the first time I ever played a video game was when my mom brought up home a Nintendo with a copy of the original Mario Bros.
3. What drives you to contribute to Flare?
I love fantasy, I love gaming, I love free culture/software and I want to help create a participatory entertainment culture. Beyond that, Clint is a stand up guy who really cares about the quality of what he makes, and listens to his contributors and community.
4. Any advice for people who are interested in making games?
I can only really say what I know about concept design, which is to banish the idea that you need talent at a thing to do it well. It's cliche, but practice is many times more important than talent, and if you stay humble and work you will get better consistently.
5. Are you involved in any other interesting projects?
I am the founder of a tabletop games collective called Black Flag Games, we're currently publishing a boardgame called To The Barricades, co-developing a mech combat card game called Subversiva, and a great narrativist story game with social commentary called Kinfolk. I've also contributed to Battle for Wesnoth and PARPG.
Community Spotlight: Igor Paliychuk
Igor has done a lot of work with the Configuration menu in Flare. Beyond that, he's added a really interesting feature that we plan to showcase more in future versions: the hero can transform into any enemy and gain use of their powers. Imagine transforming into a Fire Antlion to gain massive fire resist, or a Wyvern to be able to fly over water and pits. Here's more about Igor!
1. Where are you from and what do you do?
My name is Igor Paliychuk, I'm from Ivano-Frankivs'k, Ukraine. I'm working as system administrator, my hobby is Software localization (into Ukrainian/Russian) and a little user mode coding.
2. What's your favorite game or genre of games?
I like 3D actionRPG games with good scenario line. For me classics of the genre are games from Gothic series, Two Worlds, Fable: The lost Chapters. Games like these can fully move you to another reality, and graphics here doesn't stand at first place.(Even now IMHO Gothic I/II are good games.)
3. What drives you to contribute to Flare?
Well, I'm for free software, and I'm for free 3D actionRPG games, though developing such games is very time-consuming. But 3D isometric game as Flare can became also as impressive as fully 3D, as i said graphics quality doesn't stand here on first place. Even now we have some closed source fully 3D games, that look like isometric(Diablo3, Torchlight). I don't get why developers write 3D models and don't use them fully, showing only part of them. So that's why I'm contributing into Flare: we can make awesome game, that can stand near current closed source actionRPG games.
4. Any advice for people who are interested in making games?
Just do something you like. That's the main idea! And share it with people.
5. Are you involved in any other interesting projects?
Mainly in localization. E.g. Battle for Wesnoth, Hedgewars, Summoning Wars, VDrift, HolySpirit, ReactOS, Lazarus IDE, KVirc and other usefull software. You can check full list here.
Flare's new site layout
I tweaked the site layout a bit. It coincides with our shifting focus in Flare's development -- moving from a mere dev blog to a site all about Flare The Game. Hope you like!
The main feature of this new design is to prominently display a Flare "trailer" and download links from the front page. Right now I'm embedding GameBoom's v0.16 video. But I'd really like a short (maybe 1 minute?) trailer type video for that space instead. It doesn't have to be very flashy (especially not yet, before much of the game's plot is nailed down). It's something I might create later when I have time, but if someone does a great fan trailer I'd post that instead.
Finally you'll notice the new set set of links (pictured above) under the main download buttons. These are Flare builds/repos maintained by third parties. If you maintain Flare on another OS/platform/device and want it listed here, please email me with the info!
Quiet week coming -- vacation
I'll be out of town from July 14-22. This blog may go quiet during that time. The first real break after a release is so nice -- I get to refocus and brainstorm about game ideas for the future.
GitHub activity might slow down too. But, if you're interested in helping Flare grow as an engine during this time, I highly recommend you check out polymorphable, an LPC entry by pennomi (Thane Brimhall). Every new game made with Flare makes the engine that much more flexible, robust, and proven!
Community Spotlight: Brandon Morris
If any particular song in Flare is bringing you back to the good old days of dark/gothic dungeon crawl goodness, you're probably hearing the handiwork of composer Brandon Morris. Here's his spotlight!
1. Where are you from and what do you do?
I was born in Naples,Florida USA. I have been in the Dallas area for about 8-9 years now. I am studying Audio Engineering and Commercial music. Throughout Highscool I was a big music guy and took a lot of AP classes in theory but when college came, I began to get into sound design and audio engineering.
2. What is the first video game you remember playing?
First game for me was Probably Wolfenstein on floppy disk. But I didn't become severely obsessed with music in video games until Warcraft : Orcs and Humans and Warcraft II: Tides of darkness.
3. What drives you to contribute to Flare?
Since I didn't hop on Flare till after there was a nice array of content. I saw how it was doing the Isometric art style that I always loved in old blizzard games. Matt Uelmen was also a very high appreciated composer in my eyes. So I wanted to live my little dream with this game. Not to mention Clint is actual fun to work with. Which is highly appreciated in the Open source/Free Libre community.
4. Any advice for people who are interested in making games?
This might sound cliche but, make games because you love it. On top of that, Take work where you can find it. Regardless if the game is not really your style. If you have the ability to help out, help out.
5. Are you involved in any other interesting projects?
Not at the moment. Majority of the time I just help out where I can on Music Forums, Unity Forums, and sites like OGA. Been looking for projects recently.
New Address: flarerpg.org!
Flare has finally moved to a dedicated domain. All of the old links should work (301 permanent redirect) but it's a good idea to update: http://flarerpg.org
The blog is also sporting a new comment system powered by Disqus. I'll be adding more features to the site soon, in addition to changing the layout of the starting page.
Community Spotlight: Thane Brimhall
I'm starting a new occasional blog entry called Contributor Spotlight. Flare is supported by a great group of volunteers and they deserve some public kudos!
Today's spotlight is on Thane Brimhall. Besides having a ridiculously awesome name, he's been a contributor to Flare for over a year now.
1. Where are you from and what do you do?
I'm an all-purpose software developer (web, desktop, and mobile apps) in Provo, Utah, USA. I primarily use Python as my programming language.
2. What is the first video game you remember playing?
I think the first video game I remember is Treasure Cove - a learning game where you swam around in the ocean solving basic math and science questions. Looking back at it, it was horrendously repetitive - the same three stages over and over, hundreds of times, until you gained enough points to "win" the game.
3. What drives you to contribute to Flare?
Two of my favorite things are free software and games (whether real or virtual). I'm notoriously bad about dropping video games as soon as I've beaten them, (including Diablo II), but Flare keeps me hooked no matter how many times I've played the same content. And trust me, I've played the Averguard Temple hundreds of times. I've dabbled in other FOSS projects, but I really think the rapid pace of development makes Flare a consistently rewarding game to work on.
4. Any advice for people who are interested in making games?
If you're looking at starting a game, I'd recommend not repeating work that other people have already done. It's easy to get burnt out when you're trying to get the stupid map to render. If you don't have a good reason to start from scratch, I'd branch out from an already existing project. But even with a built engine it's easy to get burnt out, so the biggest piece of advice I have is "never give up."
5. Are you involved in any other interesting projects?
I'm currently working on a Liberated Pixel Cup entry based on the Flare engine: https://github.com/pennomi/polymorphable. Other than that, I've done a (very) little bit of work on ParselTONE, a Python interface for FreeSWITCH (an internet telephony server).
Flare v0.16 Released!
Flare version 0.16 is ready for playing and modding! Originally slated as "Advanced Enemies", this update actually includes a wide variety of engine updates.
- Improved enemy pathfinding, including flying creatures
- Summon or transform into enemies!
- Config menu including keybindings, mods, and more
- Orthogonal map support
Extended Release Notes
- Code Features
- A* Pathfinding (Nojan)
- Enemies now block movement (Clint Bellanger)
- Enemies, powers, and map events can spawn enemies (Clint Bellanger)
- Floating Combat Text (Thane Brimhall)
- New Widgets: tabs, check boxes, scroll bars, sliders, and more (Gallaecio, David Bariod, Justin Jacobs)
- Config Menu, including keybindings and mods (David Baiod, Justin Jacobs, Igor Paliychuk)
- Flying Creatures (Clint Bellanger)
- Patrolling Enemies (Thane Brimhall)
- Transformation/Shapeshifting into any creature (Igor Paliychuk)
- Configurable XP per level and per creature (Thane Brimhall)
- Configurable sell price for items (Justin Jacobs)
- Orthogonal Map Support (Thane Brimhall)
- Powers can target neighboring squares (Justin Jacobs)
- Intramap teleportation events (Clint Bellanger)
- Optional Permadeath (Thane Brimhall)
- NPCs can be both Talkers and Vendors (Justin Jacobs)
- Animated Tiles (Igor Paliychuk)
- Gold Autopickup (Justin Jacobs)
- Art Features
- Widget art via RPG GUI Construction Kit (Lamut)
- Wyvern art (Clint Bellanger and Justin Nichol)
- Wyvern sounds (Brandon Morris)
- Antlion and Zombie summoning animations (Clint Bellanger)
- New Minotaur animations (Lamut)
- Cursed Grave creature (Clint Bellanger)
- Female Merchant Vocals (Holly Daniel)
- Creepy Forest theme music (Brandon Morris)
- Ancient Temple map (Clint Bellanger)
- Full set of Kickstarter portraits (Justin Nichol)
- Handle systems without sounds (Justin Jacobs)
- Joystick handling fixes (Justin Jacobs, Igor Paliychuk)
- Multi-line gettext support (Gallaecio)
- Movement around corners (Daniel Santos)
- Disable unusable powers in the action bar (Daniel Santos)
- Multiple Event Components per line for Tiled compatibility (Thane Brimhall)
- Unspent attribute points shown on the Character Menu (Igor Paliychuk)
- Threat range and entering combat fixes (Justin Jacobs)
- Close vendor bag when closing inventory (Justin Jacobs)
- Faster previews on Load Game screen (Justin Jacobs)
- Isometric Rendering optimizations (Stefan Beller)
- Misc fixes (AI0867, AMDmi3, CmPons, manuelafm, runtime-x86, matthiaskrgr)
- French (Morgan Strauss)
- German (Thomas Glamsch and Chris Oelmueller)
- Italian (Giovanni Dalla Torre and Andrea Ranaldi)
- Russian (Sergey Basalaev)
- Slovak (Miro Jánošík)
- Ukranian (Igor Paliychuk)
Love Free/Libre games? Love old school Action RPGs? Think your favorite single-player game shouldn't require always-on Internet connection? (ahem). Well, please support us here at Flare! Here are ways to help:
To show off the new animated tiles feature, the lit braziers are now in motion.
Last Call For Translations
Last call for translations for inclusion in the v0.16 release!
This week I've taken the time to re-render some of the oldest assets with updated lighting. This includes 3-point lights, ambient light, ambient occlusion, and rendered using the smoother Mitchell-Netravali anti-aliasing. Where possible I left the assets using full alpha transparency.
The difference may be subtle to most, but it's an important step up in quality.
Stop! Collaborate and Listen
String freeze! I got one new map added in time, a small Ancient Temple. It's an area to help bridge the gap between the goblin camp quest and the Averguard hold.
Sergey Basalaev has regenerated the .pot files and submitted the Russian updates.
And we're ready for new translations! The best way is to submit them as a pull request on GitHub. But I'll gladly take them other ways -- feel free to email your .po files to me at clintbellanger at gmail.
I'm adding monster spawners to Flare. You've seen these in classic action/RPG games: they constantly summon enemies until you destroy them. This one's a Cursed Grave that spawns zombies.
Flare v0.16 RC 1
It's still early in the release process -- we have a good amount of game data, art, bug fixes, and translations before actual release. But enough of the core features are there for testing.
Features to look for in this version:
- Improved enemy pathfinding
- Enemies can no longer stack in the same position
- Hero can no longer move through enemies
- Flying creatures added (there is one Wyvern in the Plains)
- Config Menu with plenty of options
- New portraits during character creation (not all have matching heads yet...)
- Permadeath option when creating a character (how far can you get?)
- Floating combat text
There are plenty of other neat features under the hood, but haven't been put to use yet. Examples: enemies can summon other enemies. Enemies can be spawned from map events. The hero can transform into an enemy and gain their powers temporarily. We'll try adding some of these before release.
If you find bugs, please submit them to our GitHub issues list.
The code features for v0.16 are complete. We have the next two weeks to focus on bugs and game data/art. String Freeze is still scheduled for June 30th.
I placed a wyvern on the island in Frontier Plains. Notice he'll fly right over the water. We'll try making at least one new map where Wyverns have a huge advantage thanks to flying.
Version 0.16 nears! A suite of very nice engine polish is just around the corner. Some things to look forward to, if you aren't already playing from source:
- Much improved enemy pathfinding
- New! Enemies move around each other, block paths, surround the hero
- Clean, user-friendly config menu with many options
- Art additions! New wyvern, minotaur animations, female vendor voices, many new portraits
- Under the hood support for unique enemy types (e.g. bosses)
- Transformation! Change into creature form and use their special powers
- Support for orthogonal tile sets!
- Lots more ...
I'm tentatively proposing June 30th as the String Freeze Date, with July 7th as v0.16 binary release. We have only a few more tasks to get through, but if those get sticky we may move those dates back one week.
Flare's current alpha art (called "fantasycore") is limited. If you've been following the blog you know that we're working on higher scaled art. In the current art each tile represents about 1.5m x 1.5m; the new art will use 1m square.
With everything being about 150% larger, we need to put a lot more details into models. So most of the old art can't simply be rendered upscale. That's okay though -- we've learned so much in the last couple years that we can create much more polished work.
Here is a preview of some new Iron Weapons. It's mostly me playing around with a theme set of weapons (those serrated edges, the two-tone metal). Some thoughts about the designs:
- Exaggerated silhouettes. We're dealing with a very limited number of pixels, even if we up the base tile size to 128x64. So having weapons stand out by their overall shape is very helpful.
- These would be low level starting weapons, classic Iron gear before moving up to something like steel or silver. Even if they're for starting characters, it's important for equipment to look rad.
- I've just covered texture groups with simple image textures. Good hand-painted detail could make these great even for a modern game, but that detail (and work) would be wasted effort for our purposes.
- All of these are manifold, clean, and very low poly. Between 200 and 400 tris each.
We're also experimenting with better light setups and more frames of animation. Here you can see the iron longsword in the hands of the new male hero model. I like the back light and hope we can make it look correct in game.
It's rendered at 2x scale (128x64 base tile size). It holds up, and is actually a decent size on a 1080p display. I'll be pushing for all of the new art to look nice at this scale, and most likely we'll allow the entire game to be played at this resolution.
Is there a point to having so many similar melee weapons? They might not matter much in the current implementation, but we're working on ideas to make a variety of melee weapons interesting. For instance, we could give all swords a bonus to parry; all hammers a bonus to stun; all axes a bonus to bleed.
I plan on experimenting with weapon attack speeds; though it may be done with a handful of fixed speeds (slow, medium, fast instead of a continuum of speeds). That brings a nice dimension to weapons. Big slow weapons would be useful for efficiency, as you're putting out similar DPS for less MP spent. Small fast weapons would be useful for triggering procs more often.
And it's more interesting to see a variety of drops and visual looks on the hero. Right now in fantasycore we went with the bare minimum equipment to get the engine going, but we can have fun expanding the set of weapons later. With the introduction of many different sets of weapons we can add a more interesting weapon progression. Instead of linear upgrades based on size (dagger, shortsword, longsword), we can have a full suite of weapons every few levels (with updated materials or themes). Currently you need 4 Physical to use a longsword; in the future you might need 14 Strength, 9 Dexterity to use an Obsidian Katana.
Fixed the RSS feed. Had an unescaped ampersand in a blog post. That's what I get for using a roll-my-own ultra minimalist blog software.
How minimalist? Let me show you.
Liberated Pixel Cup!
The style guide and base assets provide great starting examples for map tiles and characters. So immediately I started thinking of the extra art (besides UI stuff) needed to create a game.
So I made some coins (see them at OpenGameArt)! Here's a preview of how the gold coin looks over a screenshot of LPC tiles.
Developer Discussion on v0.16
Flare devs/contributors, time to discuss the upcoming release of v0.16. Let's put together a TODO list, figure out what can wait until v0.17, and assign remaining tasks.
A note on Wandercall
Wandercall is the name of the 2nd game based on the Flare engine. All the lessons learned will be poured into that game to improve it in every way. Have a peek at this 2X scale art test to see how a Flare-based game could look.
Wandercall won't just be an art reboot of Flare. We will be spending a lot of time in pre-production with a vertical slice of art and gameplay. The goal is to work out animations, combat mechanics, etc. to make a much smoother and more professional experience. We'll test adding acceleration to movement and transition animations. We'll experiment with an active combat system that isn't just button mashing. We'll work out combat numbers to make progression feel engaging. We'll figure out the technical aspects to create more visual armor slots (probably head, chest, hands, feet, plus held items).
We'll iterate on that vertical slice until we are sure that we can achieve a great game that will shine for years. Once the specs are nailed down we'll create a deluge of art. We hope that the new quality art will attract highly-skilled artists to flesh out a world's worth of content.
Flare the Game
Soon we'll be discussing how to turn Flare's current content (the "fantasycore" art assets) into a full game. Let's get v0.16 out the door first.
On Diablo 3
The last two weeks have been a blur for me. Conference, funeral, lots going on at the office, and Diablo 3's release. I'm itching to get back to Flare development soon, but taking a break to enjoy some D3 is nice.
Here are my thoughts on Diablo 3.
Blizzard still has a way of polishing games that is second to none. What I mean is that the game feels professional and finished. There are tiny interface and feedback tricks that action RPGs (and many other games) will be copying for years.
I'm a bit surprised at how actiony the game feels. Maybe I'm not remembering D2 well, but everything here feels over the top. The game certainly makes you feel like a badass that can mow down hordes of enemies (even rewarding instant bonuses for Massacres of groups of enemies). It's a long way from the lonely wicked survival feeling that Diablo 1 had.
The sounds in D3 are excellent. Even regular weapon swipes can't be just a swooshing sound; it has this sort of "metal-on-metal" slicing sound that doesn't make sense but feels awesome.
Most of the models are incredibly low poly. It's really surprising. It seems more of the rendering (time) budget is spent on mist/lights/particles instead, and poly count isn't the main bottleneck. Kind of interesting really. I think D3's art style is fine (I enjoy the painterly feel of some areas) but they certainly could have pushed more polys if they wanted. It makes the game feel a bit dated. That didn't stop Diablo 2 at the time though.
I'm mixed on the art direction. Some of the higher end weapons/armor look a bit gaudy. But I thoroughly enjoy all of the environments I've seen so far. Even the "mundane" dungeon areas that others might find boring. I found myself taking note of all the tiny features of each tile set. I really liked three areas of Act II: the oasis, the sandy dungeons, and the ... sewers? Each had interesting layers of features that showed some great attention to detail. I'm blown away that some really nice art was only used in very small segments.
I find the number of stats overwhelming. Will anyone actually care about the range for picking up gold and health? Does the game really need both % lifesteal and N lifesteal?
I really dig the action bar. Essentially I was slotting four cooldown abilities of various lengths, a main attack that built up my power, and a secondary attack that spent power. I think that's the way to go for designing powers: 2-3 main powers that juggle your resource levels and 3-5 cooldown abilities for varying occasions.
I like the cooldown on potions. I find the health globes intriguing. Those features definitely help to normalize the balance of difficulty (can't just chain chug potions).
The main story is very pedestrian. There's far too much dialog stating the obvious. It causes theses Prime Evils to really feel one dimensional. E.g. the Demon Lord of Lies did a poor job of manipulating anyone in the game, much less me as a player. The companion/vendor stories are much more interesting so far.
The game's fun. I can't stop thinking about it. Something about solid action RPG gameplay gets me, even when I know I'm obviously in a Skinner box.
It's disappointing that there is no offline single player. I always played Diablo 1 and 2 single player. So far I have no interest in the Auction House nor in coop play. Hell, I'm constantly tempted to dismiss my companion so I can maybe feel that lonely dread that came from Diablo 1. I think a real money auction house is weird.
It makes me feel that Flare has a niche though, providing a solid DRM-free single player experience for Action RPG fans. Blizzard is definitely set the polish bar pretty high though, and it's intimidating to think that people will be comparing their Flare experience to the juggernaut that is D3.
I'll be away on a work conference the rest of the week. If this space goes quiet for a while, that's why.
In the meantime, check out the latest master branch for interesting new features.
- Launch flare with the flag --azerty to default to an azerty keyboard
- Skeleton of a config screen, join our discussion here on implementation details
- Permadeath option for new characters!
- Configurable XP for level-up and creatures
- Configurable sell prices for items (besides the default %)
'Twas brillig, and the slithy toves Did gyre and gimble in the wabe; All mimsy were the borogoves, And the mome raths outgrabe. "Beware the Jabberwock, my son! The jaws that bite, the claws that catch! Beware the Jubjub bird, and shun The frumious Bandersnatch!" He took his vorpal sword in hand: Long time the manxome foe he sought— So rested he by the Tumtum tree, And stood awhile in thought. And as in uffish thought he stood, The Jabberwock, with eyes of flame, Came whiffling through the tulgey wood, And burbled as it came! One, two! One, two! and through and through The vorpal blade went snicker-snack! He left it dead, and with its head He went galumphing back. "And hast thou slain the Jabberwock? Come to my arms, my beamish boy! O frabjous day! Callooh! Callay!" He chortled in his joy. 'Twas brillig, and the slithy toves Did gyre and gimble in the wabe; All mimsy were the borogoves, And the mome raths outgrabe. - Lewis Carrol
Isometric Tiles Tutorial Update
By popular demand, I've updated my Isometric Tiles Tutorial for Blender version 2.6.
Is an "Accuracy" stat appropriate for action games? Even RPGs which are heavy action?
Classic D&D had an "attack" roll separate from a "damage" roll. The attack roll simulates the chaos of combat and relative skills of the attacker and defender.
But action games can actually show all of that chaos. The player himself gains combat proficiency. Creature AI can act and react defensively. There's no need in action games to abstract attacks into a random chance.
Cubicle mini tile set
The Cubicle tile set is released under the terms of CC-BY-SA 3.0 (or later). If you are interested in using this tile set under different terms, please contact me.
Have another peek at some rough Cathedral art.
Tile Set Definitions guide
If you're trying to understand how Flare's tile sets work, check out this article on Tile Set Definitions.
I plan on putting together more tutorials as time permits.
Cathedral tile set mockup
A few months ago I had this grand, weird idea for a Cathedral tile set. It's a relief to finally be able to show this mockup. Click to see full-size.
This is a sample of the art direction I want to take my next Flare-based project.
Flare art featured in HTML5 tutorial
Check out this tutorial series by David Ang called Isometric Game Development in HTML 5 Canvas!
Flare now available in Ubuntu Software Center [12.04]
Exciting news by way of Ubuntu Vibes - Flare is now available in the Ubuntu Software Center! Quote:
The good news is that Ubuntu 12.04 has latest version of the game in official repositories, so just hit Software Center to install the game.
Wyvern Elemental Skins
The new elemental wyvern skins are complete! I've added the art sources to Flare's github as well.
A Wyvern for each Element
Old palette-based games could do easy (sometimes ugly) color swapping at runtime. But carefully painted, pre-rendered color options look great. (Thanks Justin!)
- Top left is the Air Wyvern which uses lightning/wind based attacks
- Top right is the Water Wyvern which uses water/ice based attacks
- Bottom left is the Fire Wyvern which uses flame based attacks
- Bottom right is the Earth Wyvern which uses poison based attacks
It'll take me a while to render all of the Wyvern animations for each of these (I don't have a good single-click workflow yet). They'll be on OGA and in GitHub as soon as they are ready.
Here's a palate-cleanser sized game. I put this together in 24 hours to learn about new web game tech.
Focus: Game or Engine?
I'm pondering the focus for the near-future of Flare. Please add your opinion to the discussion.
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.
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).
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").
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.
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.
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.
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.
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".
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.
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.
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.
Experimenting with Wyvern animations.
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:
- Bronze Dungeon
- Mossy Gardens
- "Vertical" Town
- Aristocrat and Prole
- Statue Knight
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.
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.
Paypal Donate button added
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.
Portraits by Justin Nichol
Congrats to Justin Nichol, who has finished the Creative Commons Fantasy Portrait Marathon! Soon all 30 portraits will appear as NPC options in Flare.
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:
- 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!
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:
- 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.
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.
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
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!
Flare v0.15 "Translations and Mods"
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)
I'll be without consistent Internet access until Wednesday night, Dec 21. I'll catch up on Pull Requests etc. then. Thanks for understanding!
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.
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:
- mods/fantasycore/languages/engine.pot - UI text. If you can only translate one file, I suggest putting a priority on this one. If players can read the basic UI they can at least play some of the game.
- mods/fantasycore/languages/data.pot - Core data text. Second highest priority translation file, though it's a big one (lots of item names, in particular!)
- mods/frontier/languages/data.pot - Proper names and a small amount of quest text for the overworld areas
- mods/averguard/languages/data.pot - Text for the Averguard Keep quest area
- mods/living_bones/languages/data.pot - Text for the Living Bones quest area
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!
Flare v0.15 RC 1
Playing on Windows? Try out the Release Candidate for Flare version v0.15.
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.
- 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
Every time we add a lot of new content, everything we've done as far as balance goes out the window. As time goes on, though, this balance will start to settle into the right groove.
Many of the current monsters are too easy or boring, so I'm doing a small revamp here. Mainly this is needed because the content will be more spread out: rather than cramming levels 1-6 into the same old dungeon+cave, we now want different areas to contain a small window of creatures.
When possible, we want creatures to be unique rather than just having more stats than the last creature. So here's what we're trying.
Problem with goblins was they were just too easy. Not scary at all.
- Goblin (level 1) - just hops around and stabs, more hp than before
- Goblin Charger (level 2) - runs fast, special attack that causes bleeding
- Goblin Charger Elite (level 2) - rare and more powerful version
- Goblin Spearman (level 3) - throws spears, so more dangerous to more players
- Goblin Spearman Elite (level 3) - rare and more powerful version
- Goblin Shaman (level 4) - casts shield and shock
Problem with zombies is they didn't feel like zombies, just walking cannon fodder. Now the low level zombies have a much more devastating bite attack, and the higher level zombies have intimidating abilities.
- Rotting Zombie (level 1) - more hp than before, small chance to bite for big damage
- Zombie (level 2) - more hp, much higher chance to bite (possible to one-shot a player)
- Zombie Brute (level 3) - high hp for its level, fast speed and very fast attack rate
- Icegrip Zombie (level 4) - melee attack causes the player to be immobilized for 5 seconds
- Bloodthirsty Zombie (level 5) - melee attack heals the zombie for 50% of dealt damage
The skeletons were decent, just need some number tweaking and maybe some power shifts (e.g. take crossbows away from regular skeletons, place more archers). Eventually the skeletal warrior should block and counterattack; that will make him more interesting in v0.16.
- Skeleton (level 2) - much more hp, no ranged attack
- Skeletal Archer (level 3) - generic ranged attack skeleton
- Skeletal Mage (level 4) - casts ice missile, causes slow
- Skeletal Warrior (level 5) - high defenses, heavy attacks, armor-piercing special
- Skeletal Sniper (level 6) - level-appropriate upgrade to Archer
- Skeletal Occultist (level 7) - level-appropriate upgrade to Mage
- Skeletal Knight (level 8) - level-appropriate upgrade to Warrior
The spitting antlions were by far the best: their high damage and rate of fire made them always intimidating. We're going to make the other antlions much more interesting to bring the creature up to a mid-range enemy.
Also we'll decrease the average HP for their levels, but greatly increase their armor absorption. They will become very weak to fire, ice, or both.
- Antlion Hatchling (level 3) - mostly dangerous because they're found in swarms
- Antlion (level 4) - will get much higher health/damage
- Antlion Blinker (level 5) - will also spit a poison that stuns the player
- Antlion Slasher (level 6) - will get a higher rate of attack for poison damage
- Antlion Spitter (level 7) - ice and fire versions will have tweaked numbers to match other creatures, mostly satisfied with these guys
- Antlion Burster (level 8) - will self-detonate for insta-kill level damage
Undecided, we're not using these guys much yet. They'll be a higher level creature, so we'll put them to more use once we get more content in.
It's a bit tricky to spell out the right formula for now. Ideally a creature +2 levels is hard and a creature -2 levels is easy. For now I'm basically doing playtesting to see what vaguely feels right. Once we get a few creatures ready we'll have updated formulas (e.g. a level X creature should have about Y health).
Because of all the number shifts, we might have to go back and repopulate old maps with new level-range-appropriate creatures. Also the new maps should be constrained to specific levels. Creatures +/-2 levels are acceptable in small doses (e.g. mini-bosses might be +2 lvl).
- Frontier Plains - level 1 (mostly goblins, some patches of zombies)
- River Encampment - level 2 (goblins)
- Ydrakka Pass - level 3 (goblins early on) and level 6 (antlions in the second half)
- Goblin Warrens - level 3 (high-end goblins, and ukkonen)
- Averguard Atrium - level 3
- Averguard Prison - level 4 (showcase the new zombies)
- Averguard Academy - level 4 (skeletal mages and warriors, some zombies)
- Averguard Temple - level 3 (before locked area), level 5 (after lock)
- Averguard Complex - level 5 (lots of warriors)
We'll probably detach the antlion caves and move them to a new place. Those will be level 6.
The new Living Bones module will feature level 7 or 8 content.
Grassland Tiles Complete
The only art that might still be added to v0.15 is some NPC stuff. I'll add 2-3 NPCs to the starting village.
The primary code for Flare v0.15 is done. Already translations and mods are incredibly useful. Mods let me test all kinds of weird stuff without breaking the build.
This weekend I plan to finish up the new raw art needed for v0.15. The grassland tile set will be ready to go. New walking sounds. New NPCs. Art deadline is Dec 4th.
One week of making new content from the assets. New maps, maybe a couple simple quests if there is time. We won't worry about the maps being "final" or part of some grand story. The new maps will intentionally have stubs: e.g. walk into a cave and it's small and empty. These will be invitations for modders to add their own adventures in those locations (overwrite the stub maps with a sprawling dungeon if you want!). New content deadline Dec 11th. There will be a Release Candidate and a string freeze at that point.
A week for testing and translating. v0.15 will be released Dec 18th, or as early as Dec 16th if everything's in place.
After v0.15 release the holidays will be upon us. Good time for brainstorming about the future and for simply enjoying the game. We'll pick up new coding in earnest on Jan 1st.
Peeking at the Future
Wondering where Flare is heading? Here are some goals for 2012.
v0.16 Advanced Enemies
Right now enemies have primitive steering and simple chance-based actions. We'll evolve creatures to have better pathfinding and more variety in movement. Behavior classes will be added that cover new enemy types. Flying creatures won't move like melee creatures; they will swoop and fly in wide arcs. Guardian creatures will patrol and favor blocking. Each creature will be assigned a base behavior, with a few configuration options to add variety.
We'll add support for creatures that drop predictable equipment (e.g. skeleton soldiers that sometimes or always drop short swords). Creature-specific drops could have an assigned drop rate.
We'll also add support for large creatures (require 2 or more squares to move) and try some unique boss behaviors.
Of course, v0.16 will feature lots of new enemy art!
v0.17 Improved Menus
We'll do an overhaul of the menu system. Part of it is refactoring parts into the Menu base class and moving menu configurations to engine/ config files. It should be possible to completely reskin and rearrange a menu without touching the source code. Menu screen size and positions will be configurable.
The Character menu will be built from a long list of display-able stats. The weapon/armor proficiency unlocking art will be removed.
The Inventory menu will support a configurable number of equipment slots, along with rules on which slots are visible on the player sprite.
The Log menu will get improvements from new WidgetTabs and WidgetScrollBox features.
The Powers menu will be completely redesigned. Each level the player will gain 1 talent point to spend, for unlocking or improving a Power. Powers will be arranged in talent trees. The fantasycore mod will supply trees for Warriors, Rangers, and Mages.
The Action Bar will come with several config options: more/less action slots, hide/show menu buttons, and changing the hotkey labels for buttons.
We'll introduce configuration menus and mod-manager menus.
v0.17 will come with cleaner menu art, new/better icons, and new fantasy paintings for the main menus.
v0.18 and beyond
As time gets closer we'll hammer out the theme for v0.18. Here are some features that will be in the pipeline towards Beta.
- Additions to the Powers system. Better handling of buffs/debuffs, passive abilities, powers that trigger in new ways (e.g. on-block, on-death)
- More event types, to support simple cutscene-like interactions
- Animated tiles and map backgrounds
- Configurable damage types (e.g. slashing, ice, toxic) instead of a fixed list
- Loot groups (e.g. Magic Loot, Armor Loot) to give creatures thematic drops or vendors limited wares
- Statistics tracking (deaths, kills, total gold, most gold carried, etc)
Beta, 1.0, and 2.0
Once the above features are in place, Flare (the engine) will go into a feature-freeze Beta. We'll limit work to bug fixes, code polish, error handling, etc. in preparation for a stable 1.0 release.
Major new development can continue on branches and forks. Solid, essential features could be introduced in 1.1 and beyond. The Flare 1.x series will remain committed to simple single-player action RPG gaming.
Flare 2.0, if necessary, would contain a critical mass of large rewrites. Multiplayer, or scripting languages, or OpenGL -- those would warrant moving to 2.0.
All of that future talk is in terms of the Engine. When are the games coming?
Flare 1.0 contains what I personally need to make the games I like. I think my role in the Flare project will shift once Beta kicks in. I'll be the arbiter of decisions for the 1.x series: this will probably mean rejecting features rather than adding them. With less of my time going towards code, I plan to focus on art and game design.
During Beta I'll be focused on building a real game. The best way to test the engine is to put it to actual use. We'll make a short but extensible campaign using many of the current assets. If feasible, Flare 1.0 will come with a fully-playable game.
After Flare 1.0, I plan to spend most of my time building new assets that work with the engine. I want to release all new high-quality art. I might build small game vignettes to show off these assets as they are released. Giving tools to people who want to make Flare games.
The grasslands are coming along. If you're playing from the latest github master, you can enable the "frontier" mod to run around the starter outpost village.
Here's what would be nice to round out the tile set. I have models for about half of these.
tent (done) boat (done) wood pile (done) anvil (done) fire pit (done) rocks (done) cave entrance (done) mines entrance (done) ruins entrance (done) well (existing) signpost (existing) lamp post (existing) stump and axe (existing) stump no axe (existing) more trees (existing)
I'm going to replace the walking sound effect (currently echoes on wood) with a more neutral effect. I'll need four similar-sounding effects, maybe something like running in belted leather boots. If you know where I can get such sounds (appropriately licensed) let me know. (UPDATE) I have Brandon Morris on the task.
v0.15 coming soon
We've been busy on v0.15. I know there hasn't been a new blog post in a while, but simply take a peek at the Flare github network graph to see the action.
All of the technical features for v0.15 are ready. We're looking at adding a few new art assets and maps to round out the release.
First, I want to thank everyone sending in translations. You guys are awesome, and it makes testing our newest code that much easier.
However, fair warning: all of this data is subject to change. The current game data amounts to a short tech demo, and it's very possible that all of it will be discarded before the first game is complete.
It's certainly nice if people in many countries can experience the tech demo in their native language. But don't worry about a huge concentrated effort to translate the current data into everything. We can have a strong localization effort further down the road.
It might look to the layman that the game is near feature-complete, but that still means the game itself is just starting. We're far enough into the game design process to see which parts of the gameplay don't work. There will be some redesigning, and thus translations will become obsolete. So let's talk about that.
A couple weeks ago I picked up Dark Souls. It's the first console game I've played since... hm, since Ocarina of Time or Symphony of the Night. I'm absolutely loving it, especially as a great example of hard melee combat.
It's making me rethink some game design choices. Although the engine itself should support several options, a great game could use some tweaks. Here are some ideas I'm tossing around.
I like the low number scale in the game currently -- it's a bit easier to visualize. But there's hardly room for varied armor when light armor is 1 absorb and heavy armor is 2 absorb. This is more affected by shields which have passive absorb. So I'm toying with changing the armor and shield system.
What if shields didn't have passive absorb, but instead required using active Block to have an effect? E.g. a Wood Buckler could have "Absorb 5 while blocking". Heavy enemy attacks could still power through such a shield, but weaker attacks would be fully absorbed.
By moving shield absorption to active Blocking, it's okay to allow higher passive armor ratings. And allow more armor. I'd want more armor styles that span the Defense rating from 1-5. I don't like how the Defense skill currently alternates between unlocking armor and shields. Each level should give both. The baseline armors/shields could look like this:
- Leather (Absorb 1, requires Def 2)
- Maille (Absorb 2, requires Def 3)
- Plate (Absorb 3, requires Def 4)
- Dragonscale (Absorb 4, requires Def 5)
- Buckler (Block 3, requires Def 2)
- Small Shield (Block 6, requires Def 3)
- Large Shield (Block 9, requires Def 4)
- Tower Shield (block 12, requires Def 5)
Enchanted or special gear could have higher bonuses.
Because of the above, and similar changes I have in mind, I want to remove the item proficiency visuals from the Character menu. This will add more flexibility in gear design. Example: we can have a Warhammer that requires Physical 3, and we don't have to think of a name for the class of weapons that requires Physical 3.
Right now in the engine, elemental resistance (damage reduced by a percentage) is treated differently than physical resistance (damage reduced by a fixed number). One could argue to combine these systems to all be like physical damage is currently. Then, each attack could have a damage type (physical, or a specific element) and an entity could have damage reduction per type. This could somewhat simplify the code, as all damage is handled the same way.
What are the pros/cons for the player? I'm not sure. One thing is, percent-based gear scales with enemy damage, so one particular piece of gear is useful for longer. This means less inventory management and gear feeling more special, but it could also mean few pieces of gear trivializing large parts of a game.
It's possible for every armor/shield to list damage absorption for each type. It leads to having a ton of numbers on each piece of loot, and that's just a bit overwhelming.
So, it's relatively easy to support these visual equipment slots: chest, legs, arms, head, both hands. Anything more complex would be hard to do with layered sprites.
But, are gloves and boots actually exciting? I suppose it is neat to mix and match equipment for visual looks (how much does this matter in an isometric sprite-based game?). Min/maxing gloves or boots stats seems a bit tedious to me. If gloves/boots always have unique effects and no armor value, I'm more excited. (e.g. acidwalk boots)
There is satisfaction with getting a whole matching set of armor, but some players end up sacrificing style to mix up optimal stats. Maybe it's okay for armor to all come in one piece, so that the player is stylish and only has to make one stat choice. Maybe having single-slot armor is less "hardcore", I don't know.
I'm considering removing health and mana regen as regular stats in the game (I'd leave code support for them though). Health regen makes some games cheap (I'm not intimidated by the next fight if I can always rest up to full) and tedious (I'm spending more time waiting for health to come back than actually fighting). When a game doesn't have regenerating health it encourages players to get better at combat to clear new areas.
One problem I have with health and health regen being separate stats: it's not obvious the best way to improve your character. Why have two stats that essentially do the same thing?
If there's no health regen, then healing spells and potions become way more important. But if there's no practical limit on those healing items/spells, someone without them (e.g. melee builds?) have a large disadvantage.
What about mana regen? It would hurt to be a caster with limited mana. Instead of a "mana regen" stat, maybe mana should have a standard regen rate that scales with max mana (e.g. 10 seconds to regen 100% mana). Weapons with mana drain could be very helpful.
Mundane vs. Magical
This is a personal preference: a game world where magic is too prevalent is boring. I'd rather have more interesting mundane items, and any magical item to be rare and wondrous.
I really like the weapon/armor upgrade system in Dark Souls. I had a similar, less refined idea going when I originally created those gemstone icons. Maybe I'll look into an Enchanting system for Flare, where you combine one equipment and one rare consumable to make upgraded equipment.
Selling to Vendors vs. Crafting
I don't know if this is necessary. It doesn't make sense in most game worlds, and is just there because of tradition at this point.
If I had a crafting system, I'd rather have items useful for their base components rather than being vendor trash. Longswords and bows could be scrapped into steel ingots and wood rods, which could then be used to build other base items.
Melee Attack Animations
When I create the planned upgraded art for Flare, I want to put in different melee attack animations. I haven't decided on the set I need, but imagine if there was an overhead smash, an uppercut swing, left and right hooks, and lunge/jab. I could make it so that these animations are used randomly so that combat simply looks interesting. I could make it so that each weapon uses one animation when standing still and a different animation if you attacked while moving (perhaps with different damage for each). I could have each weapon type affect the speed of each animation. I could have certain powers use specific animations.
Making Melee Fun
Combat can be more interactive if creatures have "tells" before they use an attack; e.g. a big wind-up before a huge swing. That would give time for the player to dodge or block. It would require more thought put into each creature but it could be well worth it. Right now there's really no time to react to what a creature does if you're in melee range; at best you can hold block while waiting for an attack, then counter-attack (which isn't too bad, really).
I've read interesting articles on how to make melee combat feel "crunchy". Instead of having a melee swing always follow through at the same speed, it feels better when the animation pauses slightly on the frame where the hit lands. It gives the attacks weight, rather than just feeling like all combat is simply swinging at ghosts.
Blocking should have some small effect on the attacker, maybe a higher-than-usual cooldown time before they may attack again. This could mimic "staggering" an enemy with a successful block and give time for the player to land a counter swing.
In Development for v0.15
Thane is working on translation support. After some deliberation, we decided to use a very simplified set of gettext rules and .po files. This is mainly because I'm always reluctant to add large dependencies to the project (especially where multi-platform support is a must). So for now, our .po files will support basic translations (simple msgid, msgstr pairs) but not more advanced features (stuff like gender/plural support). Basic translations might be sufficient for us: action RPGs are not text-heavy interfaces, and dialog is translated in whole paragraphs.
New contributor Manuel has added a "make install" option for those building from source, and has cleaned up some executable bits on various data files. He's more familiar with linux distribution concerns than I am, so his expertise is very welcome!
Tiled tileset offsets
I'm working with Bjorn over at Tiled to commission a feature for Tiled 0.8. In Flare tilesets, each tile can have an arbitrary offset from the grid space it's on. In practice, large tile subsets share the same offsets (e.g. all the "cave water" tiles have to be drawn below the regular grid). This new Tiled feature will allow setting a display offset to one entire tileset. At least for Flare's purposes, it will allow us to do all the mapbuilding currently supported.
Once the feature is ready, I'll get to build new grassland maps! With a simple overworld set we can connect multiple dungeons, add a village, more quest-givers, etc. I'm hoping to put new content in for Flare v0.15.
This week I'm working on data mod support. It will be easy to create mods that replace existing data files or add new data files. What this means is that adding new creatures, items, powers, quests, maps, etc. will be a breeze. Along with translations, this is one major feature for v0.15.
We'll be working on a few demo mods to show what's possible. In the not-too-distant future we'll be putting up several tutorials on how to create content for Flare. Exciting times!
v0.15 release date?
I don't have a planned released date yet for v0.15, but I'm looking at sometime mid to late November. Once we get the above features done, and we're sure everything is clean for downstream packaging, we'll turn the binaries loose.
Flare in Debian
Flare is now a package in Debian (unstable). Wow! Special thanks to Manuel A. Fernandez Montecelo and Jan-Hendrik (hennr) Peters for the legwork.
Putting FIRE in Flare!
I've been on a bit of a code hiatus while messing with new art. But it's time to get back into the 1s and 0s!
I plan on tackling some code towards v0.15 this week. I have one task that requires knowledge of GNU gettext, and another that requires knowledge of Qt. If you are interested in contributing to the project, please contact me!
I'm messing around with the latest Blender (2.6) after sticking with 2.49 for as long as I could. It will take a while before I feel proficient with the new interface.
Most of my previous work carries over. Some of my old baked normals are inverted but that's not a big deal. I haven't tested particles yet but that art (spells effects) is very old now and I'd like to do it better anyway.
Life events have claimed most of my free time and Flare has been pretty stagnant for a couple months. Time to start turning down other side projects and get back into focus.
Here are the major tasks that need attention.
- Replace MessageEngine with GNU gettext
- Add mod folders and ordered asset loading
- [Tiled] Allow (x,y) display offsets per tile set
Nothing flashing nor fun to work on. I'm sure that's a big part of why I'm in a rut. So what might be fun instead?
I have a very primitive action RPG done, but there are some things that deserve improvement. Here are some long-term plans. Some of these might be worth fixing before the first game.
- The inventory menu deserves a better layout. The engine ought to allow creators to define new equipment slots.
- Allow new equipment slots to display as a layer on the hero (e.g. for boots, gloves, helmet). Once this gets more complex it'll probably require having an equipment layer z-order per direction, if not per piece of equipment.
- I don't like the current Power unlocking system. It just isn't very fun: some levels you unlock useless powers, other levels you don't get any new powers. I should throw this out and implement a more traditional system to unlock powers (e.g. one unlock per level, or unlocked via magic books)
- Melee combat feels boring. The animation needs improvement, and probably there should be multiple melee swing motions. The engine should allow multiple variations for each animation, not just melee.
- I want some creatures to move very differently. I ought to implement e.g. a flying creature, then figure out how to refactor creature behavior.
- The current implementation of armor isn't very satisfying. I should probably have the Defense stat unlock armor and shields at each rank. Armors can be leather, chain, plate mail, full plate; shields can be buckler, small shield, large shield, great shield.
- I think the hard connection between base stats (phys, mag, off, def) and specific items should be broken. Remove those item icons from the Character menu, they're misleading at best.
- It was a nice idea to make Power trees based on the combination of base stats (e.g. Physical Offense), but it's awkward in practice. The idea could easily be lost in translation. Instead I'd want to make arbitrary power trees by "build". E.g. a Warrior tree, a Ranger tree, and a Mage tree. Once the trees are no longer tied to the core powers, it should be easy to add random trees with new powers.
- This is completely personal preference, but I'd like to have more non-magical items and far fewer magical items. I want magical items to be special and feel unique.
- The better I get with isometric art, the more I feel that I'm terrible at it. I think it's time to step up my techniques and push for higher quality.
Rather than roll my own translation solution, I think it makes the most sense to simply use GNU gettext. This would obsolete our recent work on the MessageEngine, which essentially is a similar solution.
If anyone has advice on using gettext with games, please pass it along. I believe several successful projects (e.g. Wesnoth) already use it to great effect.
Looks like gettext can just as easily handle data files as strings in source codes. See this wesnoth campaign file example.
Let's take a look at the almost-complete Grassland tile set (click to enlarge).
I'll add more trees, rocks, and various set pieces as needed.
New Scale Hero Preview
It's likely that this new scale will be used in game #2 for the Flare engine. But it's a good outlet now for creativity. Here's actual-scale art for the base human male and rough leather armor.
The Game Plan
Flare is only going to be relevant if I release several games: improve the engine each time until it's proven and practical.
I'm going to save the new game scale for game #2. For now I'm going to take what we already have and think about the kind of small-scope game that can be made. Maybe grasslands, caves, dungeons, and that's enough for one small episode.
Here's a tiny story I could tell using most of the current art.
Part 1: Mines
Trade caravan drops off the player and supplies to a mining outpost. Player's just looking for work. Some of the other workers are sick so you're a welcome addition. Take a pick, head down into the mines. The hero follows a suspicious tunnel and ends up in a creature-infested cave system. Has to fight his way back to town. One of the miners died, became a zombie, and had to be put down. This is trouble.
Part 2: Journey
The village will be wiped out without help. There is a fort not far from here that houses an old paladin order. Maybe they can send swordsmen or magical help. Travel overland to the fort, only to find the area crawling with creatures. Help fight the undead. Help find ingredients for a possible cure.
Part 3: Passage
The villagers must come to the fort for safety, but overland is too dangerous. The paladins know of an abandoned tunnel that connects the fort to a spot near the village. Clear it and get to the villagers, and guide them to the relative safety of the fort.
Part 4: Siege
Back at the fort, the villagers get help. The potions seem to make them feel better. Meanwhile there is a heavy siege under way against the fort, an army of undead. Fight against the hordes at the gates. Find the twisted villainous leader and destroy him.
Part 5: Guardian
When you slay the villain, his beastly corpse becomes the body of a frail old druid. The paladins recognize him, he was a great elemental guardian. Something or someone corrupted him, allowing evil to overwhelm the scales of balance. The player becomes the new Guardian. Some of the previously-sick villagers and paladins, slain in combat, are becoming undead. The cure has failed, only treating the symptoms. When you all finally die, you will become undead too. As the new guardian, you eventually seal the Fort with yourself and the infected survivors inside.
Most of this short story can be told with the existing assets. Let me list out how it would work.
Part 1 would use the grasslands and cave tileset to represent the mining village area and the mines. The caves could contain goblins, antlions, and a couple zombies.
Part 2 would feature mostly grassland areas. Closer to the village there can be more goblins/antlions, and closer to the fort there would be mainly undead. There would need to be a new set piece for the Averguard Keep entrance; it doesn't need to be a whole tile set (it can be e.g. a mostly pre-rendered set). The interior of the keep would be the dungeon tile set.
Part 3's passage would be half dungeon, half caves. The dungeon half of the passage could be minotaurs, and the cave half could be tougher antlions.
Part 4 would again happen at the gates set piece, probably an instance map that now contains tougher undead and siege tiles. The boss encounter could be just inside the fort, perhaps. The boss itself would require a new creature model.
Part 5 is mostly the denouement. Will require a handful of new graphics but nothing like a whole tile set or creature.
I've been experimenting with larger scale sprites. Here is the base human male at the current scale (each tile is 1.5m) and the proposed new scale (each tile is 1m).
I've applied a high quality normal map to the larger version, to show the kind of detail possible with this new scale.
Obviously the larger scale looks great. I'm tempted to start using it immediately. But there are concerns.
- Better scale images for this genre
- Higher detail makes equipment choices more visual and interesting
- 1m scale will have a higher universal appeal
- I'd like to redo some art anyway (e.g. dungeons), I can do much better now
- Most of the old art will be unusable and incompatible
- Any new art will require significantly more time to create
- If I switch now, there will be delays in delivering an actual game
I will definitely move to this new scale at some point, it's just a matter of when.
I need a very small camp/village for the grassland area. So here's a quick & dirty cabin.
Flare mentioned in OpenGameArt talk
Here's Bart Kelsey's talk at Libre Graphics Meeting 2011 about OpenGameArt.
Flare gets a quick mention around the 5 minute mark.
Grasslands Tileset List
The grasslands is one of those tile sets where 256 tiles aren't anywhere near enough to fit all the tiles that could belong here. So I'm going to focus on the most-usable tiles and leave some room for customization. Listed by 16-tile groups.
- 0: reserved for collision
- 1: 16 grass tiles
- 2: 16 water tiles
- 3: 16 path tiles
- 4: 16 cliff tiles
- 5: 8 cliff tiles, 8 bank tiles
- 6: 16 bank tiles
- 7: 16 bridge tiles
- 8: 8 containers, 8 village objects
- 9: 16 weeds and shrubs
- a: 16 rocks and formations
- b: 16 trees
- c: 16 top-of-cliff grass tiles
- d: 8 wood fence
- e: buildings
- f: exits
Flare has taken the back burner while real life stuff has been out of control. It happens.
This week I plan to pick back up on this grassland tile set. My next big concern is making sure the tile shapes are usable. I plan on having high cliffs and low water; but, Flare's maps are currently flat. So all the split levels will be faked, essentially. Tiles should be easy to place and work with the existing grid.
What I plan to do is make a proof-of-concept set of tiles and then see how they play out in Tiled. If the basic shapes work, it'll be easier to move on to textures. I'd rather do that than put a lot of work into the textures, only to find out the shapes don't fit together.
I was really hoping to be able to fake split-level areas: terraced elevations that look like different heights but are actually flat and faked with forced perspective. But it looks like it's too tricky to deal with. What I'd gain by forcing this, I'd lose by making the tile set much harder to create and work with.
Actually the tile set art will still be friendly to such an engine, but it just isn't quite working here. I'd need to add n layer support and drawing tiles in vertical order first. It just isn't necessary at this point, but would be a nice thing to consider for a future version of Flare.
So I'll have to do basically the same thing I did in the Cave tile set. In the Tiled version of the tileset image I had to flatten the water areas to work in Tiled.
Raw cliff test. Not too bad, maybe the rock layers are a bit too defined. I can make some changes so that they smooth more in some places.
Experimenting with Grasslands
I made some grass and water tiles before, but I don't care for the way they turned out. Using particles for grass seems gives me a very noisy grass, and it's difficult to deal with the translucency on the edges. I'm going to try to make new grass that relies more on good textures.
I want to add small cliffs. Some will just run along a grassy area to give the illusion of a split-level floor. Some will lead down to water. I'm trying to draw inspiration from the Cliffs of Moher -- look at the texture on those vertical cliff faces. I'd like to accomplish something like that if possible.
Because of the way tiles work in Flare, the cliffs won't be extremely tall. This might lead to a terraced look in some areas. Maybe that's a good, interesting thing. We'll see how it turns out.
I'll be trying different techniques. I want the result to be relatively low-poly and perhaps useful in 3D games. I might need to use some combination of sculpting, 3D outlining, and good textures to get it working correctly. I also need them to tile seamlessly. Going to be tricky, but I think I have the work flow figured out. It will be similar to what I did with the cave walls, but with more manual modeling instead of using random Fractal subdivision.
Trying out some textures and basic shapes for the cliffs. This is only one tile repeated. Just experimenting to see if this gets me anywhere near where I'm trying to go. I've zoomed these in at 200% so the detail is easier to see.
I dunno. Maybe. The angle of the light kind of washes away the details on the right side. It could look good given more variety.
I've found an easier way to get this variety on the cliffs, with a better-looking result.
Before I was trying to subdivide and extrude chunks of rock. This time, I vertically subdivided the section into 10 parts and shifted the curves of each horizontal rock layer. It's a lot faster than the previous method. I ended up with more faces but it's still not a lot (this example is 117 quads/234 tris per section).
For kicks I might tone down the poly count to 64 quads, to be extra 3D-game friendly.
SDL_ttf dependency added
I don't take adding dependencies lightly. In my mind, every new dependency is another barrier to building, another possible limitation on various platforms.
However, SDL_ttf is likely supported to the same extent that SDL_image and SDL_mixer are. And, this lets us do Unicode language support. If Flare is to be taken seriously and used by gamers all over the world, it needs to at least handle translations.
Follow-up Thought to Bug Tale #1
One reason this bug was hard to see was the delayed trigger -- something happens in one part of the code (potion use restores health), but the immediate effect actually doesn't take place until way later in the code (remove potion from inventory).
Ideally, don't do this! Have everything resolve together if possible. Why isn't it possible? Does the code need to be refactored?
In this particular situation, I think it's a matter of avoiding circular dependencies in C++ files. But there's probably a solution that gets around that and performs all the necessary steps together.
Bug Tale #1
Today I merged many significant patches added by various contributors. It was time to get back into the swing of things and try out the new code. I was especially excited to try pennomi's new "monster pack" code, where monsters in combat would notify nearby monsters to enter combat. Finally, large groups of monsters couldn't always be picked off one by one.
I'm merrily testing with a new character. I get through the alpha quest line, enjoy a romp in the caves, and make my way to the Lost Mines. I pull a large group and have to use a health potion to stay up. But the potion doesn't go away. I clear out the enemies and try drinking again. I'm getting the full effect of the potion, but the potion is still in my inventory. I check my inventory and try using the potion from there -- and finally it's gone.
But no code relating to potion use has changed, not in a long while. So what's happening?
I restart the game. I test, and potions work fine. But I'm full health; let's see what happens if I take damage. I find the nearest friendly Skeletal Warrior That Shoots Icicle Spells and take damage. Viola, my potion is stuck again!
I set debuggers to look at power use, for when I use my potion. I play again and the breakpoint is hitting every frame. Oh right, once the skeleton sees me he's dropping his warning beacon; his beacon uses the same Power system as my potions. I tweak my breakpoints and test more.
Maybe it only happens when my health isn't full? No, that's not true. I take damage from the skeleton, drink my health back to full, and the potions are still there. Maybe it's being in combat? I kill the skeleton, and my potions still persist. I test so much that I find this out: if I stand near the map entrance my potions work fine; if I go further in towards the skeleton they stop working. I can move back and forth a few tiles and watch my potions break and fix! Surely this can't be related to map position. I trace all sorts of variables but nothing turns up.
Time for a break.
A minute into my break and the answer is obvious. The potions aren't working when the skeleton sees me.
When the skeleton can see me, he's creating a warning beacon every frame. When I move towards the exit he can't see me anymore, and he's not doing his warnings anymore.
When I drink a potion, there's a "used_item" field that is set in the PowerManager. Another part of the code, later in the frame, looks for used items and removes them from the player's inventory. Well, the enemy beacon spell doesn't require an item, so it was resetting used_items to "no item used". In a single frame the hero's actions are processed first, then enemy actions, then afterwards is the cleanup code that checks for used items.
Previously, it was very rare for a hero and an enemy to use a power on the exact same frame. Even when it did happen, the consequences almost never mattered. With this new code, though, enemies are dropping beacons constantly. So this bug's been in my code for months and only manifested now: enemy powers were resetting the hero's powers "used_item" field. Thus making my potions endless if I was in sight of an enemy.
These are the weird bugs that can haunt a project for months. And apparently, keep programmers up until 3am. Feels good to solve 'em though.
Catching up on GitHub
I took a few days away from GitHub and Flare to write part of a book chapter, give a talk, and handle other strange affairs. I plan on doing some catching up tonight.
I'm working with Flare concept artist Justin Nichol on hammering out the visual story of Flare's first game. We took the map progression I posted about recently and wove it into a basic story. Justin is working on various environmental concept pieces which will guide the building of new tile sets.
I plan to post more about the story soon.
Flare v0.14.1 Bugfix Release
I've tagged v0.14.1 over at the Flare GitHub site. It patches a significant memory leak in the v0.14 release.
If you maintain Flare in a distro repo, I suggest updating to this version.
I will update the Windows and OSX binaries soon.
Free Gamer and HD Video
Flare v0.14 "Main Menus" Released
This release is all about wrapping the core gameplay in main menus, pushing Flare closer to feature-completeness. Now players have four game slots to experiment with different builds. Also, choose your gender and a portrait for your hero or heroine!
Title Screen added Load Game Screen added with four game slots New Game Screen added with choosable portrait and hero name Title Music by Brandon Morris Customizeable portraits with matching sprite heads for heroes Player portrait displayed during NPC conversations Female heroine option added Six player portraits added by Justin Nichol Save and Exit to Main Menu confirmation added by kitano GameState base class by kitano Entity base class by kitano Variable MP cost for spells added by kitano Animation class added by kitano WidgetButton generalized by kitano Arrow and X to show conversation progress added by kitano Input text widget added by kitano Clickable map events added by Thane "pennomi" Brimhall Enemy group random spawning added by Thane "pennomi" Brimhall Freeze and Multishot code expanded by Thane "pennomi" Brimhall Damage Multiplier for powers added by Thane "pennomi" Brimhall Life Steal and Mana Steal for powers added by Thane "pennomi" Brimhall Power Cooldowns added by Thane "pennomi" Brimhall and wokste Item bonus to increase base stats added by Alexander Olkhovskiy Enabled multiple bonuses on items (up to 8) Joystick support added by Artur "Zear" Rojek FileParser now used by all data files added by Bonbadil Added close buttons to several menus Attempts to use standard *nix directories if available (XDG or $HOME) Sound effects volume added to settings.txt Double Buffering option added to settings.txt Hardware Surfaces option added to settings.txt Bug Fix: Teleport Scrolls can no longer be used without a target Bug Fix: Windows mkdir fixed by Paul-Wortmann
I've been thinking about story progression in terms of maps and tile sets.
There are specific tile sets I want to build. Some just because they sound fun, some because I want to cover various elemental themes (sorta wu xing).
Let's say I shoot for 12 tile sets in this game. Alternating between "overworld" and "underworld" areas (almost) where the overworld areas feature a town and the underworld areas feature quest targets and bosses.
- Grasslands (feat. a pioneer village)
- Dark Forests (wood boss)
- Badlands/Ruins (feat. a gothic/zombie village)
- Dungeons (metal boss)
- Mountain Passages (feat. a mountain village)
- Caves (earth boss)
- Tundra (feat. a frozen fort)
- Ice Palace (water boss)
- Desert (feat. a trade post)
- Fire Temple (fire boss)
- Sky Bridge (feat. a handful of powerful NPC allies)
- Villain Fortress (end boss)
Assuming I aim to have about an hour of main-quest content in each tile set, that's a decent 12-hour story with plenty of changes of scenery. There can be side quests and optional maps too. Numbers are minutes:
- 000-060 Grassland
- 060-120 Forest
- 120-180 Ruins
- 180-240 Dungeon
- 240-300 Mountain
- 300-360 Caves
- 360-420 Tundra
- 420-480 Ice Palace
- 480-540 Desert
- 540-600 Fire Temple
- 600-660 Sky Bridge
- 660-720 Villain Fortress
Also, assuming early levels go by faster than later levels. Approximately:
- Level 1 for 10 mins (000-010)
- Level 2 for 20 mins (010-030)
- Level 3 for 30 mins (030-060)
- Level 4 for 40 mins (060-100)
- Level 5 for 50 mins (100-150)
- Level 6 for 60 mins (150-210)
- Level 7 for 70 mins (210-280)
- Level 8 for 80 mins (280-360)
- Level 9 for 90 mins (360-450)
- Level 10 for 100 mins (450-550)
- Level 11 for 110 mins (550-660)
- Level 12 for 120 mins (660-780)
Conveniently this means the player would be level 12 when on the 12th map. This fits the equipment curve as well (where max level items are about level 14)
Applying time spans to maps, here are the expected creature and treasure levels for each map.
- Grasslands level 1-3
- Forests level 4-5
- Ruins level 5-6
- Dungeon level 6-7
- Mountain level 7-8
- Caves level 8
- Tundra level 9
- Ice Palace level 9-10
- Desert level 10
- Fire Temple level 10-11
- Sky Bridge level 11
- Villain Fortress level 12
The actual XP amount per level will be adjusted once content is in place. Here's a rough estimate. Currently I'm using XP per kill is the enemy's level. Estimate about 10 kills per minute (assume some downtime dealing with loot etc, and also assume large quest reward xp).
|Level||Minutes||XP to Next||Total XP|
Here is a Windows release candidate for v0.14. We have a few more minor data changes but the code is ready for testing.
And here's the OSX release candidate for v0.14
The current code is the v0.14 candidate. All milestones are now complete.
Over the next couple days we'll do some testing (especially on various operating systems) to ensure the latest changes work as expected. I'll put out testing builds for Win and OSX later today.
Meanwhile we'll do a few data tweaks just before release:
- Make a final "X" graphic for the conversations menu
- Convert existing maps to use click hotspots and enemy groups
- Remove loot crates between the two cave maps
- Fix collision on the skeletal mage trap in the caves level 1
I'm working up some fixes for Windows.
- mkdir() calls are different on Windows, setting up some preprocessor stuff to handle this
- ItemDatabase.h blows up my MinGW c++ compiler! The item array with the new multiple bonuses is too large. Changing that array to sized at runtime.
Isometric Hero and Heroine
I've uploaded all the hero/heroine sprite art to OpenGameArt under CC-BY-SA 3.0.
Flare v0.16 focus
Flare v0.16 will be about Improved Enemies. We need enemies to be smarter, have better pathfinding, attack in packs, etc. Smarter enemies should make combat more interesting. Once these improved enemies are ready, we'll take a new look at the way heroes are built and balanced.
Female Sprites added
Very exciting -- one of the huge art components needed for v0.14 is ready. All the female sprites have been added!
There are only a handful of art pieces left for v0.14:
- Close menu button
- Close dialog/talker button
- Finished portraits (coming soon thanks to Justin!)
- Female combat vocals (hurt, die)
When those are in place I'll put out a release candidate Windows binary. We'll still be working on one more code piece (standard linux directories support).
Note To Self (Art Scale)
Herein I justify the current scale of Flare's art. I'm writing this because I get tempted to scale the art up often. Here are reasons why it's not a great idea, and that I should continue on my current path.
Concern: Tiles are 1.5m on a side. That's weird. Maybe it should be 1m instead.
- 1.5m is pretty close to 5 feet, the same scale used in U.S. D&D battle grids. Perhaps 1m or 2m scaled tile sets could be used without it being too obvious.
- 1.5m gives a pretty good combat range on many animations. For tile/turn based games (e.g. tactics or roguelikes) this scale gives a pretty good visual combat (weapons are in range to connect). 1m squares means human combatants are close enough to touch each other and weapons extend too far. 2m squares means short weapons sometimes don't reach.
- 1.5m on a side tiles means a 32x32px square directly facing the camera is almost exactly 1 sq. meter. This is perhaps more interesting for judging scale!
- At 1.5m tiles, an adult human with long weapons can all fit in a 128x128 sprite. If the switch is made to 1m tiles, the sprites could not each fit in 128x128.
- Additionally at this scale, larger non-boss creatures can nicely fit into 128x128 (see the minotaur). Need a boss creature? Go ahead, use 256x256!
Concern: high-res graphics could require nicer-looking, more detailed 3D models
- Nothing stopping me from doing more detailed models now. Some details would show up even at the current scale (more than you'd think).
- The current scale is a good trade-off between ease of creating assets and detailed required.
Concern: other games use larger graphics!
- This scale is almost identical to Diablo, Baldur's Gate, and Fallout
- These games had great-looking art at this scale.
- Flare's engine should allow a high-res pack, with all the assets rendered at double size.
Test Build for Windows
Here is a Flare test build for Windows. Many of the new v0.14 features are ready (mostly the main menu systems).
What's left before the v0.14 release:
- Fix some placeholder art
- Implement OS-specific folder usage
- Add female hero options
- Add final hero portraits
- Add main menu music
You'll notice that the New Character menu is a bit simpler than the sketch I planned below. As I was implementing it, it just seemed keeping it simple was the best course of action.
Maybe July 1st? Sounds like a good goal. The only feature I'm not confident about is switching to OS specific data and save folders, only because I have zero practical experience there. I'm hoping that feature makes it in, but I wouldn't be upset if that slips until v0.15 (when many folder changes are happening anyway). I know this is a highly-requested feature, I just want to make sure it's done properly before shipping it out.
Flare v0.14 is getting quite a bit of much-needed polish with the new main screens. I hope this will be evident in their current form. Once those menus get the background music and images, Flare will actually start to feel like a game.
The GitHub project has a long list of open issues, mostly looking at what might be added in the short term. Some are additional polish, some are slight game improvements, and some are just fun features. If you'd like to help with any of that, drop me a message. Or, fork away!
Future thoughts: v0.15
It looks like we will probably handle translations as a game-data mod. Mods will be able to override any file in the core data set or add new files. This isn't a very elegant solution but it should be powerful enough for everything from simple translations to total genre conversions.
Because translations are mods, we'll be putting the basic mod rules in place for v0.15. This means v0.15 will spend a lot of time in development. But I think that'll be okay -- after all, without a ton of game content in existence there isn't a pressing need for translations yet.
In your opinion, what should my personal priority be for v0.15? I have several programmers helping with cleaning up the code, so I'm confident about the code side of the game for the foreseeable future. But currently I'm the only artist on board for tile sets and sprites. Maybe I should do high-level code management on v0.15 via github and focus my time on creating art? Or should I get through a few more releases before I switch to an art focus?
Flare is coming along nicely. Several of you are helping with much-needed cleanup and refactoring of the code. New neat features are being added (e.g. better multi-missile options).
I've finally rendered the male armor layers without heads. I've added three male head options (the current head, a bald head, and a hooded head). Currently these "look" options can be set in the save file. The New Game (Create Character) menu will allow these choices, with matching portraits.
New Character Screen
ASCII sketch time!
####### Choose a Portrait ######## Base Type # # # # (*) Human Male # # ( ) Human Female # # ( ) etc # # # # < # # > # # Preview # # ######### # # # # # # # # # # # # # # ######### ################################## Name: [______________________________] [Cancel] [Create Character]
Officially Moving To GitHub
Flare is taking a distinct change in direction with a move to GitHub. The Google Code page will stay up until v0.14 is released, at least (though it will be increasingly out of date).
I've posted a list of code issues to tackle. If you are interested in helping Flare, this is a good place to start. As always, an easy way to contribute is to add some specific feature that you feel is lacking.
I've decided to go with a much more community-friendly approach to Flare development than I posted a few weeks ago. Some of those principles still apply, but now I will intentionally be more welcoming to change and new ideas. Already I've accepted pull requests for changes I was hesitant about before.
Essentially, this is me admitting that Flare is bigger than just me, and that Flare irrevocably belongs to the community. This isn't my game, this is our game. With GitHub it is much easier to branch, experiment, and merge. Hopefully this means Flare will improve at an ever-growing pace.
I've made a copy of Flare on GitHub. I'll try this out for a while, see how it goes.
As part of this, I want to be more open/accepting to contributions. With git, this might be easier than ever before. If you implement an interesting feature please send me a pull request on github. Note I'm fairly new to git so things may be slow at first.
Q. Is Flare ready for me to make games?
A. No. The funny part about software development: the first 90% is easy, it's the second 90% that is tough. Though Flare appears (at the surface) close to basic "feature completeness" it has a lot of work to go. I will have big announcements and tutorials up when certain parts are ready for real content-building. Map-making will probably come first. Keep in mind that you're watching the Alpha process as it happens; usually players and modders don't see games until well into Beta.
Q. Why not use OpenGL?
A. The current game runs okay enough without needing that added complexity. But I plan to experiment with it at some point. I'll also consider using a different library that does basic OpenGL for me (e.g. SDL 1.3 or SFML). As long as the game runs fine without it, OpenGL won't be a high priority.
Q. What will your game be about?
A. I have some themes in mind: elemental themes (fire vs. ice or wu xing), exploration in dangerous wilderness, ruined civilization, undead plagues, magic outlawed, religious corruption. I don't have a solid plot picked from those themes yet.
Q. What will your game be called?
A. No idea! Flare is just the engine/internal codename. I've been hunting for a good name. If you have suggestions please share them.
Here's a preview of the game slots menu which appears when you want to load a game or start a new game.
When clicking on a load slot, I will display the hero's portrait on the right side. Eventually I will add painted art in the background (though I'm not sure what of yet).
So, it's not thrilling to have a fixed number of game slots. However, four slots have nice symmetry with the four attributes and disciplines. As with everything in Flare, I've done it simple the first pass and reserve the right to do it much nicer later.
The displayed information for each slot might change. Maybe I should translate the hero's build into a class label. Maybe I should display the current map name. Possibly display the file timestamp.
Crazy Code Weekend
I'm planning on writing a lot of code this weekend. Fair warning: the latest svn version might not be playable until Monday!
Tiled and Maps
I'm looking at Tiled's automapping feature as a way to speed up basic map building. I can set up all the ruleset files for each tile set. For my reference, here's a much-needed tutorial video on Tiled automapping.
(Update) I checked in a first version of Tiled automapping files for the Dungeon and Cave tile set. It's very useful for quickly laying out the basic level. Instead of drawing with individual tiles, there is a new layer to draw with only four tiles: Void, Wall, Floor, Pit. Tiled's Automapping feature translates that to basic tiles.
My automapping files aren't perfect so it requires some touching-up for some corner cases. Some of these cases can be solved as I improve my map rulesets.
The auto-mapper does only one variation. Once the map-maker is satisfied with the basic layout he should delete the automapping layer ("set") and apply variations and decorations manually.
Action RPGs, traditionally, base the core gameplay around violent combat. Flare is no different.
So far I've been reluctant to include human enemies. Indiscriminately grinding human mobs seems in poor taste, and perhaps a waste of possibility. I'd prefer if the chance to kill another human was rare and optional, if it came down to a villain who deserves it (let the player decide if vigilante justice is moral).
Sometimes I even question having other sentient enemies as creatures. My girlfriend does not like that the cute goblins are enemies. For me it's not about cute, but about massacre of a self-aware race. There's no explanation in-game why goblins are enemies and why they should die. Sure, they do attack the hero on sight... but in my mind, the goblins were always more curious than cruel.
I'm a bit torn on how to "solve" the issue, or whether it needs solving. I could change Goblins to Imps and Minotaurs to Demons, thus have all killable creatures be some form of undead or demon. But having a game be so black & white could be boring.
I think it could be interesting if this is addressed during the story, e.g. some NPCs pushing for peace, compromise, mercy, or isolationism. It could be even more interesting if some races (e.g. goblins) are neutral and can become allies or enemies through player choice.
Do you ever think about this when destroying creatures in video games?
Lately I've gotten several very large contributions to Flare (code and art) that I've had to reject. I don't like doing that. So here are guidelines to helping the project.
0. I might not need help
Before I talk about doing a contribution the right way, realize that I may not need your contribution at all. This project is different than some free/libre projects that need contributors -- I can do most of it on my own, and I enjoy doing most of it on my own.
If you are looking to actively contributing to projects, I can point you to several other free/libre RPGs that are looking for help.
When I do need help or input on a specific task, I will put out a call for help -- often with an attached commission fee.
1. Talk to me before you begin
If you don't talk to me first, your large patch of code might break something else I was working on. Or it might not be the right time -- it's a feature that might have to be added later for various reasons. Or it might be something I had planned to do a different way. Your art contribution might not follow specifications or follow the art direction I have in mind.
Save yourself plenty of effort and contact me before you begin. If I like your contribution idea, I will give you plenty of specifications and guidelines towards a useful contribution.
2. Keep it simple
This applies mostly to code. I'm intentionally keeping the Flare code very simple. If you have a patch that adds a lot of complexity to the codebase, I will probably reject it without taking the time to comprehend it.
I want the code to be simple so that it's easy to comprehend. Especially for game programmers who are just getting started. But also, I will have to maintain this code, and simple code is easier. I vastly prefer Composition to Inheritance. I prefer implementing a small feature rather than including a new bulky dependency.
3. Keep it small
Don't sent patches that add several features simultaneously. If I like one change but not the others, now I have to perform surgery on your patch. My time is very limited; I could be making other features instead. It is often better for me to reject the entire patch.
If I already like your feature idea but it requires changing a lot of code, consult me on the timing of it. It will be harder to add your patch into a rapidly changing code-base if it is very large. I may ask you to wait to implement the feature until later, when those areas of code will be more stable (or when I'm working on different areas of the project).
4. Be mindful of licenses
I have to be very strict about licensing issues. I can only take GPL v3 code or compatible, and I can only take CC-BY-SA 3.0 art or compatible. If you're unsure about what this means, please contact me.
Loristan asked: "Clint, what is your vision for Flare, what are you trying to ultimately achieve?"
I haven't thought of Flare in exactly those terms yet. So here goes.
First, a list of big goals in approximate time order.
- Implement the minimal number of features to create a simple game
- Build enough assets to create a rich game in the medieval/fantasy genre
- Release a solid medieval/fantasy game
- Begin plans for a new game. Still action/RPG but a different genre most likely.
- Refactor the engine code so it works for the new game and for previous games.
- Build assets for the new genre
- Release a new game
- GOTO #4
I plan to keep going until I at least release one game (task #3 above). If I'm not sick of it by then, I'll continue the cycle of making new games and polishing the engine. As I get tired of code I'll focus on new assets, and vice versa.
Meanwhile I will help (to some extent) any team that wants to build a game with Flare. This might include helping with art assets or implementing new features.
So the ultimate goal? Release a fantasy action RPG.
Then if I'm not insane yet, maybe, release a zombie survival game (heavy on action, light on RPG). Then if I'm still not insane, maybe, release a steampunk intrigue game (heavy on RPG, light on action). Meanwhile, each step of the way the engine matures into a stable, proven framework that does a few things very well.
If you want to get existential, my vision for Flare is to make something I'm proud of. I've been toying with game development for 19 years yet I don't have a real game I can point to and say "I made that."
Artur "Zear" Rojek sends in a patch to add joystick input support for Flare. Excellent!
To make that patch really useful, I need to add an aiming option that always aim powers the direction the player is facing. Perhaps I can look at supporting non-cursor (mouse, stylus, touch) systems -- some of the menus could be tricky.
While I was in that area of the code, I added Hardware Surface and Double Buffering options to settings.txt -- should help with systems that don't have those capabilities.
I've added a basic title menu. Along with this I created a semi-generic button class (buttons that are all the same size) which I'll reuse on the other main menus. The buttons look great and use Lamoot's interface widgets from Open Game Art.
For now I'm temporarily using the Flare logo for the title screen. This will not last until release; Flare is only an engine codename.
I set up a Wiki for Flare. I have it open to anyone right now. I'm collecting story ideas for the first Flare game. If you have ideas for areas, quests, bosses, NPCs, etc. please post them!
No Rest for the Wicked
v0.14 is ambitious. Let's take a look.
The first attempt at a title menu will be completely simple.
- New class MenuTitle, child of GameSwitcher
- Centered image/logo on black background
- Bottom-center: buttons for Play, Options, Exit
- Other buttons can be added later
- Button clicks change GameSwitcher state
- Play goes to the Load Game screen
- Options will be disabled for now
- Exit quits the game without prompt
This screen should display a list of the current save games. It should read each save file to see the hero's name, level, location. If we get fancy it could show the hero's stance animation (load the hero's head and base body depending on equipped items).
For now this menu can support a fixed number of save game slots. Let's say 4.
- New class MenuLoadGame, child of GameSwitcher
- List of the 4 save slots, click to highlight
- Buttons at the bottom: New, Delete, Load (active an inactive art for each)
- If the player clicks on an existing game slot, the Delete and Load buttons are enabled.
- If the player clicks on an empty game slot, the New button is enabled.
The new game menu could be the most complex, especially if I want to make room for interesting choices in the future.
- New class MenuNewGame, child of GameSwitcher
- Text box to enter character name
- List of portraits, choose one
- Config file that matches portraits with heads and base bodies
- Accept button (clicking causes switch to GameEngine state)
Each portrait could be tied to a base body type and have an associated head layer. If I have the time, v0.14 will have two base body types (human male, human female). So this menu will start with 6 portraits (3 male, 3 female). In the future I could add more base body types (maybe a bulky body type, or even an elf or dwarf race type).
Flare v0.13 released - "Quests"
Flare now supports quests! This release marks a major leap forward for the story-telling capability of the engine. NPC questgivers can send players on quests and give rewards on completion. Quests can also involve finding items, killing bosses, or exploring a map area.
Detailed list of changes in v0.13:
- New "Lost Mines" area by Thane Brimhall (pennomi)
- MenuTalker code beginnings by Juan PabloTamayo (morris989)
- Added GameSwitcher class in preparation for Main Menus
- Block power buffed
- Framerate fixed. Animations adjusted and should be smoother on low-power systems.
- Added healing-over-time support for powers.
- New stat awards on level up.
- Added new potion levels
- "Magical" renamed "Mental" for genre neutrality
- Rearranged power tree. All power slots now implemented
- New "Channel" spell: short-range spell that costs 0 mana but requires a Mental weapon
- New "Immobilize" power: use a ranged weapon to pin a creature to the ground
- New config files to edit resolution, fullscreen, keybindings
- Updated health bar by Scrittl
- Stackable items and inventory refactoring by Bonbadil
- Basic conversations added
- NPC portrait by Justin Nichol
- Campaign Manager added to handle quest states
- Enemies no longer use ranged powers when losing line of sight
- Added consumable spell scrolls by Thane Brimhall (pennomi)
- Added elemental spell scroll icons
- Separated icons into 32px and 64px pages
- Added NPC ability to advance quest and give rewards
- Added monster kill to advance quests
- Added quest loot for monsters
- Added a tutorial NPC
- Added on-pickup quest advancement on items
- Added Averguard Keep quest chain featuring 4 bosses and 3 quest items
- Added a quest-giver NPC
- Added key and book icon for quests
- Added tabbed interface to Log Menu
- Log Menu has room for Quests, Messages, Statistics, and Achievements
- Weapon requirements displayed on Power tooltips
- (bugfix) Enemies no longer run before changing directions when entering combat
- (bugfix) Enemies leave combat when the player is dead
- (bugfix) Missing menu deconstruction calls added
- (bugfix) Correct memory reallocation when chaning equipment
- (bugfix) Correct resist stats on bows
Testing for v0.13
I plan to release v0.13 soon. Over the last couple days I improved the Log menu to display help/reminder text for active quests. The new tabbed interface for the Log menu is also ready for achievements and statistics (will be added later).
If everything looks okay, I plan to release v0.13 this weekend. Let me know if you test the new features in the latest check-in.
Windows test for r359
Here is an out-of-band test release for Flare (for Windows folks). This release is for players interesting in trying the new Quest system. I've added a short quest chain that covers a few of the current game maps. Download now!
The first quest chain is added to Flare in r353. It walks players through Averguard Keep. Heroes must defeat the bosses of four areas of the Keep; meanwhile they learn a bit about the history of the keep (and hints at the larger story).
All this stuff takes a lot of playtesting -- e.g. what happens if a player defeats a boss but fails to pick up the quest item he drops? What happens if a player tries to do quests out of planned order? There are many combinations at play. If you try the Averguard Keep quest chain and get stuck let me know. Note I'm not concerned with players who edit their save files incorrectly.
The quest items are using temp icons.
Next up: adding a Quest tab to the log menu.
v0.13 has a new class called CampaignManager that I'm using to store the progress of the current story. Essentially it is a collection of strings. Various parts of the game engine can read/write these strings to create some persistence and progress in the game world.
Related To Do:
- Move the processDialog and chooseDialogNode into NPC
- Give each NPC a pointer to the current Map (which also contains the CampaignManager). This structure choice will allow future NPCs to move around the map.
- Create handling for Quest Items. Perhaps this should be a new base item type.
- Prevent quest items from being dropped or sold
- Add an on_pickup command to quest items that sets a campaign state
- Allow CampaignManager to check for or remove items from the player inventory (pointer to the carried MenuItemStorage)
With this simple quest implementation in place, I need to create a few archetype quests for v0.13. My plan is to create a simple quest chain that ends in slaying the skeletal warrior Sir Evan Maddox.
- Report for duty: talk to this person, they have work for you.
- Exploration quest: I need intel from an area but it's too dangerous for me to go
- Fetch quest: get this item for me
- Key quest: take this item, now you can get into a new area
- Kill quest: kill this creature
Other common types not yet represented:
- Escort quest: universally hated so I probably won't even implement this.
- Gather quest: I don't have support for e.g. gather 10 boar lungs. That kind of tedium is more for time sink MMOs anyway. Simpler quests (e.g. gather 1 of each of these ingredients) can instead be done in a quest chain or in parallel quests.
- Genocide quest: Kill X of this creature. Again, more of an MMO time sink type quest, I might not implement this.
By covering these basic quest archetypes, I'll have the first Flare quest chain and have examples of how to create each basic type.
Open Game Art has a new weekly challenge coordinator. User kurtisevan has taken over for me, after I started and ran the contest for one year. The first new challenge: Get in the Game!, where you create a version of yourself for use in a game.
Well I'm working on NPCs and dialog anyway, and there's already a tutorial NPC with my name, so I created NPC art of myself. Looks fun in game, see the latest check-in at the Google Code page for Flare.
Contributions On Hold
I've been overwhelmed lately by the amount of interest in Flare. For now I'm asking that code/art contributions be put on hold. My personal/professional life is absolutely full for the next few weeks.
If stand-alone art or programming tasks come up, I will put out specific calls for help.
This is the approximate timeline from where we are now to Flare's first full game.
April 2011: Flare v0.13 "Quests"
In late April, Flare v0.13 will be released. It will contain talking NPCs and support for simple quests.
May 2011: Flare v0.14 "New Game"
In late May, Flare v0.14 will be released. It will contain a Title Menu, New Game Menu, and Load Game Menu.
June 1st, 2011: Feature Freeze
The engine will receive a freeze on major new features after v0.14. Any programming done after v0.14 will focus on making options in the existing engine configurable.
- Translation support
- Menu themes/design options
- Minor AI config options
- New base powers, items, etc. as needed
Focus changes from Engine to Game
At this point the focus of this project will switch from making an engine to making a game. Basically, if I can't build a game with this engine then it's useless.
June 2011 through May 2012: Art Assets
I expect to focus an entire year on creating art assets for Flare. More tile sets, creatures, equipment, NPCs, powers, etc. During this time I will be plugging the art into the engine with new test maps, side quests, etc.
June 2012 through Nov 2012: Tell A Story
At the end of 2012 it will be time to pull the assets together into the first Flare game. There should be enough variety to tell a decent story -- even a 20 hour single player campaign would be great for a project like this.
Dec 2012: Post Mortem
Assess the engine as a stand-alone project. Possible outcomes:
- If the engine is worthwhile, build a second game. Aim to reuse as much of the old code as possible. Refactor as necessary. Make sure both the first and second games run on the same engine.
- If the engine is mediocre, consider a rewrite. Design it from the ground up to support scripting engine, multiplayer, etc.
- If the engine is worthless, it ceases to be supported as a stand-alone engine. Instead it's basically the beta code-name for the finished game.
The latest check-in has example dialog support. Well, really at this point it's Monologue (the hero doesn't talk back yet). I also have support for completing dialog options (same function for completing quests) and awarding xp, gold, and loot.
I implemented campaign states as strings instead of as ints. It's much more readable and easier to maintain the data. See an example of the syntax here.
I still have to make campaign get/set in Map Events and on Enemy deaths. That will open up many simple quest types.
I started the very basic framework for the Campaign (story) Manager class for Flare. Right now all it does is read/write a bool status from the save file (as plaintext hex, cause that sounded good at the time).
On the plus side, this will be very easy to implement. Various classes will get/set these booleans. NPCs, map events, and the quest log will react to these simple statuses.
On the down side, this is as complex as I would get before strongly considering a full scripting engine. So extravagant cutscenes, branching dialog, etc. probably won't be part of the first game.
Bonbadil completed some fine refactoring of the Inventory and Vendor menus. Here's a quick explanation of the new classes.
ItemStorage is all about data; an array of ItemStacks along with generic functions to add/remove/return items.
MenuItemStorage is a derived class of ItemStorage that adds GUI functions (rendering icons, determining on-screen slot locations).
And here's how they're currently used:
- MenuVendor has a MenuItemStorage for the 80 vendor slots
- MenuInventory has two copies of MenuItemStorage (equipment and carried blocks)
- NPC has an ItemStorage for vendor stocks; multiple vendors share the one MenuVendor. NPC ItemStorage data is passed to the MenuVendor MenuItemStorage on MenuVendor::setInventory()
Having common code pulled into these new classes should help these menus work consistently. It also makes some features easy to add later e.g. workspaces for crafting or player stashes.
Bonbadil has sent in a patch that adds stackable item support. Old save files should be safe. The patch touched lots of areas in the code -- if you notice a bug let me know.
Art used in 7-Day Roguelike
I'm proud to see one of my tilesets used in a 7-Day Roguelike Challenge game! The developers, Ido Yehieli and Corey Martin, really poured some life into this minimalist tileset! Congrats to those guys -- making a game in a short amount of time is quite a feat.
Ido is also raising funds for a more in-depth roguelike. Check out Cardinal Quest on 8-bit funding (only 3 days left)!
I'm starting to test portrait integration into NPC talkers. Here's an in-game mockup.
I've been pondering how to handle dialog that depends on the current state of the story. The NPC files will have [dialog] blocks that contain story-dependent conversations.
Here's an example of plain back and forth dialog that only occurs once (sets a new campaign status upon completion).
him=Welcome to ... say, you wouldn't happen to be Matthias's kid?
you=I didn't know my father was known in this part of the Kingdom. My name's %n.
him=The kingdom's smaller than you think. I'm Reginald. I worked with your old man on the Skybridge project, back before your time. How is he these days?
you=Surviving, like the rest of us.
him=Glad to hear it. Say, unless you're just passing through, pay a visit to Jameson over at the Frothy Tankard Inn. He served at Skybridge with us too. The two of them were best of friends. Hells, Jameson might even put you up for the night free of charge.
If you talk to the guy again, he'll say something different. The engine will display the lattermost dialog option where the requirements are all met.
him=Frothy Tankard Inn is right on town square. This road will take you straight to it. I'm sure Jameson will have plenty of stories to share about your father.
Now here's an example of how quests might work with dialogs.
her=There is a storage room under the cathedral ruins. There should at least be a few sacks of grains, if the plague rats haven't gotten to them first. It would buy us a couple more weeks here... but don't go risking your neck on our account.
her=There must be a safe path to the cathedral storage rooms...
Campaign status checks could also be added to map events.
# if on the "sack of grain" quest, drop it here
msg=You find a sack of wheat grain. Maybe luck has turned around for those refugees.
And quest turn-in:
her=You've found food! I don't know what to say, or how we could possibly repay you.
So, the possible fields in a dialog node:
Campaign statuses will be checked or set in various ways to create stories and quests.
- Map Events might only occur on a specific status, or set a status
- Enemies might only spawn on a specific status, or set a status when defeated
- The Log menu will display reminder text based on current statuses
Examples of the kind of simple connections possible with this system:
- Boss treasure chest only openable if the boss is dead
- Story bosses that stay dead
- Conditional map teleports to make map phasing (e.g. village burns down, next time you enter that area it actually loads a different map)
- Doors that require specific keys to open
- Chest drops a quest item if you're on the quest, otherwise it drops random loot
The status booleans will be written to the save file. The first implementation will have 1024 status fields. I'll store them as plain text hexadecimal like this:
Flare on Ubuntu
If you're interested in trying Flare on Ubuntu, this article from Ubuntu Vibes is a great place to start: How to Download and Install Action RPG 'Flare' on Linux.
Config Settings Files
This was way overdue, but now there are finally some main config files. Now the following items are configurable:
- video resolution
- background music volume
- max frames per second
This is what happens when I get too much extra time -- I start changing things randomly!
I have renamed the following stats (across the game source code and data files).
- Magical is now Mental
- Health is now HP
- Mana is now MP
I've done this to make the engine genre-neutral. An additional reason for this is to make populating the Powers menu easier, thematically -- I can slot Mental Offense or Mental Defense powers that aren't necessarily Magical in nature. Later when I add translation support, it will be possible to change the "Mental" label back to "Magical" (if desired).
Also, I did this update with bulk find/replace. I'm sure I broke stuff in the process. If you see something wrong lemme know.
Power Tree Rearrangement
From the change log for r298:
Trying a rearranged Powers tree. - Lore removed, in its place is Channel - Return removed, in its place Block - Blood Strike moved to where Block was - Immobilize added where Blood Strike was - Haste and Cleave swapped - Piering Shot and Multi Shot swapped Additionally with this revision: - New art for Channel - New icons for the rearranged tree, and new base Powers menu - Refactored "requires_ammo" into "requires_offense_weapon" - Added requires_physical_weapon, requires_mental_weapon
Playtesting levels 1-4
Tonight I playtested each "pure" build from levels 1-4. It's a vulnerable area, especially in a non-class-based system where a player might make unusual attribute choices. Later levels aren't so bad, especially once a character starts mixing in secondary attributes.
Pure Physical (straight to longsword proficiency)
The higher health pool definitely helps this build. I didn't really need potions until I got to the cave. I was a bit reckless around some spitters so I used up a few potions, but overall I felt like I could run around and destroy stuff. Pulling using line-of-sight and bleed kiting was effective and fun.
Pure Magical (straight to staff proficiency)
I had to conserve mana at first (picked off the slow zombies with a rod bash) but it felt fun and precarious. Once I could afford it I bought a handful of mana potions that kept the action going. Keeping shields up at level 4 was important for survival.
Pure Offense (straight to longbow proficiency)
This character has a very easy time at early levels. When he starts facing ranged creatures (skeletal mages and antlion spitters) he can easily be two-shot, so cautious and smart play take over. Feels like it's lacking a mana-cost power at levels 2 and 3; a high-powered arrow shot could help.
Pure Defense (straight to steel armor proficiency)
By far the worst build in terms of fun. I died a lot until I could afford a buckler; after that I was able to stay alive by blocking and counterpunching. Survival becomes easy with a buckler and block, but it takes forever to kill anything. Block/counterattack does have a fun feel to it, but it definitely makes more sense with Physical sprinkled in. I'm not worried about the deficiencies here; nearly all players build around their main weapon first and add defense later.
Balance - Part 2
I'm testing several balance changes.
- Starting HP and MP is now 12
- Each level of Physical now grants +8 HP and +4 HP regen
- Each level of Magical now grants +8 MP and +4 MP regen
- Shock now costs mana again
- HP Regen, MP Regen, and Crit are doubled on gear bonuses
The result I'm looking for: I want basic Physical characters to feel sturdier and Physical Defense characters to feel like damage-soaking tanks.
Low-level mages and archers will have lower health. Mages have an easy Heal and early Shield but have to manage mana. Archers have no easy healing but no resource management (e.g. ammo).
In r295 I have a new low-level potion (25 points, 25 gold). The high level potion has been changed (75 points, 75 gold).
Balance, the RPG task that never ends! But has to start somewhere.
If you've played Flare enough times, you know that melee builds are far too weak right now. Over the last few days I've been trying to fix this with Powers, but now I realize it's the wrong way to go.
A new revelation: characters should be fun to play and manageable even if you take away the fancy powers. A player should be able to just basic melee attack or basic ranged attack to victory. A Physical build should feel physical/brutish instead of dying in only a few attacks. Even the Magical build has a mana-free missile right now just to make its core gameplay doable.
So this weekend I'm going to be pondering the core game stats, and ways to keep something of a balance.
- Fixed frames-per-second throttling, should now correctly run at a max ~30fps.
- As a result of the above, many animation speeds had to be changed. I'll tweak more of this later.
- As a result of the above, the game should feel faster on old machines.
- Can no longer interact with NPCs if the hero is dead
- Enemies abandon combat when the hero is dead
That's enough damage for one day. I will be out of town this weekend, and probably without a constant internet connection.
NPCs with Dialog
morris989 sent in a Flare patch to add talking NPCs. It's a simple implementation, but it adds the needed hooks to expand into more interesting conversation options later. Check out r280!
A new class named GameSwitcher has been inserted. It is in the main.cpp. GameEngine is removed from main.cpp and is not a child of GameSwitcher. The new class handles the main game modes (anything that takes up the entire screen and controls). Basically it just calls the logic() and render() for the current game mode, and will perform various checks to transition to new game states. This is the place where the Title Menu, New Game (character create) Menu, and Load Game Menu will exist.
This is how I want the menus to interact:
Executable launched -> Main Menu Main Menu -> New Game -> Load Game -> Exit Game (executable ends) New Game -> Game Play -> Main Menu (on cancel) Load Game -> Game Play -> Main Menu (on cancel) Game Play -> Main Menu (Save and Exit To Title)
Flare v0.12 "Vendors" Released
It's only been a couple weeks but v0.12 is ready! Here's a quick list of changes since v0.12
- Vendors have been added. Buy and sell items! There is one vendor at the spawn point and another vendor in the cave.
- Voice-acting for the vendor by Brandon Morris (Augmentality)
- Male vendor 3D model by TiZiana
- Potions can be placed on the Action Bar. The number of remaining potions is shown. When you run out of that potion, the icon goes dark. Thanks to help from LongerDev.
- Support for other powers on items has been added. This opens up the possibility for interesting items in the future (e.g. teleport boots).
- Action is no longer paused when menus are open. This behavior can be changed in Settings.h. Contributed by LongerDev
- Basic support for Mouse Movement added. Edit your save file and you'll see a mouse_move option. Contributed by Cheshire.
- Mouse-over on creatures shows a menu with the monster's name, level, and health. Contributed by Cheshire.
- Added a basic cmake file to the source distributable. Also rearranged the folder structure to make things easier for novice users. Thanks to gnurobert and ceninan for help on this!
- Dying now has a penalty: 50% gold loss
- Crits are more powerful and always do more damage than a regular attack.
- Click here for a full list of credits.
v0.12 Gameplay Video
v0.12 Release Candidate
I've packaged (win, osx, src) what might be version 0.12. Will do an official release tomorrow. If you'd like to test before then, drop me a note or try building from svn.
Restructuring for easier Make
I'm slightly restructuring the files/folders of Flare so that the checkout and source-packages more resemble the final structure needed to build and play the game. The "resources" folder no longer exists and all its subfolders are now moved up one level.
Vendor Ready For Testing
I've finished the basic Vendor system. There is now a vendor standing near the spawn/starting point in Goblin Warrens. He sells potions and level 2-4 normal quality items. He also has a random stock of items based on his level (same calculations as game loot).
To make Gold more interesting I've added a death penalty -- 50% gold loss upon death.
I've gotten this question more than any other in the past two weeks: "Why aren't you promoting Flare more?"
Short answer: it's coming. Sometime this summer I plan to do wider promotion of Flare.
Some people are confused: why would any project want to wait to get more attention? Well, even the tiny trickle of Flare feedback I'm getting these days is taking up a significant portion of my time. Not that I mind -- the feedback I'm getting is often earnest and helpful, and the volume is such that I can respond to pretty much everyone.
I'm not a "sales" guy -- I'm terrible at promotion because most of the time it just isn't genuine. Perhaps you can help me. I'd much rather see Flare grow organically. I feel bad signing up for a new forum to talk about Flare, but I'm comfortable talking about it to the communities I already know. Maybe you are part of communities that would enjoy this game: if so, share a link.
I'm not here to make a dime. I will probably never try to make a dime from this. I just want to make nice things; maybe someone else will enjoy them if I'm fortunate. Hopefully I'll find more people who love the genre enough to craft worlds with me.
Item Powers on the Action Bar
Items with Powers can now be used through the action bar. Details from r260:
- Potions can now be put on the action bar.
- The number of remaining potions is shown on the action bar.
- If you have no remaining potions of that type, the potion icon is darkened/disabled in the Action Bar.
- ItemDatabase no longer has an activate(). It is now handled by PowerManager.
- Powers can be attached to items. This is how potions are done as well.
- You can put permanent powers on non-consumable equipment.
- These items can be dragged onto the Action Bar to Use their Power.
- Added a Lightning Rod (item 1021) to show a spellpower on a weapon.
- Added Teleport to the Boots of Testing (item 1022) to show another item power example.
- If you remove or unequip a power item, that power is darkened/disabled in the Action Bar.
- Increased the number of total allowed powers from 128 to 1024
Special thanks to LongerDev who helped me immensely in figuring out the best way to tackle action bar items!
Having a menu open no longer pauses gameplay. This option is set in Settings.h.
I'm starting to build the Vendors menu. For now, for easy testing, I made a hard-coded vendor menu open when you press V (for Vendor). Ctrl+Click an item to buy it. I will add drag/drop buying and selling soon.
Here's a list of art I'd like to see in Flare soon.
A good grassland tileset will, of course, have excellent grass -- this is way harder than it looks. Have a look at my first attempt at grass and water tiles. It's not bad, but it's too noisy when tiled on an entire screen. It needs to be muted to fit as a non-distracting background. Also, that translucent grass sticking above the tile doesn't work well when removing the alpha layer. The final grassland tileset should avoid these issues.
The grassland tileset should contain grass-water transitions and grass-cliff transitions. It should probably also contain dirt roads, wood or stone fences to border the roads, wood road signs, and wood footbridges. The set could have various shrubs, weeds, lone trees, odd rock structures. Maybe some forgotten and unexplained monuments -- a carved statue, a circle of stones, abandoned campsites, and more. It might need a few special "exit" tiles -- a cave opening that leads to a Cave Tileset level, a thicket of trees that leads to a Forest Tileset level, etc. Perhaps this Broken Tower could be used as a Dungeon entrance.
The forest tileset might be the most challenging to get correct. I want a thick, mystical forest. The player should get the sense that he is traveling in the shaded underbrush. Thick trees and brambles form "walls". The walls can't be made by just combining lots of trees. Trees can't also be too tall and obstruct view. Diablo 2 Act 3 did something sorta like this, but I want to go for a more "deep in the woods" feel (rather than simply traveling along the river or treeline). I'll probably need the help of a great concept artist to get this tileset going.
I might want this tileset to be more fantasy-oriented than the others so far. There should be huge gnarled roots, weird glowing plant/fungal life. It should feel like a fey place of elves, fairies, dryads, centaurs, etc.
This Temple Entrance could have a place in this tileset.
I made this Medieval Building Tileset. I'll probably re-render them for Flare using different lights. Some of the Grassland tileset can probably be reused here (e.g. grass and dirt paths). There can be a few unique buildings added. Maybe a series of shop signs. Because of the way the engine works (small maps connected by teleport/transition points), the village should probably be surrounded by a wall, fence, natural cliffs, or something of that nature.
Lots of small bits to bring a village to life will be needed here. I think it's best if the village is designed by a concept artist first. That way the village looks less like a random assembly of tiles and more like a planned, living town.
Those tilesets -- dungeon, cave, grasslands, forest, village -- would be a solid start to building a world. I already have music ready for those. Many more tilesets can be added in the future. Here's some ideas:
- Natural outdoor tilesets
- Pine Forest
- Fantasy outdoor tilesets
- Crumbling Bridge Highways
- Good-guys Castle
- Bad-guys Fortress
- Magical Destruction/Fallout
- Fantasy indoor tilesets
- Inn, Shop, Home, Tavern
- Elemental Cavern
- Evil Fortress
- Wizard School/Tower
Of course, most everything in that list is a fantasy trope. Reminder: I'm mainly building an engine at this point. I'm much more curious to see unique, imaginative tilesets.
Current Flare has zombies, skeletons, antlions, goblins, and minotaurs. Here are my other must-have creatures, which have been in the Bestiary list since before Flare v0.01 was released.
Maybe I liked Dragonlance too much growing up, but I want heavily-armored draconic humanoids in my game. Originally these were going to be the main foes of my game, but I've kinda backed off that concept. In fact, it may be more appropriate to drop Dragonmen and use the concept to make a faction of heavily-armored humans instead. So the inspiration here is: Dragonlance's Draconians, Borderlands' Crimson Lance, Fallout's Brotherhood of Steel, etc.
I want Archon-style elemental creatures in the game. Fire and Ice variants at least. If I end up going the Western Element route, add Earth and Wind options. If I go the Eastern Element route, add Earth/Metal/Wood. Most likely I'll just start with Fire and Ice though. These creatures might make heavy use of particle effects, so they might require full alpha layer art.
Wyverns can double as bat-like creatures or as dragon whelps with only a few minor changes. I like this Wyvern concept by Benalene. The wyverns would be pretty small in-game. They would be the first flying creatures in game, ignoring any low-obstacles during movement.
OGA Asset Creatures
There are a handful of creatures that can be made using mostly OGA assets. There probably are many more; this is just a quick perusal.
- Ghouls -- crawly undead that stun on attack (classic old-school ghoul paralysis). These should be feared because they can lock-down a hero. This ghoul model by Riidom is perfection.
- Giant Spiders -- a fantasy trope, but throw in a ranged web immobilize attack and some poison and you have a great monster. Sunburn has a great spider sculpt that can be polished for Flare.
- Death Knights -- this character by Santiago Calleriza is begging to be made 3D. When I have a free weekend I'll probably do it myself. Would make a great boss character.
- Lizardman -- this humanoid reptile could use some tribal dress, and would make a great humanoid enemy race. There's also this lizardman, and both could be used for variety.
- Executioner -- this executioner would make a solid boss, or even an elite minion of a later boss.
- Scorpion -- this scorpion would make a great desert beast
- Antlion Demon -- this antlion demon would make a unique boss.
- I don't know what this is but I like it
- Insect Humanoid -- love this model
- Vampire -- this model would be perfect
- Vampiress -- and this one. This pair could also make interesting townsfolk.
Another v0.11 video: this time showing off more powers.
Why yet another Diablo-like?
Flare is mentioned in this post about 4 problems with FOSS games. The author says "I’m actually pretty psyched about FLARE, but if I was a Windows user I’d probably be thinking 'why not just reinstall Diablo?'"
Great question -- once that I don't have a good answer for. It's a fool's quest to try to beat or match Blizzard, even the Blizzard of 15 years ago!
I'm doing this because I'm having fun. Writing low-level game code is how my brain spends its spare cycles. And of the genres of game I'm interested in, 2D isometric action RPGs are probably the most interesting/ambitious.
Staying close to the formula is helping keep my engine on track, for what that's worth. If I'm lucky, someday, people will use Flare to tell their own interesting stories. I don't even have a storyline in my current plan. I intend to create enough assets and code to make basic storytelling and world-creating possible. The genre is still ripe for potential, even if Diablo was a perfect game.
Flare v0.11 at Free Gamer Blog
I'm always excited when someone at Free Gamer Blog talks about Flare. Thanks for the plug, qudobup!
And some Russian Blizzard fans...
Flare r247 binary for Windows
I've released an out-of-band, UNSTABLE AND EXPERIMENTAL binary of the latest code -- mainly to show off the contributions by Cheshire.
If there's demand for an OSX binary of the same, I'll release it too.
Pavel Kirpichyov "Cheshire" has submitted a patch that enables mouse movement to Flare. For those of you who prefer that method, it's a great start! Look for revision 237 or later. To enable mouse movement, set mouse_move=true in your new save file.
Cheshire has submitted another patch! This one adds an enemy HUD on mouse-over. It shows the enemy's name, level, and current HP. Look for it in revisions 239 and later.
by Sunburn. Warning: a couple spoilers of the new Cave level.
Over 1500 downloads in 2 days
No real publicity or advertising -- basically there are hundreds of people very interested in the project and its progress. Excellent!
So the obvious question....
Every time I put out a new version I get a flood of great feedback. Now that we're seeing what kind of Powers can be done easily, it's tempting to think about making new powers and replacing old ones. It's tempting to rework the entire Powers menu and make it talent-based with optional trees of powers. That may come eventually. But for now it's important to actually finish something -- I have a constant desire to replace just about everything in the game, but it's far more fun to actually have something worth playing.
The To Do List says that Vendors are up next. It's a much-needed addition for two reason: (1) a way to get the correct weapons at early levels and (2) potions! It's pretty hard to think about combat balance when a fundamental feature like "buying potions" isn't implemented yet.
I'll probably do Vendors as a left-screen menu. Perhaps the menu will show the name of the vendor as a caption. There will be a large block of sale slots (similar to the Inventory menu). Probably drag and drop to buy or sell. The starting vendors might have: dagger, shortsword, leather armor, buckler, wand, rod, slingshot, shortbow, health potion, mana potion, and 10 random items level 1-4.
Vendors can have a fixed item list plus a number of random items. I'll probably use the Loot algorithm to give vendors random items -- just assign the Vendor a Level and he'll carry random items +/-3 levels.
I'll do a new implementation of Potions in v0.12 that uses the Action Bar. The Action Bar is not storage (like Diablo's belt system) but shortcuts to powers and items (like WoW or Torchlight). Put a potion on the Action Bar and it will show the number of potions in your inventory. It should be grayed-out or darkened when there are zero potions remaining.
Potions can be implemented with Powers. Perhaps with a new "requires_item" or "consumable" field that tells the system to remove that item upon use.
Flare v0.11 "Enemy Powers"
Flare v0.11 is up! It's been a long, busy four months and I'm finally back on track. The focus on this release is Enemy Powers!
- Enemies have four slots for powers. New enemies shoot bows, cast spells, throw javelins, and more!
- Most powers moved to a config file.
- New: Cave level (head east from the Goblin Warrens. Creatures are level ~6)
- New creature art: skeletal archer, skeletal mage, fire antlion, ice antlion, antlion hatchling
- Some magical ranged weapons have Ice and Fire Ammo...
- Various bug fixes and new minor features
Special thanks to these contributors:
- Brandon Morris composed the Cave theme
- Thane "pennomi" Brimhall scripted the Cave enemies and events
- Gordon "mogrohl" patched the looting-while-dead bug
- ferrer patched uninitialized music variables
- BartK contributed new zombie sounds ("Braaaains!")
- Full list of credits here
v0.11 Release Candidate
Google Code revision 232 represents the release candidate for v0.11. As far as I know, the code features I want are complete. I may still add a couple bug fixes. I'll also add a few tweaks to pennomi's cave map.
Items that modify Powers
Items may now modify powers. This was mainly implemented to have various projectiles by bows e.g. to have slingshots shoot stones.
I converted all fire/ice resist slings and bows into weapons that shoot fire/ice missiles (and I switched the resist on them... a bow that shoots fire gives resistance to ice). This isn't just for show -- it adds that elemental trait to attacks. These weapon powers show up as Green Text on the weapon tooltip. The system can be used to add things like bleed/stun to weapon attacks. It can't change the base power type though (e.g. you can't make a melee sword shoot missile fire... yet).
Enemies with Elemental Resist/Vulnerability
The fire-shooting bows aren't just for show. Now creatures can resist or be vulnerable to Fire and Ice. Generally, if a creature shoots ice spells it is resistant to ice but vulnerable to fire (and vice versa). So Skeletal Mages that shoot Ice Shards take double damage from fire (e.g. Burn spell or fire weapons). The new fiery-colored antlions that spit fire take half damage from fire and double damage from ice.
New Creature Art
I added fire, ice, and hatchling versions of antlions. These are simple recolors/resizes.
Monster Levels and Power Definitions
Two new Wiki pages have been added.
Monster Levels is a guideline of what base stats a monster should have at each level. It's kinda untested at the moment, so these numbers will shift as the game matures.
Power Definitions is a list of all the available elements in the powers.txt file. This is a handy guide to creating new powers.
Fireball (a ranged magic spell cast by some enemies) has new art. I figured out that fire has to be significantly turbulent to register as animated, especially when flying across the screen.
This isn't something I planned on doing until later, but I added on-hit and wall-hit after effects on spells. Now that's how Blood Strike creates its blood spurt on hit. Some elemental spells have on-hit and wall-hit sparks. And finally, arrows stick into walls. This actually helps with aiming -- sometimes a missile will clip a wall or corner and it wasn't obvious before. I think the result feels much better and adds a lot of needed polish.
Since I've come this far, I want to change the way ammo works on ranged weapons. I want to make ranged weapons have a specific power as ammo. Then I'll implement slingstone missiles and arrow missiles as separate powers. This should also let me create more powerful-looking missiles for magic bows.
I was able to update several items this weekend (revision 219).
- Created a nice spear animation
- Created a goblin spearman to match. You'll find two in the Atrium and two in the Complex.
- Updated the cave tileset to include exit markers, crates, barrels, chests
- Linked the Goblin Warrens to the Cave Level 1
- Enabled fire/ice resist gear. Damage reduction due to resistance is calculated first, then regular armor absorption is applied.
Here's what I want to finish for v0.11:
- Create a new Shoot animation
- Populate the cave level
Enemy HP Lowered
I lowered enemy HP across the board. It shouldn't be a chore to dispatch one enemy of equal level -- this is an action rpg, after all. Enemies that take several hits will now stand out and appear tougher. This effect was present in Diablo, where by far most enemies died in one attack.
Cave Test Map and Speed Improvement
I'm working on a new cave map. It's not populated yet but it's looking great. I also added SDL_DisplayFormatAlpha() calls when loading SDL Surfaces. This seems to greatly improve performance, at least on my dev machine (OSX) -- hopefully it's going to help on more platforms.
Level Cap raised to 17
I've gone ahead and raise the level cap to 17. This allows one hero to unlock the entire proficiency and powers trees. The XP scale will be going through several iterations but should be fine for alpha purposes.
Enemy Power Cooldowns
Added cooldowns per power slot (currently melee physical, melee magical, ranged physical, ranged magical) for enemies. While doing so I noticed that enemy ranged powers weren't using the global cooldown. No wonder they could shoot/cast so quickly! I'll check in the update tomorrow.
One more item off the list. Flare 0.11 is way overdue!
Dispelling the Cave Magic
High Poly Modeling
I want to take the time to do nice, polished, high-poly models. But instead I'm putting that time into Flare. The sprites I need are so small that quality models aren't really necessary. A superb model might take me 80 hours; I could do a lot of Flare code in that time.
So I put together a simple skeletal archer and skeletal mage. They'll serve their purpose: get something working now. It can be made prettier later, or maybe in a future game.
This has been the longest time span between releases for Flare. I hope to fix this soon. A few more things to go:
- Goblin magic-user
- Parametrize multishot, freeze, vengeance
- Cooldown per enemy power slot
- Monster line of sight option
- Cave map
I've given monsters lots of great powers, but it seems silly for identical creatures to throw out very different powers. I want to be proud of each release... so it's time to make monster varieties.
- Goblin witchdoctor
- Skeleton mage
- Skeleton archer
I got to play several great indie games in 2010. Even some very small experiences have left a strong impact on the way I see games.
I've put more hours into Minecraft than any other game this year, indie or not. My main save world hasn't changed in weeks though. I built myself a luxurious castle and feel like a conqueror, but now I'm quite comfortable. Feels like I "won". Maybe I should build a town surrounding my castle walls, or nearby cities or dungeons.
Minecraft is a 3D experience that isn't overwhelming. The interface is simple, with the world divided into 1m^3 blocks. Most of the gameplay is taking a block or placing a block. Yet, with a simple set of blocks one can make anything. Minecraft also manages to make darkness scary again, without cheap tricks. Finally, Minecraft shows that a well-done algorithmically generated world can be inspiring.
Super Meat Boy
To me, Super Meat Boy is all about polish. The cutscenes are well-done and add a specific attitude to the game. Meat Boy is squishy, bouncy, and leaves red trails and splashes everywhere. Accomplishments are loud and satisfying. Controls are impeccable.
Replayability is finely tuned -- there are dark versions of most levels, secret levels and unlockable characters, rewards for doing levels faster (A+) or harder (bandages), and stats tracking for overall progress and number of deaths. This keeps many players at it until they have accomplished everything possible.
Mighty Jill Off
I played a lot of Mighty Bomb Jack back in the day so I'm glad to see that movement mechanic brought back. I actually enjoy the game's short length -- it does well to explore the basic combinations of obstacles and movement. Here's an example of a well-contained experience that doesn't take years to produce.
With Flare I took on a project at the edge of what I can accomplish -- been working on it a full year and still have a ways to go. After Flare I will probably make several small games. Mighty Jill Off is inspirational and shows how a game doesn't need hours and hours of content to be fun.
Of course I also like the human themes explored in the very simple story. Sex doesn't have to be gratuitous, or vanilla, or absent in video games.
Every Day The Same Dream
To me this stretches what games can be. It's an emotional piece of art with minimalist graphics and interaction.
Refactoring Powers II
I've been working on some tedious refactoring. I've got most of the powers moved to config file.
Some powers are a bit busted, temporarily. E.g. slingshots will shoot regular arrows. I'll probably make a new graphic that works for both slingshots and arrows.
The powers not yet converted are the complicated ones: Multishot, Freeze, and Vengeance. Multishot will become a "multi-missile" base type where the number of missiles and the angle between each are options. Freeze will have a "repeater" base type where the number of hazards and the distance/delay between each are options. Vengeance will have an on_block component and a requires_buff component, plus will require a separate "buff" spell I think. I might have to make "buff" a new base spell type.
I'm getting some down time. Hope you are too!
Big Picture: CC, EFF, FSF
Making and playing games are great hobbies. On terms of global importance, though, these things are pretty small.
This week four important individuals became backers of Justin Nichol's Fantasy Portrait Marathon:
- Mike Linksvayer, Vice President of Creative Commons
- Joi Ito, CEO of Creative Commons
- Lawrence Lessig, founding board member of Creative Commons and former board member of the Electronic Frontier Foundation
- Richard Stallman, founder of GNU and president of the Free Software Foundation
I'm thrilled that their portraits will appear as NPCs in Flare. In return, I support these important organizations and I hope you will as well.
Creative Commons (CC) is an organization that creates art content licenses which allow creators to give various permissions to users. These licenses are a valuable part of our remix, mash-up, and sampling culture.
Electronic Frontier Foundation
The Electronic Frontier Foundation (EFF) fights for user rights the world over. They focus on issues like internet free speech, privacy, and fair use.
Free Software Foundation
The Free Software Foundation (FSF) promotes computer user freedoms through licenses that grant and protect freedoms, free software development, and campaigns against DRM and software patents.
Project renamed to FLARE
This project is being renamed to FLARE (Free/Libre Action Roleplaying Engine). Stay tuned for more info...
Portraits of Giants
I previously mentioned that Justin Nichol is doing a Kickstarter project to make Creative Commons Fantasy Portraits of donors.
The idea is simple: Justin needs tuition for school next semester. He'd rather create art for video games than work at Starbucks. So, donors can pledge some cash and in return get a digital painting of themselves. These paintings will be released under the Free/Libre license CC-BY-SA (and GPL for compatibility with games like Wesnoth) and are designed to fit with the style of FLARE. They will be PC portrait choices or NPCs in the final game (probably displayed during conversations).
Well, only a few days into the Kickstarter we see some interesting names: Joi Ito and Mike Linksvayer -- the current President and Vice President of Creative Commons! Somehow they've gotten wind of the project and thought it's a neat idea.
We're thrilled! And it seems only fitting that giants of the Free/Libre, Copyleft, and Creative Commons community make guest appearances in my free-licensed game. So I joke: what if we ask other people? Stallman, Doctorow, Lessig... I know those guys are busy. It can't hurt though, right?
Today I get an email response from Lessig that says "done". Holy hell, Lawrence Lessig has commissioned a fantasy portrait of himself and will appear in my video game! Justin, the artist, is beyond excited too -- his portfolio will forever contain commissioned portraits of three giants in copyleft culture. And I'm excited because Lessig -- one of my personal heroes -- will end up as a literal hero in my video game!
I also got an email response from Richard Stallman! He admitted he could not donate towards a project that used the term "Open Source" to describe itself, but would gladly participate or give a nod of approval if we instead agreed to use the terms "Free" or "Free/Libre" to describe it. I've decided to take it a step further and rebrand the entire project. I'll be posting more about this later today.
Once a system is far enough along, any refactoring is daunting. Especially when it involves temporarily breaking code that works well.
I want to define powers in config files. Ideally it should be easy to make new powers similar to existing ones. The config files might get rather long, but them's the breaks. Time to break down the plan:
- Create a config file for Shoot
- Create a new struct to hold power data
- Copy ini file code to load power data
- Rework Missile routine to use this Shoot struct
- Create power config file for Shock
- Generalize Missile routine to handle common missiles
That should get me pretty far. Once I see the generalization for Missiles it should be simple to adapt the same for the other types.
Harder thought will be required for a power like Vengeance. I'll figure that part out later...
Character Creation Screen
Time to lay down my ideas about a character creation screen.
Because of OSARE's classless system, the Character Creation screen is mostly for cosmetics.
So the choices at Character Creation are:
- Character Name
- Character Gender
- Character Portrait
Note, in the future Gender choice could be changed to Race/Gender choice. Each race-gender combination requires its own base model, own animations, and own equipment layers. At first I plan to only support two base options: human male and female.
The interesting bit will be choosing a Character Portrait. If you think hard back to Diablo 1 (or look at a few screenshots) you'll see that the hero sprites have these layers:
- Hero head or helmet
- Base full-body armor
- Main hand weapon
- Off hand item
The other Diablo 1 equipment slots are not shown (two rings and an amulet) on the hero sprites.
OSARE does not have a helmet slot, and the three jewelry slots are replaced with one Artifact slot. Otherwise the display is the same. Instead of the helmet slot, I will be making a set of head choices (e.g. various skin and hair styles). These heads will match the Fantasy Portraits by Justin Nichol.
I removed PayPal as a donation option. I do not agree with their closure of the Wikileaks donation account. Previously they froze Minecraft's account without warning, causing much headache/effort to that indie developer. I simply don't want to do business with them anymore.
Creative Commons Fantasy Portrait Marathon
OpenGameArt contributor Justin Nichol is taking pledges towards creating 30 high-quality fantasy portraits. They will be featured in OSARE as PC portrait choices or story-line NPCs. Additionally these portraits will be uploaded to OpenGameArt under CC-BY-SA and GPL licenses. Finally, these pledges will help Justin attend his next semester at Concept Art Academy in Pasadena.
A $50 pledge gets you a fantasy portrait in your likeness! Maybe you'll even be the first vendor, quest NPC, or villain of OSARE...
Art To Do
OSARE has a few months of alpha code tasks before it's time to really focus on more art. However, that new art should trickle in with each release until Beta.
- Dragonmen with paladin and priest equipment.
- Elementals with fire and ice main options
- Antlion hatchling and queen size variants
- Skeletal archers and mages
- Goblin war chiefs and shaman
- Minotaurs with tribal and armored options
I'm on the lookout for existing creatures I can add to osare. If you have an open-licensed creature and want to see it in my game, let me know!
There are plenty more fantasy-standard creatures I'd like in my game. Ogres, dragons, centaurs, gnolls, demons, etc. all deserve a spot in osare.
The Caves are coming in v0.11, but there are plenty more tilesets I want to do.
- Ancient Bridges
- Temple Interior
- Wizard Academy
- Villain Fortress
I want to add hammers and axes, both using Physical requirements. They'll basically operate the same as swords in my current loot setup. This would make physical weapons much more common than other weapons. That's okay by me -- it's harder to survive anyway when you have to get into melee range to kill anything.
- Club (Phys 2)
- Mace (Phys 3)
- Hand Axe (Phys 3)
- Hammer (Phys 4)
- Axe (Phys 4)
- Greathammer (Phys 5)
- Greataxe (Phys 5)
I want to have visual variants on all items. Each weapon/armor should have a mundane, high quality, and epic art version. Maybe a few color variations for each.
This changes almost daily but it helps me to write things down. The more I write down, the less I have to juggle mentally.
- four power slots per enemy
- various power fixes for creature use
- add slot-based power cooldowns for enemies
- move all power data to config file
Some things will slip to later releases. It's easy to forgive creatures for being kinda unintelligent if they have interesting powers.
What this release will allow is an explosion of creature variations. To help with that I hope to include several variations on existing creatures. E.g. I want a skeleton variation that is obviously a spellcaster, and one that is obviously an archer.
I'll add at least one cave map too. If you've played osare as much as I have, you're ready for a change of scenery.
Timeline? I'll be traveling this weekend. Hopefully during the down time I'll get some code done. v0.11 should be ready early December.
2010 has been the year of OSARE's alpha development. I released v0.01 on January 1st, 2010. I've almost been able to do one release per month. Note that OSARE has been my priority #3 at best: work and girlfriend come first. So I'm pleased with this pace.
OSARE still has big milestones left to go. If I'm only concerned with essential features:
- NPC Dialog
- Simple Quest System
- Title Screen
- Load Game Screen
- Character Creation Screen
Glance at the list and you'll notice that it's mostly about menus. The core gameplay -- the action part of the game -- is already near completion. I would love to have those things done by May 2011 (and I think it's doable). At that point the project might be (gasp!) Beta.
Development will still continue as-needed. It's important for me to deliver a real game, instead of making tons of game types possible. These things are not going to be a priority. I probably won't be needing them for my first osare game. Essentially -- these features are neat, but distract from the goal of having a great action rpg.
- Dialog trees
- Reputation system
- Crafting system
- Minigame (e.g. fishing) system
- Scriptable cutscenes
- Puzzle style bosses (e.g. Zelda)
- Pets or hirelings
- Achievements and unlockables
Playing with enemy powers is far more fun than I expected.
If you check out the latest update you'll find a few bizarre monster combos. My favorite is teleporting antlions.
Making Powers Configurable
v0.10 added hero powers in a pretty crude way. I added power variables as needed until the entire first set was complete. With that finished, now I need to move all the powers out to config files.
Power config files will contain variables like name, description, requires_mana, animation type, graphics and sounds, etc. Then I'll have to modify the PowerManager class to handle any variation on powers, instead of branching on specific powers. PowerManager will also handle an arbitrary collection of images and sounds.
The Powers menu will be changed under the hood. A config file will allow slotting any power into the given slots. Powers could be swapped out. New powers could be added for even-numbered stat combinations. In the future, the entire layout of this menu will be configurable (but probably constrained to the given window size).
Each power will still rely on a base type. Current base power types:
- consume (for single-use items like potions)
- nonDamage (various special effects)
- missile (Shoot, Piercing Shot, Shock)
- missileX3 (currently only used by Multishot)
- groundRay (currently only used by Freeze)
- single (nonmoving area attacks that are dangerous on a single frame, like Burn and Quake. Includes melee attacks.)
New power types will simply be added as needed. I don't mind having base types that are very niche (only used by one power) but it would be nice if I can generalize them (e.g. turn Missile x3 into MultiMissle that can handle X missiles separated by Y degrees. Should be possible to make a multimissle spell that, for instance, shoots missiles out in a complete circle around the player). Ground Ray will still be pretty niche, but at least similar powers can be done with a different visual style (e.g. a flame wave or shockwave).
Hooks will need to be added for powers that work in special ways. E.g. Block is an entire state, not just a power that occurs briefly. Vengeance is a power that is activated and expended in areas of the code unrelated to Powers in general. In the case of Block, it might simply need to be its own power type. Vengeance could belong to a new class of powers that trigger upon attack (Life Stealing could be added to this type).
All this effort so that we can easily slot powers for monsters...
Enemies don't have PMOD stats in a meaningful way. Instead, enemies will have four fixed slots for powers.
- Physical Melee (usually a melee swing attack)
- Physical Ranged (shooting a bow/crossbow or throwing a projectile)
- Magical Melee (a close-ranged spell)
- Magical Ranged (often a missile spell)
Furthermore, enemies will have % chance per frame of activating these powers. This % can be zero (e.g. some creatures can simply have no magic, or no ranged). First, the enemy will determine whether he's in melee range or physical range. Then, a random chance to active the appropriate powers.
Each power (in the config file) will have a unique numeric ID. Then, each enemy file will allow assigning these power IDs into the four creature power slots.
Further behavior will be determined by simple % chances to act. E.g. some creatures will favor staying at ranged, so they will not approach the hero (instead, staying back and using ranged powers).
For those wondering, this is the file spec:
The first line is the name of the .png file for the tileset. It's assumed this file will be in the images/tilesets folder.
Each line after that contains the following data:
- index is a two-digit (always two-digit) hex value from 00-ff. This corresponds to map layer data in the map files (note, often the map files are encoded in decimal instead, so you might have to do the conversion to match them up)
- x,y is the top-left corner of this tile image
- w,h is the width-height of this tile image
- offset_x and offset_y describe where the tile should be drawn in relation to the base/floor tile slot. Assuming a rhombus-shaped isometric tile, the offset (0,0) is the exact center of the rhombus. Screen left (-x) and up (-y) are positive offsets.
Tilesets are not arranged exactly the same way each time e.g. swapping tilesets on a map does not yield a usable map. But the tiles are put into these basic categories. (The categories above 0f are not enforced in any way, this is just to help keep them organized)
- tiles 00-0f are reserved for collision types
- tiles 10-3f are floors
- tiles 40-7f are walls
- tiles 80-bf are standalone objects
- tiles c0-ff are oddly-shaped, multi-tiled, or special tiles
The first version of the Cave Tileset is complete. Check it out over at Open Game Art! I still need to create the tilesetdef file so it can be used in-game. I might get around to that tomorrow.
Rather than create full cave maps now, I'm sort of doing cave room sketches in Tiled. Putting together interesting set pieces. Then, later, it's just a matter of copy/pasting and connecting them up to make larger, thematic caves.
In the above render I'm experimenting with a serene sort of cave with a monolithic rock surrounded by water. I love when game maps have landmarks that don't require explanation but instead leave you in wonder. Also, you see I'm using cave litter sparingly. Too much and the scene is cluttered; too little and it seems empty and unfinished.
Here's a hub room for a mining operation. Would work great as a classic "first dungeon" for a young, frightened adventurer.
You are in a maze of twisty little passages, all alike.
File Format Changes
I made two small changes in some of the file formats. I wanted to make these changes now before too many people rely on them. Basically these new values make much more sense.
- Save game spawn line (x,y) location is now tiles, instead of map units
- Map Event location (w,h) is now actual tile width/height, not (w-1,h-1)
If you try the latest code and want to preserve your save game, simply delete the entire line that starts with "spawn=". This will cause you to spawn at the beginning of the starting map, with everything else intact.
I put up a new Google map showing contributors from around the world. It's rather blank so far; I'm contacting major contributors now to get permission to pin them to the map! (If you have contributed, please contact me!)
Isometric Tiles Tutorial
Added a tutorial on how to create good-looking isometric 2D tiles using Blender. This should help anyone get started in making custom art for OSARE (and most other isometric games).
I have next week off from work. Staying at home. Letting the brain rest. So I'm also putting a moratorium on new osare code next week.
Instead, I'll spend the week relaxing and making osare art. I'm hoping to put together the beginnings of two new tilesets: grasslands and caves. I started making grass and water tiles way back, but I think I can improve on them now.
And next up...
Version 0.11 will likely center around monsters. Now that the hero has Powers, it's only fair if we get skeletal archers and goblin witch-doctors.
Features coming up soon that will probably go towards 0.11
- Monsters will have four slots available for powers: physical melee, physical ranged, magical melee, magical ranged
- Move Powers to config files so they're easy to alter/add
- Add A* pathing to help monsters navigate around obstacles
- Enemies enter combat when their nearby ally enters combat
- Render a few equipment variations of existing monsters
Anything much further ahead is wildly subject to change, but here's a rough roadmap to the future. Some of these might be broken into multiple releases.
- NPC Vendors
- NPC Dialog
- Very primitive quests
- Title Menu
- Load/Save Game Menu
- Character Creation Menu
OSARE version 0.10 "Powers" released
New in this version:
- Magic, melee, and ranged powers
- Action bar support for powers
- Click-to-activate action bar and menus
- XP bar on HUD
- Minimap on HUD
- New health/mana bar images
- New creature: Minotaur
- README.txt to help new players
I have most things I want done for v0.10. The only thing I'd want to add in this release is placing potions on the action bar. But seeing as there isn't an easy way to get potions right now, it isn't an immediate priority.
Time for testing. If you try the current source from Google Code let me know what you think.
For this upcoming release I will include a good README file that explains controls and what works vs. what doesn't.
How are you?
I am busy.
I'm considering replacing the "Charge" power. It would just be a pain to implement. I need to replace it with a Shield Bash or a Missile Ward.
I'm hiring a sound effects/foley artist to finish up the remaining power sound effects I need. Please contact me if you're interested. I will update this post once I've found someone.
- Shooting a bow
- Blocking with a shield
- Echoing warcry
- Earthquake rumble
- Force field appearing
Brandon Morris "Augmentality" is helping with these. Thanks!
Too busy! So I squandered my lunch break on this.
[--update--] Added a starfield background (view at 480p) and bullets.
Power Sound Effects
I'm adding sound effects to powers. These are the ones that need effects; crossing them out as I add them to my local build.
- Shoot (slingshot/bow)
- Block (hollow metal thump)
- Warcry (yell echo)
- Shock (electricity) - augmentality
- Quake (rumble)
- Freeze (ice shatter) - bartk
- Burn (fiery blast) - bartk
- Heal (warm sparkles) - remaxim
- Shield (force field)
- Teleport - augmentality
- Time Stop (ticking) - remaxim
First Game World
The first osare-powered game (you're seeing the beginnings of it in the "Game World" section on this site) will be a generic fantasy hack & slash. I'm using Wu Xing as a vague inspiration for the world layout. Examples follow:
The center of the map has mild environments. The earth temple is guarded by a gold dragon.
The east side of the map is springtime, windy, and heavily forested. The forest temple is guarded by a blue dragon.
The west side of the map is autumn. Perhaps mines, caves, mountains. The metal temple is guarded by a white tiger.
The north side of the map is tundra, frozen, glacial. The ice temple is guarded by a black tortoise.
The south side of the map is hot, summer, desert. The fire temple is guarded by a phoenix.
The ordinal directions can be mixes of these. Northwest (Water + Metal) might be my bridge area. Southwest (Metal + Fire) might be volcanic. Southeast (Fire + Wood) might be tumbleweed badlands. Northeast (Water + Wood) might be swamp/marsh.
Working on a side project that's due on 2010/09/30 so there won't be OSARE updates this week.
v0.10 is around the corner. Things left to work on:
- Line of Sight checks on Freeze, Burn, Teleport
- Items on Action Bar
- Clicking on Action Bar
- Adding sound effects for powers
Things that probably will be implemented later:
- Charge implementation
- Lore implementation
- Return implementation
- Cleave graphic
Screenshots and Videos
Most hero powers are now implemented, if in a crude way. I need to add line-of-sight checks for several powers.
Notably missing: Lore (not sure how I want to handle it yet), Return (should be easy), and Charge (could be a mess).
Traditionally in these kinds of games, selling unwanted items means a trek back to the vendor every time your inventory is full. Some games like Torchlight added a convenience feature to allow your pet to handle this errand for you. I'm going one further: just CTRL-click an item in the inventory and you sell it, no matter where you are. This has been implemented in the latest svn check-in.
Perhaps this ruins immersion or simulation, but it's not like hack & slash games are sims. Assume your hero stashes unwanted items somewhere and does the actual transaction when you do reach a vendor. This also removes the real need for a two-way Town Portal and encourages uninterrupted action. I'll make it so this instant-sell can be disabled, in case games don't want that feature.
Added a simple minimap. I hadn't planned to do that just yet but it didn't take long.
I might add a new collision type for invisible walls. This will help mark off exits and keep hidden passages secret on the mini-map.
Added invisible wall type. This is tile #15 (h0f) of the tileset (the first 16, 00-0f, being reserved for collision). This acts like a wall when it comes to collision but does not display in the minimap. Now, map exits appear as openings on the minimap but are solid walls -- this will help with the Teleport spell to keep the player from getting off the map. I'm also using these "invisible" walls to keep hidden passages from being spoiled on the mini-map.
Player/Enemy speed is stored as int coordinates. Diagonal speed vs. cardinal speed is calculated using the Pythagorean Theorem.
There are rounding errors of course. Here is a table of acceptable speed/dspeed for enemies. The hero uses 10,7 (it would more accurately be 10,7.07 which is close enough). Note that when moving diagonal (map coordinates; this looks cardinal on the screen) the dspeed is applied in both directions.
- 3,2 (rotting zombie, goblin)
- 4,3 (skeleton, zombie)
- 6,4 (goblin charger, skeletal warrior)
- 7,5 (antlion, zombie boss)
- 9,6 (skeleton boss)
- 10,7 (hero)
- 13,9 (hero with Boots of Speed)
- 16,11 (hero with Boots of Travel)
Item bonus speed (boots) are multiples of 3. An item with 3 speed actually adds (3,2) to speed.
Projectiles/missiles use floating point coordinates to accommodate arbitrary angles instead of the cardinal+ordinal eight.
- Piercing Shot
- Time Stop
Buffs and Debuffs
These buffs/debuffs are planned for my game:
- DamageOverTime: lose 1 hp per second for the duration (e.g. bleed, poison)
- HealingOverTime: gain 1 hp per second for the duration (e.g. food)
- Stun: unable to move/act for the duration (breaks upon damage)
- Immobilize: unable to move for the duration
- Slow: movement speed halved for the duration
- Shield: absorbs damage up to the shield amount
- Vengeance: when this ability is available, gained when blocking (up to 3)
These buffs/debuffs have to be stored in StatBlocks. The routine that gathers renderables should check each active StatBlock. Each of these types will have an associated icon. If they do have an animation (e.g. Shield), the animation info is stored in StatBlock. The sprites will be stored in PowerManager.
Other animations happen over the player when casting a new spell (e.g. Heal, Return). These could be simply handled as non-damaging Hazards.
Finally, some animations happen upon impact (e.g. blood spurt, electrical sparks). These can also be non-damaging Hazards created during the TakeHit() routines of Avatar/Enemy.
Actually, all after-effects should be applied by TakeHit(). Usually these will be debuffs set to the StatBlock.
Taking a look at each power and how they operate.
- Shoot creates a Missile hazard. Already implemented.
- Swing creates a Single hazard. Already implemented.
- Lore isn't implemented, not yet determined how this will be handled.
- Return creates a NonDamage hazard; when the animation is done, set the teleportation variables. Maybe use some kind of return_countdown variable in StatBlock to facilitate this.
- Bleed upon hit sets a DamageOverTime debuff. Create a blood spurt NonDamage hazard.
- Block is a special case. It is a unique state. Transition to the state when the block key is pressed. Transition back to Stance when the key is released. Set a "blocking" bool in StatBlock.
- Shock is a Missile hazard. Upon impact it has to chain to another creature. Not sure the best way to implement this. Perhaps within HazardManager where it has access to enemies and collision data. The routine should be in PowerManager itself; HazardManager should call that routine and pass the needed data (collision info and living enemy positions). This is such a specific implementation that it might slip to another release. Tagged with Air trait.
- Heal creates a NonDamage hazard and sets hp. Not yet implemented.
- Multishot creates three Missile Hazards. When I convert to polar coordinates I can offset (+/-) Theta to get the angle of these side missiles. Multi hit is handled by the 5 frame invulnerability.
- Warcry removes all debuffs from StatBlock. Create a Single hazard that doesn't do damage but has the Fear after-effect.
- Quake creates a Single hazard with a Stun after-effect. Already implemented. Tagged with Earth trait.
- Shield sets Shield in StatBlock. No hazard.
- Cleave creates a Single multi-target hazard with a very large radius
- Charge requires a specific implementation. Probably needs to be a distinct Avatar/Enemy state with increased speed at a floating point (x,y) angle. Basically the hero becomes a missile. Stun after-effect.
- Freeze is a series of Single hazards with execution delays. Care should be taken to not let Freeze travel past walls, so PowerManager might need a copy of the collision grid. Tagged with Ice trait.
- Teleport creates a NonDamage hazard and sets an intramap teleport at the mouse target location.
- Piercing Shot creates a multitarget Missile hazard tagged with ArmorPiercing trait.
- Vengeance causes a stack of Vengeance buff to be created when taking a hit. Casting Vengeance creates a Single hazard with increased accuracy/crit and removes Vengeance stacks.
- Burn causes a Single hazard with wide radius. Already implemented.
- Time Stop creates a wide-radius hazard with the Stun aftereffect.
Missile spells have a radius and speed. Radius is how close a creature has to be to the projectile for an attack roll to take place. Speed is the distance the projectile moves each frame.
Mouse aiming shouldn't be frustrating. The best way to aid this is to give projectiles a very wide radius. However, make the radius too wide and a stationary enemy might be attacked by a projectile twice on consecutive frames. This messes up accuracy as a stat.
One solution idea: each time a missile attacks an enemy, hit or miss, mark that enemy as Targeted. This enemy is no longer a valid target of this projectile. Targeted can wear off after a very short time (say, 5 frames). Because of the global cooldown (1 second) and because there are not multiple heroes, we can just set Targeted every time an enemy is attacked and do auto-miss if still targeted. That way we can increase the radius of ranged spells without worrying about overlapping attack rolls. One side effect is that the Multishot skill is fixed and becomes an AOE skill as planned instead of a WeaponX3 skill.
One concern with this solution is firing a new missile while the previous missile is active. I believe this is not possible with current timing.
I added a couple AOE spells, as those are fairly easy to implement: Quake and Burn. Note Quake doesn't have its Stun component yet.
Also note that these spells are massively overpowered at the moment. I will be changing them so they can only hurt creatures if you have line-of-sight on them. Also I'll change Burn so that you can only cast it on a location if you have line of sight on that location.
Burn will still be overpowered because of its long range + radius. Right now monsters won't pursue if you are out of their threat range, even if they get hurt. I will have to modify creature behavior in two ways: (1) if an enemy gets hurt but the hero is out of threat range, pursue anyway; (2) if an enemy gets hurt but the hero is not in line-of-sight, use A* to find the hero.
The latest check-in (revision 128) contains simple support for projectiles: arrows and shock spell. Note that Shock isn't fully implemented (it doesn't chain). You can't use Shoot unless you have a ranged weapon equipped. Normally you wouldn't be able to use Shock until you unlock the power, but I haven't finished the changes for the ActionBar yet.
Note that simple hero sword swings are also converted to the new power system. Enemies aren't converted yet, nor are potions.
The new Armory page lists all the weapons and armor currently in the game!
Using Vista but having problems with OSARE? I've uploaded v0.09b which may help.
It looks like when running an .exe from Windows Explorer, the "Working Directory" is not always set to that folder. So when I try to load game assets (images/sounds) it fails. It fails ungracefully because I need to fix error handling in my code. But for now I've added Launcher .bat files that should help make sure the local folder is the one used when running the game.
If you have Vista please try it out for me and let me know. Thanks!
Action Bar and Powers
Time to nail down the logistics of the Action Bar and Powers.
Action Bar already has a place in the dependency hierarchy: GameEngine -> MenuManager -> MenuActionBar. Note that Avatar.logic() will need to read from MenuActionBar to determine actions.
It's possible that Powers need to be accessible in several places: MenuActionBar, MenuPowers, ItemDatabase, Avatar, Enemies, etc. It probably does not have dependencies of its own. So might create it in GameEngine and pass its pointer to the children who need it.
Action Bars slots (1-0 numbers and M1/M2) are loaded with Powers. Those 12 slots will be integers of the appropriate Power ID.
Powers have ID and Type. Each type (or collection of types) will be handled by its own function. An activate() function in turn calls the appropriate handler function for the type.
Example 1: Drink a Potion. Currently the activate() for this item is in ItemDatabase but it will move. Drinking a potion can be triggered in these ways: (1) right-click on the inventory, (2) hotkey or click the potion on the action bar. Play the potion sound effect. Alter Avatar.StatBlock.hp. Remove the potion from the inventory.
Example 2: Shoot a Bow. Triggered by hotkey or click the potion on the action bar. Create a new missile hazard. Change the Avatar state to Shooting.
Example 3: Cast Shock. Triggered by hotkey or click the potion on the action bar. Create a new missile hazard. Change the Avatar state to Shooting. Alter Avatar.StatBlock.mp.
To have access to activate(), MenuActionBar needs a pointer to Powers. Same with MenuInventory and MenuPowers, to allow right-click use. Powers will have its own set of sound effects. Powers will have a public Hazard (or queue of Hazards) so that the HazardManager can pick those up. Powers needs access to Avatar.StatBlock to change various stats. I think that's it.
What about Powers generated by enemies? I think this is basically handled similarly. Powers needs a link to the Enemy.StatBlock (in fact, activate() should probably take StatBlock as a parameter). Hazards have damage sources so that's taken care of.
Where are buff durations, etc. stored? In the StatBlock.
Where are animations and graphics for Powers stored? Probably in the Powers class. When getting renderables for Hazards we'll need to read some info from Hazard and some from Powers. When getting renderables for Buffs/Debuffs we'll need some info from StatBlock and some from Powers.
Powers could be stored in a powers.txt file.
[power] id=1 type=basic_ranged #defines tells activate() which name=Shoot requirement=po,1 #places this power in the skill tree state=shoot description=Basic Range Attack [power] id=2 type=basic_melee name=Swing requirement=pd,1 #places this power in the skill tree state=swing description=Basic Melee Attack value=p # damage is based on the equipped Physical weapon [power] id=8 type=cast_heal name=Heal requirement=md,3 #places this power in the skill tree state=cast description=Restore health sfx=heal gfx=heal value=m # healed amount is based on the equipped Magical weapon [power] id=100 type=potion_hp sfx=potion name=Health Potion description=Restore 100% Health value=max_hp # healed amount is the drinker's max hp
When a power is used that requires the user to change state (e.g. melee swing), the power (often, hazard) activates on a specific frame of that animation. The action frame should be a parameter in the animation part of StatBlock.
Where are the power animations defined? perhaps a power_animations.txt in the powers folder.
I want to write a long overdue post about why I'm making OSARE. So many thoughts churning through my head that I need to commit them to paper so I have room to think again.
I turned 30 this year. 30 has this way of making me feel both very old and very young at the same time. I've been a gamer for 27 years and a programmer for 18 (professionally for about 10). The peak of my gaming and coding was during the 90s, when I had summers of nothing to do but tinker with code or play RPGs. Also during the 90s was the height of 2D gaming -- beautiful pixel art or pre-rendered sprites seemed to push what we thought possible in games. The first generation of 3D games in that era looked primitive by comparison.
Also during the 90s is when I created and finished games. One game had a very primitive Bards-Tale style view and turn-based combat. Another had Gauntlet-style action and a nice map editor. Since then I've started and discarded countless new engines.
Typically the engines I create are of two genres: overhead or isometric RPG (action or turn-based), or side-scrolling platformer. These two genres represent my absolute favorite style of games at the height of 2D gaming. Even now when a Final Fantasy Tactics or Castlevania game comes out for the DS I'm there on release day.
One constraint I had for the longest time is creating art. I did poor quality pixel art for most of my projects. I started tinkering with Blender in 2002 but only in the last couple years have I finally learned enough to make game-quality art. I'm still learning about making polished 3D art, but my skills are enough that I can make pre-rendered 2D sprites that look similar quality to games of the 90s.
Of my favorite genre of games, some are well represented in Open Source. There are already plenty of platformers. There are plenty of console-style and turn-based RPGs. There aren't many prominent action RPGs -- surprising given the immense popularity of Diablo.
So I set off to make an isometric action RPG in the spirit of Diablo. I started it as a Java Applet, but quickly realized I didn't want to be streaming megs of content every time someone launched the game. I chose C++ because it's still the primary language of non-casual console and PC games. I chose SDL because I've worked with it before and found it does what I need it to do.
It's important for me not to take on a project too big to complete. MMOs are fantastic but take dozens of people years to make. 3D games have their charm but my heart is in the simplicity of 2D gaming. I even cut out networking support for now because a multiplayer game would be a larger undertaking than I'm capable of.
If each game takes 2-5 years to create, a game developer might not finish many games in his/her lifetime. I would love to make a platformer engine but they've been done (I'll probably save my ninja game for later and create it using the Frogatto engine).
It's an intersection of many opportunities for me. I have the programming and art skill to put together a good 2D game. There isn't a prominent open source 2D action RPG in existence. I have a good day job that I can leave at the office when I'm done for the day. OSARE begs to be made and I'm having a grand time making it.
What's Next for OSARE?
I pushed a lot of new code out this last week. It feels pretty good to sit back and just play the game for a while. I have a hero up to level 6 wearing mostly Warlord (+health) gear. The Skeletal Warriors (level 5) are no longer a real threat. The challenge and fun both feel pretty good so far.
Next up is a major update for gameplay: Action Bar and basic Powers.
The action bar needs to be customizable with Powers (from the Powers menu) and consumables (food/potions from the Powers menu). Essentially all these can be lumped under Powers. Items "effect" entries are essentially item-bound Powers.
So I need a Powers class that handles all the one-off code to deal with all possible powers. Powers each need an icon. Many powers will need data to create Hazards. Instead of planning out all the data I need for these, I probably need to start with simple examples (potions, bow shooting) and figure out what I need just for those.
Some powers will be much harder to implement than others. In particular, the Multishot (fire 3 arrows) and Freeze (sliding ground ice shards) will be tricky. Those are special cases in that they have multiple renderables and need to be balanced so they don't hurt the same creature multiple times.
When the basic Action Bar, bow/slingshot shooting, and Shock spells are done I will probably pack that up and call it v0.10. At least by then someone who wants to wield Bows and Staffs will have a reason to do so.
OSARE v0.09 Released
A fast release this time! Less than a week since v0.08, I've been having lots of fun coding updates.
- Games are automatically saved upon exit.
- Level Up system in place!
- You must meet requirements to equip items now
- Now you can respawn after dying
- Gold added to loot drops! Though nothing to spend it on yet...
- New map "Averguard Complex" added!
Note that bows and spells still don't yet work. These will be coming up in v0.10! So for now, you'll want to upgrade Physical and Defense skills, as the others won't help you much.
Added the last wing of the Averguard Keep: the Complex. The monster composition is significantly harder than the other wings.
Experience and Leveling Up
I'm on a code spree; v0.09 might come soon.
The major addition I wanted to do for v0.09 is XP and Levels. I plan to use a very simple system to start: xp granted by killing a creature equals the creature's level. So a level 5 creature gives 5 xp. This is reasonable; creature difficulty also scales linearly.
Then comes the philosophical question: how much XP to gain levels? I think I found the correct answer: "Depends on how much content there is". Basically I'm going to playtest the game, and when it feels like I should be gaining a level I'll find a nearby XP cutoff point. This point will change as I add more of the game world to explore.
The important code for XP will be on the Character menu. Each level gained (2 through 9) the player can increase one core attribute (physical, magical, offense, defense). Anytime the character menu is open and not all points have been spent I need to display [+] buttons for spending those points.
I've decided to not bother adding a respec/reset button. It's easy enough to do out of game: edit the save game file and set build=1,1,1,1. Then when you load your game you can reassign your points.
Finally I need to enforce requirements checks when equipping items. This should be easy, as I think MenuInventory already has a reference to the player's StatBlock.
XP, leveling, attribute upgrading, and item requirements checks added. Please let me know on the forums if you test this.
Here's what I did for now, for the XP requirements. I want the number of creatures to be killed (thus, time spent at each level) to increase logarithmically (20,50,100,200,500,1000,2000,5000). So the scale looks like this:
- 20 lvl 1 kills to 2: 20 xp
- 50 lvl 2 kills to 3: 100 xp (120 total)
- 100 lvl 3 kills to 4: 300 xp (420 total)
- 200 lvl 4 kills to 5: 800 xp (1220 total)
- 500 lvl 5 kills to 6: 2500 xp (3720 total)
- 1000 lvl 6 kills to 7: 6000 xp (9720 total)
- 2000 lvl 7 kills to 8: 14000 xp (23720 total)
- 5000 lvl 8 kills to 9: 40000 xp (63720 total)
How long does it take in a hack & slash to kill 10,000 creatures? I have no clue, really. Sounds like hours of gameplay though. I timed myself getting to level 4:
- 3 minutes to reach level 2
- 6 minutes to reach level 3
- 15 minutes to reach level 4
The number of kills required approximately doubles each level, and as expected the grinding time doubles also. Projecting the rest of the levels:
- 30 minutes to reach level 5
- 1 hour to reach level 6
- 2 hours to reach level 7
- 4 hours to reach level 8
- 8 hours to reach level 9
Total 16 hours of gameplay (not counting quests, trips to town, etc). That's a pretty solid number. I'd need a good collection of maps to make 16 hours work.
The latest check-in has gold coins dropping from creatures/containers. Warning: if you get over 2 billion gold you might end up with negative 2 billion :)
The latest Google Code check-in allows respawning. Grab this updated code if you like collecting epic magic items!
Save Game Files
This makes me start to think about Save Game files. I plan on using plaintext save files. This might entice some people to cheat, but how rewarding is it for some young person to edit their own save games and experiment!
What needs to be stored in the save game file:
- Skill points spent (PMOD)
- Equipped and Carried items (68 slots total plus gold)
- Action Bar customization (12 slots total)
- Respawn point (map name and coordinates)
- Campaign Flags and Quest data
- Achievement Statistics
Of those, the only implemented features are the items and respawn point. I will be working on gold, experience, leveling, and action bar stuff for 0.09 and at that point a save file makes a lot of sense (and should be easy to do).
I've added simple save same support added in the latest check-in. The game is saved to saves/save1.txt. Edit the file if you want to change your hero name (or cheat by giving yourself uber gear). Delete or rename the file if you want to start a new character.
OSARE v0.08 "Loot" Released
The newest OSARE release is focused on loot. Over 500 items are in the game, dropped from enemies or found in treasure chests. I also added the starting logic for the Log Menu (and a heads-up log display). Finally, there is a new starting area called "Goblin Warrens" where you can fight low-level creatures to scavenge for beginner equipment.
Bug Testing for v0.08
The latest OSARE Google Code check-in is my candidate for v0.08. Included is nearly 600 game items, lootable from creatures and containers. You start without any equipment, so it's kinda fun to see how long you can survive with what items drop.
If you test it (build from source), please send feedback. If no major bugs appear I'll publish the Win and OSX binaries in a few days.
All of the coding is done for the v0.08 loot update. Woot!
What remains is adding all the starting game items to items.txt. This is impractical to create or maintain by hand. What I'm going to do is put all the item data into a MySQL database and use PHP to create the items.txt from that data.
Once the data is online, I can easily create a webpage to search/browse items.
Finally got all the starting loot animations done. As far as I know, this means I'm completely done with art assets for v0.08. More will be added in later releases but this is plenty for now. I checked those animations into the OSARE svn, so you can see them in action if you don't mind compiling.
Next up is adding all the item stats. I have plenty of starting stats worked out, though I need to work on item names for bows and armors. This is all stored in the /resources/items/items.txt file. I will probably create a mysql database of the items and some php to create the items.txt. Then I could make a real item database/lookup section of the OSARE website. Sounds win-win to me.
I have two major code pushes left for v0.08. First is loot from containers. This shouldn't be too bad. In the map files I assign a level to each container event (default: level 1). When a container is opened, use a similar chain of events as killing a creature to produce loot.
The second major feature, and of course the whole point, is picking up loot. Right now when the menus are closed, mouse clicks are assumed to be basic attack actions aimed at the cursor. Loot will have a rectangular click region to be picked up. When someone clicks on the playing field, I have to check all the loot to make sure the mouse click isn't aiming for loot pickup before assigning it as an attack action. Similar code will be added for the action bar (don't know if that will be added in this release).
Then it's a few tiny bits of cleanup code. I need to add % chance of dropping loot to creature definitions. Bosses will drop loot 100% of the time, weak zombies maybe 5%. This is a pretty minor update; I'll add it right before releasing v0.08 though, because testing loot is easier when every kill basically drops something.
Making a list of the loot animations I need. Just to keep track. Essentially every item type has a unique icon and loot animation, and possibly a character layer if it is a main/off/body item.
0.08 will contain at least these loot animations:
- Leather Armor
- Steel Armor
- Health Potion
- Mana Potion
- Generic Gem (white and shiny)
It feels like I'm putting a lot of effort into content and not into the engine itself. But, a long loot list will give me enough variables to play with to see if my implementation is flexible enough for real game needs.
Lots of real life events have been overshadowing my OSARE time. Thanks to all of you who still have interest in the project.
I'm only 2-3 coding sessions (and an art/data session) away from being done with loot. Currently in svn I have a good dagger and shortsword "flying loot" animation done, and I have those dropping off creatures. The coming data push will add a couple dozen more loot animations and a few hundred items.
I still have to add the "click to pickup" mechanism for loot. It's not a particularly interesting set of code, but once that's done I should be able to use similar routines for other items. At this point I'm considering a ClickRegion struct (similar to the current Renderable struct) that can be generated by dropped loot, containers, switches, etc.
Finally I need to add support for loot to be generated from containers. I'll probably assign a loot container a level and % chance to drop an item, much like I do with monsters.
Unicode is slightly intimidating, but I think I've found the most useful way to tackle it in my game.
GNU Unifont is a GPL-licensed bitmapped font that I can work with. It is fixed height (16 pixels tall) and fixed width (8 or 16 pixels wide) so coding for the font should be easy. In C++ I could use double-width chars (wchar_t) and I should be able to find matching string functions.
Working with OpenGameArt means I'm working with artists from all over the world, and plain ASCII won't cut it for most of the people who already have direct interest in the game. If I support Unicode, at least someone could modify all my game data files to make a native translation.
Of course, just supporting a Unicode font isn't enough. I need to add RTL text support and possibly modify some menus for those languages. I need to macro lines like "Increases accuracy by 5" so the sentence can be reworked and rearranged for the target language. I need to isolate the displayed text as much as possible so that translators don't have to hunt for changes. Finally, ideally, I need to support choosing language at runtime or at least in a config file.
Language translations isn't the exciting part of making a game. My development model for OSARE has been to make the fun parts first, then make it work properly/flexibly later. Unicode/translation support might actually come once I have most everything else in place... perhaps around that phase where most of OSARE's features are complete and I need to start generating tons of game assets (more monsters/tilesets).
If I use the GNU Unifont format directly, I might not even need a bitmap version of the font. I could write out the pixels just as described in the text format. Don't know what kind of performance concerns that would create with SDL.
OSARE updates might be slow for a couple weeks while I'm apartment hunting. I am still choosing a loot system and I may have settled on something that sticks pretty close to the genre. Updates soon!
It is the business of the very few to be independent; it is a privilege of the strong. And whoever attempts it, even with the best right, but without being OBLIGED to do so, proves that he is probably not only strong, but also daring beyond measure. He enters into a labyrinth, he multiplies a thousandfold the dangers which life in itself already brings with it; not the least of which is that no one can see how and where he loses his way, becomes isolated, and is torn piecemeal by some minotaur of conscience.
- Nietzsche, Beyond Good and Evil
Choosing a loot system is probably the trickiest part; implementation is a close second. Loot affects most subsystems of OSARE: maps, camera position, renderables, mouse state, tooltips, enemies, inventory, events/containers, etc.
Here's what I plan to do with loot drops.
- Assign items a new variable: level
- Item level will determine the item's sell price and drop chance.
- Item level will also determine automatic loot tables
First, let's talk about level. Weapons and armor will be our starting point for determining level.
- Regular daggers, wands, slingshots, and leather armor will be level 2
- Shortswords, rods, shortbows, bucklers will be level 4
- Longswords, staffs, longbows, steel armor will be level 6
- Greatswords, greatstaffs, greatbows, shields will be level 8
I'll use basic judgment to assign the rest of loot.
- Food is level 1
- Potions are level 3
- Gems are level 9
- Artifacts are base level 5
Item modifiers change the level of items. This is calculated outside of the game for now and applied directly to the items.txt file
- -1 damage = -1 level
- +1 damage = +3 levels
- -0.5 absorb = - 1 level
- +0.5 absorb = +3 levels
- +1-3 hp/mp/accuracy/avoidance = +1 level
- +4-6 hp/mp/accuracy/avoidance = +2 levels
- +7-9 hp/mp/accuracy/avoidance = +3 levels
- +1 crit/regen/speed = +1 level
- +2 crit/regen/speed = +2 level
- +3 crit/regen/speed = +3 level
Now I can automatically generate loot tables for creatures, containers, and vendors. Loot will be on a basic bell curve. When loot DOES drop, what level is it?
- [Editor's Note: final implementation is +/- 3 levels]
- 1% chance: -5 level
- 2% chance: -4 level
- 5% chance: -3 level
- 10% chance: -2 level
- 20% chance: -1 level
- 24% chance: same level as creature/container/vendor
- 20% chance: +1 level
- 10% chance: +2 level
- 5% chance: +3 level
- 2% chance: +4 level
- 1% chance: +5 level
Note I can tag some monsters as "no loot" types (e.g. antlions, wyverns). Instead of dropping loot, you should find loot around their layers (in nests, rubble, dead adventurers, etc). Also I can tag some loot as "quest" types, so they don't appear in random tables.
OSARE v0.07 Released: Inventory
The newest version of OSARE is ready, this time with the focus on Inventory. In game, open the Inventory (I) menu and try out some test equipment! New in this release:
- Word wrap, size calculation, and font colors on the font engine
- Created a mouseover tooltip system
- Drag and drop support for arranging and equipping items
- Item drop sound effects
- Changing hero graphics based on equipped items
- Changing combat stats based on equipped items
- Adjusted monsters based on combat stats
- Basic test items and a few low and high quality variations
0.07 Coming Soon
0.07's main focus is "Inventory". I will probably package 0.07 this weekend. The current checked-in code represents most (if not all) of 0.07. If you try it out, please send me some feedback.
To get loot drops in 0.08 I will need to decide how to animate loot drops, probably corresponding to each icon. That will be a lot of tedious work. I also need to spend a few days away from OSARE coding, maybe playing other inspirational games.
My target for 0.08 is July, with the focus on "Loot".
My target for 0.09 is August, with the focus on "Powers". That will be a huge milestone, as the core gameplay will be there to experience.
I got artifacts working in-game. Currently they can be created to boost a few main stats: hp, hp regen, mp, mp regen, accuracy, avoidance, crit, speed. (These bonuses can be added to weapons/armor too, but would be more powerful on artifacts)
Working on 0.07
I'm working on some fun interface stuff for version 0.07.
- Mouseover tooltips system (done)
- Word wrap and newline support for text rendering (done)
- Inventory display and drag/drop arrangement (done)
- Item Database (done)
- Changing hero graphic based on equipped items (done)
- Equipment stats affect combat (done)
Here's what I'm thinking for 0.08
- Loot drops from creatures
- Loot drops from containers
- Experience from creatures
- Leveling up
- Equip items requirements check
For 0.09 I will be working on Powers and customizing the Action Bar.
OSARE v0.06 released!
OSARE version 0.06 is now ready for download. New in this release:
- Tweaked some sound effects due to license questions
- Added menu open/close sound effects
- Added map interactions when stepping on certain tiles
- Added opening containers
- Added throwing switches to open doors
- Added support for various monster types
- Added several varieties of zombie, skeleton, antlion, and goblin
Antlion and Goblin
Finally finished animating the old Antlion and Goblin models that have been sitting on my hard drive for a year or so. I will probably add a few new animation sequences later (e.g. the antlion needs his burrowing graphics). This means that half of my bestiary is complete (coincidentally, the half of the list that represent lower level creatures).
These low-poly, untextured models are so easy to create/rig/animate. If I tried to put too many tiny details on the model it would make the in-game renders too noisy. Sometimes I want to stop and instead create incredibly detailed 3D models, but it wouldn't add much to OSARE and would slow down my current progress. I always have the option of making better graphics later, and I'm sure the graphics of OSARE will improve as I keep making more. One thing that keeps OSARE ticking is that I just try stuff, do what's fun, and I'm not afraid to just throw something out and redo it.
I just finished adding support for multiple enemy types. The maps now have both zombies and skeletons. There are weak, strong, and boss versions of both. You can infer what kind they are by how fast they move and where you encounter them.
Containers and Switches
I added support for map containers and switches. Currently these are all "pressure plate" type activation, where you merely walk onto a certain tile area to interact. In most games of this genre you click on objects to interact with them: I'll add this method soon.
To accomplish these interactions I have two new Event Components for map events: mapmod (edit the current map) and soundfx (play the specified sound effect once). Each map event can have up to eight components. As an example, here are the Event Components for throwing a switch that opens a portcullis:
- mapmod to change the switch tile from position a to b
- mapmod to change the portcullis tile from closed to open
- mapmod to change the collision under the portcullis to walkable
- soundfx to play a "door opening" effect
Thinking about Powers again. I want to remove passive powers and separate melee vs. ranged powers. The new working list:
Physical Offense - Shoot (basic ranged attack) - Rip Strike (melee attack that causes Bleeding) - Multi Shot (ranged attack that fires three missiles) - Cleave (melee attack with a wide area of effect) - Piercing Shot (ranged attack that ignores armor and goes through enemies) Physical Defense - Swing (basic melee attack) - Shield Block (raise shield to increase defenses) - Warcry (remove debuffs and scare enemies) - Charge (rush and knockback a target) - Vengeance (after blocking, deal an accurate heavy attack) Magical Offense - Lore (get more info about items or nearby landmarks) - Arcane Bolt (missile that bounces to another enemy) - Earthquake (stun nearby enemies) - Freeze Ray (slow enemies in a straight line) - Burn (burn enemies in a large distant area) Magical Defense - Return (teleport to a previously-discovered safe point) - Heal (restore health) - Magic Shield (absorbs damage) - Teleport (instantly appear at target area) - Time Stop (freeze enemies for a few seconds or until you act)
I'll make new icons and update the Build Calculator and Powers pages soon.
I added footstep sound effects to OSARE (look at the Google Code link for the bleeding edge stuff). The game's animations are frame-based not millisecond-based so everything slows down when framerate drops; thus I need to play a new footstep noise every time (I can't just put it on a timed loop).
Oddly, SDL_mixer was having trouble playing sounds this rapidly (2.5 steps per second when running, it would simply skip playing some steps). I toyed with settings until something worked. On the initialization call Mix_OpenAudio(), I changed the last argument from 4096 to 1024 and it made a difference. It seems to work now in OSX and XP. But I don't know why changing the audio buffer there makes a difference.
I started having the same problem when adding new sound effects, even with the buffer at 1024. I found that reducing their quality (stereo to mono, 44k to 22k) helps. I'm not an audiophile so maybe I'm doing this the wrong way.
OSARE version 0.05 is now up.
- Added map transitions
- Added a starter dungeon with three wings named Averguard Hold (click for map)
- Added support for hex or dec map data format
- Changed definition files to use = instead of :
- Upgraded zombie steering AI. They now pursue to where they last saw the hero.
- Started refactoring to prepare for more monster varieties
- EnemyManager now holds enemy sound effects, so that we only load one copy of each
- I now use Tiled 0.4.1 to edit map layers
- Reminder: use the command-line argument -f (or --fullscreen) to play in fullscreen mode.
- Changed the tileset to use magic pink as the transparency and removed the tileset alpha layer. This should improve performance on most systems.
- Note to self: in GIMP set Alpha Threshold to 32, then remove the alpha channel onto magic pink.
I'm gathering my resource files (especially the Blender and Tiled files) for a new download archive. Also soon I'll be putting stuff into Google Code for easy perusal and tracking.
Editing OSARE Maps with Tiled
I'm using Tiled to do most of my OSARE map editing. Here's how my current process works:
- I have specially-made tileset images for Tiled. The indexes for those correspond to the OSARE tilesets.
- I edit background, object, and collision layers in Tiled.
- In Tiled 0.4.1 I use the "Store tile layer data as: CSV"
- I use a text editor to copy the three csv sections from the .tmx file into my OSARE map files
- Currently I still create the headers, events, and enemies in a regular text editor. I use Tiled's status bar to get my cursor location to get placement for events and enemies.
- Note that the Tiled tileset isn't a perfect copy of OSARE's tileset. I left it brighter to be easier to see when editing. Also some irregular shaped tiled are cropped to work in Tiled.
There are two types of collision tiles. Empty (0) is no collision. Red (1) is full collision which blocks movement, sight, spells, arrows, etc. Blue (2) is partial collision that only blocks walking, but sight/spells/arrows/flying is still allowed. Blue is used for low obstacles the player can see over and for water/chasms.
Today I tried using Tiled to edit maps for OSARE. It took a bit of work to set up, but I think it's worth it.
My maps use CSV for tile data. The latest Tiled release (0.4.1) supports writing map layers in CSV. So I can use Tiled to edit maps, then just grab the piece I need from the output XML file.
Tiled expects tilesets to have consistent tile sizes/spacing, but I pack tiles in my tileset to save space. So I made a new tileset image for my dungeon tiles where each tile is 64x128. Tiled handles this tileset beautifully. I still use the packed tileset for my game, for performance.
Tile index 0 is blank space in Tiled and in my engine. The first tile on the tileset image is given index 1, so I have to position the tiles accordingly.
Also, the CSV map format uses decimal; OSARE uses hex. The easiest thing is to allow map files to define the layer format it uses, that way I can copy/paste layer data directly from Tiled files.
Tiled will be great for laying out the map graphics. With a bit of tinkering I think I can make enemies and events with Tiled's Object Layer.
Testing some medieval building tiles:
Done! Medieval Building Tiles
Free Gamer Blog plug
qubodup has plugged OSARE over at the Free Gamer blog. Sweet!
Collecting my thoughts on map loading. The following things have to occur to dump an old map and load a new one:
- User steps on a tile tagged with an event.
- A flag is set to load a new map, with the new map filename and position taken from the triggered event.
- GameEngine needs to check for this flag because it is the parent of the following objects.
- EnemyManager::handleNewMap() // add function to remove all enemies
- HazardManager::handleNewMap() // add function to remove all hazards
- Add logic to TileSet: if we already have the correct tileset we shouldn't reload it.
- Set the Avatar (x,y) to the trigger event's destination (x,y).
- Change MapIso and TileSet to interpret tile indexes as hex 00-ff instead of dec 00-99
Looking Towards 0.05
I've been pretty busy with life and work, so I haven't really touched anything yet for 0.05. The first step is to narrow down what sounds fun to work on. If I think about the project as a whole it's overwhelming, but if I focus on a short list of tasks it's manageable.
Category 1: Map Interaction
- Map interaction (switch toggle, open door/chest/crate/barrel, extinguish brazier)
- Map interactions that edit the map (throw a lever to open a secret wall)
- Map "pressure plate" triggers (e.g. traps or portals)
- Runtime map unloading/loading
Category 2: Menu Interaction
- Word Wrap support for font class
- Upper ASCII on font graphic
- Draggable Icons (Powers and Inventory menus)
- Icon database
Several artists have contacted me in the last couple weeks to see if help is needed on OSARE. I'm already blown away with the interest in this very early project.
At this point in the project I'm not interested in forming a "team" (simply because that sounds too much like work to me). I can do a significant amount of the game art myself, and the rest I pay commissions to get specific tasks done. Especially for areas I'm not strong in: concept art (I'm a very left-brain artist, so I need creative help), music (not a composer), and items that require good painting skills (finished icons, portraits, etc).
Unfortunately, real life has interrupted my commission plans. I will have to put new commissions on hold for at least a couple months. My car died two days ago. I'm digging into my savings to get a new one. Until I get adjusted to these new payments I won't know how much I have to spend on commission work.
In the meantime I can work on getting more features into the engine. Really, the bulk of the commission work will happen when OSARE is in beta (mostly feature complete) and production on an actual game begins. At the current pace, OSARE will be close to feature complete in Fall 2010.
OSARE v0.04 Release
OSARE v0.04 is ready for download. New to this version is font support and basic menus. I spent a lot of time in the last few weeks creating several iterations of the graphics for the font, menus, and icons
- NOTE: now runs in windowed mode by default (apologies to XP users, windowed mode seems to change the desktop resolution). To run in fullscreen mode use -f or --fullscreen options at command line (easier to use options coming in a future release)
- FontEngine is a class that handles drawing of a bitmap font, with support for left/center/right justify (word wrap coming in a future release)
- Finished the icons for Powers. Commissioned Blarumyrran to finish the icons for the basic set of weapons/armors.
- Character Menu displays the proper info based on the Avatar's stats (level up coming in a future release)
- Powers Menu displays the Avatar's build (dragging powers to the action bar coming in a future release)
- Log and Inventory menus are mostly static. Inventory drag/drop and equipping coming later. I still haven't settled on a design for the Log, which will contain quest info and achievements.
- I refactored all the menus and hud under a MenuManager class. That class controls which menus should be displayed. In a future release it will handle drag/drop between the Inventory, Powers, and ActionBar menus.
- When the core menus are open (Character, Log, Powers, Inventory) the game action is paused.
- The actionbar hotkeys work but clicking on the action bar doesn't work yet. Also, still no way to change the default key bindings. All this coming in future releases.
Blarumyrran (from #opengameart on freenode) has taken on a commission to put some polish on my equipment icons. Thanks, Blarumyrran!
And they turned out amazing!
Font and Menus
I've been doing lots of work on OSARE and 0.04 is just around the corner. Most of my work has been outside of code: designing icons, menus, and a font.
I have the basic font class working and it's nice. I'm using an ascii-based bitmap font. Right now I have lower ascii, but it should be easy to add upper ascii. At the moment I'm not too interested in unicode support; that might be a sin but I don't care (yet). I have routines to write out text with left/center/right justify. I don't yet have smart word wrapping (I'll save that for when I actually need it, probably once I start doing the dialog engine).
I've been drawing up the four main gameplay menus: character, inventory, powers, log. The first version of the Character menu is done: it displays the avatar's StatBlock properly (a second version will handle level-ups and resets). The Powers menu shows the build correctly (a second version will allow dragging powers to the action bar). The Inventory and Log menus are basically blank for now. I also created a MenuManager to hold each of the menus and govern their opening/closing. I also changed the HP/MP bar and the Action bar to "menus" and put them under the Menumanager class.
The proficiency icons on the Character menu are the stock weapons/armors I have for the current male hero. Maybe the icons should be something more generic (a barbarian or samurai would have very different base items).
I will create Powers-style icons for the C,I,P,L menu buttons on the bottom-right of the action bar. Maybe make them clickable. Maybe add a very simple MenuToolTip class. Once I feel at a good stopping point I'll release 0.04.
The OSARE project has a new blog. I've imported previous news items and the conversion is complete.
I spend a lot of time thinking about my programming projects (not just OSARE). As the projects grow it's impossible to keep all those thoughts organized between releases. This blog will probably be barely-edited ramblings of ideas, dev updates, etc.
Version 0.03 Release
Version 0.03 is up! The core gameplay is starting to emerge.
- Combat to the death. You can kill zombies and they can kill you.
- Added combat sound effects.
- Added a health and mana bar
- Left-mouse click is now an aimed sword attack (1-key will instead attack the way you're currently facing)
Although the RPG combat mechanics aren't in yet (accuracy, dodge, absorption, weapon damage, etc), basic melee values are hardcoded in for this demo. The zombie has a high chance of being crit, along with a satisfying crit death animation and sound. Next to the health/mana bar is a slot for a 32x32 pixel character portrait.
I added a lot of memory cleanup in the class deconstructors. Please let me know if you encounter a game crash on exit.
One user has reported it doesn't work under Vista (hard lock, requires reboot). It works on my XP and Win7 systems. I'm compiling the Windows version with MinGW on XP. If anyone has tips on SDL with Vista please contact me.
Version 0.02 Release
Version 0.02 is up! Things are finally starting to get interesting.
- Re-rendered all assets using Blender's CatRom AA setting. The result is much sharper.
- Added SDL_mixer support and background music by Remaxim
- Added the bare bones for the Action Bar
- Set Action Bar slot 1 to melee attack (no customization yet)
- Added (much hardcode) a basic zombie creature. The zombie will pursue and try to melee attack.
- Bug: fixed an issue in the Collider class with a variable not initialized
Although the hero and zombie can try to attack each other, I haven't yet implemented the attack collisions, damage, dying, etc. That will probably come in 0.03. Zombies make a great starting creature because it's okay if their AI is oversimplistic. This zombie will pursue if in range, stop once it gets to melee range, and try to melee attack. After some melee attacks it will try to bite. The current zombie gets stuck behind walls a bit too easy. Right now he chases the player directly and can basically see through walls; in 0.03 he will not see through walls and pursue the spot where he last saw the player. This will make his pathing appear slightly more intelligent, but still as unintelligent as a Walking Dead should be.
The other major addition is background music. In the map.txt file you'll see a line that says
music: dungeon_theme.ogg. If you want to hear remaxim's other tunes in game, change that .ogg file to one of the other songs included in the music folder.