0
\$\begingroup\$

My game is a top-down 2d RTS coded in C# using SFML's libraries. I want that during unit selection, a unit will display it's movement path on the map. Currently, after the path is computed as a list of directions ({left, up,down, down, down, left}, as an example), it's sent to the graphical component to create it's UI equivalent, and here I'm having some problems. current, these I've checked three ways to do it:

  1. compute the size of the image (in the example above it'll be a 3*2 rectangle) and create an invisible rectangle, and then go over the directions list and mark each spot with a visible point, so as to get a continous line. This system is slightly problematic because of the amount of large images that I need to save, but mostly because I have a lot of fine detail onscreen, and a continous line obstructs the view.

  2. again, compute the size of the image, but now create several (let's say 4) invisible images of that size, and then instead of a single continous line I'll switch between the four images, in each will appear only a fourth of the spots, in a way which creates a path animation. This is nicer on the eye, but here the memory demands, and the amount of time needed to compute each such image-loop is significant.

  3. Just create a list of single markers, each on a different spot on the path. This is very quick & easy on memory, but too sparse.

Is there a simple or resource-light system to create path-animations?

Improve this question
\$\endgroup\$

1 Answer 1

Reset to default
2
\$\begingroup\$

You could do something similar to #3, but create a very small marker for each tile in the path in order. Then you could display the markers as arrows pointing to the next location in the path. That way, you'd only have to have one (tiny) image, which could be rotated and blitted to multiple locations, while the path is still very clear.

Example:

. . . . x .
# # # # ^ .
. . > > ^ . 
. . ^ # # #
. . ^ < s . 
. . . . . .

In your example the unit turns on a dime and partially retraces it's steps. I wouldn't expect that to be ordinary behavior but if it occurred you could just blit multiple arrows to the same tile.

I'd make the arrows very small and thin and a bright color so they stand out without obscuring your detail. Also, you should only display the path for the selected units, in my opinion...tons of paths crisscrossing your terrain could be confusing, besides slowing the game down.

Good luck with your game!

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Just I'll be certain I understood your answer - are you proposing to have an array, the size of the grid, with many different sprites, and just display them based on a looping algorithm? that sounds like it demands a lot of memory, and repeating calculations instead of onetime precomputation. \$\endgroup\$
    – nihohit
    May 14, 2012 at 9:36
  • \$\begingroup\$ Not quite. I'd use a single-linked list, with each item as a tuple (or whatever you have in C#). The first two items of the tuple would be the x,y location of the square, and the third would be the angle of the marker. You wouldn't have to loop over every square, just the squares of the route in order. EDIT: I'm not familiar with SFML--do you mean the actual blitting code is the slow part? \$\endgroup\$
    – Wackidev
    May 14, 2012 at 13:23
  • \$\begingroup\$ @nihohit - You already have the path saved somewhere for the thing to follow, so just use that to draw it. As for figuring out the next direction, you could compare the x/y of the next position in the list (i.e. if next.X > this.X then it's to the right). Also, don't assume something is slow without trying it. Test it, profile it, and, if it needs it, optimize it. \$\endgroup\$
    – Richard Marskell - Drackir
    Jun 13, 2012 at 5:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .