Download

Turn Based Strategy Grids [Released] [Many images]

I’m proud to announce that the Turn Based Strategy Grids plugin that I’ve been working on is just now released on the Marketplace! I would like to thank everyone who has made this possible by giving feedback on the work-in-progress thread and voting for it on Trello, thanks everyone!

In this post I will showcase the features that are in right now. I will continue to work on this plugin casually and I’m eager to get feedback and suggestions from people using it in their projects, or just based off the listed features. :slight_smile: See information about incoming updates in the next post.

A brief history
I’ve always liked the Fire Emblem and Advance Wars series and for a long while my goal has been, and still is, to develop and release a game in this vein. I’ve started working on a personal TBS project over a year ago in various frameworks, implementing turn based gameplay, player input handling, bot AI, combat formulas, integrating LUA scripting, a dialogue system… aaand starting to create my own editor which I’ve reconsidered by now (it was fun trying). Here is some old footage of my past TBS project and its iterations:
TBS Game - JMonkeyEngine
TBS Game - Custom Editor
TBS Game - SFML

Five months back, after completing my CS studies I put the above project on hold to explore the awesomeness that is UE4. Seeing the interest for a TBS template on the UE4 Trello roadmap sparked me to take the things I learned and see if I can apply them in UE4 using blueprints. This would also help me decide whether or not to move my prior TBS project over to Unreal. That resulted in the creation of this plugin! It turned out quite well, so without further ado let me introduce it.

Turn Based Strategy Grids
(From the marketplace description) This blueprint system provides developers of turn based strategy games with logic for representing and querying 2D grid worlds. Its main function is the computation of action grids: queriable grids that efficiently store all pathing and attack options available to a unit during its current turn. Action grids are intended to be used for efficiently retrieving shortest paths to any reachable tile, for displaying the movement and attack options that are available to the player’s selected unit, and for providing AI units with a search function to retrieve the set or a subset of valid actions, which can then be processed by your high level AI controller. Action grids only need to be computed once per turn, after that all pathing and attack information can be retrieved without further computation.

The plugin includes features such as editing of level layouts in the editor and at run-time, multiple terrain types with different interaction per unit and optional line of sight checking when determining which tiles are within a unit’s attack range. Action grids can be merged to represent the influence radius of multiple units. An example map and player controller is included that demonstrates usage of the plugin in blueprints and handling of player input. All blueprint is commented and a detailed user guide is coming soon.

storeActionGrids_screenshot1.png

Integration in your project
The focus of this plugin is to provide the logic (the algorithms) for path and attack planning. It is designed to be easy to integrate into your existing UE4 project by not limiting you in your use of blueprints and your visualization of the map and units. Any blueprint class can be made compatible with this plugin by implementing the blueprint interface IGridActor that contains two pairs of straightforward Get- and Set-functions that you must implement.

Without modifying anything you can choose to use only the grid logic in this blueprint. The visualization shown in the screenshots and in the example map is optional and stored in separate blueprints that are used only for display. The visualization blueprints are gameplay ready, just not very special. :wink: Generally useful functions such as world<->grid coordinate conversion and tile picking are contained in blueprint function libraries so that you can call them throughout your project. When using coordinate conversion functions you can specify the grid’s origin and tile spacing in world space and as well as the height.

Note that this plugin provides the pathing and attack options according to mechanics of square tile TBS games like Fire Emblem and Advance Wars, but implementing the attacks is left to you.

Features
Multiple terrain types - Terrain interaction can be customized per unit instance in terms of accessibility, movement cost and targetability. The plugin’s algorithms call a function taking a (terrain type, grid actor reference) pair to retrieve these parameters. This function can be user customized to define a unit’s capabilities and even allows units to change their terrain interaction in-game, which can be used for example when activating skills.

feature_terrain.png

Unit pass-through - You can specify which units are allowed to move through which others, for example to allow team members to move through each other. The relation does not have to be symmetrical, so you can have rogue characters that can move through enemies but not vice versa.

feature_passthrough.png

Path exploration - Computes and efficiently stores all paths that a unit can take during its turn using Dijkstra’s algorithm. Any number of paths can be retrieved without further computation.

1bb930c3870f37da49439b51789bf61bda6cb905.png

2625bc889d93bbdcc2b47fadd5915825960df870.png

feature_dijkstra.png
^ A visualization of Dijkstra’s intermediate result, not shown in actual example map

Attack range calculation - Determine all tiles within a unit’s attack range, before or after moving. Attack range is measured in Manhattan distance (horizontal plus vertical distance).

3a73d4476272387272d46f68619026c7eac43586.png
^ Before moving, attack range 2-2

66c808ac74877df254ed46e8a855e4156317addb.png
^ After moving, attack range 2-2

