RSS

Monthly Archives: August 2015

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

 

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.

 
Leave a comment

Posted by on August 6, 2015 in Making a Game