• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[vJASS] Turn-Based Game System

Status
Not open for further replies.
Level 16
Joined
Mar 3, 2006
Messages
1,564
[rainbow]Note: this is no promotion or a propaganda[/rainbow]

You may or may not know this game, it is called HoMM4 and it is a turn based game.

Well, lets describe one of the most important system, which is the adventure map system, it works like that, the character is a representation for an army; this army have a number of moves.

MOVING

When you click on a spot on the map the green arrows that you see in the screen appears, lets say 10 arrows appeared then you will reduce 10 from the movements left to your army, the problem is how could I make a grid-walking system like that and how could I show those arrows on the map.

I have more to say but first lets see if the system is possible to be made.
 

Attachments

  • heroes4.png
    heroes4.png
    665.7 KB · Views: 126
Level 29
Joined
Oct 24, 2012
Messages
6,543
u can always measure distance traveled, actions done and stuff like that that u want a full turn to take up. Then u pause the players units and unpause the other players units.

to make pausing more efficient whenever a player creates a unit store that unit into a group for the player. that way pausing will be easier.

i think ull have to make ur own model for the green arrows. Then to determine how many should appear just calculate the distance between the unit and the point and divide it into sections and place a model there..
It would be easier to make an ability used for movement that way the player can see how much it will decrease there movement by. You will need another ability to tell the unit to move and one ability ( already stated) to be a pointer on were the unit should move.
Best way i can think of measuring distance is set a max distance and use the ability to subtract from this number. Then when it hits 0 u can place red arrows instead. and when that unit hits the 0 mark u stop it from moving. i think u should move the unit in small increments that way u can accurately measure the distance traveled and stop the unit when the units turn is over.
 
Level 16
Joined
Mar 3, 2006
Messages
1,564
As a general idea that is good but here comes another problem, its the type of terrain; as there are terrains that cost 1.25 and 1.5 move for the army to move 1 tile, so a terrain with 1.5move/tile will cost 3 moves to move 2 tiles. If the terrain is of one type that could be easy to be made but mixed terrain have a strange way of calculating the movement. In the game when you click on a tile the game engine will always try to get the easiest route that will move you further for example you have a grass with 1.25 move/tile and a road with 1 move/tile if you clicked on a location on the grass and you are standing near the road the game will set most of the route on the road to cost you 1 move instead of 1.25 you will find that the route is not a straight line although it may be the shortest distance but that will cost you more move to go so the game engine automatically detects the route of the least movement cost.
 
Level 29
Joined
Oct 24, 2012
Messages
6,543
that is a bit harder. only thing i can think of doing besides moving manually lol, is that when u select a point with the ability make an array to store the points of were ur units moves to. in a loop go towards the point selected but detect the terrain in the area. so instead of making the next movement spot directly in line with the point u select it detects the area around that point to see which way is shorter(because of the movement change). Basically if each point moves 128 then detect shortest path in a 180 range of the units facing 90 in either direction. then store that value in array. to make it even better detect it by using another trigger and store the amount of movement it will take to travel to that point and then store that as path 1 then do same thing for path 2 and check which is lower. this will be hard to do especially in keeping it from hitting the op-limit.

I believe there are some pathing checkers on this site. U might be able to modify them to do what u want.

Hope that wasnt confusing lol
 
Level 16
Joined
Mar 3, 2006
Messages
1,564
It will be complicated to make but not impossible, if only Blizzard had the trackable natives fully functional that would have helped me like hell. As the next challenge will be very difficult to made if not impossible. Its the cursor and how it change according to the environment.

If you have hostile creature it has a bunch of guarding squares around it if your army enter those square the creature will engage in combat, so far so good but there are sometimes events where the creature blocks a path, take a look at the 2 attachments and compare the two cursors, the cursor that is hand means that any click will have no response and will never move you to the spot as the green arrows will never appear.
 

Attachments

  • heroes4_domain.png
    heroes4_domain.png
    863.2 KB · Views: 110
  • heroes4_horse.png
    heroes4_horse.png
    870.5 KB · Views: 119
Level 29
Joined
Oct 24, 2012
Messages
6,543
for this if u detect the movement section by section all u have to do is use an ITE to check if there is a unit or other type of pathing blocker there. if there is then u stop the movement from there on. if u use an array to store the points u can use another array which tells what arrow to display. this way if u hit a path blocker then u go back a certain amount of arrays and change there model file path.

I think thats what ur looking for ?
 
