Accueil Crush your enemies... and create an EMPIRE!!! Space Empires V -- BUY NOW!!!

Connexion utilisateur

  • Créer un nouveau compte
  • Demander un nouveau mot de passe

Navigation

  • news
    • archive
    • blogs
    • books
    • forums
    • recent posts
    • groups
  • image galleries
  • projects & downloads
  • search
  • create content
  • agrégateur de nouvelles

Rechercher

Qui est en ligne

Il y a actuellement 5 utilisateurs et 213 invités en ligne.

Utilisateurs en ligne

  • Randallw
  • goduranus
  • ForesterSOF
  • BlueTemplar
  • Lastdreamer

Languages

  • English English
  • French French

Parcourir les archives

« Décembre 2008  
Lu Ma Me Je Ve Sa Di
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Accueil » news » forums » Space Empires V » Space Empires V General

Ship movement slow on long routes...

Image de ThiloiFederation
Soumis par ThiloiFederation le Ven, 2006-12-08 00:01 Space Empires V General

I've found that if I give my ship a movement order that will take several turns (more than 5) to complete the animation lags as the ship move along the route. Has anyone else experienced this?

The only explanation of such a slowdown that I can think of is that the game is recalculating the route for every sector the ship must move through. This can take a lot of CPU time given the following route finding algorithm:

1. Find the shortest route
2. Check each sector along route for obstructions
3. If route obstructed, find next shortest route and repeat

Of course, I don't know if this exactly how the game does it, but my point is that this algorithm will have to run (N(N+1))/2 times. So for say a ship that moves 14 sectors a turn and a 98 sector route (7 turns) the route finding algorithm runs 4851 times!

I'm assuming the reason the game does this is just in case conditions on the route change and it must calculate a new route. However, conditions along the planned route should only be able to have changed at the beginning of every turn (opened or closed warp points, etc.), if at all. Therefore, the game should only recalculate the route at the beginning of the movement and the beginning of every turn thereafter. In the example of the 98 sector route above, the game only has to run the route finding algorithm 6 or 7 times depending on whether or not the ship had movement left when the movement was ordered.

Now, if I'm totally wrong about all of this and the slowdown on the long routes is being caused by something else, I apologize. And if no one else is experiencing this issue at all and it is just me, then my sincerest apologies.

Incidently, I wonder what is different with SEIV? It doesn't seem to take longer for ships to move on long routes. Is it because of the lack of the 3D engine in SEIV or does SEIV use fewer calculations?

‹ Fighters: transferring or launching from planet Scanning Enemy Orders? ›
» Vous devez vous identifier ou créer un compte pour écrire des commentaires

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.
Image de cordas

I have also experienced this

Soumis par cordas le Ven, 2006-12-08 05:15

I have also experienced this problem, although to be honest I thought it had something to do with having cargo on ships (the only ships I sent really long distances where ships with cargos....) Your reason sounds plausible to me.

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de Psieye

Lagged movement confirmed

Soumis par Psieye le Ven, 2006-12-08 06:00

Yeah I have it too. Hmm... your explanation makes more sense than anything I speculated on. I think it tries to check each sector again because sensor range is limited. This would also explain ships going back and forth because they try to take the shortest route, find an obstacle, go another way, forget the obstacle and find that same shortest route again, etc.

The algorithm needs to be upgraded as otherwise we'd have to work around this by giving multiple movement orders in short legs. Incidentally... how do you specify waypoints in SE V?

» Vous devez vous identifier ou créer un compte pour écrire des commentaires

sensors and indecision

Soumis par crward le Ven, 2006-12-08 07:55

yes, I've watched my ships dance around a warp point that they've discovered is occupied. sometimes they'll be very ineffective -- move out of sensor range, think there's no ship there, move back in, realize there's a ship there, move out... etc....

It's actually kind of smart A/I really, except that it makes it seem really dumb.

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de Captain Kwok
Mod Designer

Recalculation = longer time

Soumis par Captain Kwok le Ven, 2006-12-08 10:32

