A scripting language essentially turns game code into data -- to change major functionality of the game, the modder doesn't have to recompile. This allows modders to do things that the game creator has not planned.
I definitely would use an existing scripting language (e.g. Lua). But it's not zero effort to build an engine around a scripting language -- it takes effort tying in the core engine code (usually fast C++ render routines) to high-level script functions.
I would think that an engine built for scripting should be built that way from the ground up. Thus, Flare is not a good candidate at this point -- it would require rewriting basically everything, and reimplementing most of it in script.
The method I've chosen for Flare (1.0) is having crude .ini style files to toggle built-in options. It is slightly easier to manage than most scripting languages, for modders with zero code experience. But of course it's not as flexible for advanced modders.
From the beginning of this project I've seen Flare as having a very narrow goal: the ability to do single player action rpgs. Even that scope is wildly massive, but sticking to that scope has gotten me a lot of momentum. Anything much outside the scope is (1) outside my expertise and (2) outside my available time. Anything that adds an order of magnitude of complexity to Flare 1.0 will probably be shelved, or I'll encourage others to work on a separate branch/fork.
hmm I haven't gotten a chance to think too far into the future.
Maybe ponder this: while you were making that cave map, did you ever look for a tile and couldn't find it? E.g. "I wish I had a tile for ____". A list of possible additions to the cave tileset would be nice.
Packaging for any distro is great. I know someone is doing it for Arch Linux already. Let me know if I can help in any way, though I don't know much about packaging for distros/repos.
I do plan on looking into the openSuse Build Service when the game is a little further along.
If you would like to outline a base Units.cpp class, it definitely would be helpful to me. I could handle the trickier differences between Enemy and Avatar (just not immediately).
For timeline info: I plan on releasing v0.13 late April and v0.14 late May. That will probably come with a Beta tag and a freeze on major features. A lot of the coding I'll be doing in Beta will be refactoring, mostly to move hardcoded configs into text files. At some point in there I'll probably think about a base Units class, and maybe a separate UnitAnimation component.
I prefer using composition when possible, rather than inheritance. I think of inheritence as a necessary evil complexity saved for extreme circumstances.
Having a base class for units/entities I'm okay with. Right now there's only Avatar and Enemy so I didn't bother (my style of actually getting a project done: write it sensibly now, refactor it to be pretty later). It would be good to have a Unit class eventually because it'll help with moving NPCs or multiplayer avatars.
It's something floating on my to-do list that isn't a priority (better to write new features than refactor old ones while in Alpha). If you want to take a crack at it though, feel free. Simple is better -- if you spend more than one new class (e.g. Unit.cpp) I might not accept the solution.
Sorry to be a hardass about this, but I'll be the one looking at and maintaining this code for the rest of my life :)
I vaguely understand the concepts of branches and tags, but so far I'm not using them in Flare. So far they haven't been strictly necessary so I skipped it.
One (inconvenient) way to see which commit number goes with which point release is to look at the google code update history. https://code.google.com/p/flare-engine/source/list I'm the only committer, so it should be in order.
A scripting language essentially turns game code into data -- to change major functionality of the game, the modder doesn't have to recompile. This allows modders to do things that the game creator has not planned.
I definitely would use an existing scripting language (e.g. Lua). But it's not zero effort to build an engine around a scripting language -- it takes effort tying in the core engine code (usually fast C++ render routines) to high-level script functions.
I would think that an engine built for scripting should be built that way from the ground up. Thus, Flare is not a good candidate at this point -- it would require rewriting basically everything, and reimplementing most of it in script.
The method I've chosen for Flare (1.0) is having crude .ini style files to toggle built-in options. It is slightly easier to manage than most scripting languages, for modders with zero code experience. But of course it's not as flexible for advanced modders.
From the beginning of this project I've seen Flare as having a very narrow goal: the ability to do single player action rpgs. Even that scope is wildly massive, but sticking to that scope has gotten me a lot of momentum. Anything much outside the scope is (1) outside my expertise and (2) outside my available time. Anything that adds an order of magnitude of complexity to Flare 1.0 will probably be shelved, or I'll encourage others to work on a separate branch/fork.
hmm I haven't gotten a chance to think too far into the future.
Maybe ponder this: while you were making that cave map, did you ever look for a tile and couldn't find it? E.g. "I wish I had a tile for ____". A list of possible additions to the cave tileset would be nice.
Ok, partially added pennomi's scrolls
https://code.google.com/p/flare-engine/source/detail?r=336
I know these are kind of messy but they'll work: http://opengameart.org/content/elemental-scrolls
Packaging for any distro is great. I know someone is doing it for Arch Linux already. Let me know if I can help in any way, though I don't know much about packaging for distros/repos.
I do plan on looking into the openSuse Build Service when the game is a little further along.
Yes I'll merge these scrolls in soon.
If you would like to outline a base Units.cpp class, it definitely would be helpful to me. I could handle the trickier differences between Enemy and Avatar (just not immediately).
For timeline info: I plan on releasing v0.13 late April and v0.14 late May. That will probably come with a Beta tag and a freeze on major features. A lot of the coding I'll be doing in Beta will be refactoring, mostly to move hardcoded configs into text files. At some point in there I'll probably think about a base Units class, and maybe a separate UnitAnimation component.
hennr, I'll start tagging with v0.13. Thanks for your pointers!
I prefer using composition when possible, rather than inheritance. I think of inheritence as a necessary evil complexity saved for extreme circumstances.
Having a base class for units/entities I'm okay with. Right now there's only Avatar and Enemy so I didn't bother (my style of actually getting a project done: write it sensibly now, refactor it to be pretty later). It would be good to have a Unit class eventually because it'll help with moving NPCs or multiplayer avatars.
It's something floating on my to-do list that isn't a priority (better to write new features than refactor old ones while in Alpha). If you want to take a crack at it though, feel free. Simple is better -- if you spend more than one new class (e.g. Unit.cpp) I might not accept the solution.
Sorry to be a hardass about this, but I'll be the one looking at and maintaining this code for the rest of my life :)
I vaguely understand the concepts of branches and tags, but so far I'm not using them in Flare. So far they haven't been strictly necessary so I skipped it.
One (inconvenient) way to see which commit number goes with which point release is to look at the google code update history. https://code.google.com/p/flare-engine/source/list I'm the only committer, so it should be in order.
Pages