Making a Game – Report 15

What I did

Well this sprint could have gone better.  It turns out that creating multiplayer games in Unity is massively more complex than I was lead to believe.  If you’re making a more traditional game where you control a single character then it’s easy to get started and move on from there, but unfortunately I need to figure out a lot of the more complex stuff before I can do much at all.

As a result only 2 tasks actually got completed this sprint.  The first one was to increase the number of checks done when calculating levels of cover.  That was just a matter of doubling a couple of numbers, but I did refactor the code to make it a bit nicer at the same time.  The other task was upgrading to Unity 5.1 and Visual Studio 2015 which went well, although the outlining shader I was using to draw the movement circle is now broken.  I’ll need to replace this in the near future, but not until after I finish implementing multiplayer.

What I didn’t do

Every single task involved in making the game Multiplayer friendly.  From what I’ve learnt know so far I need to rewrite a lot of my tasks to better explain what I’ll need to do.  Some of this was hampered by a lack of tutorials out there, and the only good ones I’ve found so far have been a YouTube series on UNET (which is excellent), and the official Unity manual (detailed, but a bit dry).  More resources are always better, but those should teach me bulk of what I need to know about UNET.

Aside from this I also had a task to fix aiming so that you could aim from behind cover which might currently block your shot. I’ve not make any progress with this other than mull over a couple of ideas for how to get it working, and unfortunately none of them really fit the bill.  I’ll need to do some research into how this is done in traditional tabletop games to find some inspiration, but this will wait until after I’ve finished the multiplayer.

I’ve also done little to flesh out the setting and backstory for my game.  I’ve thought a few things over and decided to drop some elements that feel a bit too forced, but I’ve not yet put pen to paper to write it out in any detail.  I really need to scale this up.

What I will do next time

The main focus for now is the multiplayer.  Because it’s more complicated than I first thought, I need to make a simpler prototype to make sure I understand the basics.  It doesn’t need to be anything too fancy, just a simple game where you take turns clicking a button, changing the colour of a box for all players.  Before starting on this, I need to finish watching the UNET tutorials on YouTube, and read the entire official manual.  There’s bound to be things I don’t understand the first time through, but I’m hoping that both should give me enough of an understanding to make it through.

After I’m happy with how I’ve got the prototype to work, I’ll start off simply, creating a player spawn point for each team and creating a roving camera which each player controls independently.  From there I’ll set up the controls so that only one player can interact with them at a time, only moving on to the other player when the first has finished.

After I’ve done this, I will sync up the character’s movements, so that when you finish on one machine, the correct character will follow the same path on the other.  If possible I should probably send the path to follow over and redo the movement to cut down on the amount of data that sent over the wire.

When a player tries shooting at someone I need to make sure the other player sees this.  I’m not sure I want to try drag them into the 3rd-person view over the shoulder of the other player, but I can at least pan the camera over to them to show the shot taking place.  After that, I need to make sure I show the updated health level, and kill the character if they’ve run too low.

Finally, when the game is over I should take each player to the correct win/lose screen.  This one should be pretty simple, but it’s important to make sure I do it before I next release a tech demo.

As always, you can see my current Trello board here.

 

Making a Game – Report 14

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.

 

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.

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.

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.

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.

 

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.

 

Making a Game – Report 11

What I did

Quite a productive sprint this time, all but one item completed.  The biggest one I finally tackled was the health bars which plagued me last sprint.  Each one displays just above a character and rotates it constantly so they point towards the main camera.  They’re looking pretty good now although there’s still a couple of issues.  When you switch into aiming mode the health bars stay pointed towards the original camera, which doesn’t look too great.  Shouldn’t take much more to figure out a solution to that problem.  The current character’s health bar still shows in aim mode too, which gets in the way a bit.  This also shouldn’t take much more work to finish off, but that will have to wait until next sprint.

I’ve also improved the shooting mechanics, so that now you get a (really primitive) projectile shooting out at your target, hopefully hitting it.  There’s a couple of seconds delay now too so to give you chance to learn about if the shot was successful before play moves to the next character.  That one took a lot of rejigging of code to get it working, and could probably do with some more tidying up later.  In fact, one thing I’m sorely in need of is a major tidy up of my code to stop them from getting too bloated. Not sure that’ll be for another sprint or two though.

