Thanks Zeus!
Hi HeadCot, thanks for showing interest!
I’m not sure what you mean by this, are you talking about multiple floors above each other, or height differences? Or multiple grid instances within the same map? For the path exploration it does not support take into account any height values, but if you have a specific request I may consider adding it. You can add custom data to tiles and make getters/setters to retrieve them, though, and update the search function to take that data into account.
You can place multiple grid instances on the same map and manage each separately. You won’t run into issues but they will not interact. I am planning to add a room compositing feature, so that you can create large levels by defining smaller rectangular rooms and hallways. I made that before and you can see this in action in the third video of my past project. If this is something you would like let me know and I’ll push it up in the priority list.
Path exploration only searches locally around the unit, so for the computation of action grids the performance is independent of the global grid size. It does depend on the unit’s maximum movement cost, its min-max attack range and whether you want a line of sight check with the attack range. The line of sight check has the biggest impact, but I intended the LOS check to be for close quarters where units don’t have wide attack ranges like 1-10. Note that a LONG attack range like 8-10 would be fine. To give you a general number to work with, a combined [movement + attack] range of 10 is easily computed. If you tell me the move and attack ranges that you’re going to work with I can give some more insight on that.
Edit: I added a video on top that demonstrates some action grid sizes.
The other performance factor is rendering, this depends on your visualization. Using the included blueprints for rendering you will not run into framerate issues, but will experience a short hiccup (0.2 s) the instant when spawning the visualization of a large (21x21) filled action grid (i.e. many blue and red tiles in total).
Firstly let me clarify that while the plugin computes attack range, it does not do any combat calculations. Combat-wise, its role is to display to players/AI what tiles and enemies are targetable, or whether a specific tile or enemy is targetable. What happens when attacking, or even when trying to move, is down to you.
Now let me first discuss multiplayer support in general. The plugin does not have replicated features but all computations are deterministic, so any sequence of global grid manipulations have the same result given the same initial state. Action grids can be computed client-side and show up the same, given that both players are viewing the same unit and that unit’s movement/attack values are the same on both clients. So the plugin does not exclude multiplayer, but you yourself would be responsible for:
- Movement-wise: accepting player move commands (with the help of action grids), validating the move commands on the server (with the help of action grids) and then telling clients to update unit positions including showing an animation
- Combat-wise: accepting player attack commands where action grids will tell you which tiles and units are targetable, but you will have to define what the attack is. On the server, validate whether the targeted tile or unit is indeed targetable and compute the result of the attack. Then again telling the clients the result.
- Support for drop-in gameplay: so when a player joins mid-match, tell him the current state of the global grid (what units are where, any dynamic terrain changes, etc). For unit placement, as long as all your actors are replicated, you can replicate their (X, Y) grid position and use that on the connecting client to register them on the client’s version of the global grid. After that, business continues like described above.
As for asynchronous multiplayer, that is a very interesting idea. Are you thinking about games like Frozen Synapse? Well, like I mentioned before this plugin provides the commands available to the player. The results of those commands are up to you. Both players could tell the server, “I want to take this path” and the server could determine that they bump into each other and then tell both clients at what tile they ended up. The clients then update their version of the global grid.
In its current state you can make air units that can cross any terrain without movement penalty. It does not support air units hanging above other units on the same tile.
It will cost $55.
Does that answer your questions?