Monthly Archives: July 2015

Making a Game – Report 13

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.

Character Details - Professor Snuggles

Spoiler: Professor Snuggles will not be in the final game.

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.

Not particularly helpful

Not particularly helpful.

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.

Somewhat better.

Somewhat better.

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.

Leave a comment

Posted by on July 22, 2015 in Making a Game


Making a Game – Report 12

What I did

A fairly sparse sprint this time around, but at least I managed to get everything done.  I managed to clear up a few small issues that were going to bother me later.  I stopped damage from being done to an enemy before you found out whether it hits, so it’s now applied immediately after showing you whether you hit or missed.  The current character’s health bar is hidden from view when you enter aiming mode, and I might end up expanding that to cover other characters health bars later on to help reduce the amount of irrelevant information on the screen.  As with a number of other issues though, it’s not a high priority for now.  Speaking of health bars, I’ve also refactored that code so it’ll rotate them towards either the main camera or the aiming camera depending on what’s needed.

The most troublesome task in my sprint this time around was figuring out what was going wrong with my hitboxes.  For some reason while they looked like they were pointing in the right direction, my code was picking up the collider as if it were pointing in a slightly different direction, messing up my cover calculations.  I threw together a quick test area and did some looking and it turned out the issue was down to the way I was calculating the points along the hitbox, looking at the wrong end of the z coordinate half the time.  I won’t go into too much detail here, but I did update my Unity Answers question with my solution if you want to find out more.  Long story short, once I noticed what the problem was it was a really quick fix, so that took out the tough part of this sprint.

The other task I had was setting up a better variety of weapons.  I didn’t want to go too far with trying to make them balanced at this point, but I used some tips I picked up from The Art of Game Design and did some calculations to make sure that they were all equally useful at a mid range, then scaled differently at shorter and longer ranges.  It all comes down to comparing the damage to the hit percentage at a certain range and working out the average damage per shot.

Finally, I came to unit tests, which was a bit more interesting.  Surprising no-one, it turns out that Unit Testing unity code isn’t very straightforward.  You can’t write unit tests for any of the scripts which are derived from the MonoBehaviour class, which means any scripts that I want to attach to an in-game object can’t be unit tested directly.  Instead if I want to unit test something in there, I have to refactor it into its own class and write the tests against that instead.  That’s a good thing in general too as it’ll stop the main scripts from getting too bloated and follow the separate of concerns design principle.  The one problem I have is that the unit tests I’ve written won’t actually run…  I’ve looked at a few other sample projects, but no-one else seems to have this problem so I’m not really sure what’s causing it.  I suspect I might need to look into the Unity Test Tools and do some more config, or just something really basic that I’m missing.

What I didn’t do

This was one of those rare sprints when I managed to get everything done.  This was mostly thanks to it being a light sprint, but I also managed to resolve the issue with the hitboxes far faster than I thought I would.

What I will do next time:

Until I started to release tech demos I thought I’d laid out my interface fairly well.  It wasn’t until I started playing them and selecting different resolutions that I realised how wrong I was.  Even if it’s just a placeholder it looks pretty darned horrible when the buttons are all grouped in the middle of the screen, or stretching off the edge.  I need to figure out how to lay out the UI elements on a canvas properly and apply that work to every screen.

Now that I’ve got several different characters on a team with different health levels and weapons I need some way to keep track of them.  As always, it’ll be a placeholder for now, but I need to think about where it should fit into the UI, and how to make it work.  It also means I’ll need to add some character names in too.

One major scenery piece I’m missing from the game are walkways.  There’s a lot of issues involving them, such as how to use them to connect buildings and let people walk along them to other buildings.  It sounds simple enough at first, until you realise that you only have the player’s position and destination, with no idea what’s between.  On the ground that’s not an issue, but it’s going to take a serious piece of design work to get this working.  That will be for next sprint though, for now I want to get some walkways in and allow people to walk under them.  It’s an early step, but I’m hoping that this will give me some inspiration for how to solve the bigger problem.

While it may seem fairly minor, I want to replace the current placeholders for the title screen, win screen, and lose screen with something that’s not just green text on a blue background.  It won’t be anything final by a longshot, but as placeholders go it’s pretty bare-bones.  I’m no artist so I’ll have to see what creative commons images I can dig up online.

The GameController class needs some major refactoring.  Mostly this is to make it more unit testable and meet a few more of the SOLID principles, but this will also make it much easier to work with in the future.  I only have a few classes that have grown this big, and I’d like to refactor them all one by one over the next few sprint.

Before I start writing any more unit tests I want to try to get them working, so I’ll be spending some time this sprint setting up the Unity Test Tools and seeing where I might be going wrong.  Even if I can’t figure out what I’m doing wrong I’ll still keep up with the unit tests.  It might mean that I hit a wall of failed tests and buggy code I need to fix further down the line, but it’s better than just not being aware of it.

As with last sprint, I’ll be spending some time at the end writing unit tests.  As this will be a regular feature in each sprint though it won’t be included on my Trello board as it’ll just end up as a feature that never leaves my list, which is the same issue I had with tracking my progress with the Art of Game Design.  As with that, I’ll still be working on it but there’s no benefit to me to have it included on the board.

As always, you can see how my current sprint’s going on my Trello board.

Leave a comment

Posted by on July 8, 2015 in Making a Game