Ok, great that you’ve got the basics working. If you want to spawn the grid while designing what you want to use is the blueprint’s construction script. To use instanced static meshes you will need to add an instanced static mesh component to your blueprint, assign a mesh to it and then using “add instance” to spawn instances of this mesh. I have made a YouTube tutorial video that goes through every blueprint in my toolkit in detail. In theory you could recreate my entire toolkit by following this tutorial. Here is a link to the part in question: http://www.youtube.com/watch?v=cK1EFnmSyE4&t=4m27s
Edit: Saw your second edit. That maze tutorial looks good, though it is of course a bit overkill for what you need. I would also recommend using hierarchical instanced meshes instead of static meshes for even better performance when not viewing all tiles at once. They are used the same way as instanced static meshes. Also, consider disabling “cast shadows” on your grid meshes as well as not having collision on each individual tile, which will further improve performance significantly.
So do I It represents nearly ten months of development since the last proper feature update (1.4 back in april last year) so a lot of stuff has been added and changed. I’ll start making fresh videos as soon as it hits the marketplace.
It should hopefully be live fairly soon. Epic have had my update for a while so it should be in their update queue. As mentioned earlier I can also send the update directly to anyone if they send me their order info (after I verify it with Epic).
Is it possible to use an action point system with your toolkit? For example:
Maximum: 10 AP
Movement: 1 AP per tile
Interaction with the environment (open door, push button, …): 2 AP
Item use (potion, medkit, …): 3 AP
Attack (cast spell, fire weapon, …): 4 AP
An action point system should not be too hard to implement. Simply subtract the cost from an Action Points variable on a unit each time an action is performed and only call End Unit Turn if Action Points reaches zero or the player chooses to end the turn early. Insert branches at relevant points in the ATBTT_PlayerController event graph to make sure the player cannot initiate actions he does not have enough action points to do.
The update is live! The update that was previously on the marketplace was 1.4 so this update contains all the stuff from both updates. Here is a reminder of waht has been added (all updates are listed in the second post of this thread):
v1.6
Support for multi-level grids. Multi-level grids are generated automatically from underlying meshes.
Added walls and platforms that turn semi-transparent when zoomed in or hovered over. Especially useful for multi-level grids. A simple example map is included demonstrating their use.
Support for multiple factions. An arbitrary number of factions can be added. Units can be setup individually to be allies or enemies of the various factions.
Any unit can be designated as AI or player controlled, regardless of faction. Allows for hot seat multiplayer among other things.
Added option for using custom pathfinding specified for each unit. Included examples such as units that can pass through friendly units, units that ignore difficult terrain and units that cannot move diagonally.
The path spline now uses a linear instead of a curved spline, which usually looks a lot better. Movement is still guided my a curved spline, as this makes for the most fluid movement.
The default grid mesh can now be set as a hierarchical instanced static mesh, further increasing performance on large maps compared to regular instances static meshes.
Various smaller changes including blueprint organization and commenting improvements.
v1.5
Changed the edge array to be a nested array of structs, with each struct representing a single edge. This change required major changes to all parts of the toolkit that utilize edges, but makes pathfinding even quicker and opens for grids with customized connections between tiles.
Added touch controls and an option for rotation 90 degrees at a time (currently default, but can be unchecked in BP_GridCamera)
AI has been improved significantly. AI now selects from all possible tiles to attack its target from, choosing depending on a personality enum. The AI will now move as close as possible to units it cannot reach if the path is blocked by a friendly unit.
Player units can be set to display all possible tiles that can be attacked from all tiles in move range, similar to Fire Emblem and many other TBS games.
Tiles in Sight Range and Move Range can be displayed as a frame.
Improved commenting and organization across the board. Variables and functions are now grouped in categories.
Included a variety of utility functions in BP_GridManager such as spawning units and tiles during gameplay among other things.
Split up the Event Graph of Unit_Parent into several sub-graphs for easier modification. Unit_Parent’s event tick now only fires when it is needed for movement, improving performance.
Added several “slow loops” which spread loops over multiple ticks. These can be used to improve performance when necessary. These are used by default when displaying all possible visible tiles for player units, since this is a demanding operation, and when an AI unit is activated.
Added an example game called Hydra’s Lair that demonstrates how the toolkit can be tweaked to create a 2D dungeon crawler. This includes many experimental features such as fog of war, weapons and armor.
The example game contains sprites from Dungeon Crawl Stone Soup, which are licenced under Creative Commons Zero and can be found here: Dungeon Crawl 32x32 tiles | OpenGameArt.org
Glad to hear it! It’s downloading in the background as I type, I’ve been a big fan of the toolkit for a while now and it’s just getting better. Thanks again!
I hope it lives up to your expectations, Micah! I have put a ton of work into this update and a lot of stuff has been changed. Everything should hopefully be cleaner, faster and more flexible than ever before. Because of the sheer amount of changes there are bound to be some bugs that my testing has not picked up, however, so I encourage anyone using the toolkit to report anything that doesn’t seem to work as it should or is not well enough commented. I hope the transition will be painless for old users and hope you will agree with me that all the changes are worthwhile.
Thanks for the update. I will look into it when I get the time. Initially I will just do a digital port of the board game I talked about, but we’ll see what happens after that.
Hi, I’ve been trying to work on a system that would allow some amount of randomness when attacking an enemy. Like xcom’s random roll for damage/hit success, I’d like a weighted random number generator that will determine whether or not an attack is successful, and if possible how much damage was done to the enemy. I’ve gone astray somewhere along the line, and it would be greatly appreciated if someone could show me the way. I’m including a screen shot of my mess of a blueprint to show where I’ve made the changes and hopefully figure out what I’m doing wrong. Thanks!
The condition in your branch is set to always be false so your attack will always miss (or to be more specific it will end without printing “missed” 50% of the time in the CompareInt or reach the always false branch the other 50%). If what you want is a 50/50 chance of hitting you could remove the branch, connect the “>” on your CompareInt to Set Current Health and the “==” to the Print String. From how I understand your blueprint this should work.
Edit: After I got home I threw together another way of doing this. The nodes below are inserted into the Attack Unit part of Unit_Parent’s event graph since I feel it makes more sense to calculate miss chance as part of the attack instead of when receiving damage. Here I have added two new public floats to Unit_Parent called Accuracy and Dodge. To hit chance is calculated by subtracting the dodge of the target from the accuracy of the attacker. An attacker with an accuracy of 0.9 attacking a target with a dodge of 0.3 would have 0.9 - 0.3 = 60% change to hit. Hope you find this solution satisfactory. If not I think it is a good starting point for many other ways of calculating hit chance.
hello ,
i have bought your great product a few days ago, i am wondering, how difficult it will be, to implement a game setting , where you are able to control your player characters for example like in a jagged alliance style.To be me more specific, you control your player character(s) over the tile map without movement restrictions until a battle begin.
It represents nearly ten months of development since the last proper feature update (1.4 back in april last year) so a lot of stuff has been added and changed. I’ll start making fresh videos as soon as it hits the marketplace.
