That’s certainly possible, though the amount of work it will require will differ depending on how you’d want to implement it. The simplest way would be to just modify the initiative order array so that the player character is always on top of initiative when he’s not in combat, meaning he’s the only one moving. While not in combat also make the tiles he can move to invisible and give him a move range larger than what is visible on screen so that the player can move wherever he clicks. When combat starts use initiative like normal and make the blue can-move-to tiles visible again. You’d probably want to add a lot more stuff than that, but that would achieve a lot of the basics.
Alternately you can just use navmesh and something similar to the top down example when not in combat, and when combat starts you could place all pawns on the tiles closest to their location and start combat.
I haven’t encountered the bug you’re describing before. Are you able to replicate it? Is the enemy pawn’s faction set to “Enemy” and not to “Empty”?
Thanks for the quick reply, Ill try out your advice
I will also try to replicate the bug for you… You will hear from me if I can replicate it If not It was probable me doing something stupid.
Here’s a short clip showing off a new macro I’ve made for splitting up forLoops and forEachLoops over multiple ticks. The slow version showed in the video is way slower than what you would ever need (this is adjustable), for demonstration purposes.
The video shows the regular (instant) and loops per tick based vesions of creating a visibility grid. Visibility is efficient enough that the instant versions should work well for most games, but I’ve created this method for games on less beefy hardware (like mobiles) that want to use large grids and still be certain of a constant framerate.
This is a big step towards my next major planned feature, which is mobile and tablet support out of the box. Some users have already made the toolkit work on mobile, but I wanted to get this option done before implementing touch controls myself.
I enabled draw debug line per tick and it created a cool barcode-scanner effect For a real game you’d probably want to keep everything invisible until the grid was done generating.
First of all, again, cool toolkit.
I believe it has great potential.
Is there a way to have empty tile put over the base grid block range attacks?
Like lets say a building roof that you could walk on? Building itself should block vision, but still allows you to walk on the roof.
I’ve tried to put a wall and empty tile on one tile but that combination makes it not walkable.
Any suggestions?
@Oskarek: Vision (and thus ranged attacks) is checked by doing line traces from the attackers tile at “visibility trace height” (by default head height of the UE4 mannequin) to the same height on the target tile. This trace is done on the custom trace channel “Range trace”. To block vision there must thus be something blocking “Range trace” between the start and end Points of the trace. So you can for instance set the mesh of your building to block range trace (make sure it has an appropriate collision volume and collision enabled). You can also create a copy of the invisible wall tile and set all its edge costs to 1 and Place them wherever you want to block vision. Or just drag collision volumes into the viewport wherever you need them.
We have talked in emails about making hover markers more aligned to the surface.
I’ve been thinking, maybe instead of static meshes use something that align by default?
Maybe tile could lit up a little instead of generating static mesh on top of it?
I’ll try this tonight, seems like a legit idea for my novice brain
What do you think?
@Oskarek: Thanks for the link and the suggestion. Please let me know how it works out. I have at the moment thought out three different solutions to the slanted tile problem:
Instead of just having a vector array for the tile grid also include rotation information. This should work well in many cases, but it would require the user to rotate tiles placed on the map to appropriately match the underlying terrain in cases where the user does not want the entire map to be made up of visible tiles.
Use render targets instead of instanced static meshes. This is a bit similar to what you are suggesting, and projects a texture down on any underlying geometry. I do like this solution, but I’m uncertain how well it would work performance-wise. I suspect placing individual render targets for each tile in range would be bad for performance, and that I would have to find a way to limit the amount of render targets. I’ll have to test this out a lot more more before deciding.
Do not display every walkable tile, but instead show the edge of the walkability grid as a frame, similiar to how it’s done in XCOM and Massive Chalice ( Mac|Life ). I could possibly use beam emitters to create such a frame, though there might be better ways.
I like option number 3 but only as an option.
I believe some people (me :D) would still want whole tiles to be marked.
Render target sounds good, I believe that there won’t be too many markers to use. Range that is set in example map is very high.
I guess you could just test it out with matinee example scene or whatever example project.
During implementation of my game logic, I’ve easily (thanks to the comments!) implemented a damage randomically chosen from a min damage to a max damage instead of applying directly a fixed damage.
It was really easy, but I had to modify your blueprint directly, this means that I will lose this change when I will apply your next update.
Some posts before you explained to me how to do a custom control on a custom blueprint, but how can I implement a logic like this in a separate blueprint?
Can I access to the damage pawn block outside your blueprint in some way?
@Oskarek15: Yeah, I would keep the old method as an option, of course. You say that range is set very high in the example, but that’s not necessarily true. For games similar to advance wars, Fire Emblem and the like, render targets can be safely used even if they are inefficient, since range is so small. For games like XCOM, however, range is much longer, and I want my toolkit to work for all kinds of turn based games. Scalability and efficiency is important for me.
@Wisdom_HELLy: Good to hear that you find modifying the blueprint easy, as that was always my intention. Updates overriding modifications is a problem I’m trying to find the best way to tackle. I’m currently working on making more and more parts of the blueprint into functions, so that they can be easily called from ouside the blueprint. For a future update I will probably be moving the combat, movement and AI logic to from the Grid Manager blueprint to separate blueprints (possibly the level blueprint or to individual pawns). For the time being you can for the most part call functions from the level blueprint and create much the same functionality as can be found in the grid manager. However, this will take a bit more work with the damage system as it is at the moment. To call it from outside you could create a custom event that you plug into the “damage pawn” macro and call it from another blueprint. That custom event would disappear on an update, but adding it back would be very quick and simple.
@Wisdom-: Hey, don’t mention it. It is important for me to know that everything is intuitive and in working order, so all questions and comments are valuable. I just tried adding the toolkit to a new project, and the updates do not seem to be implemented yet. Epic has been busy with GDC, so that’s probably why it’s taking so long. They are supposed to set up some new lines of communications with priority for marketplace contributers to deal with this sort of thing. Hopefully the update will be added this week.
Been having a blast setting up my levels and combat arenas. Have you had any luck in finding an easier way to use meshes without the default Unreal Skeleton?
@Gugenheimer: Great to hear it’s fun to work with! Finding a simple way to use custom skeletons has been in the back of my mind since you asked it. However, I’ve focused my attention on fixing bugs and adding seamless mobile and tablet support, which has taken me longer than I expected. Animation is not what I am best at, so there is probably a way to change skeletons easily that I have not figured out yet. If you are not able to wait some more (and I’m sorry you’ve had to wait for a while already), you can do it the way I currently do it myself. Make a brand new anim BP with your custom skeleton. Copy all the blueprint and animation code manually over from Anim_BP_parent, making sure to add the appropriate notifies to attack animations. Then replace the Anim_BP_parent references in the Grid Manager with references to your new Anim_BP_parent. These are cast-to nodes found within the movement and attack parts of the Grid Manager.
Yes you’ll have to cast to your own Animation Blueprint (at least I do) and setup attack animation event in your animation blueprint (or call whatever other event/function you like).
Then you have to setup attack end notify in your anim blueprint and handle it.
You can basically copy all code from the anim unit parent blueprint.
What I did was copy almost whole event graph and anim unit parent blueprint and set-up it myself.
Unfortunately things like attack target are still custom event ( I believe that author is going to migrate them to functions ) so you can’t easily override them.
Thanks Oskarek15, that’s what you have to do, Gugenheimer.
I am indeed planning on overhauling that part of the toolkit to make it easier to adapt and call from outside the blueprint. For now, however, this is the only way I know of to change it. Good that you’ve got it working for movement. That porbably means you’re almost there. Have you added notify event to your attack animations? Then you need to call it in the event graph of the Anim BP and get it to fire the “Attack hit” event in the Grid Manager, just like I have set it up in Pawn_Anim_BP_Parent. One thing I forgot to say is that you should set the default value of Grid Manager Ref to BP_Grid_Manager if you have not done so.
Success! I had to make my Cast to Anim_BP into a “pure” cast. After I did that it worked. Does this mean that all pawns have to use the same skeleton? My project is fantasy themed so some of the creatures will have a lot of different bones (wings, tails).
My end goal is to make a VR friendly turn based game. I have done some configuring of the grid manager camera, and have it so you switch between the overhead grid camera for planning, and then can switch to a free floating camera ( I made this a Beholder ) to roam the map.
@
Do you think you could add markers match to under tile and rotation into core, please?
I’ve done this by doing Line Trace by Channel on Path Trace channel and getting hit actor transform/rotation to apply this to hover/active/move/attack meshes.
Unfortunately it seems to much of code copy to include in my child blueprint, so it would be great to see that in core!
@Gugenheimer: Great that you got it working! I’m reluctant to do a proper tutorial for this yet, as I’m sure I’m going to change how it’s handled, but I’ll do one as soon as I’ve found a better solution. As for having multiple sketetons, the way I would do it in the current system is to keep casting until you find the right animation blueprint. So first try to cast to your most common Anim_BP, if it fails, cast to another and so on. It shouldn’t be that inefficient, since these things are never called on tick. Looks a bit ugly in the blueprint, but it works. I’ll hope to find a better solution for this as well later on.
@Oskarek15: That’s a creative solution, and I’m glad you got it working. However, though it might work for you, there are much more efficient ways of doing this, which important for mobile and VR. A more efficient way to fix it is to add the rotation of all meshes to a rotation array on startup and get from that aray when placing meshes. That way all the calculations are done before the game starts instead of during runtime. Traces are pretty expensive too, so I’d prefer to get the rotation directly from the tile actor on the appropriate index instead of doing a trace. Fixing mesh rotation is close to the top of my priority list, and will hopefully be in the next update.
Edit: In fact, that seemed so simple to add that I just did Now you can be certain it will be in the next update.
If not It was probable me doing something stupid.
Now you can be certain it will be in the next update.
