Map Code: Ideas, suggestions, improvements

For discussion of the code running behind the game

Moderator: Staff

User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Fri Jul 15, 2011 12:22 am

Thanks nemesis,

Speaking of assignments or so we could call them, I've been putting myself in the mud of enemies placement in battles.

I already saw the code part to modify, where I could put the new algorithm, and I thought it would a nice first visual task for me.
Hence, if you let me a chance... :)

I'll try to put the precise specifications of it in the battle thread before implementing.

Also, i wondered whether the text draw fps drop bug fix was pushed or not. Anyone?

Best regards,
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Fri Jul 15, 2011 12:34 am

Bertram wrote:Speaking of assignments or so we could call them, I've been putting myself in the mud of enemies placement in battles.

I already saw the code part to modify, where I could put the new algorithm, and I thought it would a nice first visual task for me.
Hence, if you let me a chance... :)


Awesome, go for it! :approve:


I can't remember anything about the FPS bug so I have no comment there. If you find the thread where that bug is mentioned bump it there so we can keep this topic limited to map code stuff. :)
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Sun Jul 17, 2011 11:40 pm

Moved here from battle thread as requested by Roots.

Hi,

Me again :D

1. As I found the soldier in the opening map were a bit, well, randomly placed, and didn't look like a military troop, I took the liberty to make changes on the characters placement. If you want to simply try it for yourself, just replace this file in your dat/maps folder:
opening_scene.lua.txt
(134.54 KiB) Downloaded 160 times

new-formation.png
new-formation.png (217.43 KiB) Viewed 6388 times

