Woah, the icing on the cake after all the hard work and throughout explanation on the tactics innards approach (3D and animations included to the best of capabilities) that also the music and sound effects were tackled by yourself.
Hey man! I just wanted to say thanks for putting your content out into the world. So many videos focus on getting the basic functionality working that it's hard to understand how to implement larger scale systems in Godot from most of the content that's out there. Your content is helping me understand how to architect the systems I want.
Love this. I’m looking to build a tactical game with Mechs as well so this was a particularly interesting watch. Great work, hopefully I can use this as a resource to get started faster and have a more clear start and finish. Thanks for the video!
Thanks! Good suggestion for the future, though I'd probably need to revisit this type of game at least once more before I could more confidently and properly teach how to make a game like it.
It's a amazing job. I'm here because I need some inspiration for a game that I have in mind. I just don't know yet how to code properly, but your video gave me some important directions.
Nice :) Esp the sound fx :) Just found your website - it and the video tutorials are magic, I hope you keep providing us with insights, bites and conceptual blueprints. Thank you.
This has SO MUCH potential, I hope you keep exploring this concept!! It reminds me a bit of one of my favorite games of all time, Vanguard Bandits. It's a rare PSX tactics game with mechs as well haha. Great content as always, keep it up!
Oh wow, didn’t know about this game. I just can’t get enough of the isometric pixel art look, at least they kept the units pixel art the main map view with the environment in the distinct PSX lo-fi 3D. And the portraits and overall approach, such a 80s and 90s style Robotech look.
Really useful DevLog, some very good pointers and tips. Thankyou muchly. The game looks great BTW, wouldn't mind seeing you expand upon it at some point. Seems pretty fun! *EDIT:* Just finished playing it, it was fun. I know it's simple but I actually really like the visuals too. Got a certain charm to it. Was kinda sad when it was over. You nailed the core gameplay, shame you didn't have time to expand on it further (I see the interacting elements is mentioned in the tutorial, but it really only applies to the water/lightning combo, or fire/water cancelling each other out). That 2x speed was definitely a necessary addition though!
Awesome looking jam game! Also thanks for this post mortem! The special abilities are the part that always stumps me. Back in the day I made a multiplayer turn-based tactics game with migrating host servers, yet I could never figure out how to make abilities other than attack and heal lol. With your drawing and explanation of the code design, I feel like I can work my way through this. For AI, I just use a variant of A*, with the heuristic being based on unit preferences, capabilities, target, internal state such as HP, and a heat map of enemy locations and positioning data, and a small random value. Instead of cells, I use ability objects. As with A*, ability objects get thrown into a collection and sorted by weight, yielding reasonable action for the AI to take.
As someone getting into Godot from elsewhere this was super useful to get to know how you created the system and leverage Godot. Do you have a video where you go more into details about your other system for another game you mentioned (Kaiju? can't pronounce it right). Thanks.
Thanks! Glad it's helpful. Afraid I don't have a video for Kaiju Klash, but I would consider this system to essentially be an improved version of what I used there. There's still a turn order system, asynchronous turn execution, etc. The only real difference is I used code instead of Resources to define actions, but there's no magic sauce there. I had an Autoload (aka singleton) that held a big dictionary defining moves that you could look up for a given unit and part type. The actions themselves were just simple Reference classes (renamed to RefCounted in Godot 4), which acted as simple data containers so I could parse out what an attack does when I need to.
You should really consider to make a tutorial, good tutorials for godot seem rare. Your idea is cool and a good starting point! Would love to dive deeper, especially to have an intense peek into the gd scripts you created... maybe you could add those.
How did you handle grid positions? Since every mech has both a world position and a position on the grid, which essentially acts as the 'master'? Does each mech expose a grid position which is used by other mechs and the managers for calculations, and how does this interact with the walking animation system?
I always use grid cells as the "master" for grid-based games as that's what most logic will rely on - Can attack a target within 3 grid cells, can move 5 cells per turn, etc. I've only done a handful of grid-based games, but my experience has been that using cells as the primary unit generally requires less back and forth conversion than world positions. So in my navigation code, I have small conversion functions that can do grid to world position and vice versa. For movement, I convert the current position to a cell, get a path to travel in cells, then convert those cells to world positions to do actual movement. Similar process with targeting other mechs or objects. I just say "I'm attacking these three cells, is anything there?" and get an answer back.
This came out really well. I wanted to make a grid based tactics game as well, but had a ton of issues with 3D and restricting movement and combat to a grid. Can you share how you handled the 3D grid and keeping the pathfinding well? I've only found solutions for navmesh
Sure. So as mentioned in the video I used the Astar2D library in Godot to handle the pathfinding, which is naturally quite friendly for grid-based movement. So I load the data in from the GridMaps I use, ignoring the y-axis since there's no verticality. As for managing that data, I exclusively use grid cells for my data and then convert that to world coordinates or vice versa when needed. So, when I want a mech to move, I translate its current world position to the equivalent cell location using my_gridmap.world_to_map, get my path as a series of grid cells, and then convert those results back into world positions with my_gridmap.map_to_world so I know the exact world positions I need to move to. The result is mechs that are always aligned to the grid! I should probably also mention that there are no physics bodies in this game whatsoever. Mech's are just basic Spatial nodes with the code and models shown in the video, and they move by directly manipulating their transform.origin property.
I am working on an isometric tactics game currently and have ran into a problem with the A star path finding. When I click on a tile, the player moves but doesn’t move in the right direction or completely to the tile. I was wondering if you knew a good way to do point and click in 2D isometric godot.
Hey amazing video, loved the detail and organization! At 4:13 when you show the mech scene and what it made up of is this an example of compisition where you dont have fire_mech inherit from base_mech, but instead add it as a child of fire_mech?
Yep, pretty much. "base_mech" is actually just the model and animations from Mixamo, so you can also think of that node as just representing the base model to be used alongside everything else. Though there's not much variation between the mechs in this game since they're all generally the same, each node shown is capable of acting independently on it's own and without making any assumptions about the structure of the nodes around it. I could add or remove nodes and things would still work as long as the top level script is updated accordingly since that's where all of the orchestration and dependency injection occurs. If I did need a mech without AI or particle effects, for instance, I could do that without having to inherit those nodes and code and just have them sitting there unused.
@@zephy6446 No, but you're right in that each type of mech is inherited from another scene. That scene is a generic Mech scene that defines the structure of the four mech scenes. That's where the bulk of the composition actually occurs and where I add the AI, Action Resolver nodes, etc and the base_mech scene (which is just for animations and not the best named for instructional purposes). There's some more composition in each mech, with particles and sound effects, for instance (though you don't see that in the video because those nodes are collapsed), but that higher level scene is responsible for most of the structure and work. Not the best example of composition since every unit is the same in this game, but the principles were still generally applied.
@@TheShaggyDev I see now I fully understand! Also, in the base_mech, there is a node called RootNode, is this used to position the childern to then send to the _mech root node?
@@zephy6446 That's actually just a side effect of the FBX import and not something that I added to the game. It's not directly used in any capacity. Movement and positioning is actually just done at the top-level _mech node. I move that and everything else goes with it!
Looks really nice! I got some specific question if you don't mind. I know pretty well how to use GridMap in Godot and how to layer multiple ones like you did (e.g. for having a GridMap for the ground, another one for foliage, buildings and other obstacles, yet another one for the player and enemy units etc.). But how exactly did you implement the grid's UI for controlling the mechs? Is this also just a GridMap whose cell items are based on usual 3D meshes? Or are you somehow using a plane that you're "painting" the grid and the mechs' movement indicators on? Seems to be a very basic question, but something like that isn't really tought often in Godot tutorials so I am lacking quite a lot of knowledge in that regard. How to implement game UI elements in 3D scenes as used in tactics games or an RTS games is really something. I am thinking of an RTS game in particular and of some kinda marker on the ground indicating a location the units have to move to. How would I ideally implement such in a 3D game whose levels are made with GridMap? Would I make this another GridMap as well or are there any other (better?) solutions? Thanks for your answer! 😘 And keep up you awesome work! 👍
Glad you liked it! For the UI piece, the grid is just a simple plane with a grid texture on it. At runtime, I resize it based on the size of the map and adjust the UV scaling of the material so that it tiles the texture appropriately. Any highlighted cells, such as when planning a movement path, are individual planes with a grid texture that get snapped to the right grid position. For the logic side of figuring out where something should go, though, such as determining what cell a mech is in or what cells to highlight, the easiest technique is to use the world_to_map and map_to_world functions available in the GridMap class. These functions can automatically convert a grid cell to a world position or vice versa, and they don't require you to have anything at that location in the GridMap. So in your RTS example, if I know I need a marker at a certain cell location, I can use map_to_world to give me the center of that cell in world coordinates so I can spawn an object there. Hopefully that helps a bit.
could you elaborate on how you setup these animations. im still not sure how to setup an animation that includes variable conditions like distance based timing or having differnt users and targets.
My typical approach is that if an action doesn't fit nicely into a pre-canned animation, I use an "escape hatch" of sorts to perform the action programmatically instead of with any of Godot's animation-related nodes. Ex: A punch plays the punch animation and everything is fine because that animation is always the same. Movement, though, goes to a special node where the path to travel is animated over time, the unit is moved and animated along that path, and callback is used to signal when the action is over.
Why wouldn't you make a course for intermediate game development using Godot like this one when you were taking about how you organized the game code? I think it would be helpful since learners such as myself are trapped in beginners' tutorials, and when we try to make something beyond our scope of knowledge, problems begin to appear.
@@Retro-Future-Land I'm afraid not. It's still something I'd like to look at at some point, but just haven't had the time to get something of that scale together. Open to suggestions for content ideas if/when it does happen, though! At the very least, stuff like that will end up on the channel at some point.
@@alexi2706 I had to set it up manually with AStar2D as this was made in 3, but in Godot 4 you can use the AStarGrid2D class to do grid-based pathfinding. I have a video and article on that if you're curious. The important thing to keep in mind for this game is that the logic is all 2D, despite the visuals being 3D. The vertical axis plays no role in game logic so I'm able to use 2D pathfinding and logic to manage everything.
Nice video. Very insightful. One question: When you go through the effects for each action you're using a switch statement to distinguish between effect types. Do you prefer this solution to an interface or inherited method on each effect or was it just the simplest and quickest solution you came up with for the jam? What I mean when I say interface method is a method that is implemented on each effect so when you loop through all of the possible effects you can just call it e.g. effect.apply() where apply() is overriden for each effect type.
I'm fairly flexible, though I typically have a preference towards interfaces if there's much complexity involved because I like the organization of code that offers. The switch statements in this game kind of just came about as a side effect of: 1) Just coding things up as quickly as possible due to time constraints of the jam while not making a complete mess of it 2) How I implemented action planning in the action resolver, which lazily relies on exiting the loop early to process but could / should be done a different way 3) The fact that everything inside of the switch statements is a one line call. A switch statement is easy to manage and expand upon, but if there was any more conditional logic than what exists I'd have gone ahead and broken it out into proper function calls
Haha, thanks! Yeah the 3D to 2D conversions of everything definitely took some time to figure out. Pathfinding went smooth enough for me, but even in the final release the mechs sometimes turn in the wrong direction when turning, resulting in them doing a big spin before they face the right direction :D
Just to enforce typing. It let's me know later on not to expect anything from a given function, and by explicitly declaring it the editor will also be able to tell me that with its code hints.
It seems to be fixed in Godot 4, but in 3 I would often get weird errors from the engine when switching between multiple GridMaps in a scene. Like, I'd be editing the level layout with my Level Gridmap, switch to my Mech Gridmap to place units, get an error in the console, and then have tiles from the Level Gridmap appear in my Mech Gridmap. It was like the engine was expecting there'd only ever be one gridmap in a scene. I'd typically have to restart the editor every time I wanted to change which gridmap I was working with otherwise I'd be at risk of getting an error.
For this game, since each cell has the same height, I do a raycast from the mouse position on screen to a plane in the world, using the camera to project the mouse position into 3D space. This Q&A has some discussion and code for the technique: ask.godotengine.org/25922/how-to-get-3d-position-of-the-mouse-cursor
In this case, since the entire game is on one plane, I just ignore the vertical (Y) axis for pathfinding purposes. No tiles or anything like that needed.
@@TheShaggyDev I don't understand you saying: "Since levels are composed of GridMaps, that also made it easy to load data into Godot's built-in AStar2D library to build out pathfinding". How can we link the 3d gridmap with astar2D?
@@longuemire748 Sure, let me see if I can explain a bit more in depth. GridMaps are 3D, but I don't care about the vertical axis in this game, so I can ignore the Y-axis and treat the map as 2D for most purposes, including pathfinding. So for Astar2D, I take the X and Z coordinates of a cell from the GridMap, which are the two axes that represent the horizontal plane in 3D space, and directly tie those to the X and Y values of locations in AStar2D, which are the axes used for 2D space. So an example conversion might be: This cell is at 3D position Vector3(1, 2, 5), which is equivalent to the Astar2D location Vector2(1, 5)
It's kind of just conventional to prevent hit and run tactics. Otherwise you could end up in a situation where a unit damages you and then runs out of range. Instead, if you end movement after shooting, you have to plan where you want to attack from since you have to commit to that position for a turn.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
hot dang. now that's an incredible devlog. glad the algorithm sent you my way. a+ stuff.
Thank you! Glad you liked it!
"I know just enough Blender to be dangerous." Hah! I love that. Fantastioc devlog, enjoyed your process.
Woah, the icing on the cake after all the hard work and throughout explanation on the tactics innards approach (3D and animations included to the best of capabilities) that also the music and sound effects were tackled by yourself.
Really enjoyed your explanation of making sound effects
Thanks! Always have fun doing sound effects, though there's still plenty of room for improvement on the ones I make.
Hey man! I just wanted to say thanks for putting your content out into the world. So many videos focus on getting the basic functionality working that it's hard to understand how to implement larger scale systems in Godot from most of the content that's out there. Your content is helping me understand how to architect the systems I want.
Thank you! Glad to be of help!
Wow, you excel about everything. Great job!
Ha, don't know if I'd say I excel, but thanks!
Wow, I watched this for the first time 2 years and I’ve kept coming back. Your tactics vids are probably my favorites on the topic.
Really well presented about your approach, process, and tradeoffs. Thank you.
Thank you for sharing!
Very neat - well done
This was so inspiring, thank you for sharing!
Thanks for making this log. Your approaches to game and code design are very insightful!
Thank you! Glad you liked it!
Thats an awesome concept!
Thank you! It was a fun one to work on!
Love this. I’m looking to build a tactical game with Mechs as well so this was a particularly interesting watch. Great work, hopefully I can use this as a resource to get started faster and have a more clear start and finish. Thanks for the video!
Extremely underrated video, would love to see you a tutorial series!
Thanks! Good suggestion for the future, though I'd probably need to revisit this type of game at least once more before I could more confidently and properly teach how to make a game like it.
@@TheShaggyDev Would love to follow up and share with friends!
This is a really helpful video, thank you !
It's a amazing job. I'm here because I need some inspiration for a game that I have in mind. I just don't know yet how to code properly, but your video gave me some important directions.
Dude, this is awesome.
this is cool. you should 100% expand on this.
Nice :) Esp the sound fx :) Just found your website - it and the video tutorials are magic, I hope you keep providing us with insights, bites and conceptual blueprints. Thank you.
Loving this video. Man i want to try it later when I'm at home. I want to create tactics games, and this was impressive.
This is great, thanks for sharing!
Glad you enjoyed it!
Great dive into your game and process! Thanks for showing how you made the mech models, I'm going to give it a try.
Go for it! Asset Forge is a really nice piece of software!
Very creative sound effects techniques!
Thank you! It was a fun one to experiment with.
This has SO MUCH potential, I hope you keep exploring this concept!! It reminds me a bit of one of my favorite games of all time, Vanguard Bandits. It's a rare PSX tactics game with mechs as well haha.
Great content as always, keep it up!
Thanks! Glad you liked it! I've not heard of that game but it looks pretty cool from what I'm seeing of it!
Oh wow, didn’t know about this game.
I just can’t get enough of the isometric pixel art look, at least they kept the units pixel art the main map view with the environment in the distinct PSX lo-fi 3D.
And the portraits and overall approach, such a 80s and 90s style Robotech look.
Great video! Watched every minute love your work
I'd love to see this hit the market! Especially if you added the features you wanted to it too 👌💯
Thanks! No plans for that in the immediate future (I need a break to work on something simpler 😅) but definitely keeping this one in my back pocket!
Oh wise dev. I bow to your wisdom.
Really useful DevLog, some very good pointers and tips. Thankyou muchly. The game looks great BTW, wouldn't mind seeing you expand upon it at some point. Seems pretty fun!
*EDIT:* Just finished playing it, it was fun. I know it's simple but I actually really like the visuals too. Got a certain charm to it. Was kinda sad when it was over. You nailed the core gameplay, shame you didn't have time to expand on it further (I see the interacting elements is mentioned in the tutorial, but it really only applies to the water/lightning combo, or fire/water cancelling each other out). That 2x speed was definitely a necessary addition though!
Thanks for playing! I still would like to come back to it at some point and flesh it out further. Definitely something I'm keeping in the backlog...
Awesome looking jam game! Also thanks for this post mortem! The special abilities are the part that always stumps me. Back in the day I made a multiplayer turn-based tactics game with migrating host servers, yet I could never figure out how to make abilities other than attack and heal lol. With your drawing and explanation of the code design, I feel like I can work my way through this.
For AI, I just use a variant of A*, with the heuristic being based on unit preferences, capabilities, target, internal state such as HP, and a heat map of enemy locations and positioning data, and a small random value. Instead of cells, I use ability objects. As with A*, ability objects get thrown into a collection and sorted by weight, yielding reasonable action for the AI to take.
Do you have the code for the Ai open sourced? It sounds interesting and I'd love to take a look at it
Thank you a lot!
As someone getting into Godot from elsewhere this was super useful to get to know how you created the system and leverage Godot. Do you have a video where you go more into details about your other system for another game you mentioned (Kaiju? can't pronounce it right). Thanks.
Thanks! Glad it's helpful. Afraid I don't have a video for Kaiju Klash, but I would consider this system to essentially be an improved version of what I used there. There's still a turn order system, asynchronous turn execution, etc.
The only real difference is I used code instead of Resources to define actions, but there's no magic sauce there. I had an Autoload (aka singleton) that held a big dictionary defining moves that you could look up for a given unit and part type. The actions themselves were just simple Reference classes (renamed to RefCounted in Godot 4), which acted as simple data containers so I could parse out what an attack does when I need to.
You should really consider to make a tutorial, good tutorials for godot seem rare. Your idea is cool and a good starting point!
Would love to dive deeper, especially to have an intense peek into the gd scripts you created... maybe you could add those.
Me: I wanna make a tactics game
My YT recommendations: here you go
How did you handle grid positions? Since every mech has both a world position and a position on the grid, which essentially acts as the 'master'? Does each mech expose a grid position which is used by other mechs and the managers for calculations, and how does this interact with the walking animation system?
I always use grid cells as the "master" for grid-based games as that's what most logic will rely on - Can attack a target within 3 grid cells, can move 5 cells per turn, etc. I've only done a handful of grid-based games, but my experience has been that using cells as the primary unit generally requires less back and forth conversion than world positions.
So in my navigation code, I have small conversion functions that can do grid to world position and vice versa. For movement, I convert the current position to a cell, get a path to travel in cells, then convert those cells to world positions to do actual movement.
Similar process with targeting other mechs or objects. I just say "I'm attacking these three cells, is anything there?" and get an answer back.
This game looks fantastic, and considering you made it in two weeks it's quite a feat.
This came out really well. I wanted to make a grid based tactics game as well, but had a ton of issues with 3D and restricting movement and combat to a grid. Can you share how you handled the 3D grid and keeping the pathfinding well? I've only found solutions for navmesh
Sure. So as mentioned in the video I used the Astar2D library in Godot to handle the pathfinding, which is naturally quite friendly for grid-based movement. So I load the data in from the GridMaps I use, ignoring the y-axis since there's no verticality.
As for managing that data, I exclusively use grid cells for my data and then convert that to world coordinates or vice versa when needed. So, when I want a mech to move, I translate its current world position to the equivalent cell location using my_gridmap.world_to_map, get my path as a series of grid cells, and then convert those results back into world positions with my_gridmap.map_to_world so I know the exact world positions I need to move to. The result is mechs that are always aligned to the grid!
I should probably also mention that there are no physics bodies in this game whatsoever. Mech's are just basic Spatial nodes with the code and models shown in the video, and they move by directly manipulating their transform.origin property.
I am working on an isometric tactics game currently and have ran into a problem with the A star path finding. When I click on a tile, the player moves but doesn’t move in the right direction or completely to the tile. I was wondering if you knew a good way to do point and click in 2D isometric godot.
Are you the same person I replied to on Itch? Want to make sure I got your question answered.
Hey amazing video, loved the detail and organization! At 4:13 when you show the mech scene and what it made up of is this an example of compisition where you dont have fire_mech inherit from base_mech, but instead add it as a child of fire_mech?
Yep, pretty much. "base_mech" is actually just the model and animations from Mixamo, so you can also think of that node as just representing the base model to be used alongside everything else.
Though there's not much variation between the mechs in this game since they're all generally the same, each node shown is capable of acting independently on it's own and without making any assumptions about the structure of the nodes around it. I could add or remove nodes and things would still work as long as the top level script is updated accordingly since that's where all of the orchestration and dependency injection occurs. If I did need a mech without AI or particle effects, for instance, I could do that without having to inherit those nodes and code and just have them sitting there unused.
@@TheShaggyDev Wait but in the video the mechs were inherited from another scene, so are they inherited by base_mech?
@@zephy6446 No, but you're right in that each type of mech is inherited from another scene. That scene is a generic Mech scene that defines the structure of the four mech scenes. That's where the bulk of the composition actually occurs and where I add the AI, Action Resolver nodes, etc and the base_mech scene (which is just for animations and not the best named for instructional purposes). There's some more composition in each mech, with particles and sound effects, for instance (though you don't see that in the video because those nodes are collapsed), but that higher level scene is responsible for most of the structure and work.
Not the best example of composition since every unit is the same in this game, but the principles were still generally applied.
@@TheShaggyDev I see now I fully understand! Also, in the base_mech, there is a node called RootNode, is this used to position the childern to then send to the _mech root node?
@@zephy6446 That's actually just a side effect of the FBX import and not something that I added to the game. It's not directly used in any capacity. Movement and positioning is actually just done at the top-level _mech node. I move that and everything else goes with it!
Looks really nice!
I got some specific question if you don't mind. I know pretty well how to use GridMap in Godot and how to layer multiple ones like you did (e.g. for having a GridMap for the ground, another one for foliage, buildings and other obstacles, yet another one for the player and enemy units etc.).
But how exactly did you implement the grid's UI for controlling the mechs?
Is this also just a GridMap whose cell items are based on usual 3D meshes? Or are you somehow using a plane that you're "painting" the grid and the mechs' movement indicators on?
Seems to be a very basic question, but something like that isn't really tought often in Godot tutorials so I am lacking quite a lot of knowledge in that regard. How to implement game UI elements in 3D scenes as used in tactics games or an RTS games is really something.
I am thinking of an RTS game in particular and of some kinda marker on the ground indicating a location the units have to move to. How would I ideally implement such in a 3D game whose levels are made with GridMap? Would I make this another GridMap as well or are there any other (better?) solutions?
Thanks for your answer! 😘
And keep up you awesome work! 👍
Glad you liked it!
For the UI piece, the grid is just a simple plane with a grid texture on it. At runtime, I resize it based on the size of the map and adjust the UV scaling of the material so that it tiles the texture appropriately.
Any highlighted cells, such as when planning a movement path, are individual planes with a grid texture that get snapped to the right grid position.
For the logic side of figuring out where something should go, though, such as determining what cell a mech is in or what cells to highlight, the easiest technique is to use the world_to_map and map_to_world functions available in the GridMap class. These functions can automatically convert a grid cell to a world position or vice versa, and they don't require you to have anything at that location in the GridMap.
So in your RTS example, if I know I need a marker at a certain cell location, I can use map_to_world to give me the center of that cell in world coordinates so I can spawn an object there. Hopefully that helps a bit.
could you elaborate on how you setup these animations. im still not sure how to setup an animation that includes variable conditions like distance based timing or having differnt users and targets.
My typical approach is that if an action doesn't fit nicely into a pre-canned animation, I use an "escape hatch" of sorts to perform the action programmatically instead of with any of Godot's animation-related nodes.
Ex: A punch plays the punch animation and everything is fine because that animation is always the same. Movement, though, goes to a special node where the path to travel is animated over time, the unit is moved and animated along that path, and callback is used to signal when the action is over.
@@TheShaggyDev I see! I think I understand that now. thank you.
AMAZING VIDEO! thank you so much for this, i wish every indie dev in the world did this LMAO.
Thank you! Glad you liked it, haha
Why wouldn't you make a course for intermediate game development using Godot like this one when you were taking about how you organized the game code?
I think it would be helpful since learners such as myself are trapped in beginners' tutorials, and when we try to make something beyond our scope of knowledge, problems begin to appear.
It's definitely cross my mind from time to time. Would just need to think a fair bit on what it should look like and how I would want to do it.
@@TheShaggyDev Any updates Guru of the codes?
@@Retro-Future-Land I'm afraid not. It's still something I'd like to look at at some point, but just haven't had the time to get something of that scale together. Open to suggestions for content ideas if/when it does happen, though! At the very least, stuff like that will end up on the channel at some point.
Awesome work. BTW, your Text Version is showing Bad Gateway.
Thanks! Yeah I just found out my host is down right now. Convenient timing with a new video drop... Bout to send a wider message out.
nice, the ADT!!! @15
I turn the music off in every game. it detracts from the sfx anyways
you gotta give us shots of you making the sounds... part... thanks
Is there a way you can reproduce how you created the grid movement?
@@alexi2706 I had to set it up manually with AStar2D as this was made in 3, but in Godot 4 you can use the AStarGrid2D class to do grid-based pathfinding. I have a video and article on that if you're curious. The important thing to keep in mind for this game is that the logic is all 2D, despite the visuals being 3D. The vertical axis plays no role in game logic so I'm able to use 2D pathfinding and logic to manage everything.
Good video
Thank you!
Nice video. Very insightful. One question: When you go through the effects for each action you're using a switch statement to distinguish between effect types. Do you prefer this solution to an interface or inherited method on each effect or was it just the simplest and quickest solution you came up with for the jam?
What I mean when I say interface method is a method that is implemented on each effect so when you loop through all of the possible effects you can just call it e.g. effect.apply() where apply() is overriden for each effect type.
I'm fairly flexible, though I typically have a preference towards interfaces if there's much complexity involved because I like the organization of code that offers. The switch statements in this game kind of just came about as a side effect of:
1) Just coding things up as quickly as possible due to time constraints of the jam while not making a complete mess of it
2) How I implemented action planning in the action resolver, which lazily relies on exiting the loop early to process but could / should be done a different way
3) The fact that everything inside of the switch statements is a one line call. A switch statement is easy to manage and expand upon, but if there was any more conditional logic than what exists I'd have gone ahead and broken it out into proper function calls
@@TheShaggyDev Thanks for the insight. Point 3 makes a lot of sense. Switch statements often start out simple, but over time grow into monsters.
@@ironbytes Yep! Completely agree! Gotta be careful with them...
I'm really impressed how well this looks. I tried doing a tactical game in godot, and pathfinding straight up did not work for me lol!
Haha, thanks! Yeah the 3D to 2D conversions of everything definitely took some time to figure out. Pathfinding went smooth enough for me, but even in the final release the mechs sometimes turn in the wrong direction when turning, resulting in them doing a big spin before they face the right direction :D
Excuse me, but to draw the grid lines on the map, do you use a shader or do you just draw the lines?
It's just a mesh with a texture on it. No shader necessary.
@@TheShaggyDev Thank you
I'm not understanding why you wouldn't use a single grid.
What is a grid ?
How is a grid?
can i ask what's the importance of adding the return void to each function? is there a reason for it?
Just to enforce typing. It let's me know later on not to expect anything from a given function, and by explicitly declaring it the editor will also be able to tell me that with its code hints.
@@TheShaggyDev oh okay that makes sense.
Can you explain the issue with the grid map I'm not sure I got it
It seems to be fixed in Godot 4, but in 3 I would often get weird errors from the engine when switching between multiple GridMaps in a scene. Like, I'd be editing the level layout with my Level Gridmap, switch to my Mech Gridmap to place units, get an error in the console, and then have tiles from the Level Gridmap appear in my Mech Gridmap. It was like the engine was expecting there'd only ever be one gridmap in a scene. I'd typically have to restart the editor every time I wanted to change which gridmap I was working with otherwise I'd be at risk of getting an error.
how to highlight gridmap cells in mouse hover ?
For this game, since each cell has the same height, I do a raycast from the mouse position on screen to a plane in the world, using the camera to project the mouse position into 3D space. This Q&A has some discussion and code for the technique: ask.godotengine.org/25922/how-to-get-3d-position-of-the-mouse-cursor
Excuse me, but how do you apply an astar2d to a 3d map? Do you apply invisible tile2d to it?
In this case, since the entire game is on one plane, I just ignore the vertical (Y) axis for pathfinding purposes. No tiles or anything like that needed.
@@TheShaggyDev Thank you
@@TheShaggyDev I don't understand you saying: "Since levels are composed of GridMaps, that also made it easy to load data into Godot's built-in AStar2D library to build out pathfinding".
How can we link the 3d gridmap with astar2D?
@@longuemire748 Sure, let me see if I can explain a bit more in depth. GridMaps are 3D, but I don't care about the vertical axis in this game, so I can ignore the Y-axis and treat the map as 2D for most purposes, including pathfinding. So for Astar2D, I take the X and Z coordinates of a cell from the GridMap, which are the two axes that represent the horizontal plane in 3D space, and directly tie those to the X and Y values of locations in AStar2D, which are the axes used for 2D space.
So an example conversion might be: This cell is at 3D position Vector3(1, 2, 5), which is equivalent to the Astar2D location Vector2(1, 5)
@@TheShaggyDev Thanks, I understand:).
Why is that mech's element "gun"?
Hey, why is it commonplace that you can't act THEN move? If there's a logical reason for this decision, I'd love to know!
It's kind of just conventional to prevent hit and run tactics. Otherwise you could end up in a situation where a unit damages you and then runs out of range. Instead, if you end movement after shooting, you have to plan where you want to attack from since you have to commit to that position for a turn.
What's an 'Action Resolver' node?
That's just a Node object with a custom script I use to parse out a pending action and resolve it.
@@TheShaggyDev Thanks. The game is great BTW Very addictive.
@@MikeMcRoberts Thanks for checking it out! Glad you enjoyed it 😁
This was an awesome video to watch! I’ve been trying to get a couple RUclipsrs together to do a little game jam sometime and would love if you joined!
Sure, I'd be open to that!
Make an Evangelion DLC and take my money !
12:26
why do you pronouce it "ekspecially" though
Ha, just a mispronunciation. It was a long script so this happened several times, just didn't catch this one in editing.
Actually, it's pretty fine for mobiles.
Lighting is definitely better in Godot 4.
Elemetals has a better ring it.