Making a Game – Report 21 (Tech demo released)

What I did

First off was setting some limits on the team size.  Now you can’t have a team smaller than 1, or larger than 8.  I might change that later, but that’ll happen later when I have the combat fleshed out enough to start fine-tuning the balance.  You can also change the sprite of your team members.  I was going to let you select an image from your computer and use that, but it turned out that Unity doesn’t supply an in-built way to let you browse your computer for files.  So I ended up throwing together a quick gallery of faces to choose from.  I’ll have to come back to this later and figure out how to allow people to use their own images without much work.  That’s a “would be nice” feature though.

Team and team member data is now saved to and loaded from disk when changes are made to it.  It saves each team to a separate file and is fairly easy to cheat by editing the files manually.  Granted there’s not much advantage in doing that right now as you can do the same things by using the in-game team manager.  Another thing I’ll take a look at fixing up much further down the line.

On the world map front I’ve made a few changes.  You can now only attack territories which border your own, which means you have to select one of your own territories to attack from too.  I’ve hard-coded which territories you can attack from for now, which I’m not entirely happy with.  I’m not sure what solution would work better though, other than storing it all in an XML file.  I could do something based on the distance between hexes, but I don’t want to have the art start affecting the gameplay.  I’ll put this on the backburner to look at again later.  Also, I’ve made sure that when a battle’s over the losing team’s territory will be passed to the winner.

Each battle now ends with a battle results screen, which lists the characters in each team and the damage they took, damage inflicted, and have many killed. There’s plenty of room for improvement here but most of this can wait until I’ve fleshed out character progression, which will clarify what sort of data is important to show off.

I managed to fix both the annoying bugs that cropped up a couple of sprints back.  The first one is the health bars disappearing,  I spent a couple of afternoons trying to figure out what was wrong with this, reaching some sort of success by changing the renderer sorting layer’s during runtime (didn’t work if I set it in the editor).  Eventually I decided to upgrade Unity and the issue went away.  Turns out it was a Unity bug that must’ve crept in when I upgraded in the past…  The other bug was a bit more devious.  It was happening seemingly at random and thought there there was no-one in the first team even though the check didn’t happen until after they’d been generated.  Looking at the logs the people had definitely been spawned but it still thought they were dead.  A little more digging and it looks like my IsAlive check was to blame, as it always returned false until the CurrentHealth was set partway through the internal setup work for each character.  A simple enough race condition issue to fix, but a bit of a devious one to track down.

With everything completed this sprint, I decided to go ahead and release a new tech demo, but at this point it’s starting to turn into a very rough Alpha.  I’ll try to release them a bit more often from this point.  You can find the current version here.

What I didn’t do

Somehow I managed to get everything done this sprint, so nothing for this section.

What I will do next time

Right now the game is mostly complete, although many areas are still in a slipshod “it’ll do for now” way.  But you can start a new game, and attack enemy territories one by one until you’ve taken over the map, so long as you don’t mind seeing the same demo combat area over and over again.  There’s also one noticeably outstanding issue, which is the game still needs you to manually control each team.  Originally I planned this to be a multiplayer game but it really needs decent AI for the single player mode.  Unfortunately I don’t know much about developing AI right now, so this sprint is going to be a bit vague and involve a lot of research and prototyping

First thing to do is find some articles on basic AI theory and practice. I’ll try not to spend too much time on this, but if I don’t understand the basics beforehand then I’ll be making my job that much harder.

Afterwards I’ll start putting together some prototypes. The first one will be getting the AI to move someone to the closest of 3 specific points. Next I’ll do the same, but have them prioritise the slightly further away one which provides cover. Then I’ll do the same, but make them check to make sure the cover will be effective against an existing target. I’m realising that I could make job significantly easier if I replaced my click to move system with a simple grid system. It wouldn’t be what I originally envisioned but it would make this a damn sight easier to get off the ground.

I’ll also try to create another set of prototypes for combat. It won’t be as in depth, but I’ll first make one to target people based on the highest chance to hit. The next can do the same, but will take into account how much damage a target has suffered. Finally, if I have time, I’d like to make another where it looks at which weapon each enemy has and decide who’s the biggest threat. More often than not it’ll be the one closing in with the shotgun.

That should do for this sprint. I’m not certain I’ll get it all done, but it’ll give me plenty of practice either way.  Ultimately I’ll combine these ideas into a single opponent who can assess the enemy ahead of time and move into appropriate cover to take out the most dangerous target. That should be fun.

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