(N.B.: Please allow .lua, .diff, and .patch as attachment; I'm getting crazy :( )

The main conceptual changes proposed are those (Sorry for the long description for such small changes):
- As Claudius seems to be level 1 at the beginning of the story, I looked at the military grades and assumed he was at the lowest one: 2nd Lieutenant.
- I also assume that the "Captain" needed to have at least one follower and I assumed it would then be a 2nd Lieutenant, but as Lukar seemed to be the chief of the small squad of four where Claudius took place, I took also the liberty to promote the Captain to a Major, and made his direct followers Captains (I've put two of them for now).
- As a conclusion, Lukar and three other became 1st Lieutenant.

Hence, in the opening scene, the squad are already visually formed when the soldiers are marching, which sounds more like soldiers would do to me.
The last liberty I took was to make Lukar called "1st Lieutenant Lukar" in the first map. As I assumed the player was starting the game and knew nobody from the story, I thought it would be a bit more gradual introduction to first name the guy corresponding to the orders he's giving before the map transition. In the second, and next maps, I guess calling them using their names is perfectly fine, for sure.

This is just a proposal about something I found a bit rough for an opening scene. :) Tell me what you think about it!

2. Secondly, I also noticed the soldier were animated too slowly comparing to Claudius, so I made a patch used to make the engine accept a custom frame_speed, making the soldiers on the same trend than Claudius, which sounds better looking IMHO:
first-map-try.diff.txt
(18.88 KiB) Downloaded 149 times

(Note that the patch is including the changes I made to the lua map file).
This patch has the obvious flaw to not permit to set up a custom frame_speed for each frame, but I noted that the number of frames seems to be hard coded also, :heh: Anyway, I wondered whether I was on the right track with such a change. Please, tell me how you'd see it improved! :help:

3. I have a proposal for the map stamina bar when it's infinite: Why not display it for, say, 5 seconds, and then gradually make it disappear?

Best regards,
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Mon Jul 18, 2011 1:06 am

1. My initial reaction was :|, but then after thinking about it I guess it makes more sense. I tried the script though and at the beginning some of the knights, including Claudius, started moving in weird directions because I think their paths were being blocked by the knights directly in front of them. They all managed to eventually straighten out though and get to the end of the map.

Unfortunately you were a bit too late with these changes because this map is already being worked on to accommodate the return trip for this release. So I think any changes like those that you are proposing here will have to wait until after the July release. Also don't forget that we will eventually have mak hounds traveling with the knights on this map, so it may be better to just wait until the hounds are ready so then we can worry about getting all the sprites into proper formation and everything.

As for the assignment of ranks, I'd really rather not do that. There is a second-in-command to the captain (who will be made more prominent after the boss fight in the cave), but other than that I think assigning ranks to Lukar, etc. is just distracting. Its clear (or will be made clear) from the dialogue itself that Lukar is a senior and a squad leader, and that's all that matters. Plus I think its quite difficult fitting "1st Lieutenant Lukar" onto the available space, and other languages might be worse. I don't know how anyone else feels about the rankings, but I just don't like it.



2. Yeah I've noticed this problem too, but I don't think assigning a custom frame speed is the right way to go about fixing it. I feel like the frame speed should be proportional to the movement speed. Maybe setting a custom frame speed might be useful in some rare cases like for certain events, but I don't see us having a need for something like that right now.

I haven't looked into this myself, but I think the reason why Claudius moves faster than the other knights is because his default walking speed by default is set higher than the walking speed for the knights. So when the walking animations are loaded, the animation speed is set to reflect this walking speed. However, to get the knights to move together in a single unit, I had to change Claudius' walking speed in the script to that of the knights. This updated his movement speed, but not his walking animation speed. That's where the real problem is (I think) and it should be relatively simple to fix (I think). You just have to have the "SetMovementSpeed" function, or whatever its called, alter the walking animation speed as well.


3. That's exactly what I thought we should do. I don't like having a stamina bar covering the screen that gives no useful information. I mentioned this on IRC a while back I think and I believe rujasu was against it and he wants that bar to always be visible, even during "infinite stamina" mode. But I'll let him speak for himself because my memory may be incorrect.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Mon Jul 18, 2011 9:09 am

Hi Roots,

1. My initial reaction was :|, but then after thinking about it I guess it makes more sense. I tried the script though and at the beginning some of the knights, including Claudius, started moving in weird directions because I think their paths were being blocked by the knights directly in front of them. They all managed to eventually straighten out though and get to the end of the map.

No, the script was perfectly working before nemesis's latest change on pathfinding. (No offences intended.) This also happened for me with the current script between revisions 2015 to 2020. The important point to me, was the troop's formation anyway.

1.
Unfortunately you were a bit too late with these changes because this map is already being worked on to accommodate the return trip for this release. So I think any changes like those that you are proposing here will have to wait until after the July release. Also don't forget that we will eventually have mak hounds traveling with the knights on this map, so it may be better to just wait until the hounds are ready so then we can worry about getting all the sprites into proper formation and everything.

As for the assignment of ranks, I'd really rather not do that. There is a second-in-command to the captain (who will be made more prominent after the boss fight in the cave), but other than that I think assigning ranks to Lukar, etc. is just distracting. Its clear (or will be made clear) from the dialogue itself that Lukar is a senior and a squad leader, and that's all that matters. Plus I think its quite difficult fitting "1st Lieutenant Lukar" onto the available space, and other languages might be worse. I don't know how anyone else feels about the rankings, but I just don't like it.

Np, you're here to bring the vision, and we're here to help about it :)
I just tried to point out the 'military' side of a troop marching in the desert. Maybe I'll be back with some position change proposal once the mak hounds are there.

2. About the walking animation:
Hmm, I'll think more about it, yet I do think the walking animation speed is wrong for most animation as the soldiers, and even claudius seem to slip on the floor when walking, like when they're walking on a moving walkway.
IMHO, the actual solution is to make the engine able to support the configuration for an arbitrary number of frame, with an arbitrary speed for each.
Then, tuning the numbers so that the animation speed adapts well to the movement speed will be quite easy to do. Anyway, that's low priority for now. At least, not until you've got a game running for the thenth first levels, IMHO. :)

