Eventually I will do some beach tiles for Flare, but it will still be a few months from now.
Side note, I'm having a hard time visualizing how to handle the ocean water. Unless I do lots of complicated animated tiles, I don't think I'll be able to manage small waves hitting the shore line. I'll probably just need some good reference images, and just start with a still beach tileset.
Version 0.01 of this project was released on January 1st, 2010. So right now I'm 1 year, 4 months in.
People say that Flare's development is fast. For a most solo effort (I've done about 90% of the code and visual art) done on nights and weekends, it's fairly fast. It's been that way so far for a few reasons:
I keep moving to the next thing. If I gave myself the time I would rewrite 90% of the code and redo 90% of the art. But that's a sure way to never finish a project.
I keep the scope narrow. If I added multiplayer, there would not be a game until 2013. If I also added a full scripting engine, more like 2014. 3D rendering, the game might never be completed.
I'm the main coder and artist. I welcome contributions but this is still very much my project -- I know where I'm going, I don't need permission from anyone else to get there.
Even with all this speed, the release of the first game is looking like the end of 2012. 3 years from scratch to a game is pretty fast for a game of this size.
pennomi, I just committed r344 that has the fixed Tiled cave set with the crates/barrels/chests.
I've thought about that idea of having a shared tileset for these things -- actually it could be done without too much trouble. I haven't done it yet cause I was hoping on having different art for cave containers. Just haven't gotten around to that yet.
AI gets into a long discussion, I think we should figure stuff out before code gets written/changed.
Pathfinding
Currently the pursuit AI is dead simple: face the hero and walk forward. It is supplemented by one main feature: If the enemy loses Line of Sight on the creature, the enemy instead pursues where it last saw the hero. This works surprisingly well for most situations.
I think this could be supplemented by A* in the following way: If the enemy has Line of Movement, use the simple pursuit (face hero, move forward). If the enemy loses Line of Movement but can still see the target, calculate an A* path once and follow that path until Line of Movement is re-established (then abandon the A* path and continue with simple pursuit).
Fear
This can be done simply: face away from the hero and move forward. A chance_flee could be used, and checked when certain situations occur (e.g. another nearby enemy dies, the enemy takes damage, etc). Spells could also have a fear_duration added (War Cry was intended to have an AOE fear component).
Monster Packs
One simple way that monster packs can be done: enemies in combat could emit an AOE pulse that targets creatures (e.g. source Neutral). It could have no damage component but still have an attack roll. Basically, if a creature is attacked (even if missed) it automatically enters combat. Dropping an invisible AOE hazard could be an easy way to get nearby creatures into combat.
Non-Target Specific AI
This might be too far outside the scope of Flare 1.0. Save it for another time. Flare 1.0 won't have henchmen, pets, multiplayer, creatures attacking each other, etc.
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.
Eventually I will do some beach tiles for Flare, but it will still be a few months from now.
Side note, I'm having a hard time visualizing how to handle the ocean water. Unless I do lots of complicated animated tiles, I don't think I'll be able to manage small waves hitting the shore line. I'll probably just need some good reference images, and just start with a still beach tileset.
Throwing my pasty-white self into the ring!
Version 0.01 of this project was released on January 1st, 2010. So right now I'm 1 year, 4 months in.
People say that Flare's development is fast. For a most solo effort (I've done about 90% of the code and visual art) done on nights and weekends, it's fairly fast. It's been that way so far for a few reasons:
Even with all this speed, the release of the first game is looking like the end of 2012. 3 years from scratch to a game is pretty fast for a game of this size.
pennomi, I just committed r344 that has the fixed Tiled cave set with the crates/barrels/chests.
I've thought about that idea of having a shared tileset for these things -- actually it could be done without too much trouble. I haven't done it yet cause I was hoping on having different art for cave containers. Just haven't gotten around to that yet.
wokste,
Looks pretty good. You kept it simple and that's always great.
Sometime this week I'll look at merging this Unit code in. You, Bonbadil, and I all did some coding over the weekend and it can't be merged easily.
AI gets into a long discussion, I think we should figure stuff out before code gets written/changed.
Pathfinding
Currently the pursuit AI is dead simple: face the hero and walk forward. It is supplemented by one main feature: If the enemy loses Line of Sight on the creature, the enemy instead pursues where it last saw the hero. This works surprisingly well for most situations.
I think this could be supplemented by A* in the following way: If the enemy has Line of Movement, use the simple pursuit (face hero, move forward). If the enemy loses Line of Movement but can still see the target, calculate an A* path once and follow that path until Line of Movement is re-established (then abandon the A* path and continue with simple pursuit).
Fear
This can be done simply: face away from the hero and move forward. A chance_flee could be used, and checked when certain situations occur (e.g. another nearby enemy dies, the enemy takes damage, etc). Spells could also have a fear_duration added (War Cry was intended to have an AOE fear component).
Monster Packs
One simple way that monster packs can be done: enemies in combat could emit an AOE pulse that targets creatures (e.g. source Neutral). It could have no damage component but still have an attack roll. Basically, if a creature is attacked (even if missed) it automatically enters combat. Dropping an invisible AOE hazard could be an easy way to get nearby creatures into combat.
Non-Target Specific AI
This might be too far outside the scope of Flare 1.0. Save it for another time. Flare 1.0 won't have henchmen, pets, multiplayer, creatures attacking each other, etc.
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.
Pages