Unity 5 is out! I've also finished roughing-in crews on ships for the upcoming unity release!
It took a little bit to get Unity 5 downloaded and installed due to some issues on Unity's website, but I finally got into it yesterday afternoon and I'm really impressed with it so far. The two things that I am loving the most is the 64bit editor and pro features in the free version! I tried out the pro version of Unity a few months ago during the Angular Destruction Unity Release
, which allowed me to do things like SSAO and see how atrocious my code was for CPU usage. Having those features again is very nice.
On to crews!
In this unity test, decks represent the different levels on the ships, with lifts in between. Just like the components, the decks, the lifts, and which decks are connected to the lifts, are assigned based on the name of their object. "deck_01" is a deck, and "deck_01t02" is a transition between deck_01 and deck_02.
Crew members can only move along the deck level in 2-dimensions. When assigned a new task on a different level, crew members check each available lift connected to the current deck, then that lift checks the deck it is connected to and then the lifts that are connected to that, and so on, until it finds the deck the the crew member's target component is on. After searching every possible route to the component, the script will pick the route with the shortest distance and use that to reach its target.
It should be understood that my method for pathfinding in Unity is going to be very different from how we'll do crew movement in BR. For instance, in my version of the pathfinding, the actual "deck" object is just a visual thing. There are no rooms, or walls, and there's nothing stopping your crew from going off the deck object, or through the ship.
Gabe is currently working on the way we're actually going to do pathfinding in BR, but for this Unity release, an approximation will have to do.
Now, as it turns out, having each crew member search through every possible route after every new task is given requires some CPU power. I didn't realize just how much until I tried out Unity 5's profiler.
I knew there would be some hitching due to this code but I didn't think it would be *that* bad. This spike was caused by ten crew members calculating their paths at once, but even a few at a time caused a noticeable hiccup. I thought of a couple ways to do it that might work better and faster, however, for now, I've added a parser that will add requests to calculate a crew member's path to a queue so that only one calculation happens per frame.
It's not the greatest solution, but it works for now and lets me get the feeling of crew without having to optimize it all that much.
Anyway, peoples on ships! I'm really liking how it feels to see crew scramble to repair components or man stations. What do you guys think?