You can also find the current tech demo here.

Leave a comment

Posted by on November 17, 2015 in Making a Game, Release


Making a Game – Report 20

What I did

Had some things occur this sprint which took a lot of time away, but somehow it still ended up being a somewhat productive.  I’ve thrown together a quick world map with a number of territories (shown as hexes) which display some basic info and can be occupied by any team. At first I was all for using hexes, but now that I’ve had some time to play around with it I’m not sure it’s right feel for what I’m after. I think something with fewer, more spaced out territories with better graphics to represent them would be nice, but as I’ve said so many times before it’ll do for now.


I still really like hexes, but I just don’t think they’ll work.

I’ve changed the character placement in the combat mode to randomly place characters within that teams spawn area. This lets me put any number of characters in each time, although I will have to add some options for choosing where to play them later. Could do with a better demo level before that though.

I’ve completed an early Team Management screen. It’s very rough, but does the job until I have the time to do some proper UI research and design. From here you can change the name and equipped weapon of any team member for any team, and add or remove team members as you will. I haven’t placed a hard limit on the how many/few team members you can actually have yet, but that’s a fairly trivial thing to set.


When I say rough I really do mean rough.

What I didn’t do

Only have a few missing features from the team management screen now. I want to be able to set the portrait used to represent your character. Later I’ll build a library of images to choose from, but it feels important to allow players to import their own faces to use. I’m not sure if that’ll stay long term, but it’ll certainly work for now.

I’ll also want to save all team data to disk, and loads it again when you start a new game. It won’t be very visible to the player, but it’s important to do right and will need some research doing beforehand.

I want to update the world map so that you can only attack territories adjacent to your own. There’s a few ways I can do this, some quicker than others, but what I really need is do is make something adaptable which I can just load in for future maps. It’ll take a bit of planning, but shouldn’t be too difficult to figure out.

Finally I still need to let teams take over enemy territories when you defeat them in combat (or lose of your own if they defeat you). It’s kind of key to the whole persistent strategy side of things.

What I will do next time

I intend to implement all the features mentioned above, none of them are really optional at this point. I’ll also fix the issue I discovered while writing this post where there’s no lower/upper limit on team sizes. I’ll look at this properly later when I start to balance things out, but for now I’ll set them to 1 and 8.

On the bug side of things there’s 2 annoying ones which gave popped up recently which I need to fix. First of all the game will sometimes instantly leave combat mode after it begins. I’m not sure what’s causing this to happen, but as its intermittent I think there’s a timing issue somewhere which I need to look at.

For the second one, I’m not quite sure when it happened, but most of the health bars aren’t showing in the combat mode. It just flicks between showing one, then another as you move and rotate the camera. I’ve got no idea what’s causing this one, so I’m going to need to crawl through my past commits in git to see when it stopped working.


You can only ever see the one belonging to the top-most visible character.

When that’s all finished up I’d like to create some sort of post battle report screen which appears when the combat mode ends. No idea what I’d like on there right now, but the health levels, damage done, and characters killed for all people involved seems a good start. I’ll also need to track that data during the combat.

If I can get all of this done then I think I’ll be ready for another prototype release for anyone who’s interested. It will still be incredibly rough, buy at least I’ll finally have something resembling an actual game.

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

Leave a comment

Posted by on November 4, 2015 in Making a Game


Making a Game – Report 19

What I did

Well this ended up being a productive couple of weeks.  Not only did I manage to do everything I’d set out for this sprint, I managed to get a couple of bonus tasks completed too.

I tied up the health bars which were still sort of broken from my multiplayer attempt.  Health bars are now rotating to point towards the correct camera when it moves and rotates and the health levels shown in the team roster is also updated correctly.  While fixing that I also noticed that the health bar shown in the character details pop up was also trying to rotate, but as it’s part of the UI it just looked kind of weird from certain angles.  Apparently I’d added a script to it at some point telling it to keep pointing at the camera.  Not sure when I’d made that change, but after removing it everything looks fine again.

After that I could finally start on the strategic view, or world map.  For starters when you begin a new game you’re taken to the world map initially.  From there you can select an enemy territory and choose to attack it.  There’s placeholders to show information about these territories and the teams that hold them but for now shows no real info (that’s something I’ll be working on in my next sprint).

