Mouse clicking to move RTS units inside buildings and caves
by Gary Haussmann · in RTS Starter Kit · 09/08/2005 (9:43 am) · 1 replies
Hi all, I'm looking at how to allow semi-autonomous characters/units move inside buildings and underground, hopefully by using mouse clicks.
In fact, I have the player controlling a group of FPS Player objects, but the movement and attacking is controlled by mouse-clicking, so the issue I am trying to address seemed more relevent to RTS style units. Also, I may start using RTS objects instead at some point.
The first solution is to zoom in the camera really close to the characters, so that the player can see inside buildings and click on stuff inside them. The second solution is to switch into "first-person mode" similar to the possession effect used in dungeon keeper.
However, I would really like to try and allow the player to remain in a zoomed out, god-view camera mode to maintain a consistent presentation. The most successful method I've seen is to "fade out" the roof of a building so that players can click on things inside. A similar concept would work for the terrain, where the chunk of terrain that covers a cave or underground passage would fade out so you can click on places and things inside the passageway.
Anyway, the working concept I have to implement this is to mark parts of the play area as "fadable" and then fade those parts out when appropriate. Ray collision testing for mouse clicks would have to ignore the faded parts, while still providing normal collision for everything else. In terms of nitty-gritty coding, interiors would either have to be broken into two DIFs, one representing the fadable part, or perhaps I could allow certain brushes to be marked as fadable. For terrain, it seems as if I would have to add a isfadable" material or flag to the terrain data and allow designers to mark fadable terrain areas in the same way that they mark empty areas (for caves or whatnot).
Anyway, based on that, it seems as if I will have to modify code for both the interiors and terrain, and change not only the rendering sections but also the collision detection. Since the TGE code for interiors and terrain is much more, er, "challenging" than some other parts of the engine, I'd appreciate some comments on the feasibility of this proposed solution. Is this experiment going to end in tragedy for me? Is there a better way? Or should I just forget the whole thing?
Thanks,
Gary
In fact, I have the player controlling a group of FPS Player objects, but the movement and attacking is controlled by mouse-clicking, so the issue I am trying to address seemed more relevent to RTS style units. Also, I may start using RTS objects instead at some point.
The first solution is to zoom in the camera really close to the characters, so that the player can see inside buildings and click on stuff inside them. The second solution is to switch into "first-person mode" similar to the possession effect used in dungeon keeper.
However, I would really like to try and allow the player to remain in a zoomed out, god-view camera mode to maintain a consistent presentation. The most successful method I've seen is to "fade out" the roof of a building so that players can click on things inside. A similar concept would work for the terrain, where the chunk of terrain that covers a cave or underground passage would fade out so you can click on places and things inside the passageway.
Anyway, the working concept I have to implement this is to mark parts of the play area as "fadable" and then fade those parts out when appropriate. Ray collision testing for mouse clicks would have to ignore the faded parts, while still providing normal collision for everything else. In terms of nitty-gritty coding, interiors would either have to be broken into two DIFs, one representing the fadable part, or perhaps I could allow certain brushes to be marked as fadable. For terrain, it seems as if I would have to add a isfadable" material or flag to the terrain data and allow designers to mark fadable terrain areas in the same way that they mark empty areas (for caves or whatnot).
Anyway, based on that, it seems as if I will have to modify code for both the interiors and terrain, and change not only the rendering sections but also the collision detection. Since the TGE code for interiors and terrain is much more, er, "challenging" than some other parts of the engine, I'd appreciate some comments on the feasibility of this proposed solution. Is this experiment going to end in tragedy for me? Is there a better way? Or should I just forget the whole thing?
Thanks,
Gary
Torque 3D Owner Stephen Zepp
Other than that, it will depend on your coding/design skills, and time--as you obviously are aware, this isn't trivial work, but I don't see anything majorly flawed in your idea or top level design.