For support on either version please use my support forum at http://forum.plyoung.com/c/mapnav since I do not visit this forum often and the email notifications do no seem to be reliable and I often miss posts here.
Yes, there is a sample of how to have one unit attack another. I totally forgot to show it in a vid, but touched on the attack markers in video 2. It is very basic attacking though and units do not even take damage or get destroyed. I feel it is something that will have to be changed depending on how your game works so I’ve given just enough to get started and see how you can create your own units from the base unit type.
It looks very nice and polished, but I have one thing that I consider a major issue: You use one quad per node, which ends up being 4 vertices. If I would like to create a really big, big grid - this would not scale at all. If I wanted a 512x512 grid, I would end up with using 1048576 vertices just for the grid. Which would slow a lot of machines down to a crawl.
Edit: just watched the 2.1 update video with the variable height, Looks very nice! But the way the “move” marker clips into the terrain looks very cheap/bad and I would expect it to flow with the terrain.
Overall, it looks very good - but some of the display issues worry me, which is why I’m not buying it yet!
I don’t think that would be too hard to implement, for moves at least. You could use the current unit class as a template and then replace the movement code with something that calculates the path, set the destination node as occupied and then save off the path info till it can be used to move. If Units, moving through each other, is not a problem then it could be done; and even if it would be a problem I there would still be ways around it, but this is not a feature outa the box where you just set a boo lto true and you have this feature, it will involve some code from your part. The current turn sample is just that, a sample, and not seen as the core of this package, which is the mapping, grid layouts and some base classes for things like units to calculate paths for example.
Battlemass is a game I’ve developed and was the inspiration for this package.
I’ve not yet tested with Unity Terain, I’ll look into that.
Those markers are not all on at the same time. The idea is to use them to indicate where units may move and you do not even have to use them. It is just an easy way of showing them. That said, this package is best for situations where you would have a grid of say 50x50 or smaller, like in Battlemass, or one of those games where you switch into a turn based strategy map for combat, as examples. It can become quite hard to use in the editor if the grid is something huge, like 100x100+, and you do not have a very powerfull machine.
Concerning the terrain, yup, it does not look cool in that sample and I am gonna add more samples of how one could use other methods like projectors rather than the flat markers.
Ok, I think I will have to re-consider my thoughts on purchasing this then, It looks really solid, but I’m looking at 2048x2048 terrains in my current game. I’ve been working on basically the same thing you have, but with a larger scale in mind and have managed to come up with a way of visualizing basically infinitely large grids, with support for things like unit sizes, dynamic updates of the grid, etc. currently only does colored squares, but working on hexagonal visualization and using symbols instead of colors for squares, example:
The grid in the picture is 1024x1024. Anyway, great work and I will not try to hijack your thread, keep up the great work!
Edit: Also, I realize the visualization for the “movement” marker is very fast to render, but what I was more concerned with was the actual visualization of the grid inside the editor, when you can see the whole grid and you’re both using the hexagons + cubes, which will crush any standard machine if you try to display a 1024x1024 grid, that requires a quad for the hexagon/square and then a cube to display the other data, that is 12 vertices per node, which at a 1k grid ends up being ~12 million vertices.
@Johny
I did a quick Unity Terrain test and the Height Setup tool works with it and the units bascially move in the same manner as they do in that 1st sample shown in the 2.1 video. The default grid is small compared to the size of the default terrain though, if you do not change the tile size and spacing from 1. Let me put it this way, a 20x20 grid needs tiles of size 100 (spaced 100 from each other) to almost fill the default terrain, but I guess it all depends on what you need it for.
This update includes a sample of how the package can be used with a dungeon crawler and a new way of telling the path calculator that units ned to spend more movement points when trying to enter certain tiles.
Would it be possible to add an option to block access to a tile from certain directions? Or are the connections between tiles all fixed? I don’t want to jump my units up on a very high cliff (or back down for that matter) but access should be possible if you take the long way around.
Update 2.3 includes the ability to switch the links between nodes to on or off. Usefull for doors, or preventing movement from certain tiles to their neighbouring tiles, thanks for the idea, c-Row