The answer is simple. The ship has to recalculate its patch each hex it moves - so the longer the path the slower the movement. Calculating ship movement is the main reason why the AI turns are so long - not script execution etc.

-----

Space Empires Depot | SE:V Balance Mod

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de cordas

Isn't it possible to make

Soumis par cordas le Ven, 2006-12-08 11:30

Isn't it possible to make the ship make use of "visible space" (as in what can be seen at the time) and just move through that without recalculating everything, then when it hits "dark space" simply start plotting again until it hits the next bit of visible space. You could also have it check ahead for and hexes (warp gates or mine feilds for example) that it knows are blocked and tag these to help it make a new route without doing the two step?

» Vous devez vous identifier ou créer un compte pour écrire des commentaires

If you put two or more ships

Soumis par Brad le Sam, 2006-12-09 14:47

If you put two or more ships in a sector and give them a simultaneous move to order, they don't suffer this slow-down problem. Also, when the single slow-down ship moves over another object (ship/planet/asteroids/storm/whatever) it moves at normal speed in that sector.

Strange but true.

» Vous devez vous identifier ou créer un compte pour écrire des commentaires

Wow!

Soumis par Cosmic Marvel le Sam, 2006-12-09 19:18

Captain Kwok wrote:
The answer is simple. The ship has to recalculate its patch each hex it moves - so the longer the path the slower the movement. Calculating ship movement is the main reason why the AI turns are so long - not script execution etc.

Gee whiz, Kwok - that's got to be the most obtuse and inelegant programming I've ever heard of! Certainly it has to first calculate the entire route (no way around that) but then it could still quickly make all the moves within sensor range - since all obstacles are clearly obvious - before calculating again. The current method as described is very, very wasteful of computer resources and CPU cycles. NO wonder it's so dreadfully slow and the CPU stays maxed out!!!

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de Rilbur

But...

Soumis par Rilbur le Sam, 2006-12-09 22:24

Cosmic Marvel wrote:
Captain Kwok wrote:
The answer is simple. The ship has to recalculate its patch each hex it moves - so the longer the path the slower the movement. Calculating ship movement is the main reason why the AI turns are so long - not script execution etc.

Gee whiz, Kwok - that's got to be the most obtuse and inelegant programming I've ever heard of! Certainly it has to first calculate the entire route (no way around that) but then it could still quickly make all the moves within sensor range - since all obstacles are clearly obvious - before calculating again. The current method as described is very, very wasteful of computer resources and CPU cycles. NO wonder it's so dreadfully slow and the CPU stays maxed out!!!

But what happens when the obstruction is RIGHT outside of the given sensor radius? You could run for several sectors in a direction that takes you nowhere before you "notice" the enemy. Ick.
_______________________
There are 10 types of people in the world:

Those that understand binary, and those that don't.

» Vous devez vous identifier ou créer un compte pour écrire des commentaires

So? {grin}

Soumis par Cosmic Marvel le Dim, 2006-12-10 01:33

Rilbur wrote:
Cosmic Marvel wrote:
Captain Kwok wrote:
The answer is simple. The ship has to recalculate its patch each hex it moves - so the longer the path the slower the movement. Calculating ship movement is the main reason why the AI turns are so long - not script execution etc.

Gee whiz, Kwok - that's got to be the most obtuse and inelegant programming I've ever heard of! Certainly it has to first calculate the entire route (no way around that) but then it could still quickly make all the moves within sensor range - since all obstacles are clearly obvious - before calculating again. The current method as described is very, very wasteful of computer resources and CPU cycles. NO wonder it's so dreadfully slow and the CPU stays maxed out!!!

But what happens when the obstruction is RIGHT outside of the given sensor radius? You could run for several sectors in a direction that takes you nowhere before you "notice" the enemy. Ick.

Sorry to burst any programming/coding bubbles but it does precisely that right now! Eye-wink

» Vous devez vous identifier ou créer un compte pour écrire des commentaires

So? {grin}

Soumis par Cosmic Marvel le Dim, 2006-12-10 01:54

Rilbur wrote:
Cosmic Marvel wrote:
Captain Kwok wrote:
The answer is simple. The ship has to recalculate its patch each hex it moves - so the longer the path the slower the movement. Calculating ship movement is the main reason why the AI turns are so long - not script execution etc.

