Map Code: Ideas, suggestions, improvements

For discussion of the code running behind the game

Moderator: Staff

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

Map Code: Ideas, suggestions, improvements

Postby Roots » Sun May 29, 2011 4:11 am

There are existing threads about the map code, but I figured it would be nice to start a fresh one for the upcoming prologue release. Basically I want to use this thread to talk about the current state of this code and where we want to bring it in the future. There's already another thread about graphical bugs in map mode, so lets not duplicate that discussion here.


There are two minor but important features that I am thinking about adding.

1) Smooth map camera movement

Currently the map camera does nothing more than follow the virtual sprite that its assigned to. So we can move a camera around the same way as we would a sprite (a virtual one that has no collision and no image), but I want more. I want to be able to pan and scroll the camera around as I please. For example, lets say that our party walks out of a building and here's a distant scream. I want to quickly and smoothly move the camera in the direction of the scream and focus on the center of the action, then back to the player's party. Or to use the camera to scroll down a cave or maze passage. Think Zelda: Ocarina of Time here.

I actually don't think it will be too difficult to implement either. I may play around with a basic implementation later.


2) Dialogue continue indicators

For the dialogue box, I was thinking that when the end of a line has been reached a small, slowly flashing down arrow could appear at the bottom right of the box to indicate that there is additional lines and that the player should hit the confirm button to continue. When the last line has been reached, instead it could be a small flashing flat rectangle like a '_' character. Dialogues that run automatically and don't process user input (like the very first dialogue in the game's opening scene) will have no indicator. Thoughts on this?
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 » Mon Jun 27, 2011 8:04 pm

As I still want to understand the map code more and also want to add some new features for the dialog system I'm going to assign both to me if there is nobody else wanting to work on the same.

:hack:

So lets go.
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Mon Jun 27, 2011 9:58 pm

Sounds good. :approve: I'll make the graphics for the second item and commit them when I can. If I fail to do so and you're at the point where you need them, send me a reminder that I said I would do that.
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 Jun 28, 2011 7:14 am

Roots wrote:Sounds good. :approve: I'll make the graphics for the second item and commit them when I can. If I fail to do so and you're at the point where you need them, send me a reminder that I said I would do that.

Great. The additional graphics were what I feared most. :rolleyes:
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Wed Jun 29, 2011 12:21 pm

Rev #1981 shows the first code for 1).

The basic idea was to temporarly release the camera position from the sprite it is assigned to. Right now, the movement is not smooth (right now I only go step wise for each tile, the offset was not used so far but will be later) and the whole calculation is in a temporary state. Both I will change in the next commit.

This is just for some initial feedback.

Now, a new function is available from lua.

Code: Select all

    Map:SetCamera(sprite,duration);

where sprite is the sprite the camera should move to and duration is the time in ms this transistion should take. The original SetCamera is stilll available without any changes.

In river_access_cave.lua I showed the usage inside an event. Simply move a few steps and you will see how it works.

Basically, I think about having a special type of sprite for each map that is always available without be created in the lua file. This one should have no image, is not visible and has no collision and can be used to move the camera to any location in the map.

Therefore, the designer can move the camera either to an existing sprite on the map or to any place without a specific sprite using the special one.

Any suggestions?

EDIT: changed num_frames to duration.
Last edited by nemesis on Tue Jul 05, 2011 7:54 am, edited 1 time in total.
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Thu Jun 30, 2011 12:00 pm

Just one idea that was just comming into my mind.

Right now, independent if there is an event, dialog or something else, everything on the map continues. Two things happen to me that should be removed in my oppinion:

1) During a dialog, enemies continued walk and also attacking. That mean, you are in a dialog, some monster is approaching and you have to fight it. After that, you can continue the dialog. In my oppinion the best would be to stop all map sprites (not tile-sprite animation) during a dialog.

This can be easily tested with the two knights at the beginning. Talking to one and after a time the green slime may attack during dialog.

2) During camera movement the same can happen, i.e. the camera is far away but an enemy can come close to you (you don't see it), a battle starts and once it is finished, the camera continues movement. Basically here, all sprites should continue moving during a camera movement, but in my oppinion no battle should start.

Can be seen during the map movement for the corpse event. The scorpion may attack while the camera is on the way to or focussing the corpse.

Any thoughts about this two points?
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Thu Jun 30, 2011 6:31 pm

1) Agree. Although I'd like the dialogue to have an option on whether it "pauses" the other sprites on the map. Because in a town or other safe place, I'd rather see the sprites walking around continuing their business while I'm talking to a NPC. Seems more realistic that way.

Maybe instead of adding in a new option to make dialogues toggle this behavior, for now we can just have the dialogue examine the current map and look at whether or not the map has any hostiles. If it does, dialogue should freeze sprites. If it doesn't, dialogue should not affect other sprites.