I managed to get a some extra screens sorted so that you don’t just jump straight into the game.  When you boot the new tech demo linked to below, it’ll take you to a title page (the image will come later), and let you view the game controls from either there, or within the game itself.  There’s also a pair of game over screens, one for each time, although they also need a fancy image to go with them.

I mentioned in my last report that one thing I wanted to do was spend a day focused on playing through a built version of my project when I’m ready to release a new tech demo, which I made a point of fitting in this time.  This led to this update going up a little late, but I think it’s worth it in the long run.  I did discover a number of small, easy to fix issues that would’ve gone completely unnoticed before, like the wildly different scales before scenes, the health bars disappearing when aiming at someone from above (the movement circle was getting in the way), and that I’d forgotten to hide the big grey hit boxes attached to every character.  None of those were particularly tricky to fix, but it’s nice to get them out-of-the-way sooner than later.

Lastly, after finishing up the health bars and some other areas I’ve now released an updated tech demo.  Working towards this over the past month has helped me push myself to make sure it’s that bit more polished than the last version, on top of trying to get all the big features done.  With that in mind there’s no reason for me to not release a new one in two sprints time.

What I didn’t do

The one task that I didn’t manage to get done this sprint was to take a proper look at the cover calculations and see what’s up with them.  That’s not going to go away any time soon until I do, so that one’s on the top of my list next sprint.  I’ll need to create a new level specifically so I can aim at characters at different angles and different levels.  Other than that it was a pretty good sprint.

What I will do next time

I’m going to make sure I get the leftover problems from this past sprint polished up and out-of-the-way.  First on the list is that cover calculation problems which I just mentioned.  After that I’ll fix up the health bar issues I mentioned before, namely them needing to point at the aiming camera when you switch to aim mode, and hiding the current player’s health bar to free up the view somewhat.

When looking up other items to add to this list I realised that it’s run surprisingly low, which mostly bug fixes and clean up work left.  The game isn’t anywhere near that complete, but I’ve neglected to spend much time thinking about what’s left.  The biggest stand outs are the following:

• Networking – Will allow you to play the game online.  I’ve done nothing for this so far.
• Combat – Ranged combat, now that it sort of works, needs expanding to more than just one weapon type, possibly including some form of mêlée attack too.
• Interface – The number of giant grey buttons everywhere is starting to get a bit silly.  This needs redesigning to become something a bit more pleasing to the eye.
• Code refactoring – I need to take a serious look at my code and refactor a lot of it and start writing some unit tests.

I’m not going to have a great deal of time over the next couple of weeks, but this time I’m sticking to a 2 week sprint and will work on fixing up the bugs mentioned earlier and see what how much I can do to make the ranged combat a bit more varied.  I’m also going to start working on refactoring and writing unit tests each sprint.  It’s work that will prove invaluable later on, but it’s not the sort of thing that I want to spend an entire sprint on at this point.  I will try to do the same thing I’ve done for my pre-tech demo releases and spend a day or two dedicated to writing up unit tests to make my code that bit more solid.

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

 

Making a Game – Report 10

I had a whole week this sprint where I wasn’t able to get anything done for this game, so this ended up becoming an impromptu 3 week sprint. Even with that, there was a lot that didn’t get done. But first, let’s start with what did get done.

What I did

The biggest item I worked on this sprint was to make cover meaningful. When you aim at a target it calculates how much of the other character is visible, and assigns a cover level to it, ranging from 0 to 3 (0 meaning no cover and no penalty, while 3 is total cover and cannot be targeted). I did this by placing a single quad (basically a rectangle in 3D space) through the centre of the character, and rotated it towards the shooter. I then run a number of Linecasts between the shooter’s head and a number of points on this quad, then use the number of Linecasts that make it through to get a cover percentage, which is then converted into a cover level and displayed next to the target reticle. You don’t see anything through the UI other than the cover level, but in debug mode it looks like this.