3.
That's exactly what I thought we should do. I don't like having a stamina bar covering the screen that gives no useful information. I mentioned this on IRC a while back I think and I believe rujasu was against it and he wants that bar to always be visible, even during "infinite stamina" mode. But I'll let him speak for himself because my memory may be incorrect.

Ok.

Best regards,
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Mon Jul 18, 2011 10:29 am

Yesterday I fixed some bugs for the path-finding. Basically, the collision check was not performed correctly. -> I switched to using the existing collision detection.

However, there is another problems I don't want to discuss now that occured. I put a workaround in the code for path-finding that works to avoid this bug.

The next steps I'm going to take are the features I discussed last monday in this thread.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Mon Jul 18, 2011 11:23 am

Hi,

Yesterday I fixed some bugs for the path-finding. Basically, the collision check was not performed correctly. -> I switched to using the existing collision detection.

Yeah, i saw that. It's nice you're taking care of that. :)

However, there is another problems I don't want to discuss now that occured. I put a workaround in the code for path-finding that works to avoid this bug.

Could you describe it, even slightly? I've some experience in A* pathfinding debugging, and I even may lay a hand if you allow me to.

I'm looking forward patrolling units, though! :D

Best regards.
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Mon Jul 18, 2011 12:15 pm

The A+ algorithm was correct, except for the collision detection, which is now fixed. Therefore, the path that is found is correct.

However, I try to explain the problem I saw:
  • Assume your last point was (4,3) and the next point is (5,4).
  • When the sprite is near the next point at lets say (4.995, 3.995) the next time the sprite is on (5.033, 4.023). (real values depend on the FPS of the system). Therefore, the exact point (5.0,4.0) is not reached exactly.
  • If it now occurs that collision is detected for this point (that have not occured for (5,4)) and the sprite can not be moved around corners, it is set back to the last location (4.995, 3.995), keeping the direction of movement. Therefore, in the next frame it moves again to (5.033, 4.023) and back.
  • Obviously, this is repeated until the player closes the program, since the (5,4) point is never reached and the movement event cannot finish.
Maybe, a more intelligent algorithm for the direction setting is required. My workaround was using and offset of 0.5 for x and y for any collision check. Therefore, the point (5,4) would not be taken into the path since (5.5, 4.5) leads to an collision. Maybe, (5,3) or (4,4) is taken instead (depending on the map). Bascially, now sprites are holding more distance between walls to avoid this problem. It should work fine if there is always enough space to walk, i.e. I think only 1 tile wide corridors can lead to an abortion of the path-finding.

Would be great if you can find a better solution. Go ahead. :approve:
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Mon Jul 18, 2011 1:29 pm

Hi nemesis,

Please excuse a maybe dumb statement as I'm slowly getting in touch with it:

When the sprite is near the next point at lets say (4.995, 3.995) the next time the sprite is on (5.033, 4.023). (real values depend on the FPS of the system). Therefore, the exact point (5.0,4.0) is not reached exactly.

I see a problem in that sentence already here. If the character was intending to go to 5.0,4.0 why does it go further?

I guess the algorithm should do a std::min in that case when computing the distance reached in one cycle, right?

I'll have a look at the code more closely, but any piece of advice is very appreciated :)

EDIT: Second problem I saw. As none of us is going to implement a pathfinding algorithm where actors are fully taking care of each other's path in real time (or change its licence and sell it to the nasa ;) ), The actor-to-actor (being-to-being) collision should be auto-disabled while the actors are moving.
If you want to have a slight better experience, you may check the path for beings existence and recompute it adding a slight cost on tiles where beings are present, making the moving character avoiding others wherever possible, while not being blocked by ignoring the collision to other in worst cases. My two cents so far.

Best regards,
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Mon Jul 18, 2011 1:55 pm