2) Agree here too. Maybe the best thing to do is to just add a new function called "FreezeSprites()" and "UnfreezeSprites()" that halts sprite movement. That way whether we're moving the camera, entering a dialogue, or running a custom event, we can easily request that map mode not update sprite movement for a period of time.
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 » Sat Jul 02, 2011 9:30 pm

Because in a town or other safe place, I'd rather see the sprites walking around continuing their business while I'm talking to a NPC. Seems more realistic that way.

I totally agree. Therefore, I implemented it now in a way, that no sprites are paused during dialogues. The problem was also that if I skip the update of map sprites also e.g. Claudius didn't get an update and so he was sometimes paused while he was running (or walking) having still an animation frame.

Also, during movements of the camera (e.g. accross a maze), sprites shouldn't be stop. That would not look good or realistic.

However, the way I did it now (Rev #1990) is that sprites keep moving everytime. They "ask" the map during movement, if they are "allowed" to attack or not. If they are, nothing has changed. If they are not, they will just wander around randomly (as if the camera is not in the enemy zone) and also will not attack if the accidentely have a collision with the player.

The map will not hide the player if:
  • He is in a dialogue.
  • He has found a treasure.
  • The camera is connected to the virtual focus.

Therefore, everything keeps moving all the time but the events mentioned above will not be disturbed by an attack.

:angel: Okay, it is still not realistic that enemies are hunting the player and just stop the hunt if the player starts a dialog. However, maybe in maps sprites with dialogs should not be located in enemy zone, since it is also not realistic that any NPC will have a standard dialog while enemies are wandering around in the near location.

Okay, as long as there are no comments regarding the implementation regarding point 1) I will continue with point 2).
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Sun Jul 03, 2011 2:05 am

nemesis wrote: :angel: Okay, it is still not realistic that enemies are hunting the player and just stop the hunt if the player starts a dialog. However, maybe in maps sprites with dialogs should not be located in enemy zone, since it is also not realistic that any NPC will have a standard dialog while enemies are wandering around in the near location.


I've thought of this as well. Except for the first pair of sprites that are together in the lower part of the cave, I think I mostly tried to avoid putting NPCs in enemy zones for this reason. I think for the cave map I'll move those two to another spot where enemies aren't roaming around. We still need to consider the case of NPCs and dialogue occurring in an enemy zone though, as I don't think just avoiding putting NPCs into an enemy zone is a real solution (we may have a scripted event where a NPC is battling an enemy sprite on map, for instance).
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 03, 2011 7:48 pm

Basically we can also give NPCs a few more properties. One could be their behavior if enemies next to them. Different options for such a flag can be:
  • Fight enemies: Not a real fight but they are moving against enemies rather than standing at a fixed place.
  • Avoid enemies: NPCs are moving away from enemies.
Also, in this case they can get an alternativ dialogue like:

"Don't stop me now. We need to fight here. Lets kill them and move to a different place."

while enemies are in a certain distance to them. Once enemies are dead (and maybe will respawn with a delay) they will have their right dialog. However, when I think again of this, this should be skripted rather than hard-coded for the hopefully low number of the NPCs located in enemie zones.

However, this all can be done later.

Another point:
For now, dialogues will be printed outside the dialog window if the line too long. Since designers can always make sure this will not happen it may not be avoided for translations if the (original) English text is close to the maximum length. E.g., German text are generally much longer than the corresponding original text.

May dialogues be scrolled. I.e., once a certain text comes and the end of the last line is reached all lines will be shifted up and the first line is removed. Once everything is shown, the player can use the arrow keys to move the text up and down (with some up and down arrow appearing if neccessary).

The other option may be simply to make all dialogues short enough that it will fit for all languages.

The reason why I ask this is that I also need to have always some space at the low right corner for the flashing arrow and this may lead to additional line breaks for long texts. ;)

... the flashing arrow for the next screen will only appear if the text is at the end and the down arrow would not appear...
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Map Code: Ideas, suggestions, improvements

Postby nemesis » Wed Jul 06, 2011 7:30 am

Just another thing for the maps, since I want to implement this first for the next release.

Following some ideas about enemies roaming in a map. Bascially right now, two cases exist.
  • Player is in the near distance: The enemy moves directly toward to player. However, if there are blocking elements in the path, the enemy is blocked, even if there exists an easy way around.
  • If the player is not near, the enemy moves completely randomized.