Optional line of sight check - You can enable a LOS check to have vision blocking terrain. For each terrain type, you can then specify whether vision can pass through the tile area, and whether it can pass through the corner of the tile. The LOS check affects which tiles that are in attack range can actually be attacked, not to be confused with fog of war.

17fc3e9286ea68b6a4076189e5df15a41de016cf.png
^ Attack range 3-5 with LOS check

Single tile data retrieval - Intended for handling player input and scripted AI. Retrievable data: whether you can reach that tile and if so, the path to that tile. The current occupant if any. Whether it is within your attack range or your move and attack range. A list of enemy units that are within the attack range of that tile if you stood there.

1059e9126f19add6fc00325f01122d402eea4a7d.png

Multi tile search - Intended to assist high level AI. You can search action grids for tiles that satisfy a combination of conditions, including whether it is reachable, within attack range, occupied and by whom (friend or foe) and whether that tile has enemies within your attack range if you stood there. The list of tiles that is returned by the search function can then be processed by your high level AI. For tiles that have enemies within your attack range, you can retrieve the list of attackable enemies using single tile data retrieval.

b6912ce65e1217b06ba7f35af467d27ff547c69d.png

Action grid merging - You can merge the action grids of multiple units to obtain a grid that represents their combined movement and attack range. This is useful for allowing the player to select multiple enemy units and preview their attack range. It can be used by AI as well to access the same information.

b84f153575a273a62d28c6bdf066cb16e1b5751e.png

User guide
User guide is now available here: http://www.zkshao.com/downloads/TBStrategyGrids_UserGuide.pdf

I will use this post for information about incoming and released updates.

Released updates:
None yet.

Incoming changes:
Target searching for allies/neutrals
Adding the ability to retrieve friendly and neutral targets that are within attack range from a tile. Note that retrieving a list of targetable enemies is already possible. Adding search options to find tiles that contain friendly and neutral targets within attack range.
targetEnemies..png targetAllies.png
Targeting enemies (left) and targeting allies (right)

Hexagonal tile grids
Will fully support all features that are available to square tile grids.
hex_grids.png

Sparse grids
Grid composition using smaller grids to save memory when creating irregular shaped levels.
hex_sparse.png

**Feature requests / Being considered: **
Multi-tile unit
Units that occupy more than one tile.

Looking pretty neat, NisshokuZK! In a few weeks UE4 users are going from having no solutions for making turn based strategy games to being spoiled for choice :slight_smile:

Yes I think this is a good time for creating TBS games. ^^ I’m itching to restart my own project as well.

Looking forward to this :slight_smile:

So questions -
Can this do multi-level grids?

How large can these grids be before performance drops?

Is Asynchronous multiplayer planned? (Multiple Players Move, attack, etc. at once and the server decides the outcome based on numbers.)

Can this handle air/space units?

Last but not least how much will this cost?

Just curious,
Headclot

Looks great! :slight_smile:

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?

Does it support or do you plan to add support for hex grids?

Ditto. I would like to use hex grids in a space game.

As of this moment I’m not planning to add support for hex grids, sorry. :slight_smile: I may succumb under popular demand, but for the time being I want to focus on square tiles. My goal for now is to perfect it in terms of providing easy access to any positional info that high level AI would want. I bet you’ve already seen Monokkel’s plugin announcement, who did a great job on hex grids. If not, you should go check it out.

Edit: I updated the first post to include a video of the plugin in action.

Looks really good! Can’t wait for it to be on the marketplace.

Thanks for showing interest! :smiley:

Hex grids for the win … but on a side note … this looks very cool as well. Will definitely keep my eye on this. 8-}

This looks really great. I hope to hear more about it. Well done so far!

Another one for hexes… I’ll keep it in mind. Thanks for your support. :slight_smile:

Thank you!

It just has appeared on the Marketplace! Please note that the video on the Marketplace page is outdated, I’m requesting Epic to use the new video (the on in the opening post). I’m excited. :smiley:

Good job NisshokuZK … roll on home time so I can buy it. 8-}

Super, thanks! Let me know if you have any questions on usage.

I will post information about incoming changes in the second post. I already have a change incoming soon: the ability to search for tiles that has friendly or neutral units within attack range. So this enables your AI to find tiles from which he can use his range restricted healing/support skills on allies. :slight_smile:

Hey everyone, after listening to your feature requests here and on Youtube I have decided to add support for hex tiles. After studying the differences between square grids and hex grids, I’m confident that I can fit hex support neatly into the existing framework. The hex grids will be just as fully supported as the square tiles, so that means: path exploration, attack range determination, single tile queries, multi tile queries, merging, everything. :slight_smile:

I will push an update with hex support soon where all features are in, but one feature will come with another update later which is the support for line of sight checking when determining attackable tiles. The reason for this is that line of sight checking with hex tiles is vastly different from square tiles.