Each territory is different depending on which team holds it, and attacking different ones takes you into battle with a different group of enemies.  When the battle ends, whether you win or lose, you’re taken back to the world map to continue playing.

What I didn’t do

Nothing for a nice change, a very productive sprint.

What I will do next time

I got a lot more done this past sprint than I expected, so this month I plan to finish off the rest of the world map changes, and expand the combat mode some more.

First up is expanding the world map to include a larger number of territories.  From there each team will own several territories and you can choose which one you want to attack, winning that territory if you win the resulting combat or losing one of your own if you lose.  With that in mind, I’ll also add some information to the territories which will pop up when it’s selected.  It makes sense that you can only attack bordering territories too, slowly working your way to the edge map where the enemy team’s more heavily protected home base will be (that will come later).

I will update the combat mode to randomly place team members within their starting area, which will let me increase team sizes to more than 3 members.  I also want to add in some team customisation options which you can accessed from the world map.  For now you will view existing teams, change their equipped weapon, create new team members (specifying name and loading in an image for the face), and dismiss existing ones.  To aid things I’ll also make this persistent so that the team data saves and loads in the background.

That’s all for this coming sprint.  This may look like a short list (and it’s easily one of my shorter reports), but as you’ll see from my Trello board there’s actually quite  a few tasks involved in this.

Leave a comment

Posted by on October 18, 2015 in Making a Game


Making a Game – Report 18

This report will be a little different to the past ones as I’ve done in the past.  Being that I’m 3/4s of the way through the year of trying to making this game I’ve been doing.  For the most part, I’ve been focused on trying to make the core game and combat work to a reasonable degree.  While this is important, I feel that I’ve lost focus of my main task of “making a game” and have instead been chipping away at all the features that were needed for the combat work.  I had an inkling at the beginning that I wouldn’t finish this game within a year, and it’s plain to me now that this definitely won’t happen.  But what I wanted to happen within that year was have the core framework of the game set up.  Instead I just have a fairly basic turn based combat mode.  This wouldn’t be so bad, but I’ve spent the last 2 months trying to get the basics of online multiplayer to work, and while it works ok so far, it’s a long way from being done.

Considering the relatively small number of people that might actually play this game when it’s done, I’m not sure it’s worth spending any additional time trying to make the multiplayer work.  None of the time I’ve spent on this has been wasted, as I’ve learnt a lot about how Unity’s UNET system works, and also refactored a lot of my code that needed some serious tidying up.  The way my game’s set up now it’s fairly easy to get it working in either single player or multiplayer mode.  Instead of them, I’m going to spend the last quarter of the year making the basic framework needed for the rest of that game.  I still expect the combat to be the more complicated part of the game, but the rest is still essential to make it a more complete package.  Now, on with my usual report.

What I did

Despite my moving away from multiplayer, I finished off 2 features that were causing me some annoyance, but didn’t take too long to fix.  When it was the other player’s turn you could still see the movement circle and create waypoints around their current character.  Neither of these served any purpose and didn’t matter a great deal as you couldn’t actual move them, but it looked untidy and could cause some confusion.  When play moves away from you, both these features are disabled.

At some point when I was refactoring my movement code to work with multiplayer, I’d messed up how it calculates the remaining movement after you confirm where a character should go.  Instead of using the correct value, it was reset back to the original value, letting them move around forever.  I had to change where the calculations take place, but this is no longer a problem.

The biggest task this sprint was refactoring the game to work in offline mode again.  Thankfully it wasn’t as big a task as making it work with online multiplayer originally, and the code’s considerably neater as a result.  All of the original online code is there and the game should still work in online mode when I come back to it later, although I haven’t tested it and probably won’t for some time.  There’s still a few issues left which I’d like to finish up, both of which were introduced from my original multiplayer refactor.

What I didn’t do

Every other networking task that wasn’t listed above.  As I mentioned at the beginning of the post, I’ve stepped away from working on the online multiplayer for now and won’t be doing any more tasks until I need to.

What I will do next time

Over the next couple of sprints I’d like to get the strategic overview of the game world working.  That means being able to look at your territories, as well as those of your opponents, viewing your team status and being able to select a territory to attack.  Some of these features might end up in later sprints, but here’s what I want to accomplish for this one.

When you start a new game you should be taken to the strategic overview rather than jumping into combat.  From here you will see the enemy territories and can select one to attack.  This means you will encounter different enemies with different equipment when when entering combat.

