What I did
I managed to wrap up the leftover tasks from last month fairly quickly. I now have a better placeholder for the title screen. It’s not great, but at least it’s not black any more. I’ll sort out something better when I’ve settled on an art style. The character details box is also hidden when you start the game, and disappears when you click on it. Each character’s name appears just above their health bar too, and it points towards the camera using the same code that controls the health bars.
I also did some much-needed improvements to how I use git. I updated the project’s ignore file to ignore all automatically generated files, and then removed a lot of large and unused files. Should make this easier when/if I start working with other people on this. I also created a new development branch for any day-to-day work. I’m already checking in my work on a more regular basis, but now I don’t need to worry about not having a stable version I can share with others.
The most important task this sprint took a bit of thinking about at first, which was stopping characters from walking across open air to go from building to building. I had all sorts of crazy ideas about how to fix this, invisible barriers around the upper areas of each building, blocking attempts to move through unless another barrier also existed. Like I said, they were pretty crazy. Thankfully I came to my senses and realised all I needed to do was make sure that there was a walkable platform along the path the character wants to walk along. Turns out that it’s pretty easy to do a Raycast from the character to the platform directly beneath them. In the end I managed to get this done within a couple of hours.
I did a lot more refactoring of my code too, tidying it up wherever ReSharper found issues with them, and refactoring out whatever I could into smaller methods and external classes. There’s always more work to be done, but as long as I keep doing this little by little every sprint I’ll get it looking more complete in the end. I also wrote another 9 unit tests to cover some of these, and I’ve got a few more areas lined up which need some serious unit testing next sprint.
What I didn’t do
The one item I didn’t get manage to complete was creating a gap in the scenery when it’s blocking where you want to click. You can still click past scenery to get there, but in some cases it’s difficult to see that area. I did some looking up around this area, and the closing thing I could find was a guide to use a Projector which projects a hole onto the scenery (in this case, from the camera to the mouse cursor). It would take some effort to get this working, and a bit more to get it to stop when it hits the current level which the player’s on, but I’m not certain if this is the route I want to go down. What would be nice is the effect you see in some other games, such as XCOM, where the building’s walls drop away as you try to select areas behind them, but that sounds like it’s going to involve even more work and possibly some special building models. I’m going to have to think a bit more about what I want to do with this before I start implementing it, and I’ve decided to take it off my to-do list for now.
What I will do next time
This sprint I’d like to tackle one thing that’s been bothering me about aiming. Right now when you aim at someone it treats every Raycast which encounters any scenery as cover. This works fine if the enemy’s behind cover, but if it’s you behind cover then it shouldn’t count as cover for the other guy. Cases where you’re behind some sort of grating, or maybe a bulkhead with a few strategic gaps should let you comfortably fire shots out, while giving only you with a good cover level. I’ll need to do a bit of research to see how to do this fairly, but there’s plenty of good resources available. I’d also like to increase the number of checks performed to see how much cover a character’s behind, although that won’t take very long.
With that done, the main focus this sprint will be getting some sort of basic multiplayer mode working. I’ve been told this is pretty straightforward to do in Unity, but haven’t begun reading around that area yet. By the end of this sprint, I’d like the game working on 2 different machines, with each player able to control 1 team only. Then after the game is over, each player is shown the win or lose screen as appropriate. I’d also like for the character details for each team to only be viewable by that team’s player, leaving figuring out the stats and weapons used to examining the examining the battlefield and the characters. As there’s no visible difference between the team members currently, and the weapons aren’t even shown on the model, I’m not sure how well this will work. If it gets too irritating then I’ll go ahead and do this work anyway, but leave it turned off until a later time.
It turns out that they’ve completely redone the networking functionality in Unity 5.1, apparently for the better. I’m going to take a bit of time to read up about this first but it doesn’t make sense to do a whole bunch of research and developing in Unity 4.6, then have to redo it all when I move to Unity 5 later. If it turns out to be horribly broken, or have some other significant flaws then I guess I’ll stick with 4.6 but it seems unlikely. As I’ll have to redo some set up to get Unity 5.1 working I might as well update to Visual Studio 2015 at the same time so I don’t need to start worrying about that a few months down the line.
Finally I need to spend some time fleshing out the setting and backstory of the game world. I’ve got some rough ideas and a few drafts, but believe me when I say they’re rough. If I want people to help out, especially with the art, then they’ll need to know more about the setting and what sort of art style would be appropriate. I’ve found in my early write-ups that it’s easy to come up with very specific ideas about what I want, then alter the backstory to fit that in, but that also results in some really janky background that feels kind of forced. What I should do is update the backstory and think about what sort of world that might create, then see if that sort of world would make a good setting for the game. It’s going to take a lot of drafts though…
As always, you can see my current Trello board here.