Military RTS [my attempt at large scale battles]

Project is only a week and a half old. My job means I usually don't have time or energy to work on it. But I get a kick out of it, and figure this will help motivate me to keep progress.



The basic idea is simple : Player is the commander in charge of the battle. You tell squads where to go, and they get there (staying as a group and moving tactically). When a squad finds an enemy squad you lose control over it and the squad begins attempting to kill the other squad. When the firefight is over you gain control over the squad again.
Overall goal is to have a cool looking firefight game with as many units as possible.


Right now there isn't much, but every time I sit down there is more.

Things Done​

-Basic squad selection and movement (Few issues with it, messy, but works)
-Squads move together, assigns positions (Should be easy to add logic for enemy positions)
-Efficient sound (gunfire is a single 10s loop of wind for every gun, rather than a sound for every gun)
Very proud of this one, listen carefully and you can kind of hear the sound of wind with a lot of guns going off.
-Unit movement and rotation now work together, avoids use of FixedUpdate Update.
-Recycle system(Things like muzzle flashes are recycled instead of constantly created and destroyed)
-Unit Death (Truly a feature to bring the masses!)
-Unit Targeting (Looks for units in vision. Adjusts vision occasionally. Adjusts targets if squad mates see close enemies)

Things Not Done (for first real demo)​

-Enemy Squads
~~~~~basics added, enemy squads exist and detect enemy squads.
-Better terrain, scene
-Unit collision (easy to overlap squads ontop of squads)
-Squad moving with danger areas in mind (puts units in cover likely to protect them, more units looking at danger areas)
-Improved squad positions (closer to cover)
-Move units from GameObjects and into their own class. This will help with large counts of squads. Same with mesh.
-General UI (including pathfinding)
-Fog of War
-Enemy and friendly AI (some kind of over-ruling AI that dictates general battle flow as well)
-Improved Pathfinding (Eventually I want battlefields in km+ size.)
Will require me to have my own solution just to understand behind the scenes

 

Right now there isn't much. Honestly getting that youtube video up was the hardest part of this whole project. But every time I sit down on it there's a little more down. Holy hell did youtube compress the ever living S*** out of this video.

The video shows off 2 major things : The sound (I love how easy it was, and how easy on performance it is) of guns going off, and the squad movement. Right now movement is very jittery, but the basics are there.
I have a system that moves the squad forward, a system that assigns them a position that works, and this system will take things like danger areas (other squads) into account.
http://youtu.be/qwzkipUsZ40

Now with that said, I have 2 big goals with combat.
1 is the scale of it : I want the player fighting to keep control of what is going on. I want this game to have a ton of units moving against each other, while not feeling too cheap about it. If I can get hundreds of soldiers at once, awesome.
2 is the lack of control. You can tell squads where to go, but now how to set up. When they face the enemy you lose control over them : the squad will begin to move on it's own to kill the enemy. Another way is once the player takes enough casualties, the game's speed will rapidly increase (3x, 4x?). The whole point of this transition is to throw the player off. Information overload, ect.

 

Slow work continues, it was hard to get back into after a week break.

I added the basics of enemy squads in preparation of shooting at them. I want a lot of units, but next to pathfinding having a unit figure out what it can shoot at is pretty darn difficult to efficiently.

What I have gotten done was redoing movement and rotation - looks much better when they move around the scene.
A recycle system : I have a pool of muzzle flashes and dirt impacts I reuse over and over, instead of creating 1 and destroying it shortly later.
Basic enemy squads. I have a simple script that sends them around randomly, player can't control them, ect. It's not much, but it's one step forward to shooting at each other.

And the real big one, was making it so when units stop they face an intelligent direction. You don't want units facing a wall. You don't want them facing the center of the squad. You don't want them looking at another squad. You DO want them looking at areas of enemies. Figuring this all out with doing as little work as possible was difficult. The current way isn't perfect, but it's a good start.


Friendly forces are at the bottom. Enemy forces are at the top right. They stick near cover, and look in the direction of enemies while preferring not to look right at a wall.

 

