Free/Libre Action Roleplaying Engine
[–Update–]
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.
I’m planning on writing a lot of code this weekend. Fair warning: the latest svn version might not be playable until Monday!
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.
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.
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.
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.
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).
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.
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.