Basically you are right, the sprite should only go to (5.0,4.0) and not further. However, movement is done is the following way:
  • The direction is defined by the Uint position. Therefore, if the sprite is at (4.995, 3.995), the direction is defined by 4->5 and 3->4, independet of the current offset.
  • In the next frame, the system time is checked and the time difference is multiplied with the speed. This distance is added to both, x- and y-direction. This leads to e.g. (5.033, 4.023) for this frame, although the sprite should only move to (5.0,4.0).
This system is very clever since it makes sure, sprites are walking in the same speed independent of the actual FPS value. However, maybe some limitation algorithm for the movement can be used here but I'm not sure that this is a good idea. Better can be the definition of directions to more than 45°.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Mon Jul 18, 2011 3:22 pm

Hi,

In the next frame, the system time is checked and the time difference is multiplied with the speed. This distance is added to both, x- and y-direction. This leads to e.g. (5.033, 4.023) for this frame, although the sprite should only move to (5.0,4.0).

What I'm now not understanding is the normal case:
What is happening when a character goes beyond the destination and hasn't any collision problem? Does it still try to reach the destination, or is there something making it go to the next destination/path node?

Note that if we're making the beings reach their destination before going to the next node/destination, I guess there'll be no more fps problems than now, because the rule will be the same for every being, IMHO.

Yet, thanks for all the explanation :)

I'll have a look at it more closely when the time is permitting me to do so.

(Off-topic: Check the dynamic battle formation proposal and tell me what you think about it!)

Best regards,
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Mon Jul 18, 2011 3:51 pm

What is happening when a character goes beyond the destination and hasn't any collision problem? Does it still try to reach the destination, or is there something making it go to the next destination/path node?

Correct. When the sprite reaches (5.033, 4.023) or e.g. (5.955, 4.995) (from the other side), the node is reached, i.e. only the integer value is checked.

(Off-topic: Check the dynamic battle formation proposal and tell me what you think about it!)

I will do. :)
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Tue Jul 19, 2011 9:04 am

Hi,

Correct. When the sprite reaches (5.033, 4.023) or e.g. (5.955, 4.995) (from the other side), the node is reached, i.e. only the integer value is checked.

Then, there is no problem in making the character go to the exact position i.e. 5.0, 4.0 in any cas, right?
I will personally try to make the algorithm do that, and see what it means visually.

Thanks for all the advice :)

I will do. :)

Great! :approve:
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Tue Jul 19, 2011 4:41 pm

Since I also want to work in the dialogs (appearance), one question. Why do the DialogueSupervisor classes in map and battle mode do not inherit the CommonDialogueSupervisor class?

Although there are differences there are many common things between both. If there is a good reason not to take CommonDialogueSupervisor as a base class please tell me. Otherwise I will try to merge everything as much as possible.


-------------------------------------------------------
I will personally try to make the algorithm do that, and see what it means visually.

It would be perfect if you can make this work better. :)
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Tue Jul 19, 2011 7:03 pm

nemesis wrote:Since I also want to work in the dialogs (appearance), one question. Why do the DialogueSupervisor classes in map and battle mode do not inherit the CommonDialogueSupervisor class?

Although there are differences there are many common things between both. If there is a good reason not to take CommonDialogueSupervisor as a base class please tell me. Otherwise I will try to merge everything as much as possible.


This was a tough decision for me to make, and I'm still not sure if it was the right one. Basically, it has to do with the CommonDialogue class. CommonDialogueSupervisor keeps a container of CommonDialogue objects. However, both map and battle mode create different dialogue classes (both inheriting from CommonDialogue) that have extra properties that need to be handled. It didn't make sense to me to have to either have a duplicate dialogue container holding the specific dialogue type (ie BattleDialogue) nor did I think it to be a good option to continuously have to cast CommonDialogue objects into whatever dialogue they were supposed to represent.
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Tue Jul 19, 2011 8:02 pm

Good point. I will keep my fingers away from this code. ;)

No I won't, but I will keep supervisors as they are.
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Sat Jul 23, 2011 12:27 pm