Lets talk about the second item first. As stated in a different topic, there should be a more advanced algorithm for the sprites. (I just want to post it here to have all map mode related topics together) I would suggest implementing different moving patterns that can be assigned to an enemy sprite. Here some ideas:
  • RANDOM_MOVEMENT: As already implemented.
  • WAYPOINT_MOVEMENT: Two or more waypoints can be assigned to the sprite. The sprite will follow all in a listed order. The advantage is, we can define more realistic movements for e.g. human sprites, i.e. guards in a castle following their standard way. Also, this can be applied to non-hostile sprites as people in a town, i.e. moving from thier house to the pub and back. The sprite will go the a waypoint, stay their for a certain (or randomized) amount of time and go to the next one. Maybe two options will be best: ONEWAY-> waypoints in the order 1-2-3-1-2-3-... or ALTERNATE_WAY-> 1-2-3-2-1-2-3-...
  • LURKING_MOVEMENT: As proposed in the other thread. The sprite moves somewhere, stays there for an amount of time, looks in all directions and finally moves in one.
  • more ideas to come...

Right now, some path-finding algorithm is implemented but used for the corresponding event. However, there are more cases, where path-finding can/should be used. Two are mentioned before:
  • Enemy is following the player and avoids obstacles.
  • Enemy finds the shortes way to the waypoint

Therefore, the path-finding sould be used in a more general way. The most important thing is that e.g. for item 1 of the last list, the number of path-generation is reduced and not repeated in every frame when the player has moved (maybe by only recalculating when the player has reach a new tile but independent of the offset).
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Wed Jul 06, 2011 9:22 am

Sounds right to me. The only thing I'd add is in waypoint movement is that in addition from moving from A to B, we'd also want to be able to declare that it stop and face a direction for a certain amount of time. So we could build an enemy sprite with a bunch of different movements and "look in direction X" in a cycle that it repeats.

This functionality should be available on map sprites as well. I know we can tell the map sprite to move from A to B, but I don't know if we have the "stop and look in a direction" part available. Since enemy sprites are derived from map sprites, if you implement the functionality on map sprites (which you should) then enemy sprites should naturally be able to make use of 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 » Mon Jul 11, 2011 5:30 pm

So I would suggest having something like:

Code: Select all

sprite = ConstructSprite("Karlate", 2503, 242, 8);
sprite:SetMovementMode(Map.LISTMODE);

moveList = ConstructMoveList();
moveList:AddWayPoint(242, 8, 2000); -- A
moveList:AddWayPoint(280, 8, 2000); -- B
moveList:SetRandomStop(1000, 3000, 0, 3, 0.3, 0.6); -- min duration, max duration, min number, max number, possible min distance, possible max distance
moveList:AddWayPoint(280, 30, 2000); -- C
moveList:SetFixedWaitStop(1500, 0.5); -- Duration, distance
moveList:SetDirection(hoa_map.MapMode.NORTH);
moveList:AddWayPoint(242, 30, 2000); -- D
moveList:SetDirection(hoa_map.MapMode.SOUTH);

sprite:SetMovementList(moveList, Map.CYCLE);

This would define the way a sprite (any sprite on the map, not only enemies) will walk. In this example, one defines 4 waypoints the sprite is going to in the Form A-B-C-D-A-... Stops are always defined for the way between the last two waypoints. The third number for the waypoints is the time, the sprite will stay at this point.

Between point A and B, there is a random number of stops for the sprites (between 0 and 3 stops). These should all happen in the range of 0.3 ... 0.6 of the full distance between the points. E.g., guard is moving through a prison with some cells.

Between B and C the will always be a stop in the center between both points. E.g., guard is moving on a wall with a tower in the center.

Between C and D and D and A there will never be any stop.

For a stop, the duration (either random or fixed) must be defined. In that time, the sprite will not move but change the facing direction a few times.

Code: Select all

SetDirection(hoa_map.MapMode.NORTH);
defined directly after a stop definition will define a fixed direction (rather than the default random). Directly after a waypoint will define the direction during the stop at a waypoint.

Possible modes may be:

Code: Select all

sprite:SetMovementMode(Map.LISTMODE);
as shown or

Code: Select all

sprite:SetMovementMode(Map.RANDOM);
as already implemented but more "intelligent".

Possible for the list mode can be:

Code: Select all

sprite:SetMovementList(moveList, Map.CYCLE);
as shown above

Code: Select all

sprite:SetMovementList(moveList, Map.ALTERNATE);
for the form A-B-C-D-C-B-... or

Code: Select all

sprite:SetMovementList(moveList, Map.SINGLE);
the sprite will only move one time. This can be usefull for scripted events, where the sprite movement mode is changed from random to list and changed back to random later.

Is this too much? :angel:

Right, all can be done by scripted events but since this may be applied the many sprites (I hope), hard-coding make sense. :rolleyes:
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Tue Jul 12, 2011 11:05 pm

Sounds great to me. Yes, I agree that this will be done often enough that it merits hard-coding for these types of actions. Although I think we should call this a sprite's "action list" instead of a movement list, because I want to be able to do more than just do movements. We may want to display custom animations of the sprite, or change its appearance, etc. as well. But yeah I'd say you are on the right track with this set of ideas. :approve:
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Wed Jul 13, 2011 2:35 pm

