(RTS) How to make RTS mechanics with C3 tools?

0 favourites
  • 7 posts
From the Asset Store
Make your craft game come to life with this sounds :D
  • Dear developers!

    Thank you for making Construct accessible and understandable for people who want to create games but have difficulties in programming.

    You've added a lot of powerful tools, behaviors, and other features to your beautiful engine that are not only time-saving, but also user-friendly. However, for 4 years I have not been able to find a solution when implementing RTS projects, when units can search for a path and adequately move in formation.

    I've looked through a lot of topics and tried to find solutions to the unit sprite overlay problem for a long time, but I haven't found anything suitable and similar to the behavior in the classic games like WarCraft 2, C&C, Settlers, KKND, Dune. These games are many years old, but I do not know how to create something like this in Construct. The behavior of "pathfinding" is not at all friendly with "Solid" and you have to make complex combinations of different behaviors and tricks so that units can move in formation, surround the target or block the path. To be honest, I'm not happy with the result and I'm very upset, why can't I make a game in Constuct similar to the old RTS games?

    If someone can convince me otherwise, I will be infinitely happy and grateful...

    I also want to pay attention that I am not alone in finding a solution to this problem, you can find on your forum a lot of topics that raise this issue, as well as in my native c2community.ru people are also trying to find solutions. But, in the end, everyone has to use the available mechanics instead of the one they actually want.

    At the moment, I come to the conclusion that Construct is not suitable for creating games in the style of classic RTS and the best solution is to change the engine to Unity, since there are good examples for the mechanics of RTS.

    So I really ask you to rework the "Real Time Strategy(RTS)" template. This mechanics is absolutely crude and does not correspond to the logic of RTS. You offer users to improve it on their own, but adding their own features turns out that this mechanic initially creates a lot of problems. Is it normal that objects can pass through each other?

    Or add more settings to the "pathfinding" behavior. Because you can tell the object which obstacles to avoid, but in truth it does not work correctly and is not suitable for RTS.

    Thanks for your attention. I hope for your understanding and response.

  • There's two methods for using the Pathfinding behavior.

    The first method involves timing the objects with the behavior to go one after the other to end up at different positions that you must choose.

    The second involves the same method, but with only one object finding a path, and the "swarm" using that path. Its much more complicated in that those objects will use their own formulae to detect each other as well as bottlenecks, collisions, etc.

    The latter is extremely complicated, and entire books have been written on the subject.

    Don't use physics, don't use solid, do read a book.

  • This means that Construct does not have the tools to implement such mechanics?

    Or was it originally not worth using Construct for such projects?

  • The games you mentioned pretty much all had different implementations of pathfinding. Which one would you want to be default in construct? They all had different limitations and solutions, there isn't a one size fit all.

    Even Starcraft, which came significantly after some of the games you mentioned, used different pathfinding algorithms for certain units only, within the same game.

    Here's an example codeofhonor.com/blog/the-starcraft-path-finding-hack

    The reason you haven't been able to find a solution for the sprite overlay problem is because even the big name developers couldn't find a solution for it, they just designed around it and hid it well. Case in point, some units like air units and zerglings don't move in formation at all. They just lose collision with each other while moving, and spread out when they get to the destination. A good developer will focus on making a fun game look good, rather than get stuck on a specific requirement like non overlapping units that doesn't matter in the end anyways. See what this guy did - striketactics.net/devblog/starcraft-1-pathfinding-technical-analysis

    Here's another great article. tl.net/forum/starcraft-2/132171-the-mechanics-of-sc2-part-1

    Note that Starcraft 1 (Brood War) relies extensively on a* pathfinding, which is exactly what Construct gives you. How you implement it is up to you though.

    Swarming boids style movement used in Starcraft 2 can also be done using the 8direction behavior in addition to pathfinding. That's another huge topic as well, but that could be a specific thing that I wouldn't mind seeing added as its behavior in Construct. construct3.ideas.aha.io/ideas/C3-I-1680

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Its doable, but its complicated, and more importantly less financially viable than it used to be.(says the guy doing a tower defense game)

    Case in point I did a template a while back then removed it when there was zip interest.

    Here's the demo: construct.net/en/free-online-games/pathformers-1099/play

    Its the first type I was talking about, and its simple in concept, but horribly mathy.

  • I've looked through a lot of topics and tried to find solutions to the unit sprite overlay problem for a long time, but I haven't found anything suitable and similar to the behavior in the classic games like WarCraft 2, C&C, Settlers, KKND, Dune.

    As noted, the main issue is this is an exceptionally complicated problem that even the designers of commercial RTS games struggle with.

    This question comes up from time to time; see also my previous posts on it here and a bit of a longer explanation here (from way back in 2014!).

    As I mentioned back then, I have spent many hours on this in the past. If objects collide with solids, they get permanently stuck. If they collide with each other, they get permanently stuck. If they try to steer out the way, they will hit something else doing the same and they both get permanently stuck. If you try to have smarter evasion strategies, it still gets permanently stuck. Often the evasion actually makes things worse and causes gridlock, and all moving objects get permanently stuck.

    By far the easiest approach is to allow things to overlap each other (including actually ignoring solids, and only avoiding them when calculating pathfinding). Since Construct is aimed at beginners, this is by far the simplest and most reliable solution, which is why the template uses it.

  • Dear people.

    After much thought, I realized that I was wrong to state my claims to the Scirra team. Thanks to you, I changed my mind about the approach to the technical implementation of RTS projects.

    You helped me to look at the problem from a different angle and this was the reason for new ideas that I will try to implement in the future. Thank you so much for your patience and generous explanations.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)