My characters now rotate to face the direction they move and shoot in, which generally makes for a nicer game appearance. They’re still very much placeholders, but if I can spend just a bit more effort to make them look nicer then I consider it worthwhile. I’ve also replaced the movement circle with something a bit smoother. After lots of experimentation I learnt that, with the shader I’m using, a cone won’t do the job after all.  I really need to use a shape with rounded edges such as a sphere, or maybe something shaped like a pizza. I did find an excellent sphere that looks perfect, but at 10Mb it seemed a high to include. I’ll have to come back to this again later, but for now it’s good enough. And finally, there’s a small button in the upper-left corner which allows you to exit the game. Testing this game entirely through the editor has taught me that there’s some issues which really don’t present themselves until you’re running it properly, which is why I missed items like this as well the cover level icon repositioning itself further away than I wanted it to. With this in mind I’m going to devote a full day to testing out a new version before I release a new tech demo. Early prototype or not, it’s a good habit to get into and there’s no point making this if it only works for the person making the game.

What I didn’t do

The biggest task I wasted far too much time on this sprint was the health bars. This seemed like a simple job at first, but eventually this ended up being a colossal time sink. At the time I couldn’t find a single good guide to do exactly what I wanted, and when I did find one they assumed you’d already watched and memorised content from some of the previous 50 articles/youtube videos. The methods I did try never seemed to work quite right, and contained problems which I’ve already learnt will cause serious memory issues later on. Eventually I discovered that the methods I was trying did not work in version 4 of Unity, but only in older versions of Unity 3… I’ve since been pointed at a new guide that covers how to do this in Unity 4, and it seems much more promising. This will take up the bulk of this next sprint.

In addition to this I’m still having some problems with the cover mechanics, which is baffling and very intermittent. Every so often when it rotates the quad to point towards the target the game seems to detect the collider as if it were pointing at a different angle. I’m not sure why it’s doing this, and if anyone fancies a go at figuring it I’ve posted the question on the official unity answers here.

With the amount of time spent on these 2 areas there were several things I didn’t even have time to look at. The simplest one was the Game Over screen when you take out the last target so that the game doesn’t just endlessly throw errors at you. I also wasn’t able to fix up the firing process to let you see if your shot hit before it moves to the next player.

What I will do next time

Due to how overloaded I was last sprint, this sprint is focused on finishing up everything I didn’t get around to doing last time, with particular attention paid to getting the health bars working. Before starting on that, I want to tidy up a couple of smaller UI issues such as adding the Game Over screen, as well as a Title screen to start the game from.  Additionally I need to show the controls within the game somehow, so I’m adding an extra screen to display this information which you’ll be able to view with a button click.  Considering how this is a feature of every single game out there I don’t expect too much trouble from this, and it seems pretty essential to have it in there before I release an updated tech demo in 2 weeks. This may seem a little light, but last sprint a lot of time was lost trying to get the health bars working, so I’m making that the one big job to concentrate on for now.

As always, you can see the current state of my sprint on my Trello board.

 

Making a Game – Report 9 (Tech Demo released)

What I did

This sprint turned out pretty well, with all but one item completed.  First off was the outstanding issue from last sprint, where I was trying to give all characters a health level and take them out of the game when this runs out.  When their health reaches zero, the character collapses and can no longer be selected to play, or targeted when aiming.  I also fixed a small bug when starting the game where the initially selected character couldn’t take any actions.

I tied up the user interface a bit, and now any buttons which you can’t select are hidden from view when they’re not available.  The interface as a whole needs a much neater design, but I’m not going to spend too much time on that until I’ve got a general design and theme finalised so that I can make something that compliments it.  I also stopped button presses from being treated as movements when the two areas overlapped.  It was occasionally causing problems but mostly it was just annoying.

I’ve changed the team’s appearances so that now they look different (Team A are generic soldiers, while Team B are generic SWAT members).  They’re still very much placeholder models, but at least they look a bit better than they did.  I also stopped them from remaining tilted when leaving aim mode.  They now go back to their forward-facing position when you switch back to movement mode, or take a shot.  Finally on teams, I’ve got the camera to flip 180° when you switch between teams.  Later when I’ve made the team members turn correctly I’ll position the camera behind them properly, but this will do for now as I was forever rotating my view around when switching teams.

