What I did
Managed to get nearly all the UI reworked this sprint, with just a few minor things leftover. Of course, it’s all still placeholder work, but it’s looking much more well laid out now and will do until it’s reworked later, after finalising the design. It will do just fine for now though.
The first thing I did was start to work through an excellent free tutorial on UI development for Unity 4.6 which I found on 3DBuzz. There’s a lot of critical aspects to UI development that I didn’t know anything about, so it was pretty essential learning. With that knowledge it was fairly trivial to rearrange the UI elements so they were relative to the different areas of the screen, and just not a set distance from the centre. It won’t work at really low resolutions (well beyond what most people work at these days), and it should probably increase the button sizes after a certain point, but it’s looking better than it did.
After that the biggest task this sprint was to set up the Team Roster to keep track of the people on each team. I’d optimistically put this down as one task, but it became a bit more complex so I needed to break it down into 3 different tasks in the end. Now you can see everyone on each team (Team A on the left, and Team B on the right), with their current health displayed beneath them, and a blue border surrounding the current player. The “selected” border seems to reuse some of the character portrait which makes it look a little weird, but it’s not a major issue at the moment. It’s easy enough to see who’s no longer in the game from the health level, but I’d like to have an extra indicator to confirm when someone’s completely out of the game.
I also threw together a quick extra screen to display the character details. When you click on a character portrait in either roster it fills up with their details, which consists of their name, health, equipped weapon, weapon damage, and the basic range. Right now it displays the panel at the start, even when there’s no character selected, so that needs fixing at some point so it will open and close on demand. It should also only display details for the player’s own team, but there’s not much point in working on that part until after I’ve done some work on the multiplayer side.
I put a placeholder image up for the Win and Lose screens, and spent far too long searching for images for both. Even though it’s just a placeholder I still wanted something that passably worked, and it’s surprisingly hard to find a creative commons image about success that doesn’t involve business. I did find one in the end that’s only a little bit business-like, and I guess that’ll have to do.
I got the Unity Test Tools working and it turns out it’s required to run unit tests within Unity, which is why I was having so many problems before. The official tutorial on this topic was really helpful although it only talks about code-based unit tests from the 48 minute mark. I only wrote 1 new unit test, but when I ran the ones from last sprint 3 of them failed, leading me to discover a bug with my range calculations. I’ve barely started with unit testing and already it’s showing benefits. Later on I’d like to do some integration testing with UI, but for now I’ll stick with cleaning up the code. To aid with later, I finished refactoring the GameController class, splitting up into lots of small methods instead of several large ones. Now I just need to extract them out into a number of helper classes for unit testing.
The last thing I did probably isn’t interesting to a number of you as it involves source control. I took a look over my list of recent commits and I noticed that they share a certain pattern that makes them useless for keep track of changes. I realised I’ve been treating it like a glorified backup service when it’s so much more useful than that. Previously I was fixing issues, then checking a whole bunch of them in after a few days with a message such as “sprint 12 work”, with a few more comments further down.
I’m now changing that habit to check in each fix as I complete it, with a comment focused just on what that fix is, not which sprint it was for. As a result I’ve also removed the “to be checked in” column in Trello since it doesn’t serve much point now.
What I didn’t do
The character details panel appears when you start the game, although no information’s loaded into it. I had some trouble fixing this at the time and ended up leaving it to focus on other issues, but it’s annoying enough that it needs dealing with quickly. Additionally it should also disappear when you click anywhere on that panel. These will be quite high in next sprint’s list.
I got so annoyed trying to find decent placeholder images for the win and lose screens that I didn’t end up spending longer trying to find a decent title screen image. I’m still not sure what I want for this, but I’ll need to spend some time this sprint looking for one so there’s something other than a blank blue screen with 2 buttons. I’ll try to get this done early on too.
I never even had chance to think about how to allow characters to walk under platforms. This is a complicated issue to fix and will take some thinking about, but it’ll be a nice warm up for some of the other items I’ll be tackling this sprint
What I will do next time
Everything that wasn’t done last sprint will be tackled in this sprint, starting with finishing off the Character details panel so that it’s not shown at the start, and disappears when clicked. I will then try to find something to use for the title page, although I suppose at this point I’m not entirely sure what I want there. For now I guess it’ll have to be something generic.
I want to improve how I’m using git, so from this point on I’ll be using a separate development branch for all my changes, then merge them through to a master branch at the end of each sprint. It’s a good habit to get into, and will make things easier when I start releasing more elaborate tech demos, or maybe even real demos. I’ll also rewrite the .gitignore file so that it skips only the auto-generated and user files, rather than the large ones. Instead I’ll just remove any large files which I’m not using. This will help if anyone else helps me with this later and needs access to Git.
I’d like to display the names of characters next to each model, as there’s nothing else to distinguish them other than the health levels. This will appear just above the health bar of each character, which also means I can tie it into the same code, so it won’t be a difficult job. I’ll need to work it into the character roster too so you can quickly see who’s who.
The other tasks involve updating how the movement code works for certain situations. If there’s a platform or walkway over a certain area, you should be able to walk and stop underneath it without having to wrestle with the camera. I’ll also have to figure out some way to make the area around the mouse cursor transparent when you’re hovering over an area like this.
I will also need to solve a long-standing issue, where you have 2 buildings on the same level, and nothing stopping you from walking from the top of building 1 to building 2, as both the starting point and end point are on the same level. Raycasting can’t detect that there’s no floor between these two points, so it doesn’t see anything wrong with it. I’m not sure what the most elegant solution is to this, maybe some sort of invisible barrier around each building that stops movement but not line of sight? I don’t like the idea of fixing this issue for every single climbable object I ever make, as odds are I’ll miss more than a few that way. No idea what I could do in the code at this time though…
And that’s the lot. As always, you can see how my current sprint’s going on my Trello board.