I need a UI for the strategic mode too.  Most of it will be placeholder buttons and fields for features to come, but I’m going to set up what I can now so that I can at least make it obvious what will be coming in the near future.

When you finish a battle you should come back to the strategic overview screen.  Later on I’ll put in a battle report view, and have the game overview update to show territory gained/lost, but for now this will do.

Finally I’ve got 2 areas that still need fixing after my move to multiplayer.  First of all the health bars in the team roster have stopped updating.  I’m not sure what I’ve broken there, but it shouldn’t take a great deal to fix.  Slightly more of an issue is that the character names and health bars aren’t pointing towards the camera anymore.  That’s going to take a bit more thinking about to get working correctly, but also shouldn’t be too difficult.

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

Leave a comment

Posted by on October 4, 2015 in Making a Game


Making a Game – Report 17

What I did

First thing this sprint was the “quick fix” to get the character’s rotations synced correctly.  It turns out that was a bit more tricky than I thought, with me using the wrong method to point towards a point 3 times.  For anyone interested, the correct method in the end was “Quaternion.LookRotation(pos2 – pos1)”.  I had to tweak it a bit too if your final move was going down a ladder, as it left a player facedown on the ground.  Unless a bug presents itself there’s nothing left to do with this one now.

After a fair amount of roughness, play now switches between players correctly.  I had a lot of trouble with this one, with it refusing to sync player names correctly, but it’s finally working. In the end, the trick was to realise that my game logic only cared if you were the current player, and beyond that it simply didn’t matter.  I had some issues where it was changing players, but not changing teams, and another when it was changing teams, but not players, but both of these have been resolved as well.

Finally I made it so that when play switches away from you, all the turn-based UI buttons are hidden from view.  You can still move the camera around, look at the controls, exit the game, etc (when the buttons work that is), but everything you shouldn’t be able to do, you are now prevented from doing.

What I didn’t do

I wasn’t able to start on synchronising health levels and character deaths. In fact, when doing some testing it seems these values aren’t even being updated on the div local machine. Quite a bit of work to do here.

It’s not enough to show a character lose health, you need to see the shot taking place. I’m going to create a small package containing the necessary information (character shooting, character shot, damage, hit success, etc) and that as a one big update when the Fire button is clicked.

When that’s finished I’ll be at a point where I can start working on the main game mechanics again. The first thing is to get the game over screens to show correctly, whether it’s a success or fail. When I’ve got something more interesting to display I can turn this screen into a battle report, showing the immediate and long term effects of the battle (injuries suffered , loot found, experience gained, etc).

Finally I’ve still got 3 videos left to watch in the UNET tutorial series I’ve been following, totalling 40 minutes. Shouldn’t take too long, and the next one deals with writing a customised HUD for the network manager, which I’ll need to do before too long as the default one isn’t very pretty.

What I will do next time

As mentioned above, I’ll be synchronising characters health levels and whether they’re alive. I’ll also rewrite the firing methods to send a package over so both players can watch the shot take place at the same time. Each player will be taken to the correct game over screen after finishing the game, and I’ll watch the last few UNET tutorial videos.

Currently the movement circle is shown even when you’re not the current player. It serves no purpose so it should be hidden.

Additionally I’ve noticed that the movement circle is reverting to its original size after you’ve confirmed a move. I’m not sure what’s broken here, it’s either the code for resizing the circle, or the movement mechanics. Either way, it needs fixing.

When you’re the inactive player you’re not alerted when your turn begins. For now I’d like to move the view to the character you’re controlling when this happens. I need to do something more than this, but I’ll think about that a bit longer before I try something with it.

Even though they can’t move anyone, the inactive player can still place movement waypoints. Should just be a case of adding an extra check when you try clicking anywhere to make sure you’re the active player.

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

Leave a comment

Posted by on September 24, 2015 in Making a Game


Making a Game – Report 16

This sprint didn’t go particularly well.  In fact I had so much trouble with the networking code that I had to extend it by an extra week just so I’d have something to talk about in this post, something I haven’t had to do in several months.  It’s safe to say that networking in Unity is one of the toughest things I’ve had to wrestle with since I started this project, and it’s the closest I’ve come to just giving up.  Partly that’s due to just how little documentation on the new UNET Networking system for Unity, as well as how complicated I made it all by starting to use it after writing a large amount of code.