Level 20
Joined
Jul 14, 2011
Messages
3,213
You could just order the unit to move to the target point as long as it's in the unit vision sigth, or the point is not on black mask or fogged terrain. Keep track of travel distance (Bribe's has a system to detect wheter a unit is moving). Wc3 can handle the movement direction.

You can check the position of the unit every time you check distance (0,03) or every distance you travel (i'm not sure if you move 50 by 50, or 100 by 100, etc.) and apply a penalty to the total distance to travel if the terrain is rought or dirt.
 
Level 29
Joined
Oct 24, 2012
Messages
6,543
You could just order the unit to move to the target point as long as it's in the unit vision sigth, or the point is not on black mask or fogged terrain. Keep track of travel distance (Bribe's has a system to detect wheter a unit is moving). Wc3 can handle the movement direction.

You can check the position of the unit every time you check distance (0,03) or every distance you travel (i'm not sure if you move 50 by 50, or 100 by 100, etc.) and apply a penalty to the total distance to travel by a % of the total distance to travel.

only problem was he wanted different terrain to affect movement in different ways and allow for a unit blocker type of thing.
 
Level 20
Joined
Jul 14, 2011
Messages
3,213
He can make the map with the blocking thing. Wc3 handles moving. He can apply movement penalty based on terrain of position of unit at the distance check (either by time or distance)
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
You must basicly create your own pathing algorythm for that.

There are natives that allow getting the terrain tile type.

So what you need to do is write an algorythm that detects all tile types in an area around the target point and the ordered unit, then approach the problem from a maths perspective.
Consider the linear movement. If it's a complete path of the 100% movement type (roads), that's it. If there's 75% or 50% movement tiles in it, you need to check the tiles around the tiles in the linear way.
You should google pathing algorythms before you start with that. There are some pretty effective ways to do that, as the deviation from the linear path is very limited depending on the type of pathing on the linear way.
The lower the total "sum" of movement points on the linear way, the less adjacent tiles actually need to be checked, as the possible "longer" routes need to be faster to be considered.


Basicly, the algorythm could look like this:

You consider the direct linear movement tiles, sum all movement factors together, to keep as a "reference":
example: 1+1+1.5+1.25+1.25+1 = 7

Then, you consider your starting point.
At the first tile, you have 4 possible choices.
Each choice comes with 3 more possible choices (the fourth choice is going back, which would make no sense).
Each of those comes with another 3 more possible choices.

So the number of possible paths equals down to:
4*3^(n-1) with n being the maximum number of tiles a unit can possibly move.

If a unit can move up to 10 tiles of "road" pathing, then this equals to: 78732 possible paths (but only a very small fraction of those paths actually reach the target tile!).

As you can see, this would be way too much to calculate in a loop. What we can do to reduce the number of possible paths by comparing it to the movement time of the current "shortest" path.
As we have no "shortest" path saved yet, we simply consider the linear movement path as the shortest, so that makes an "action point cost" of 7.

So what do we do now?
Basicly, we use a recursive function.

This recursive function has a starting tile passed to and a target tile passed to. The target tile is passed over every time and does not change. The starting tile changes with every recursion.
Whenever the function is called, we create 3 "moved" counters. This is because the paths "branch out". With every tile moved, the number of possible paths multiplies by 3.
We then call this function again for each of the 3 adjacent tiles (excluding the backwards movement). By this, we also increment the counter of the considered path by the movement value of this tile.
If we exceed the current "shortest" path movement value, we do not need another recursion on this tile again, as it will never be shorter.
If one of the adjacent tiles is the target tile, we can also stop recursion of the "parent" tile and consider the new value of the counter as the new "shortest" value (this path will always be the shortest, as all recursion steps stop as soon as the current "shortest" value is reached).

This way, the algorythm will clean all recursions that exceed the current "shortest" value one after one, until there is only the shortest possible path left.


This process is very CPU heavy, though and might reach the operation limit. Make sure each recursion runs on a seperate thread for longer paths!
 
Last edited:
Level 16
Joined
Mar 3, 2006
Messages
1,564
@ Spartipilo

Here is what I mean by least movement path:


126172-albums6067-picture69138.png
In this image the route was straight because when the movement was calculated the engine found that moving to the road and returning back to the snow was going to cost equal or more movements so the route was calculated straight .


126172-albums6067-picture69139.png
But in this case it will cost less movements to go to the road then return to the snow, since snow costs 1.75 move/tile
 
Status
Not open for further replies.
Top