I really like the gunfire sounds in the video, moving the squads via one big central box is a nice concept as well.

 

Actually the Graphics are quity nice, only the very boxy soldiers can be improoved...
Anyways, nice game you got there.

 

And now units can see enemies. No damage or death yet, and I have not accounted for how visible units are to each other.


Each unit looks for enemy squads in his field of view. It than looks at each of those squad's units to see if they are in his field of view. Lastly I do an actual raycast to see if I can see the unit. When a unit stops moving / loses a target, it does this check rapidly. Each time however, it will take longer between checks.
The idea behind that is not only is it less checks (more fps) in the long run, it also means 2 things.
1: When I add a cover value to each unit, a unit might be looked over the first few search attempts, than be caught later on.
2: A unit hasn't moved and hasn't shot anything (aka turtling) may only search for enemies once every 20 seconds. An enemy who just stopped moving is searching for his enemies every 0.2 seconds. The guy who just stopped moving is much more likely to spot his enemy.


I think I do need to step back though and look at what is going behind the scenes - the way units are told to move around is a little whonky. The logic for where units move to could be more spread out. I also need to start thinking about having a movement AI that handles moving squads towards the enemy without being suicidal. Or at least the basework for it.

FPS desktop test is awesome. Each squad is 20 units. I zoomed out to view all the units.
4 squads moving and shooting : 480-500 fps (hanging at 495~)
15 squads moving and shooting :440 -450 FPS (hanging at 444~)
30 squads : Was doing good, I saw it low at 370 but it was hanging about 410. Than suddenly, Z fighting and 2 of the sounds that handle gunfire went quiet. No idea what happened, thank god for logs. I'm going to guess it has something to do with my recycling pool of 256 gunfire effects.

 

Nice game you are doing. The idea is original and the system looks like it can manage a full sized battle with realistic numbers. One thing i noticed from the video, when issueing the order to move you should be able to trow a waypoints instead of a single destintaion point. You know to have more control on how troops aprouch a location. Also the player as the commander should recive updates on the states of the squads so you don't forget to use a unit. (happens all the time)

 

Hey Windexglow2, I'm wondering how you structure your squads? I'm working on a squad-based RTS as well. Each squad has 4 'units' within it. I have the animations and movement scripts all setup and functioning perfectly (well, nearly) but I'm having a hard time moving them as a squad.

The way I have it structured now is with an empty GameObject (called Squad) that contains the Squad script and then 4 child empty GameObjects within the Squad GameObject. I'm using the 4 child objects as place holders for when I send the Squad a new destination (right click) that way each unit will move to their respective position. Both the parent and child objects move to the destination with no problem (and rotate to face the desired direction). The problem is that I need a GameObject for the whole squad that remains with moving units in order to select the squad when moving. I tried another parent object but then the rotation for each of the 4 children goes all crazy.

I'd greatly appreciate any advice you can offer on how to structure the objects and give them a destination (and direction). Thanks.

 

Your question is a little confusing : So I'll just talk about how I handle the movement of the squad.

I have a faction, which have squads, which have units. It works on the princible that the more I can filter, the faster everything will be.

For selection, I have just a general box that is averaged to the units positions. The squad stays as a (for the most part) consistant group. Never will a fireteam rush out, nor will it ever seperate itself to take an objective. It always stays as a tight group. When the player's mouse clicks on this box, he selects the squad. (Since only 1 squad can be selected, units share the actual selection graphic with each other)

Now with the actual order, this is kind of multi-step.
Step 1 : It creates an imaginary path from the current squad center, to where you want them to go.
Step 2 : I optimize the path (basically every 15 meters is a new point).
Step 3: I now have a path. Each point in this path is a major area where we send units to.
Step 4 : A loop function sends 4 units to the next point. I move the point forward when half of the squad has reached the current objective point. This means the squad is always kind of bounding forward.
Step 4.1 : When a unit is told to move somewhere, it creates it's own path for it. Short paths == much faster than long paths.
Step 5 : Eventually all units reach the final objective, and the order is now done.