Regarding the action system for map sprites. I didn't have any time last week for coding but started last night. Here are the cornerstones of the implementation ... so stop me if you think it is no good idea doing it this way. ;)

  • I will create a new file called map_action.cpp (and the header file), where all implementations for the actions a map sprite (i.e. all actions like moving or waiting and the list for these actions is implemented.
  • There, a class MapAction will be the base class for all actions, a sprite can do. Also all inherited classes will be implemented there.
  • Also, there will be a ActionSupervisor class, which holds the list of actions and ensures the correct process of the list. The member function of this class are more or less already shown in the post some time ago.
  • Each VirtualSprite object will have its own
  • _action_supervisor, which is also available in the lua scripts. I was not sure putting it for the VirtualSprites or the MapSprites, but since the basic movement and collision control is done for VirtualSprites, I decided to implement there.
  • The process of the action list can be started and stopped at any time. Also, it can be defined as: run one time, run in a cycle and run in an alternating way.
  • A sprite checks, if it is controlled by an event. If this is the case, the _action_supervisor won't do an update. Obviously, if there is no event controlling the sprite, the _action_supervisor will take control over the sprite.
  • Each _action_supervisor will be created in a stopped mode and needs to be started manually. This ensures that the camera sprite will still only react on input. However, the STATE_SCENE is still perfectly for non player movement of the camera, either for events or for the _action_supervisor.

Are there any ideas and additional thoughts for the implementation? Otherwise I hope tomorrow (today I have much different stuff to do) in the evening you can see an initial version of this system.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Sat Jul 23, 2011 9:05 pm

  • I would change the name of the MapAction class to SpriteAction. It better describes that these actions only act upon sprites.
  • I would prefer that ActionSupervisor have only a single instance, contained by the MapMode class. This is because all of our other supervisor classes operate in this manner (ie they are basically "helper" classes that manage one specific part of a large class like MapMode or BattleMode). ActionSupervisor can keep a container listing all of the sprites that have actions that should be processed.
  • I'm a little bit concerned about the similarities between events controlling the sprite and actions controlling the sprite. I think its confusing to have two ways to control a sprite. Can't an action sequence be implemented as a chain of events anyway (ie: SpritePathMoveEvent, SpriteDirectionEvent, etc)? You could simply create a closed event loop for the sprite and that is effectively their "action list", and the event supervisor should be able to take care of the rest.

I don't know, I'm having second thoughts about this. :| I think we need a more firm concept on the interaction between actions and events before we get too deep with this. You can go ahead and write the foundation code though, as I don't think that will require much change based on this result.

I'm going to take some time to think about it and I'll post again later. I welcome anyone else of course to propose how events and actions should cooperate together, or even if we need only the event system with some additional work to build a sprite action-type system right into it.
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Sun Jul 24, 2011 8:33 am

Just a very short reply now, a longer may follow later.

First thank you for the detailed reply. I also thought about using the already existing event system for that. However, I thought in the different way. Let events just create actions for the sprite and let the sprite handle this action alone.

This is maybe the most important question. Should the map and a global supervisor for all sprites handle sprites action or should every sprite do this on its own. I definitely agree with the point having two similar systems (events and actions) doing the same is no good idea. I thought about to replace events later.

But otherwise I could do this the other way around.

However, the reason why I initially decided to have the sprite controlling its actions was simply the enemy sprites already do this.
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Fri Jul 29, 2011 7:00 pm

Okay, I'm sorry for not having done anything, buth I was very busy at work and also at my accomodation.

Also, I waited for some more thought here. Since I definitely hope to find some time this weekend I want to continue. I decided to do it the way roots proposed. We definitely should only have one basic system for actions for sprites. We already have a good system with events, so the action system will basically some hard coded map events. Also, some more actions may be required, so doing it as events will also easily allow to use it seperately in lua-scripts.

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 1 guest