Perhaps sort your tall tiles in a draw order before drawing them.
I've placed a + sign at the center,floor of each tall tile. I numbered them in the order to draw them if you sort by screen y position first, then screen x position.
This should work if your tiles are always the same size (1x1 grid space). If your tiles are larger there are other algorithms to use (painter's algorithm, z-index, etc).
Scribe, I did the outline in GIMP. Blender does have an Edge setting that does toon style outlines but there's not very precise controls for doing individual pixel outlines.
I find Blender quite useful for this kind of situation. I could have tried animating a spinning cylinder manually but it would have taken way longer and not been very good.
And I think the layperson won't notice or care that this started in 3D.
Multi-player is something that usually has to be done from the beginning. It's easier to make multiplayer choices first, e.g. put all of the game logic in a server, and make single player just run from a local server.
Flare isn't built that way. The game is simplified in ways that won't work for multiplayer (e.g. fixed time step). It means we can actually make and finish a nice single player game, where a multiplayer game would take much longer to develop.
My expertise isn't in multiplayer games, and I vastly prefer single player games. That, combined with choosing a project scope I can actually finish, is why Flare is single player.
Now, some people are working on multiplayer support. Best of luck to them, and if they get it working great I'll include it in baseline Flare.
To those people, though, I would really suggest taking an existing proven multiplayer engine and building an action RPG on it using Flare's assets, rather than trying to make Flare a multiplayer engine. Maybe I'm overestimating how difficult a solid multiplayer code base is though.
So for now, Flare is lightweight and is actually getting done because it's been simplified. Maybe Flare 2.0 or 3.0 could have a bigger multiplayer focus? We'll see where the project goes.
Note that I plan to rewrite the loot dropping algorithm too (not a priority yet though). If you have ideas on that, I'm interested to hear them. I'm also interested in having different loot options -- per-creature loot tables, for instance.
Anything you've implemented that you feel would work in base Flare (as an option or as the default mode), let us know. If the implementation is general enough we might make use of it.
I'm a complete armature newbie. Most of my models have utterly simple FK bones. Maybe this is fine for the kind of very simple stuff I'm doing with Flare?
I'm working on a new base human model for the art upgrade and I've added an IK point to the feet. It certainly helps with some animations where I need to keep the feet planted. But it's not nearly as complex as the rig you have shown here. Do you mind explaining why each piece is needed and how it's useful? Also, in your opinion as an animator, should all human rigs have this level of complexity or does it depend on usage (e.g. a 3rd person 3D game with smart IK to keep feet on uneven ground, vs. a pre-rendered 2D game like mine with tiny sprites).
Oh, there may be two separate issues. Now I'm not sure which one (or both?) you mean.
Add a brightness/gamma slider to the config menu that changes the brightness/darkness of the entire game. I'm pretty sure we CAN add this.
Add in-game lighting that affects tiles dynamically, like torches on walls or spell effects.This one is not easy to do, and we don't currently have plans for it.
If you were referring to #1, then cool. We'll take a look at that now, and have it in release v0.16.
Artists donate all this great open art and you want to use it for a closed game? Maybe that doesn't seem right to me.
Free/Libre art and code is important to people like me. We hope that you "Share Alike".
But yes, you can mix proprietary code and CC-BY-SA art as Botanica says.
Perhaps sort your tall tiles in a draw order before drawing them.
I've placed a + sign at the center,floor of each tall tile. I numbered them in the order to draw them if you sort by screen y position first, then screen x position.
This should work if your tiles are always the same size (1x1 grid space). If your tiles are larger there are other algorithms to use (painter's algorithm, z-index, etc).
I have to throw this a Favorite for the name alone.
wulax, that skeleton is ADORABLE. Great work.
Scribe, I did the outline in GIMP. Blender does have an Edge setting that does toon style outlines but there's not very precise controls for doing individual pixel outlines.
I find Blender quite useful for this kind of situation. I could have tried animating a spinning cylinder manually but it would have taken way longer and not been very good.
And I think the layperson won't notice or care that this started in 3D.
There are no plans.
Multi-player is something that usually has to be done from the beginning. It's easier to make multiplayer choices first, e.g. put all of the game logic in a server, and make single player just run from a local server.
Flare isn't built that way. The game is simplified in ways that won't work for multiplayer (e.g. fixed time step). It means we can actually make and finish a nice single player game, where a multiplayer game would take much longer to develop.
My expertise isn't in multiplayer games, and I vastly prefer single player games. That, combined with choosing a project scope I can actually finish, is why Flare is single player.
Now, some people are working on multiplayer support. Best of luck to them, and if they get it working great I'll include it in baseline Flare.
To those people, though, I would really suggest taking an existing proven multiplayer engine and building an action RPG on it using Flare's assets, rather than trying to make Flare a multiplayer engine. Maybe I'm overestimating how difficult a solid multiplayer code base is though.
So for now, Flare is lightweight and is actually getting done because it's been simplified. Maybe Flare 2.0 or 3.0 could have a bigger multiplayer focus? We'll see where the project goes.
Awesome! Welcome to Flare modding.
Note that I plan to rewrite the loot dropping algorithm too (not a priority yet though). If you have ideas on that, I'm interested to hear them. I'm also interested in having different loot options -- per-creature loot tables, for instance.
Anything you've implemented that you feel would work in base Flare (as an option or as the default mode), let us know. If the implementation is general enough we might make use of it.
Nice!
I'm a complete armature newbie. Most of my models have utterly simple FK bones. Maybe this is fine for the kind of very simple stuff I'm doing with Flare?
I'm working on a new base human model for the art upgrade and I've added an IK point to the feet. It certainly helps with some animations where I need to keep the feet planted. But it's not nearly as complex as the rig you have shown here. Do you mind explaining why each piece is needed and how it's useful? Also, in your opinion as an animator, should all human rigs have this level of complexity or does it depend on usage (e.g. a 3rd person 3D game with smart IK to keep feet on uneven ground, vs. a pre-rendered 2D game like mine with tiny sprites).
Thanks!
Oh, there may be two separate issues. Now I'm not sure which one (or both?) you mean.
If you were referring to #1, then cool. We'll take a look at that now, and have it in release v0.16.
Pages