Monthly Archives: September 2015

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