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.
Players should be careful with teleport scrolls. If they get stuck, save and exit.
Death penalty will have some config options.
Examples:
Mix and match to create the death penalty desired.
The tone of the individual game should dictate what the death penalty is.
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!
Pages