Gee whiz, Kwok - that's got to be the most obtuse and inelegant programming I've ever heard of! Certainly it has to first calculate the entire route (no way around that) but then it could still quickly make all the moves within sensor range - since all obstacles are clearly obvious - before calculating again. The current method as described is very, very wasteful of computer resources and CPU cycles. NO wonder it's so dreadfully slow and the CPU stays maxed out!!!

But what happens when the obstruction is RIGHT outside of the given sensor radius? You could run for several sectors in a direction that takes you nowhere before you "notice" the enemy. Ick.

Sorry to burst any programming/coding bubbles you might have here but it does precisely that right now. Eye-wink one of the best examples is when it encounters a ship blocking it's path at a warp point. Your ship will run right up to it, bounce back, run into it again - over and over until it runs out of moves. And all this while an alternate route DOES exist! Very, very poor approach indeed!

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de Rilbur

I <3 subjects

Soumis par Rilbur le Dim, 2006-12-10 11:57

Cosmic Marvel wrote:
Rilbur wrote:
Cosmic Marvel wrote:
Captain Kwok wrote:
The answer is simple. The ship has to recalculate its patch each hex it moves - so the longer the path the slower the movement. Calculating ship movement is the main reason why the AI turns are so long - not script execution etc.

Gee whiz, Kwok - that's got to be the most obtuse and inelegant programming I've ever heard of! Certainly it has to first calculate the entire route (no way around that) but then it could still quickly make all the moves within sensor range - since all obstacles are clearly obvious - before calculating again. The current method as described is very, very wasteful of computer resources and CPU cycles. NO wonder it's so dreadfully slow and the CPU stays maxed out!!!

But what happens when the obstruction is RIGHT outside of the given sensor radius? You could run for several sectors in a direction that takes you nowhere before you "notice" the enemy. Ick.

Sorry to burst any programming/coding bubbles you might have here but it does precisely that right now. Eye-wink one of the best examples is when it encounters a ship blocking it's path at a warp point. Your ship will run right up to it, bounce back, run into it again - over and over until it runs out of moves. And all this while an alternate route DOES exist! Very, very poor approach indeed!

I haven't seen that one before... (probably because I tend to keep my own skys clear, and when entering enemy skys I just blow everything in my path) ok, that sucks.
_______________________
There are 10 types of people in the world:

Those that understand binary, and those that don't.

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de Psieye

Suggested improvement to Ship Movement algorithm

Soumis par Psieye le Dim, 2006-12-10 16:31