I’ve improved the movement code a bit too.  A bug in how I’d set up the movement lines meant it wasn’t showing you moving up ladders correctly after clicking a hot spot.  It now maps out correctly.  I also tidied up some of the code which was causing the game to get confused about which level a person was on, allowing them to walk out over thin air.  I’m not convinced that I’ve closed this off completely, but I haven’t figured out a way to reliably trigger this since.  The movement circle now shows the correct distance a character can move during their movement phase… usually.  To get this to display correctly I have to multiply the remaining movement by 3.  But every so often I’ll be testing the game later and find that it falls short, and I now have to multiply it by 3.33.  Then later again I’ll have to change it back to 3.  This doesn’t seem to be related to how much movement is left, and when it works it works consistently throughout the game.  I need to do some more investigation into this, but I’m drawing a blank.

And finally, I spent some time tidying up the demo level I was using, adding some extra buildings, some blocking walls and a number of different textures.  They’re still very much placeholders, but it helps give me an idea of what types of textures to use.  So far I’m favouring the metal ones which you can see in the screenshots below, but I’m curious what everyone else thinks.

And finally, I’ve released an initial tech demo.  It’s not really much of a game currently, and it’s missing a lot of features before it could be considered one, but it gives a general idea of the feel I’m going for.  If you’re interested you can find it here, just unzip and run.  I haven’t put in an exit button yet, so the only way to exist the game if you’re in full-screen mode is to ALT+F4.  When you’ve taken out the last target the game just sits there and waits for you to quit.  Not ideal, but it is an early tech demo after all.  The controls are the Left mouse button to perform actions, Right mouse button to undo a movement waypoint, the WASD keys to move the camera, and Q and E keys to rotate the view.

What I didn’t do

I wanted to make the Camera move up/down levels automatically as your plan your path across different levels.  Unfortunately I’ve realised that the way I’ve written the movement system doesn’t allow this, and carries a lot of other restrictions to boot.  This will need refactoring to make it fit in with how I’ve structured the rest of the project, but it’s not a high priority.  I’ll note it down and work it into a future sprint.

What I will do next

For the next sprint I’d like to improve the look and feel of the game some more.  I’d like add in health bars for each character so you can see how close to death they are.  I’m used to being able to see this in the code at the same time as running through a demo, and it wasn’t until I was testing the tech demo that I’d put nothing in place for this.  A game over screen would be nice too, as currently the game just sits there after you’ve taken out the last target.  Some sort of indicator that you’ve won would be nice.  I need a quit button too, ALT+F4 isn’t a good way to leave, and this is also something I didn’t realise was missing while developing.

I’m not happy with the way the shooting works, it really needs some sort of cover mechanics.  I won’t go into the depth I’d originally planned just yet, mainly because I don’t have any girders, but I’ll figure out how much of the target you can see, and use that.  Some sort of indicator next to the targeting reticle.  I also want to add a delay into moving to the next character after you take the shot, and add in a basic animation showing you hitting or missing your target.  As always, it’ll be a simple placeholder for now and I can substitute in proper firing animations later on.

Movement wise I want to tidy it up slightly by turning the character to face the direction they’re moving, and leaving them facing the target they’ve just fired at (so long as they’re not tilting into the scenery).  I’d also like to replace the movement circle with something which more closely resembles a circle than the large polygon that’s there now.

Depending on how well I do with these items I might end up adding a few more items, but this will do for now.  As always you can see the state of my current sprint by looking at my Trello board.

 

Making a Game – Report 8

A busy bank holiday weekend threw me off, so this one’s up a few days late.  It’s been a very productive sprint, with only 2 items left incomplete from my Trello board.  I’m now able to detect whether two characters can “see” each other by drawing a straight line from the head of one to the head of another.  It doesn’t take into account things like partial cover yet, but it at least lets you know if they’re behind a building.  I’ve discovered that the aim-cam I’ve set up will need some tweaking, as it makes it look like you can see a character from some positions, despite the edge of the building being completely in your way.  I want to tackle that next sprint, as it’s going to cause problems if I’m constantly getting confused about Colliders and Raycasting.  I’ve also got a rough hit chance calculation in place for when you take a shot.  It’s pretty basic, only reducing it based on distance, but I don’t need anything fancier until I’ve got a more thorough design done for this weaponry and combat in general.  If you do hit someone they take damage, but this doesn’t have any in-game effect.  That’s going to take a bit of thinking about, but I can polish it off at the start of next sprint.