Hi there,

Here is a very small optimization proposed to the first map, permitting to avoid the rough camera focus changing,
thanks to nemesis work:

Code: Select all

+++ allacrost-game\dat\maps/opening_scene.lua   2011-07-13 15:17:57.233284800 +0200
@@ -561,7 +561,7 @@

 -- Sprite function: Focus map camera on sprite
 map_functions[1] = function(sprite)
-   Map:SetCamera(sprite);
+   Map:SetCamera(sprite, 800);
 end


I also noticed two bugs that someone might be interested in fixing those:

1. While the characters are marching to the east, try dragging the window's border (you have to play in window mode, of course :]) in Windows XP for a few seconds, and release it. Then, the soldiers are becoming like crazy. This can even block the entire scene sometimes if repeated.

2. If you push escape while the screen is fading to black (for instance between the map transition), you stay stuck with the escape menu being invisible due to the opacity of the transition mask. May I suggest that the escape menu should be displayed above it?

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

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Thu Jul 14, 2011 3:07 am

Cool, thanks for that. I just tried it out and wow, that's really smooth camera movement. I love it! :D (Thanks nemesis).


Regarding your bugs:

1) Could not reproduce in Linux. I do get some "lag" if I switch the active window context from Allacrost to another application and then back, but that's because (I believe) I designed the main game loop so that if the game is not in the active window context, then it runs slower so it doesn't take up as much CPU. I assume in this case that the user is wanting to do something else with their system resources if Allacrost is not active. This also occurs whenever you go into pause/quit mode, since we don't need to do a lot of updates/drawing there.

It does sound like an important bug to fix though.


2) Yeah I remember this issue, thanks for bring it up. Its actually harder to fix this one than you might think. What happens is that when we do a screen fade, that's a command sent to the video engine to fade whatever it is drawing to the screen. However if we switch to another game mode during that fade, the video engine doesn't know that so it keeps fading the screen, and won't fade it back in until it is told to. I see two possible solutions to this problem:

A: Never allow a transition to another game mode during a screen fade.

B: Add a feature to the video engine that will allow us to pause/unpause fading.


But I suspect that this problem is not isolated to just fading, but other graphics effects as well such as lighting or screen shakes. I think thus (B) is a more suitable alternative, because its difficult to place responsibility on the game mode programmer to account for every graphical effect that may be happening.
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 » Thu Jul 14, 2011 7:28 am

The first bug also happens for me in windowed mode. I already put it somewhere in the forum here but it is very good for me to know that this happens for other Windows users also. Thanks for this confirmation. :)

This one should definitely be fixed.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Map Code: Ideas, suggestions, improvements

Postby Bertram » Thu Jul 14, 2011 8:39 am

Hi,

Cool, thanks for that. I just tried it out and wow, that's really smooth camera movement. I love it! :D (Thanks nemesis).

I'm glad you like it. May I ask you to push it along with the other patch?

1) Could not reproduce in Linux. I do get some "lag" if I switch the active window context from Allacrost to another application and then back, but that's because (I believe) I designed the main game loop so that if the game is not in the active window context, then it runs slower so it doesn't take up as much CPU. I assume in this case that the user is wanting to do something else with their system resources if Allacrost is not active. This also occurs whenever you go into pause/quit mode, since we don't need to do a lot of updates/drawing there.

It does sound like an important bug to fix though.

Indeed, the windows border in linux don't forcefully pause the application. (They don't on KDE4, for instance.) So the problem is more likely to happen with windows systems.
(Note that I have the luck to be able to test Allacrost on both system :])

It seems to me me that it must come from a difference in computation with the beings position update and the camera viewpoint when the application is paused in such a way. I noticed that the beings seem to keep on walking in the given direction as if the application never paused, while the current pathfinding node to reach seem to really pause, hence making them go back to it once you've released the window title bar. The bug seems also to be not only that, since the beings are deviating north-wise once you've released the window.

I hope it helped.

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

Re: Map Code: Ideas, suggestions, improvements

Postby Roots » Thu Jul 14, 2011 7:34 pm

Yeah this change will already be in for my next commit. I'm adding a lot of changes to all of the maps today in preparation for our release this week.


As for this bug, someone else is going to have to take responsibility for it because A) I can't reproduce it and B) I have way too much on my plate right now anyway.
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 » Thu Jul 14, 2011 8:37 pm

Since I can reproduce this I can work on A) or Bertram will. ;) No I can do this. Unfortunately I didn't have much time the last week. I try to fix pathfinding for the next release and later will work on the dialogs, sprite movement and the bugs we have discovered.

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 1 guest