Pseudo-code time~ (that means I can write horrible syntax so long as it's understandable to humans). But first, one extra order that needs to be created for this to work: "WAIT ONE TURN"

This would be useful to human players too - I don't know how many times I've had to write down somewhere "now move those ships since the others will have caught up from last turn" then find those ships next turn. It should also make Next Ship better too, as sometimes we want a ship to stay where it is for just 1 turn, possibly in enemy territory (i.e. the Sentry order is useless for this job).

METHOD{EfficientMovement}

   DO While(Mv points left)
      IF (New Visible Hex) Then

         //Check if ONLY this new hex has an obstacle:
         IF (Non-trivial Obstacle Found):
            RaiseFlag(ObstacleFound at {Location})
            GiveOrder(WaitOneTurn)
         ELSE
            Move 1 hex
         End IF

      End IF
   End DO
End METHOD

EVENT{Move Order Given}

   Find shortest path to destination given known obstacles
   Move 1 hex
   //Everything's as before so far

   CALL Method{EfficinetMovement}

End EVENT

EVENT{New Turn}

   IF (ObstacleFound flag raised) Then
      IF (Human Player) Then
         Change Ship Status to "Tried to move to {Location}"
         //The player would then have the option to tell the ship
         //"Go find another path to same destination" in response to this status
      ELSE
         CALL Method(Assess Situation)
         //where the AI checks if that obstacle is still there,
         //and if so, decides whether to form a fleet to push through or find another path
      End IF
   End IF

   CALL Method{EfficientMovement}

End EVENT

By "Non-trivial Obstacle" I mean things you can just side-step around. Let's define it as "new path would take at least an extra half-turn's worth of movement compared to last one"

On a similar vein, the AI ought to have a command like "mark this sector as Restricted for X turns" or "mark this sector as Needing Military Action of strength X" (where it updates X whenever it can see what's on the other side of the waypoint).

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de ThiloiFederation

Ship movement: additional algorithm complications

Soumis par ThiloiFederation le Lun, 2006-12-11 19:55

Brad wrote:
If you put two or more ships in a sector and give them a simultaneous move to order, they don't suffer this slow-down problem. Also, when the single slow-down ship moves over another object (ship/planet/asteroids/storm/whatever) it moves at normal speed in that sector.

Strange but true.

I have actually noticed this since my first post. It makes me believe that there is something else such as the graphics engine contributing to the slow down. That is an area I'm totally inexperienced in as I develop business applications only. Does anyone have any thoughts on if and how the 3D engine could be affecting our movement problem? Also, in the latest IRC with Aaron, he mentioned that there has been some interest in having a 2D system display, perhaps this could help alleviate the problem?

Personally I don't really like the 3D system display. If there are a lot of colonies in the sytem, you have to rotate the map to see things hidden by all the flags. Then I have to move the map back to original position so that I don't get my warp points confused since I find it easier to remember the locations of the systems rather than their names.

Back to the core of the route finding issue, this one fact greatly complicates things: to maintain realism the computer must not be able to rule out a route because it sees something down the line even though the player doesn't. That is, it has to work with available sensor data only. This is not a problem when the entire route is covered by sensors, if that is the case, then reducing the number of times the algorithm runs is not a problem. It is when there are sectors along the way that are concealed by fog of war that we run into complications. What should the ship do if it runs into an enemy blockading a warp point along the way? Should it wait a turn or should it pick a new route? And if there is a new route available, when does it become disadvantageous to try the new route instead of simply waiting a turn or two for the enemy to move? These are all the things that make the problem more difficult than it seems at first glance.

Maybe if we can find out from Aaron what the actual entire ship movement algorithm is (in pseudocode of course) then we will all be able to brainstorm on it and see if we can come up with some real suggestions for making it more efficient?

Sorry for the long post, it sometimes takes a while to explain things sufficiently. Smiling

» Vous devez vous identifier ou créer un compte pour écrire des commentaires
Image de ThiloiFederation

Movement slowdown workaround found!

Soumis par ThiloiFederation le Lun, 2006-12-11 20:17

Thanks to Crystalmage for posting this: http://www.spaceempires5.com/en-US/node/1826

I have tested this work around successfully.

If you turn off ship movement lines in the system display then the slowdown disappears. If the graphics engine has to redraw the movement lines for every sector along the route every time the ship moves then this could definetly slow down the display.

This workaround is good news, but I find ship movement lines very very helpful so I think this must be fixed in the future.

» Vous devez vous identifier ou créer un compte pour écrire des commentaires

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Now on STEAM

Now on STEAM!Space Empires V via STEAMSpace Empires IV via STEAMSTEAM online by Valve Corporation

Contenu populaire

Aujourd'hui :

  • Babylon 5 Wars SEV Mod Update
  • Known SE5 v1.74 Bugs
  • Research By Percentage SUCKS
  • Space Empires V and VI: Expansions and the Future: Tell the Company What's on Your Wish List
  • Bad Bookkeeping

Depuis toujours :

  • Space Empires V and VI: Expansions and the Future: Tell the Company What's on Your Wish List
  • Space Empires V
  • Gritty Galaxy Fleet Clash
  • Damn Dirty Bugs/Annoyances
  • Space Empires V: General Thoughts, Observations, and Suggestions

Dernier accès :

  • Noob Woes
  • Coming soon: Starbase Defense
  • Efficiency in Simultaneous vs. Single Player play
  • Please add a compressed facilities view option in colonies lists and planet details
  • Research By Percentage SUCKS
(c) Strategy First, Inc. All rights reserved.