Dependencies and path-finding.

Hi everyone,

The last week-end, I spent a bit of time in changing Valyria's Tear dependencies.
Just like anything sensible, the dependency problem is something tedious one has to take care very softly.

To be honest, and since Allacrost already used SDL, I took the way of adding the SDLImage dependency that will take care from now on to load the image data.
Since the SDL Image library is made by specialists and tested by a lot of people, it will ease the pain of testing libpng direct calls for that case.

More importantly, I've also been working on the collision detection algorithm.
After a lot of pain and struggle with the existing system, I simply took the step to rewrite it from scratch, and it came out much more simply than I thought.
The previous algorithm was splitted into about four functions, each containing their own limitations and historical bugs, making it all a nightmare to debug.
The new implementation is much smaller and permit to fix most cases, uncluding pathfinding and sprites untangling, and permit also not to block the player or a NPC when it is walking diagonally against a wall, by making it fall back to the free straight direction in that case.

I guess a big final step forward as been made in this sensible area, as you can see, and the only blocker left to make a first complete episode so far (art excepted) is the rewrite of the shop mode :)

Stay tuned ;)

Visual debugging

Hi,

Lately, I've been still working on several little things:

I Merged the sprite position and offset into one float, both in scripting and in the inner API.
I left proper pixel perfect rounding where necessary, to keep avoiding the flipping seen because of the map mode view point and technique chosen.

Based on that, I'll be aiming at using float based path coords for path move events and collision detection which should all in all simplify a bit everything.
To start with something helping, at least IMO, I added a debug view in the map mode showing the different collision types in a visual way:

The blocking area can be displayed for debugging purpose.

I also removed the fringe layer support in both the game and the editor, and made other minor fixes.
I guess that pathfinding apart, the engine is quite in a good shape to go further in the story now. :)

Scripting system simplifications and other fixes

A lot of behind-the-scene work has been done to the scripting engine lately, as told before, and I must say I'm quite happy with several of the schortcuts added. :)

Namely, the Event and dialogue Managers are the one important pieces there, cleverly thought by Tyler, IIRC.

In a first row, I added mostly support for several shortcuts, using handlers as parameters, instead of Ids.
Permitting to avoid this :

local character = ...

...

local character_id = 1

local dialogue = hoa_map.SpriteDialogue(1)

local text = "My Text";

dialogue:AddLine(text, 1);

DialogueManager:AddDialogueReference(dialogue);

character:AddDialogueReference(1);

...

Imagine now a map with 15 npcs, two important characters, and I didn't speak about events there, yet.
Do you think you can still remember the id used there without making a bunch local variable retaining the important ids?

The equivalent code is now:

local character = ...

...

local dialogue = hoa_map.SpriteDialogue()

local text = "My Text";

dialogue:AddLine(text, character);

DialogueManager:AddDialogueReference(dialogue);

character:AddDialogueReference(dialogue);

...

No more ids, in that case. Same philosophy for events. And it does seem to work quite well so far. :)
Don't worry, I still left the former way of doing it, so that one can go back using it when needed.
EDIT: Note that events still have ids, but they are now string based, and I do think it more readable so far.

The second problem I had to fix is the event chain handling, which appear to not handle chain breaking, and delayed event pausing. This is now done, and permitted to make the hero's mother to stop waking here and here, and come and speak to him when he tries to get out of his house. Sounds quite a simple case, but believe me, that one gave me some hard times.

The hero's mother can now come and speak before he can leave the house.

I, then, started to rework on the maps, and fell on the context handling, which was currently only handling the base context inheritance, which is fine in itself.
As I'm a little bit crazy, and saw that the editor was semi-prepared to welcome the feature of context inheritance for something else than the base context, I hopped on finishing the feature, both in the game app, and in the editor, and while on it, I made the context and its inheritance be declared in the same table in the map files. The context data is still declared at the usual place, but I guess it's fine in the loading logic for now.

With all that so far, we (yes we were two on this.) worked on the three first maps corrections and finally added inhabitants in the village map. (Hurray!)

The village feels less empty now.

Translation system fix and preparing the story characters.

Hi all! :)

Everything is in the title:
I fixed the translation system yesterday, making the boot menu option texts reload when changing the game language.
For those using CMake, the mo files are auto copied upon po file modification in the local (testing) translation location, so you can directly see in game what you've just translated by making modifications to the po file and typing 'make'.
Here is an example:

The menu, in French.

We also discussed the beginning of the story yesterday and I started to revamp the characters' sprites data accordingly.
Most notably, Claudius portrait will be renamed Thanis and be used with the former Kyle sprite, which will kinda stay the Hero's rival in the story.

Warning dev notes below!

Last but not least, I've been lurking in the darkness of the scripting system, most importantly in the event supervisor, to look after possible scripting simplifications: (I've also put the end notes about it here for further self-reference, I must admit :])
- I first removed the need of event id, making the system auto-using the object pointer as reference internally.
On the user-side, it first came as a brilliant idea for simple cases, but had many flaws (and it was already a lot of work just to test it.) For instance, I had to declare the event chains in the reverse order, which is very confusing.
- I also looked at integrating functions that auto-create the event needed in the object. Again, nice for simple cases, but horrible for advanced scripting.

I then fell on the conclusion that even if the event id use was not optimal, it was necessary for not too uncommon cases. I also learned where a simple case is and where it is not, and I might add some shortcuts functions later, trying to simplify simple npc creation.
As the use of Integer id for events is simply hard to carry, I fell on the simple fact that it could be changed to string based ids. After all, it's not more error-prone than integer, and can be used in a more readable way, IMO.

Now it's settled, the next story update should come rather soon.

Best regards,