I think the player model fits fine with the tiles. You mentioned PS1 era games, which makes me think painted backgrounds + "crisp" (e.g. no blended edges) sprites/models.
The problem I see is with the brick building tiles you added. They're nice on their own, but they don't fit the architecture of the previous set of tiles. To match the curved arches, I would suggest trying round pillars made out of the same (or similar) material as the walls.
Funny you should mention that you went from phone to tablet. My tablet recently died, but I got a smartphone to replace by old dumbphone and the tablet in one swoop. It definitely makes me want to make a small game with much lower resolution art assets to better fit small screens.
Clint's been working hard on creating new art resources at the higher scale. You're right that this stuff is time intensive, and I'm not sure how much free time Clint actually has.
First off, this project looks really cool. Definitely keeping an eye on this. As for your questions:
1) We have our tiles in Tiled setup to be 64x128. This leaves empty space above the smaller 64x32 tiles, but allows for "tall" 64x128 tiles such as walls. You'll need to modify your tileset image so that it fits on a 64x128 grid.
2) Some time ago, I wrote a Python script to take a Tiled tmx file and generate a Flare tileset definition + tileset image. You can find it here: https://github.com/dorkster/tilesetdef-generator. You will probably need to edit the image file path in the resulting tileset definition to fit the file structure of your mod.
Colorblind mode only adds text descriptions for item qualities. So for "green" items, we'll display the text "Quality: High" in the tooltip. That bug you describe with combat text is a new one. I have no idea what could be causing that.
As for alternate architecture, I would want to try using this artwork by Clint: http://opengameart.org/content/medieval-building-tiles. We'd need to add these tiles to the grasslands tileset, and potentially need to re-render them to fit the most recent lighting scheme.
To be fair, the Android port has mostly been a fun "because we can" experiment. I'm a bit relieved that someone else had the same issue as me with the game freezing when opening switch-controlled doors. I think some devices might have an issue with modifying textures directly, so we may need to do our pixel writting in a regular SDL_Surface and convert afterwards...
As for the controls, there's probably something we could do about the areas where we expect the player to mouse-over on PC, like the Character menu tooltips. I'm not sure how we fix reading books from the Inventory menu yet.
Combat controls are definitely the toughest. The controls are essentially the same as enabling mouse movement on PC. So one solution I've thought of is taking advantage of multi-touch to emulate SHIFT-clicking on the PC. This would work by holding the player in place with one finger, and using another to do the aiming. We'd probably have to refactor a bit of our input code to handle multiple input points.
It looks like the engine wasn't translating text in books. It should be fixed now. Also, I've fixed the bug with incorrectly animating enemies after the player dies.
As for hitting close enemies, this is because the standard mage attack starts a bit in front of the player (we call this "melee range"). We start the spell in that position so that it looks like it's coming out of the wand/staff the player is weilding. Unfortunately, this means that the starting position is sometimes beyond nearby enemies. The fireball spell, on the other hand, starts directly from the player's position. So that spell is much more likely to not go beyond nearby enemies. I'm not sure there's an elegant solution to this problem with they current way we do player/enemy collision.
P.S. Thanks for providing video clips with your bug reports. It's very helpful.
I just pushed a set of changes to flare-engine that add an option (enabled by default) to automatically equip items. This should allow you to pick up equip-able gear even when your inventory is full.
I"m not certain about a solution for the skeleton problem you mentioned. I did, however, find a bug in the pathfinding code that could have caused enemies to give up following their path early. That bug is fixed now and may help with the skeleton case.
I think the player model fits fine with the tiles. You mentioned PS1 era games, which makes me think painted backgrounds + "crisp" (e.g. no blended edges) sprites/models.
The problem I see is with the brick building tiles you added. They're nice on their own, but they don't fit the architecture of the previous set of tiles. To match the curved arches, I would suggest trying round pillars made out of the same (or similar) material as the walls.
I just pushed a change that should allow reading notes/books on touch screen devices. Just select the note in your inventory and tap on it to open it. Here's the relevant commit for reference: https://github.com/clintbellanger/flare-engine/commit/a86456227cbe23dcff...
Funny you should mention that you went from phone to tablet. My tablet recently died, but I got a smartphone to replace by old dumbphone and the tablet in one swoop. It definitely makes me want to make a small game with much lower resolution art assets to better fit small screens.
Clint's been working hard on creating new art resources at the higher scale. You're right that this stuff is time intensive, and I'm not sure how much free time Clint actually has.
In the meantime, here's a video of what the new art scale will look like: https://gfycat.com/TenderPointlessBlacklemur
And here's the Wandercall Git repo (obviously very much WIP): https://github.com/clintbellanger/wandercall-ch1
First off, this project looks really cool. Definitely keeping an eye on this. As for your questions:
1) We have our tiles in Tiled setup to be 64x128. This leaves empty space above the smaller 64x32 tiles, but allows for "tall" 64x128 tiles such as walls. You'll need to modify your tileset image so that it fits on a 64x128 grid.
2) Some time ago, I wrote a Python script to take a Tiled tmx file and generate a Flare tileset definition + tileset image. You can find it here: https://github.com/dorkster/tilesetdef-generator. You will probably need to edit the image file path in the resulting tileset definition to fit the file structure of your mod.
Unfortunately, I'm not seeing the XP issue. I have two +8% rings on, and killing a level 10 monster nets 1239 XP.
Colorblind mode only adds text descriptions for item qualities. So for "green" items, we'll display the text "Quality: High" in the tooltip. That bug you describe with combat text is a new one. I have no idea what could be causing that.
As for alternate architecture, I would want to try using this artwork by Clint: http://opengameart.org/content/medieval-building-tiles. We'd need to add these tiles to the grasslands tileset, and potentially need to re-render them to fit the most recent lighting scheme.
To be fair, the Android port has mostly been a fun "because we can" experiment. I'm a bit relieved that someone else had the same issue as me with the game freezing when opening switch-controlled doors. I think some devices might have an issue with modifying textures directly, so we may need to do our pixel writting in a regular SDL_Surface and convert afterwards...
As for the controls, there's probably something we could do about the areas where we expect the player to mouse-over on PC, like the Character menu tooltips. I'm not sure how we fix reading books from the Inventory menu yet.
Combat controls are definitely the toughest. The controls are essentially the same as enabling mouse movement on PC. So one solution I've thought of is taking advantage of multi-touch to emulate SHIFT-clicking on the PC. This would work by holding the player in place with one finger, and using another to do the aiming. We'd probably have to refactor a bit of our input code to handle multiple input points.
Anyway, thanks for being so thorough.
It looks like the engine wasn't translating text in books. It should be fixed now. Also, I've fixed the bug with incorrectly animating enemies after the player dies.
As for hitting close enemies, this is because the standard mage attack starts a bit in front of the player (we call this "melee range"). We start the spell in that position so that it looks like it's coming out of the wand/staff the player is weilding. Unfortunately, this means that the starting position is sometimes beyond nearby enemies. The fireball spell, on the other hand, starts directly from the player's position. So that spell is much more likely to not go beyond nearby enemies. I'm not sure there's an elegant solution to this problem with they current way we do player/enemy collision.
P.S. Thanks for providing video clips with your bug reports. It's very helpful.
I just pushed a set of changes to flare-engine that add an option (enabled by default) to automatically equip items. This should allow you to pick up equip-able gear even when your inventory is full.
I"m not certain about a solution for the skeleton problem you mentioned. I did, however, find a bug in the pathfinding code that could have caused enemies to give up following their path early. That bug is fixed now and may help with the skeleton case.
That bug should be fixed now: https://github.com/clintbellanger/flare-engine/commit/37e2e92e0d548e815f...
Pages