Not yet a game announce, still a lot of work to do.
But here are the results from some experimenting I am doing with implementing a classical Fallout-style gameplay/combat engine, where you swap between live and turn based control, depending on the situation.
It's very basic at the moment. No collision detection and only knives as weapons. But it didn't take too long to get it to this state (I started it yesterday).
Now to start thinking about collisions, which will necessitate better AI, pathfinding and in the end, line of sight blocking. Also, support for ranged weapons, multiple enemies (expanded system for combat turns, who goes when).
Afterwards I might turn it into a small fighting-focused game (before, eventually, trying to build a full-fledged RPG game on it).
Here I am showing another facet of my experimenting. Apart from the textures being changed, each tile is also assigned values. Right now the main value is whether it is walkable or not (whether it restricts movement). But it can easily be expanded to terrain cost etc., depending on the game. I will show practical effects of this once I finish implementing a movement system that readily reacts to these values (at the moment the movement bricks when checking for walkability, for some unknown reason).
I have finally made some inroads on collision detection and basic pathfinding. It took me some time to crack the code on this one, because for this to work, you need to add 1 with each step number, but you need to avoid all the obstacles and tiles already assessed. On top of that, you cannot keep track of the step number using a global attribute, since the step is directly dependent on the parent of the current tile -- that's how you can start figuring out not only how to get somewhere, but what is the shortest way.
The only thing I'm starting to notice -- and I hope it's just my old hardware, not GameSalad -- is that it's relatively slow, which could be a problem with bigger maps.
Enjoy!
Braydon_SFXMember, Sous Chef, Bowlboy SidekickPosts: 9,273
Looks great - though, do you need to create a new thread for each vid? Why not stick with one?
Having said that - this looks fabulous. Really. Are you using Stormy's Pathfinding to do this? Top notch!
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
@pHghost I'm going to merge all of your threads. as a good rule of thumb. if what you are posting is a "follow up" then it almost certainly belongs in the same thread that you are following up too.
@tenrdrmer -- yeah, that's fine. I made separate threads because each video was about a completely different aspect of the process so far, but I understand why it is better to keep them all together.
It's a custom-built system. I was thinking about utilizing @StormyStudio's Pathfinding, but once I started looking through it, I realized that with a feature this complicated, it would be much easier to make something myself than to try and understand someone else's GS logic.
It also allowed me to optimize for the specifics of my random map generation.
One of the things that I do quite differently (and it's also a minor departure from A* ) is that a vast majority of the calculation is done on all the separate tiles themselves, instead by a moving A* node. Only time will tell if it is faster than traditional A* or not. It might actually prove to be very inefficient on bigger maps, since it is essentially scanning the whole map (I will try to optimize that, and cut the scan on finding the target tile).
I will do a speed comparison between the two systems once I finish implementing full pathfinding.
Updated! I've finished implementing the pathfinding. Here is a synchronized comparison of the speed side-by-side with @StormyStudio's A* Pathfinder. I am very happy with the results, to say the least.
I ended up moving a chunk of the calculation into a dedicated pathfinding controller (though the scan is still decentralized and multi-directional, unlike A* ), because it meant I could much easier cut the calculation once the target tile is found, so I'm no longer scanning the whole map. This results in an added speed benefit.
Optimization succeeded! I managed to cut down the calculation time to roughly 50% of what it was previously. Also, I finished working on feeding all the pathfinding data back into the actor, to make him move around.
I rewrote the project for iPad size (maintaining the same tile size as on iPhone) to test it in a more taxing (i.e. bigger) environment.
Long paths take noticeably longer to calculate, but due to the fact that I built in a stop scan once the target tile is found, short paths are as quick as in the iPhone project. Part of the reason it takes some time to do the calculation is I needed to manually limit the speed due to a quirk in GS. I'll likely post about the quirk later on.
Here's a video:
Braydon_SFXMember, Sous Chef, Bowlboy SidekickPosts: 9,273
Holy Moly - That's brilliant! Absolutely love it! Man, I'd pay money for that. I bet there's great logic in there. Great job man!
@Braydon_SFX -- thanks a lot! I'm quite proud of the logic. It all is still a little rough around the edges, some quirks here and there, and also there are some GS related issues.
One of example is the problem in the current build of GS with calling on table rows by their name, which seems to be broken. This means I have to have two coordinate systems, GS actor XY positions and tile XY coordinates (so positions 60:60 and 1:1 respectively are the same position). In the pathfinding logic, I need to convert between these quite often, and also with some actors (like the player) to constrain a conversion calculation of these values. Firstly, it slows things down a little, no doubt, but mainly I had to hard-code some logic in for it to work consistently, which is dependent on the number of tile rows and columns -- converting the project to iPad was more complicated than just spawning a larger map. And if you don't know where to look to change things, it's frustrating trying to get it to work.
Once the different quirks are ironed out (some on my side and some on the side of GS), to make it a very user-friendly template that can be reasonably well understood and adapted (map size and tile size changed, with the logic reacting to that), I'll definitely work in some documentation and release it. So sit tight!
Comments
Very impressive! @pHghost
Thanks, @FallingBoxStudios!
It's very basic at the moment. No collision detection and only knives as weapons. But it didn't take too long to get it to this state (I started it yesterday).
Now to start thinking about collisions, which will necessitate better AI, pathfinding and in the end, line of sight blocking. Also, support for ranged weapons, multiple enemies (expanded system for combat turns, who goes when).
Afterwards I might turn it into a small fighting-focused game (before, eventually, trying to build a full-fledged RPG game on it).
Bump for our US brothers and sisters.
Nice - big Fallout fan here
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Me as well. That and Fire Emblem. I would love to bring those two together and make a super-RPG out of that.
Here I am showing another facet of my experimenting. Apart from the textures being changed, each tile is also assigned values. Right now the main value is whether it is walkable or not (whether it restricts movement). But it can easily be expanded to terrain cost etc., depending on the game. I will show practical effects of this once I finish implementing a movement system that readily reacts to these values (at the moment the movement bricks when checking for walkability, for some unknown reason).
Very cool, I can imagine a lot of people will be interested in that.
http://jamie-cross.net/posts/ ✮ Udemy: Introduction to Mobile Games Development ✮ Learn Mobile Game Development in One Day Using Gamesalad ✮ My Patreon Page
Wow! That's fantastic! Love it!
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
awesome!
✮ FREE templates at GSinvention ✮
✮ Available for hire! support@gsinvention.com ✮
I have finally made some inroads on collision detection and basic pathfinding. It took me some time to crack the code on this one, because for this to work, you need to add 1 with each step number, but you need to avoid all the obstacles and tiles already assessed. On top of that, you cannot keep track of the step number using a global attribute, since the step is directly dependent on the parent of the current tile -- that's how you can start figuring out not only how to get somewhere, but what is the shortest way.
The only thing I'm starting to notice -- and I hope it's just my old hardware, not GameSalad -- is that it's relatively slow, which could be a problem with bigger maps.
Enjoy!
Looks great - though, do you need to create a new thread for each vid? Why not stick with one?
Having said that - this looks fabulous. Really. Are you using Stormy's Pathfinding to do this? Top notch!
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
@pHghost I'm going to merge all of your threads. as a good rule of thumb. if what you are posting is a "follow up" then it almost certainly belongs in the same thread that you are following up too.
@tenrdrmer -- yeah, that's fine. I made separate threads because each video was about a completely different aspect of the process so far, but I understand why it is better to keep them all together.
@Braydon_SFX -- thanks!
It's a custom-built system. I was thinking about utilizing @StormyStudio's Pathfinding, but once I started looking through it, I realized that with a feature this complicated, it would be much easier to make something myself than to try and understand someone else's GS logic.
It also allowed me to optimize for the specifics of my random map generation.
One of the things that I do quite differently (and it's also a minor departure from A* ) is that a vast majority of the calculation is done on all the separate tiles themselves, instead by a moving A* node. Only time will tell if it is faster than traditional A* or not. It might actually prove to be very inefficient on bigger maps, since it is essentially scanning the whole map (I will try to optimize that, and cut the scan on finding the target tile).
I will do a speed comparison between the two systems once I finish implementing full pathfinding.
this is pretty neat. I would love to see a whole game come from this.
@gamestudent -- cheers!
Hopefully it will progress there, through it might be some time, we'll see. If it does, I don't think it will stop at one.
Updated! I've finished implementing the pathfinding. Here is a synchronized comparison of the speed side-by-side with @StormyStudio's A* Pathfinder. I am very happy with the results, to say the least.
I ended up moving a chunk of the calculation into a dedicated pathfinding controller (though the scan is still decentralized and multi-directional, unlike A* ), because it meant I could much easier cut the calculation once the target tile is found, so I'm no longer scanning the whole map. This results in an added speed benefit.
@Braydon_SFX
Working on optimizing (speeding it up) and finishing up actual movement!
Optimization succeeded! I managed to cut down the calculation time to roughly 50% of what it was previously. Also, I finished working on feeding all the pathfinding data back into the actor, to make him move around.
I rewrote the project for iPad size (maintaining the same tile size as on iPhone) to test it in a more taxing (i.e. bigger) environment.
Long paths take noticeably longer to calculate, but due to the fact that I built in a stop scan once the target tile is found, short paths are as quick as in the iPhone project. Part of the reason it takes some time to do the calculation is I needed to manually limit the speed due to a quirk in GS. I'll likely post about the quirk later on.
Here's a video:
Holy Moly - That's brilliant! Absolutely love it! Man, I'd pay money for that. I bet there's great logic in there. Great job man!
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
@Braydon_SFX -- thanks a lot! I'm quite proud of the logic. It all is still a little rough around the edges, some quirks here and there, and also there are some GS related issues.
One of example is the problem in the current build of GS with calling on table rows by their name, which seems to be broken. This means I have to have two coordinate systems, GS actor XY positions and tile XY coordinates (so positions 60:60 and 1:1 respectively are the same position). In the pathfinding logic, I need to convert between these quite often, and also with some actors (like the player) to constrain a conversion calculation of these values. Firstly, it slows things down a little, no doubt, but mainly I had to hard-code some logic in for it to work consistently, which is dependent on the number of tile rows and columns -- converting the project to iPad was more complicated than just spawning a larger map. And if you don't know where to look to change things, it's frustrating trying to get it to work.
Once the different quirks are ironed out (some on my side and some on the side of GS), to make it a very user-friendly template that can be reasonably well understood and adapted (map size and tile size changed, with the logic reacting to that), I'll definitely work in some documentation and release it. So sit tight!
Genius!
I'm a bit late to the party... great work... I'd love to see the logic on this... :-)