Coding Task List - Before IB2 Initial Release

[youngneil1]

Framing the screen correctly for diagonal maps works much better now. There's a little framing glitch still ongoing (for all neighbourign maps actually), but a player must focus on it to notice, so I think this one can wait.

Debugging the erratic mover behaviour on diagonals will be much harder. They do strange jumps between positions sometimes. This '"sometimes" makes it even more tricky for me.

I think I have to figure out whether this is draw related or pathfinding related for starters...

On another note: I have an idea that might speed up pathfinding a lot (ie only recalculate an existent, old path if a block is on the next five steps).

[youngneil1]

Good news here - I fixed the tricky bug concerning scrolling props on diagonally neighbouring maps, yeah !

There are still minor screen framing issues which I revisit now.

Then I will take a look into optimizing the pathfinding performance (see above)...

[youngneil1]

Almost done with fixing the remaining framing issues - only one instance left to look ino as far as I can see. Oh, I also have to investigate the code for drawing the shadows - it stops drawing those a bit too early on scrolling.

[youngneil1]

All framing issues fixed.

I optimized pathfinding heavily (basically old paths, which are now stored for each prop, are used much more often instead of doing a full recaluculation on every step; this is more tricky than it sounds because we have movers with dynamic targets (chasers, time driven movers when departure time of next waypoint is reached before actually getting to this waypoint) as well a as dynamic area maps, eg walkable state changes via scripts, and also move blocking props that can be movers themselves; note to self: eventually consider effetcs of dynamic height changes, too; also movers can do 2 moves at once on the right rolls... lots of stuff to keep in mind here when trying to just use a path that was valid eg three turns ago).

[youngneil1]

Bug fixing left and right here (eg clones of time driven movers on certain area change constellations, unwanted automove on exiting chest screens, duplicate encounters when idling too long on the battle summary screen, etc).

I would be lying if I said that this is the most fun part of it all, but hey, I fix it now while the relevant code sections are relatively fresh in my brain or it becomes a real nightmare when it hits easily distracted future me a few months later down the road .

[youngneil1]

Debugging and polishing chaser behaviour right now. Generally, I try to set up the movement and triggering system in a way that the trigger on a mover entering the party square is only called when the prop has a good overlap with the party icon. It is not totally glitch free, but much more intuitive alreday (the palyer sees which mover attacked/initated conversation before the combat/conversation screen pops up).

[youngneil1]

Takes quite a bit of resolve to get the whole living world (seamlessly connected, all the movers types with their diferent logics, scrolling and animated, weather, height shaodws, light system, fading fog of war, outer border framing, good collision feedback so the player knows intuitively why an encounter/conversation started, visual hints for chasers (done), double movers (todo) and idlers (todo), ideally all while above 30 fps, sigh) right... last glitch fixed concerned behaviour of chasing props when the player crosses over to a seamlessly connected neighbouring map (return to post). Had an odd pathfinding crash that happened only once, must be watchful for this one (I set up some try/catch debugging lines in various pathfinding related methods here).

To improve performance for many movers in calculation range I might add a system that puts a hard limit to the number of pathfinding calculations each turn, idling/pausing all other movers. I will have to make sure then that the enigne remembers who was already moved last turn and choses new movers from the pool this turn. I would exempt chasers from this (they would always be preferred).

[youngneil1]

So, I optimized performance by quite a margin again (finetuned streaming system for loading/unloading graphics again, placed limit to 10 pathinding calculations each turn; note: this is does not limit props just following their existing path and also a prop will never skip twice in a row due to performance cap, even if performance cap is exceeded due to this; currently chasing props are never excluded from pathfinding calculations).

Also, I added graphic indicators for props taking a pause, due to speed comparison with party speed or due to being hit by performance cap (little grey cloud) and for props moving very fast due to speed comparison (little green speed lines).

Furthermore, I squished various little glitches and bugs. I have become a bit zealous with this, but letting bugs/glitches pile up is one of the greatest dangers for the project I think.

Next up is adding a little village with time driven movers and time/place fitting barkstring ("Good Morning" (time is morning), "'Have a good night" (time is evening), "Zzzzzzz" (night time), "Praise the Lord of Light" (currently in temple), "The ale is fine" (currently in Tavern), etc.) to my 25 map connected testing ground. This will likely include scale changes (inside house zoomed in, outside zoomed out) and an overview map of the village (using the show map button(s)). Having this work bug free is the crucial, watershed benchmark for time driven movers. I am bit afraid of the effort (and outcome ), but I think we will get very valuable intel from this excercise. I have to do this now, as I was never deeper into this part of the code.

[Dorateen]

[youngneil1]

Thank you, Dorateen - once I get the village up and running I will do a video about it. Also, it will be included in the Tutorial Module, so it can maybe be used as a builder's template/ressource .

Edit: Before starting this work, I am having one last go at improving the ui draw performance. Testing shows it is related to the text on the buttons. I yet have to figure out why rendering this button text is so performance intensive.