I handle unit rotation with a self-looping yield function. Basically I tell the unit to face a direction, and every 0.2 seconds it rotates closer to it until it is exactly at the rotation. When it reaches that (or a new rotation is needed) the function stops looping.

 

Sorry nevermind, after watching your video I got an idea to make the 4 destination transforms into an object of the mouse controller, leaving the ability to easily have a separate object for the Squad.

 

So I'm using this post as a kick in the butt. Finally have a few days of free time after being flown every other day for my job.

Right now units can see and shoot each other : But I want to add a value for how visible a unit is to each other, which is used for how fast units will see each other (right now it is instant, with visibility values it could take seconds). I think visibility (for now) will be based on soft cover and vegitation. So order of checking enemy units goes like this

Enemy Squad in vision-cone -> Enemy unit in vision cone range -> Raycast to enemy-> Sort remaining units based on visibility -> First X units have dice rolled based on visibility. Success means we start shooting at this unit.

Units moving, in the open, recently fired, and so fourth are more visible. To get the visibility I'm thinking each unit stores it's own 8-directions of visibility : If someone needs to check visibility from a direction (and it hasn't' been update it) we update it, instead of updating all 8.

----
Now when we shoot at a unit, a bullet is placed around it. That than grabs enemy units really close to the predicted bullet impact, and I will than do a more complex cover-calculation. If the planets are aligned than I may adjust the impact to before some sandbags, instead of on the unit. This means units behind soft cover will have less bullets hitting them.

I got all weekend to work on this bitch, let's see how much I can do.

 

Hey Windexglow2, I was wondering if I could get your opinion on something I'm working on as well (in addition to the squad movements).

I have vehicles moving around a city (the city is essentially a grid) and I'm having big problems with Unity's navigation since it both wants to immediately rotate a vehicle and make it face the destination (obviously that can be turned off) and also causes the vehicle to begin moving in that direction. Realistically the vehicle would move forward and make a turn (either u-turn or move to the end of the block then turn). My plan is to have each street/ave intersection have empty objects as sort of way points and then just move the car through a loop cycling through the street/ave numbers. So basically you check if you're currently on a street or avenue then based on the destination (which would also return a street/ave coordinate) just move so many number of streets then over so many number of avenues.
I'm not really sure I need Unity's navigation at all for this really since once the car is on the right street/ave I can move it over to the exact Vector (though the navigation could still come in handy to help avoid any obstacles on the street.
I'm sure you're pretty busy but any kind of feedback would be greatly appreciated. Thanks.

 

Vehicle navigation is a pretty common thing, and anything common is going to have tutorials and papers all about it online. Here's one(I'm hoping you haven't already done this homework)
Here's a single track design, but a lot of the path (and waypoint idea) could translate well into a multiple intersection city.
http://www.ijmlc.org/papers/82-A1090.pdf

Unfortunately it's going to take some work, but if you make your own pathfinding you'll really know the ins and outs of it.
Obstacle avoidance could be better suited to simply checking in front of it for anything in the way, and working to avoid it (either by stopping, changing lanes, or completely swerving). This is also something that has a ton of papers and tutorials online.

You could do a series of nodes : Between each node is a Bezier Curve. Vehicles first move from node to node to reach their end point : While between nodes, it matches it's position onto the bezier curve. You can have straight roads and bendy roads. Of course making roads flow into each other correctly is a beast in and of itself.

 

Wow, that's a lot to consider. I'm basing the city on New York so hopefully making roads flow into one another won't be a major issue (since it's all a grid) but at this point I really have no idea.
Big thanks for the feedback.

 

Unit Death!

60 VS 20, even with cover on the defending side it was very 1 sided. Now the fact that I did spurts of work over 2 weeks (and usually with a few beers) means my code is spotty all over the place. I added in unity death pretty quickly and there are still a few minor bugs with it. I need to think about how units acquire new targets when they already have one. Also with acquiring new targets when they have none (Squad being decimated? Guess I should keep looking in another direction). Units also need to move under combat better - If there is cover nearby, they should get to it.

But it's progress, and that's awesome.