For anyone reading this thinking about creating a multiplayer game in Unity I’d recommend you to a) wait several more months until there’s a lot more information out there, and b) Start working on the Networking code from day 1 so that the rest of your project is structured around it.  I’ve had to disable a large chunk of code to get working what I’ve managed so far, and it’s going to be a painful process to get it all working again.

What I did

Despite all this, I still made some progress.  I’ve worked my way through the entire official UNET manual, which was a lot barer than I expected.  It gave me enough information to go on for now, but it’s really missing a lot of the more useful stuff that you tend to see in the official video sessions.  Hopefully there will be more in the future.  In the meantime though I’ve worked my way through all but the last few videos of this excellent Gamer to Game Developer guide on how to use UNET, building a simple multiplayer survival game from scratch.  Despite not being the same style of multiplayer game as what I’m trying to make it was the far more useful resource.  If you’re planning on making anything from a first-person view, this series is the place to start.

I managed to get my little prototype game working too, where 2 players take turns clicking buttons to change the colour of some boxes.  It might sound trivial, but until I could get a basic turn-based program like that working then there’s no chance of getting the rest of the game working.  This took far longer than expected because of one simple item which I didn’t notice in the any of the UNET documentation I’ve read.  In UNET you can program a variable so that when it’s updated on the server the new value gets pushed out to the same item for each player.  You can also create a hook method which executes a method when this value is updated.  That’s pretty nice, but what I didn’t notice is that by adding in this hook it stops the value from being updated…  A rookie mistake, but now that I know it’s one I’m not likely to encounter again.

I’ve placed down a spawn point for each team, so that when you start the game each player begins in the same position as their team.  It’s not perfect yet as they both start facing the same direction, but it’s good enough for now.  You don’t choose your team either, it decides based on whether you were the first or second player to join the game.  That’s a feature I’ll be adding when I’ve created a custom network interface.

It took a lot of doing, but when you move a character in the game it’s position is updated on the other player’s machine.  Currently this sends the last position and moves them instantly so you don’t get to see it moving across the battlefield.  That’s something to work on in the near future, but as it’s mostly cosmetic I’ll be leaving that until after I’ve got the rest of the core networking code completed.

What I didn’t do

There’s quite a few tasks I didn’t get around to finishing this sprint.  I haven’t finished the entire playlist of videos in the GTGD UNET tutorial, but I’ve only got a few left now.  I’ve not begun making the turn-based gameplay work over networking.  Until I could get some basic things like movement synced up there didn’t seem to be much point trying to get the more complex areas working.  As I’ve accomplished this work already with my prototype it should now be reasonably straightforward to get this working here too.

I haven’t started making the combat multiplayer friendly yet either.  Right now a player can still move somewhere and shoot at someone, but the firing animation and damage is only inflicted on the local machine.  Damage should be updated on both machines, and you should also see the firing animation take place before this happens.

Finally I still need to take each player to the win or lose screen after the game ends.  After everything else is done and dusted, this should be a fairly straightforward task to complete.

What I will do next time

First on the list is to make the game turn-based again.  I’ve got the basic idea for this completed already in my little prototype, but transferring that to a larger game is a different task altogether.  As part of this I’ll want to disable the UI elements when it’s not that player’s turn.

I’m going to finish off the last few videos in the GTGD playlist too.  There’s only a couple left, but as he’s still making them there may be more by the end of this sprint.  Should still be doable though.

Next I’ll want to finish up something I left out for the movement.  When a player sends a character’s new position to the other player, the player’s position is updated, but they keep facing the same way.  It’s a quick fix, but they need to be lined up for when shots are fired.

For the combat I’ll first get the health levels to update when someone takes damage, and die if they run out of health entirely.  Then I’ll want to trigger a firing animation on the enemy machine so they can see the shot being taken.

Finally I want to make sure the correct screen is shown to each player after the game ends, whether it’s the win screen, or the lose screen.

This may look like a fairly short list for the next 2 weeks, but after all the trouble I’ve had with networking so far, I’m not going to overwhelm myself again.  If I somehow get everything on this list done, there’s plenty more networking tasks and bugs that I could work on before I begin the next sprint.

As always, you can see my current Trello board he

Leave a comment

Posted by on September 9, 2015 in Making a Game


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.

Leave a comment

Posted by on August 19, 2015 in Making a Game