Stefan Beller, the original author of that code, wrote an explanation at one point. But it seems to have gotten lost for some reason (probably due to the Github organization migration). Luckily, I saved the email, so here's what he wrote: https://gist.githubusercontent.com/dorkster/ddd19a0c91400ffd1c31c8ba18df...
I'll also attach the graphic he made, since I think it does an even better job of showing how the information is laid out. Granted, the description is a bit out of date since we don't have the 256x256 map size restriction anymore. Which is why the shift amounts are different in the current version.
The TL;DR explanation is that there are 4 critera for sorting. In descending order of importance:
Which tile the object is on (red)
Which row is the object on (green)
The object's position within the tile (blue)
Any additional priority information, such as when handling dead/alive or speical effects (yellow)
While invincible, the only thing that can alert Mez is the player getting within his "threat range". With the location that Mez spawns at, this is impossible to do without triggering the trap.
The bear trap only sets enemy speed to 0%, which is not the same as the "stun" effect that prevents all actions. Lezaith could still attack, but chances are you moved outside her targeting range, so she could effectively do nothing. So yes, it's better to prevent trapping her altogether.
One trick for the zombie bug is that summoned creatures will teleport to the player automatically if they get too far away. This distance is currently set in the engine as 40 tiles. Unfortunately, this is too large for smaller arenas such as Mez's. I don't think there would be much harm in decreasing that 40 tile distance, but there might be a better solution.
I fixed Mez by simply making him invincible towards all attacks until the player is trapped in his arena.
The thing with Lezaith technically wasn't a "bug", especially since she could still use her ranged attacks when trapped. But she's also the final boss, and should be a tough fight because of that. So I've given her immnuity to slow and stun effects.
I had mentally lumped it in with this issue, but it's really something separate.
Instead of just adding hp_regen_percent and mp_regen_percent, I did some thinking on how we should handle such percentage-based bonuses and opened a new issue. I think it will be better in the long run.
No new platforms. I just enjoy playing PC games with a gamepad sometimes. Flare in it's current state has a lot of flaws in that area, so I felt the desire to focus on it.
Since I'm the only one doing most of the engine work, I usually just take notes locally in a text file for the stuff I'm working on. I just went through and updated the 1.13 milestones on Github for both the engine and the game.
I don't really have too much to say about my "dream" game. Some key points would be:
Isometric perspective
2D art instead of 3D
Space/Sci-Fi setting
Main character is a salvager looking for crashed ships and old tech.
Primary weapon is a staff. Used for self-buffs and close range AOE. Light melee attacks with the butt end of the weapon.
Firearms as off-hand weapons to provide ranged attacks, but with limited ammo.
Slow combat down and have enemies telegraph attacks more (compared to flare-game). It should be in the realm of human reaction and not just devolve into a stats vs stats battle.
"Bigger" boss fights. The plant boss in Ghostlore is a great example of having big boss within the current limitations of Flare.
I've done what I can to streamline the release process, but it's still not effortless. Releases happen when it "feels" like the engine and game are in a stable place, but it also depends on finding the time to do the release process. Point releases are only done if there is truly a critical bug that keeps the game from working.
There was a crash scenario found in 1.12 dealing with summons, but it can be avoided entirely by defeating most of the enemies on the affected maps (which most people do anyway). I'm still not happy with that, so I'd like to get 1.13 out around November.
There's no hard-set deadlines for most features, so things make their way into the engine when they can. It's usually a combination of community ideas/feedback and my own desires for "that game I want to make one day but haven't gotten to yet." Aside from the current change log, I have a few more things I want to squeeze into 1.13.
I am currently working on overhauling the gamepad experience. I haven't pushed my changes yet, but I've already switched to SDL_GameController from SDL_Joystick, added support for >3 bindings per action, and changed the keybindings config format to better suit these new features. The next step is changing the UI behavior to better support gamepads. For example, instead of having multiple dedicated buttons to alter the actionbar, use one button to toggle the actionbar's focus while using the existing movement/action buttons to interact with it. Other things such as picking a good first widget for all menus, some new bindings (e.g. one to exclusively open the pause menu), and button prompts are yet to be done.
After all that is done, I'll be looking at implementing this, which I think will tie into the topic of this thread in some places. So both may end up being worked on at the same time. That's a common theme, where component A touches component B, and vice-versa.
Of course, there are plenty of other things I have on the idea list. So there may be more in 1.13.
Also worth mentioning that someone is currently working on fog-of-war support. I haven't closely reviewed the code yet outside of helping with a few patches. But it's something I think will be ready for 1.13 as well.
I might be able to fix some of the engine issue I mentioned to get dual wielding to work, but that would be the most I could do. It wouldn't be a priority for me, mainly because, like Danimal pointed out, the required artist work needed to take advantage of it is pretty massive. It would also increase exponentially if we wanted to add new visible armor and weapons.
And if even we did find an artist that wanted to flex their talents, I think they'd be better utilized making new pieces that fit into the existing inventory slots and animation rigs.
@WithinAmnesia Let me give an example using the Waist slot you defined:
# In the item definition item_type=waist gfx=belt
Note that the documentation for gfx is a bit misleading when it says it's a filename. It's a partial filename which, in this example, will translate into "animations/avatar/$GFX_BASE/belt.txt". $GFX_BASE would either be "male" or "female" in the case of flare-game.
Then in engine/hero_layers.txt, you would add "waist" somewhere in each line. I think between the "legs" and "hands" slots would work in this case.
Stefan Beller, the original author of that code, wrote an explanation at one point. But it seems to have gotten lost for some reason (probably due to the Github organization migration). Luckily, I saved the email, so here's what he wrote: https://gist.githubusercontent.com/dorkster/ddd19a0c91400ffd1c31c8ba18df...
I'll also attach the graphic he made, since I think it does an even better job of showing how the information is laid out. Granted, the description is a bit out of date since we don't have the 256x256 map size restriction anymore. Which is why the shift amounts are different in the current version.
The TL;DR explanation is that there are 4 critera for sorting. In descending order of importance:
The bug with the set tooltips should be fixed as of v1.13.05.
That zombie trick is interesting (and totally valid). I think Seagate might be the only major boss battle where that tactic would work:
While invincible, the only thing that can alert Mez is the player getting within his "threat range". With the location that Mez spawns at, this is impossible to do without triggering the trap.
The bear trap only sets enemy speed to 0%, which is not the same as the "stun" effect that prevents all actions. Lezaith could still attack, but chances are you moved outside her targeting range, so she could effectively do nothing. So yes, it's better to prevent trapping her altogether.
One trick for the zombie bug is that summoned creatures will teleport to the player automatically if they get too far away. This distance is currently set in the engine as 40 tiles. Unfortunately, this is too large for smaller arenas such as Mez's. I don't think there would be much harm in decreasing that 40 tile distance, but there might be a better solution.
Thanks for the reports.
I fixed Mez by simply making him invincible towards all attacks until the player is trapped in his arena.
The thing with Lezaith technically wasn't a "bug", especially since she could still use her ranged attacks when trapped. But she's also the final boss, and should be a tough fight because of that. So I've given her immnuity to slow and stun effects.
I had mentally lumped it in with this issue, but it's really something separate.
Instead of just adding hp_regen_percent and mp_regen_percent, I did some thinking on how we should handle such percentage-based bonuses and opened a new issue. I think it will be better in the long run.
Render sizes for Rafflesia:
Main body = 128 x 108
Melee tendril = 144 x 112
Ranged tendril = 150 x 150
None of these are that large by themselves. But when combined, they make the boss feel much bigger.
No new platforms. I just enjoy playing PC games with a gamepad sometimes. Flare in it's current state has a lot of flaws in that area, so I felt the desire to focus on it.
Since I'm the only one doing most of the engine work, I usually just take notes locally in a text file for the stuff I'm working on. I just went through and updated the 1.13 milestones on Github for both the engine and the game.
I don't really have too much to say about my "dream" game. Some key points would be:
I've done what I can to streamline the release process, but it's still not effortless. Releases happen when it "feels" like the engine and game are in a stable place, but it also depends on finding the time to do the release process. Point releases are only done if there is truly a critical bug that keeps the game from working.
There was a crash scenario found in 1.12 dealing with summons, but it can be avoided entirely by defeating most of the enemies on the affected maps (which most people do anyway). I'm still not happy with that, so I'd like to get 1.13 out around November.
There's no hard-set deadlines for most features, so things make their way into the engine when they can. It's usually a combination of community ideas/feedback and my own desires for "that game I want to make one day but haven't gotten to yet." Aside from the current change log, I have a few more things I want to squeeze into 1.13.
I am currently working on overhauling the gamepad experience. I haven't pushed my changes yet, but I've already switched to SDL_GameController from SDL_Joystick, added support for >3 bindings per action, and changed the keybindings config format to better suit these new features. The next step is changing the UI behavior to better support gamepads. For example, instead of having multiple dedicated buttons to alter the actionbar, use one button to toggle the actionbar's focus while using the existing movement/action buttons to interact with it. Other things such as picking a good first widget for all menus, some new bindings (e.g. one to exclusively open the pause menu), and button prompts are yet to be done.
After all that is done, I'll be looking at implementing this, which I think will tie into the topic of this thread in some places. So both may end up being worked on at the same time. That's a common theme, where component A touches component B, and vice-versa.
Of course, there are plenty of other things I have on the idea list. So there may be more in 1.13.
Also worth mentioning that someone is currently working on fog-of-war support. I haven't closely reviewed the code yet outside of helping with a few patches. But it's something I think will be ready for 1.13 as well.
I might be able to fix some of the engine issue I mentioned to get dual wielding to work, but that would be the most I could do. It wouldn't be a priority for me, mainly because, like Danimal pointed out, the required artist work needed to take advantage of it is pretty massive. It would also increase exponentially if we wanted to add new visible armor and weapons.
And if even we did find an artist that wanted to flex their talents, I think they'd be better utilized making new pieces that fit into the existing inventory slots and animation rigs.
@WithinAmnesia Let me give an example using the Waist slot you defined:
Note that the documentation for gfx is a bit misleading when it says it's a filename. It's a partial filename which, in this example, will translate into "animations/avatar/$GFX_BASE/belt.txt". $GFX_BASE would either be "male" or "female" in the case of flare-game.
Then in engine/hero_layers.txt, you would add "waist" somewhere in each line. I think between the "legs" and "hands" slots would work in this case.
Pages