Finally for combat, firing a shot ends the turn and moves play to the next character.  There’s some flakiness still, as it does this at the same time that it tells you whether you’re shot hit, and what happened to your target.  Usually you’d sort this by spinning this out into a separate thread to tidy things up after a certain amount of time passes, but in Unity you can only do certain things, like hide the aiming crosshair, from the main thread.  And I can’t delay that thread too much without blocking the UI, which would also stops things such as firing animations, watching characters take damage, etc.  It seems that the accepted way to fix this is to start a timer and move the code to sort out these changes into the Update thread.  I’m not particularly fond of this idea as it will clog up the main Update thread and you lose some control over when the difference actions will occur, but at the moment I can’t see an alternative.

While it’s not as big as getting basic ranged combat working, I’ve now got some rough team mechanics in place.  Again, it’s nothing major, but characters are now split into 2 teams, with members of each one only able to shoot the others.  I’m not sure if I’ll be changing it later, but the way it works now it will always shift to the next usable character in the other team.  So if Team A has 3 members and Team B only has 1, it will always change to that 1 member after Team A finishes their turn.  I took some inspiration from Worms here, where even if you’re one or two team members down, you can still scrape through to victory with one plucky survivor.  It’s never felt enjoyable to me when you lose someone early on and it ruins your chances for the rest of the game just down to sheer numbers.

As said a couple of times earlier, I’ve only partially implemented health.  Each character has a health score which starts at 100, and when it reaches 0 they’re taken out of the game.  I’ve also not worked on the cover mechanics yet, using simple line of sight to decide if they can shoot someone, and this will take a bit more thinking about.  If someone’s hidden behind a barricade with only a few gaps in it, then that would be considered heavy cover, but if the person behind the barricade is shooting, should the other guy also be considered behind heavy cover because the barricade’s between them?  I’d say no, but then how close to the barricade should you be for this to not be the case?  What about if it’s not a barricade, but a gap between two large obstacles, such as buildings.  How far can this impromptu cover go out before you can’t just aim around it and stop them from using it as such?  What about two people on opposite sides of a set of girders, should both of them or neither of them get cover?  So yeah, this will need a bit more thinking about before I try to do anything.  It may just be safer to put this off until later so I don’t end up doing a bunch of work that’ll need completely rewriting after a design change later on.

Which brings us to next sprint.  The first thing that needs finishing off is taking characters out of the game when they run down to 0 health.  I’d like to keep their models around, so I plan on pushing them over to show where they were.  The game will also need to end up there’s no more characters alive on one team.  While I’m likely to leave full cover calculation until later, I’d like to put some rough work into place so you at least get some protection from standing behind a chest-high wall while shooting out at someone standing out in the open.  Other than this I want to focus on tidying things up a bit so I can start taking some screenshots.  There’s a lot of huge buttons all over the place, some of which don’t matter when you’re moving, and others which are just as useless when aiming.  It makes sense to hide those and free up more of the screen.  I also want to stop a button-press from counting as movement if it’s positioned over a walkable piece of terrain.  I’ve looked into this before early on, but I hope that now I know more, I can figure out where I was going wrong.  Mostly there’s just lots of little tidying up tasks that need working, which aren’t worth going into major detail here.  I’ve also taken reading The Art of Game Design out of my sprint, as every time I finish one chapter, it’s replaced by another straight away.  I’m still reading it, but it wasn’t helping anything by having it up there.

As usual, you can see the my current sprint on my Trello board.

 

Making a Game – Report 7

