Making a Game – Report 12

08 Jul

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


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: