Hi , I’v got a question. How do i change the actor(pawn) movement speed?
Hi. With the current setup speed is dependent of the move speed of the pawns. That way, a pawn with a max move speed of 6 moves twice as fast across the grid as one with a max move speed of 3. I thought that made sense, and would eliminate the sorts of situations you see in some games with enemies with slow walk speeds but high movement/turn slowly snailing their way across huge distances. I know a lot of people might want to do it differently, so I’ll want to implement different solutions in the future. At the moment you can adjust the relative speed of all pawns on the map by increasing the public variables Pawn Movement Speed Scale, Pawn Movement Speed Acceleration and Pawn Max Speed in the Grid Manager blueprint. If you want to modify the way speed is handlet, take a look at the “Follow Path” part of the main event graph in the Grid Manager blueprint.
I’m currently working my way through the videos and I’ve built up quite a list of questions. I figured it might be easier to put them all here rather than randomly through the YouTube playlist.
after going through my questions I’m sure allot of them will be a simple yes I guess I would like a quick explanation for how this toolkit could do them.
1: The visibility range is cool though I’ve been wondering. can you have a building or base with a roof that you can’t see enemy pawns inside unless you have a pawn in the building? also to be able to walk on top of the roof?.. could this be done with invisable tiles/rooms?
2: Another thing I was wondering about is say you have an open map with trees and rocks laying around can you delete sections of a grid and put a river or crevice in the map than place a bridge over the gap? if it’s a crevice it would be cool to place a ramp on either side going down into it than up to the normal level.
2B: is it possible to have sections of water/mud that units can walk or swim through?
3: Can you hide in a block say a wooden crate and have that crate take damage?
4: Can you have a half block high wall and have it absorb hits and take damage?
4B: If 2 pawns are standing behind each other can a 3rd pawn shoot a spear or lazier beam through both them and have it so the pawn behind take less damage?
5: Can you have pawns use equipment to change their stats and abilities?
5B: would it be possible to have say vehicles where one or more pawns can ride in and have the vechial take damage and only kill the pawn(s) if the vehicle blows up?
6: With an empty pawn will I be able to set up options so the player can change what faction it’s apart of? (story reasons)
7: When you were talking about looking around blocks it got me thinking. what if you had a window or a clear block of ice is there a way to look through it but have it be a solid object?
7B: If I wanted to place say a rock between squares can I change the way pawns see and behave when it comes to moving and attacking around those objects?
7C: If I have oddly shaped blocks like a pillar or paramid can I set it up so the movement and visibality changes around that object?
8: can you controll what direction a pawn is facing and have features set so it takes more damage from the side or has less evasion from behind?
8B: can you change the death animation bassed on the direction the pawn is being attacked from?
more a comment than a question. I would like to see animations able detect and than climb short walls, fences, and ladders too. Also having the death animation take height into account so it could fall down a hill or off a wall.
-Thanks for going through my list of questions.
Hi Kairon, I’ll try replying to all your question in turn. First I would like to note, though, that the toolkit can be modified to include most features you can think of, but that it will in most cases require work on your part. I have created the toolkit with the goal of making a generic framework for all sorts of grid based turn based strategy games. These sorts of games are very varied and have a lot of different rules, so I’ve focused on creating features that are common to most or all such games.
In the future I plan to make example levels that show off some more genre specific features (see my planned features list), but that won’t be added for some time. As such, I do not have out of the box solutions for a lot of the things you are asking, as most of them are quite game specific. However, I will give you estimates for how difficult I believe it would be to add the different features you are mentioning, as well as short explanations of how they could be added.
For the first part of the question, you can have pawns inside a building with a roof, and by default you would naturally not be able to see through the roof mesh. There are a few ways you could add this, though. One simple way would be to add a collision volume inside the building. Set it up so that when there are one or more pawns with faction set to player inside the volume, the roof becomes invisible (the roof should be an actor, so you can modify its mesh’s visibility on runtime).
For the second part, you can have pawns walk on the roof on the building, but not if the inside of the building is also walkable. The toolkit does not currently support layered grids, where a pawn can stand on a tile directly above or below another pawn. This is a requested feature that I plan to add in the future, but it will take me a while to get there.
If I understand the first part of your question correctly, then yes, that’s something you can do by default. Just set the walkability of your rivers and crevices to whatever is appropriate. For a crevice that can be entered and exited on each side you could place invisible walls along its edges or you could use automatic walkability based on height. After my next update you won’t even need to place a single invisible tile, as walkability will be generated automatically for such terrains, as long as you make sure they conform to the grid.
I have to note again concerning bridges, that you cannot at the moment have bridges where you can walk both on and below the bridge.
For rivers and mud I think you might be talking about difficult terrain that takes more movement to walk across? This is included by default. For swimming you’d have to add swimming animations, of course.
It is possible to add destructible terrain, and not terribly difficult. You have to create a new sort of terrain tile with a health variable and set it up so it can be targeted by attacks. When it is destroyed you just need to update the walkability grid.
Hiding in blocks would mean you’d have to add a lot of stuff depending on what you’re going for. You can easily make a tile that blocks visibility but not movement, so that it can be entered. However you would need to add animations for entering/exiting crates, behavior for how AIs react when they lose track of a player pawn etc.
For the first question you’d again have to add destructible terrain plus some sort of cover system. I have plans to add a cover system similar to XCOM for one of my example maps, and I’ve thought of a few ways you may do this. One is to do separate visibility traces at head and leg height, and give half cover if one is blocked and full cover if both are. You could do something similar with pawns blocking one another, perhaps by having invisible blocking volumes surrounding all pawns that block a new, custom trace channel. If this trace channel is blocked when checking visibility to your target, deal less damage to the target and also deal damage to the pawn on the grid index corresponding to where the new trace hit.
Changing the stats of pawns is pretty straightforward. Just get and set their public ability variables. You’d have to add all the specifics of an inventory system with adding/removing gear yourself.
The simplest way to do vehicles with multiple pawns would be to “destroy” all the pawns when they enter a vehicle and treat the vehicle as a single pawn. Then you could deal damage to the vehicle like a normal pawn, and if it is destroyed you could spawn the pawns occupying the vehicle on surrounding tiles and apply damage.
Faction is a public variable, so changing faction is as easy as changing the variable.
Walkability and visibility are independent, so creating windows and such is simple.
You have to be a bit clearer on question 7B. Visibility is determined by the collision volumes, which can be whatever shape you want. If you’re talking about granting cover to enemies standing behind a corner, see my previous comment on cover.
Visibility is determined by individual collision volumes set to block the custom trace channel RangeTrace, and those volumes can be whatever shape you want. Walkability can be set individually for each edge and corner of each tile, which is in my experience good enough to create believable walkability for most types of terrain.
This is also a much requested feature. It should also be quite simple to add. Just change the rotation yaw of a pawn when you click a rotate button or something similar. Then when attacking, compare the look at rotation between the attacking and defending pawn with the rotation of the defending pawn and modify the damage accordingly. You should similarly be able to select a custom death animation, though you’d of course have to modify the animation blueprint.
I’m not an animator and I’m not allowed to include animations available freely online on marketplace releases, so it seems unlikely I’ll be able to add such features unless I hire someone to make those animations. I do however intend to include the options of having pawns ragdoll when killed, which would allow them to plummet off cliffs and the like.
Don’t mention it 
To reiterate, most things are possible to add to the toolkit, but you do need to be proficient with blueprints or C++, same as for any other game genre. If you end up purchasing the toolkit I suggest you start by making the parts of your game that do not require you to heavily modify it. After you’re done with the basics and want to add your own functionality you should hopefully have a good enough understanding of how the toolkit works that the process should be simpler.
Finally got this working on OSX as a note. Issue seems to be when you create/add it fresh the first time the GridManagerBP tries to compile it would allocate a really large portion of memory and then subsequently crash the editor a with memory access violation.
This only happened if I tried to add it to a scene fresh(where it’d add the grid and try to compile at the same time). Long as I make a point to compile the gridmanager before I try to use it in a scene, it works fine. This ultimately seems like a bug with UE4 itself and not this package, this is just the first BP where I ever witnessed that behavior.
So all that said, this is a great tool. The only feature I think that’d be nice to add is more control over the turn structure out of the box. Like Player/Enemy turns and then “per unit” initiative(i.e. turn order is determined per unit by some variable as opposed to per faction). With just that change I feel like this tool becomes really useful for a large variety of SRPG type games with very little tweaking.
@: Great to hear you got it working! Epic made some changes to the way blueprints are compiled in 4.7 that significantly increases the size of blueprint scripts. This, in combination with the already massive size of the Grid Manager might have been to much for your Mac to handle. As you can see in my list of planned features I intend to make the toolkit more modular in the future, which includes splitting it up overmmultiple blueprints. This will hopefully remedy the problem.
As for individual initiative values, that’s actually how I planned to make it initially. However I decided that it was too game specific to include as default. I will be adding it when I make my dungeon crawl example level. That won’t be for some time, so if you want to add it yourself it’s actually pretty simple.
Just make a new public float variable called initiative on Unit_Parent. Then in the event graph of the Grid Manager find the add pawns in initiative order function and modify it so that it adds the pawns into the initiative array according to their initiative values.
Hi, just want to say straight up that i’m really impressed with many aspects of the toolkit, but as a programmer looking for a tile solution it’s very difficult to get into it. It will mainly need a migration of gameplay logic away from the grid manager (the one problem i have with this otherwise fantastic product) though It does do exactly what you say it does and that is no criticism (Well done!).
If i can manage to get the main logic operational i’d be glad to send it to you as abstracted gameplay specific logic from the manager itself into more programmer friendly places.
Gamemode(world rules) -> Pawns(handle their own movement) -> Grid manager (make network safe/only handle path generation/only tile data) -> Player controler (send data to camera controller/handle user input)
for me, this should be a higher priority (from my perspective of course, art wise it’s a dream) as it really will help with anything to do with extending the features in the future.
Thanks for both the kind words and the valid criticism, Midnaut. If you have read the rest of this thread you are aware that ambershee raised similar points shortly after I released the toolkit. At the time I was uncertain if the benefits of splitting up the blueprint would outweigh the costs, but as I’ve continued working on the toolkit and gotten feedback from numerous users I’ve become convinced that it has to be done. As you can see from my planned feature list, increased modularity is a fairly high in priority.
There are a few reasons why it’s not on the very top, though. Firstly, the main feature I’m working on now (automatic walkability grid generation without tile placement) is such a major overhaul of the toolkit that I prefer to get it out of the way before doing any reorganization. The other feature that has higher priority, touch controls and performance increase, is what has been requested the most by users and also something that’s fairly easy to add. I am also working on preparations for migrating the gameplay logic in parallel with adding these features; by turning more of the functionality into self contained faunctions, for instance.
Thanks a lot for the suggestion of how it would make the most sense to split up the blueprint. It’s pretty close to what I had in mind myself. I have to ask for a couple of clarifications, though. Could you explain in more detail what you would consider “world rules” to be contained in game mode? Also, could you expand on what you mean with “only tile data” in the Grid Manager? Do you feel that generation of visibility grids would be appropriate for the Grid Manager?
Hi, sorry for any ambiguity in my previous post. For the Game mode, even though ive seen you say in your previous posts that you dont want to overwrite peoples game modes already, its the ideal way to encapsulate the game rules as per the unreal documentation.
So to clarify a bit, GameMode should handle players (2 or 1vai), how players enter, what units they can place, should contain data like points needed to win etc, all things to do with defining how a game mode will function. For more info check out the gameplay framework documentation as itll word it a lot better than i can (this is all typed on my phone sorry)
With how the Grid manager should work in my opinion, is that it handles the main grid state (unit positions, tile data), and would provide access to functions that would output visibility for a given unit. That would be called by the unit itself when appropriate so yes, generating the visibility should be a part of the grid manager from my understanding.
Ok, thanks for clarifying. Here is how I am now planning to split up the blueprint:
**Grid Manager: ** Contains all grid-sized arrays. Contains all functions pertaining to these arrays. This includes generating walkability (pathfinding), finding paths within walkability grids, drawing shapes on the grid and checking line of sight (visibility). None of these functions will be called by the grid manager at runtime, but will be called through different blueprints. The grid manager is also responsible for a lot of things at event begin play and in its construction script, including procedurally generating grids depending on terrain.
GameMode: Handles initiative order, starting and ending turns. Handles placing of new pawns and tiles on the grid at runtime if the game allows for this. Decides when to end the game.
Player controller: Handles input to control the camera and interaction with the grid. Handles displaying the hover marker and visualization of splines used in movement and aiming. The logic contained within “Choose action depending on tile clicked” and parts of the logic within “Display path” will be moved here, as well as most of what is currently contained in BP_Grid_Camera.
Pawns: Queries the grid manager for pathfinding and visibility. Handles movement and attacking along the splines created in the player controller. Handles animation through the pawn event graph and the connected animation blueprint. Handles what happens when damage is received. Includes the code currently contained in move pawn, initiate movement, initiate attack, attacking and damage pawn. Notifies the game mode when movement is completed or the pawn dies. Might handle the AI, though I’m still uncertain if this would be better handled by the game mode or if I can recreate it in behavior trees.
If anyone reading this feels something here is out of place or that I have forgotten something, please post in this thread.
If I can add something to this list an “Art guide” for the lack of a better term for size, scale, etc. would be handy as well for making our tiles and units.
Just saying
thanks for your reply. I think your answer for 7C answered 7B also. mainly I was wondering about objects that take up more than one block but fractions of others too.
if I ever get use to the Unreal 4 engine I’ll be sure to buy this toolkit.
I’m not sure if I completely understand what you’re saying. This is not related to me splitting up the blueprint, right? Do you mean if I could create a guide for how big you should make any custom meshes you’re importing? That shouldn’t matter as long as you keep everything you make proportional to each other. The grid scales automatically to the size of the default grid mesh. As for importing and using your own meshes, my third video tutorial concerns this. Could you clarify a bit?
Ok, great! Just post here if you have any additional questions.
Edit: Sorry for the post, I fixed it - my friend (who I’m working with) packaged the content incorrectly.
Didn’t get to read what problem you were having, but glad you sorted it out
I just seen this on the market place, seems very interesting. I have two questions before I buy.
-
Is it possible to use units other than a single humanoid, like vehicles
-
Is it possible to have stuff on the tiles the pawns interact with; for example a (one hex size) building a pawn would enter
I would assume there would need to be some tweaking to get the above, but wanted to make sure the kit was a decent place to start for such things.
Hi nrm21122,
both things you mention are certainly possible, though you will of course have to script the specific functionality yourself. For vehicles that isn’t much harder than replacing the skeletal mesh with a vehicle instead. You would mostly have to modify the parts concerning animation, but that’s not too hard.
Interaction is a very broad term, but everything can be done if you script it. If all you want is entering buildings all you have to do is make sure the tile does not have a wall on the edge containing the entrance and it should work out of the box. There are a number of ways you could then fire events when the unit enters, from using functionality in the toolkit to just using a simple trigger volume.
Feel free to ask if you have any more questions.
Actually I have troubles on sorting Units based on a custom Initiative integer value (inherited from Unit Parent and different for every unit: for example enemy ranged has an initiative value of 5, player ranged has 6 etc.) … basically I’ve implemented an insertion sort algorythm but it doesn’t work in clean way.
Anybody here has implemented a working sorting algorythm?
It seems like that the GET function during debug gets a wrong value on the array index… for example a* where i=4 and array has 5 elements (0,1,2,3,4) get a value out of bounds (none value) but it should pick the correct value as I can see in the debugger… not easy to explain at all.
Any suggestion?
Hi Wisdom-,
I’ve made an inititative sorting algorithm as per your request. Replace the nodes in the “Sort Pawns in initiative order” funtion with these and the pawns should be sorted automatically. You’ll of course have to replace the initiative variables I’ve used here with your own. I’ve used floats in this case.
Edit: In case you haven’t used bluprintue before, copy the code below the graph on bluprintue directly into the appropriate event graph in your project.
Edit 2: This does naturally not work in conjunction with allowing to switch between pawns by clicking on them.
Thanks for the quick response
I will buy it here in a few, want to get on a more secure machine before entering payment info
With that I do have one question:
I am under the impression that using Blue prints alone are not the best option for making a game, and C++ should be included. It is my understanding blue prints are great for quick little things; is this correct?
Assuming that that is true, are blue prints alone a real option for a turn based strategy game?
I ask because I was going to use some c++ code, and possibly converts some of the blue prints into c++. A couple of friends were saying they think for a turn based game there may be little need to use c++
was hoping a few people on here had thoughts on this