After a surprisingly easy process, I now have my Unity project stored under source control.  I had some sound advice from a fellow developer (thanks Andrew), and instead of trying to use Git with Dropbox I created a private repository using BitBucket’s free service and manage my source code with SourceTree.  After quickly running through the tutorials it was pretty straightforward to upload my work into a fresh repo, then check in some minor changes to confirm it all worked.  SourceTree is a really nice tool to use too, and whilst I do like diving into the command line this seems like it will be a much simpler process.  I’ve also get the Visual Studio tools for Unity working correctly too.  Turns out it’s also pretty easy to do so long as you actually read the documentation.  This will be a massive time saver for me next time I’m having trouble debugging.

I didn’t have a great deal of free time this sprint, but I did manage to squeeze some in to look at ways to calculate hit percentages to keep it fair and balanced.  Unfortunately I haven’t found much information on that topic, mostly just articles on AI decision trees, although I did discover several fascinating articles on probability in games such as XCOM.  The biggest discovery was learning that the random number generator isn’t as broken and unfair as everything thinks it is.  What I did learn though is that even completely balanced systems will seem unfair to a good number of players.  Not really an issue when I don’t have much of a game, but something to keep in mind when I eventually get to playtesting.  I’ll have to schedule in some more research into this area for later, but for now I’ll make do with some really simple calculations based on the range and amount of cover.

Speaking of which, I managed to do some research into cover mechanics too.  Again I mostly found irrelevant articles on AI, but I did find one interesting perspective on the Unity3d boards, and I can see where they’re coming from.  At the end of the day it doesn’t matter what fancy pants calculations you have in the background, it’s what the player perceives that’s important.  One memory I have of playing Necromunda though is looming over the game table, carefully nudging characters around to try to line up a shot that will just get past most of the cover.  If I want this then I can’t get away with a simpler cover system based on position and direction which games such as XCOM use.  So I guess that means doing things the hard way.  There’s a bunch of fancy calculations I can use for this, and that’s top of the list to get working for next month, as well as showing the hit chance to the player.

For next sprint I want to finish off the work I started on ranged combat, and get to the point where you can shoot someone and inflict damage.  I’ll also want to get a number of characters in different teams and switch between them as you move around shooting each other.  Shouldn’t be much longer before I’ve got something I can call a rough prototype.

You can see the Trello board for my current sprint here.

 

Making a Game – Report 6

This sprint I managed to refactor the movement system, so now it can group multiple movement steps into a single action, which in comes in handy when someone’s climbing a ladder.  That might not sound like much on the surface, but it sure makes the code a lot neater and easier to manage when planning your movements out.  I’ve also completed a very simple aiming mode,  Right now all you can do is look at the different targets available, with no regards to their team, distance, cover, or any other factors (it does stop you from aiming at yourself though).  There’s a lot more work left to so here.  I’ve also added a few more UI buttons to allow you to cycle through targets and move the camera up/down levels as you view the map.  It does the job for now, but it’s starting to look a bit crowded.  This will be high on my list of things to fix when I start tidying everything up.

I didn’t get around sorting out my problems with the Visual Studio Tools for Unity, and that’s something that’s going to come back to bite me if I don’t get it sorted soon.  With the combat mechanics next on my plate, it will be a real pain to debug if I’m trawling through log files instead of watching the data as it changes.  I also need to sort out some form of source control for this.  Right now, everything’s backed up, but not in a way which makes it easy for me to go back through older versions of my code.

For the next sprint, I’m going to first get Visual Studio tools for Unity working.  If I don’t do it now, I probably never will.  After that, source control.  With a quick Google it seems that it’s fairly straightforward to use Dropbox to host a private Git repo, which sounds good as I don’t really want to make everything open source.  After that’s all done I’m going to focus on the more in-depth combat mechanics.  I could probably come up with a few formulas myself to decide on the hit percentages, but there’s likely a wealth of material out there already which covers this sort of thing in greater detail.  After I find and read through said material, I’ll start putting them into play, and show the likelihood of hitting a target based on distance, elevation, and cover.  When that’s all completed I can take a look at tidying things up a bit to see what’s needed for a tech demo of sorts.  It’s far too early to call it an Alpha or the like, but when you can at least move people around and have them shoot at one another, it’s got enough in it to show off.

You can see the Trello board for my current sprint here.