[Unity3D Hex Map Game Dev] 50: From Single To Multiplayer (AI Realms)
00:00 Intro
01:15 How Visibility and Exploration Works
06:30 Exploration Per Player
07:40 Complete Per Player Split
08:23 New Player Script
09:14 Testing Multiplayer
10:03 Player Colours
11:25 Outro
Subreddit:
/ world_turtles
Discord Server:
/ discord
#worldturtles #unity #indiedev
Hello and welcome back to coverage of the development of World Turtles. For the last two months or so I’ve been focussed on the Steam Next Fest, and I’m glad to report that the total number of wishlists for World Turtles just about doubled during the festival – one week of exposure lead to as many wishlists as all my previous efforts combined. I’m glad I participated! But now that it’s over, it’s time to add some content and functionality to the game again. We start off with a big one: changing all the behind-the-scenes structures and methods from single player to being able to handle multiple players. While it will only be used to incorporate AI players on the same computer for now, you can actually cycle through the players and give manual commands to all of them, with all the UI also updating to the player’s situation. Maybe in time I’ll be able to turn it into proper multiplayer by allowing different players on different computers to play over a network, but I’m quite happy with how the first step turned out. And it was actually easier than I thought it would be! Let’s see what it took to implement.
(Intro)
When I started off on this quest, I planned on only implementing a small part of it – the exploration bit. The reason was that I’d introduced Tribal Camps to the game – the first non-player buildings and units. However, in the background, units weren’t allocated to different groups – everything was one big list of units. I had to set the vision range of the Tribe members to 0 to prevent them from exploring the map, and, because I placed them in unexplored territory, I had to allow them to ignore map vision states altogether in order to allow their pathfinding to work “in the dark”. (Al Pacino clip) I clearly had to do something about it, and I started with the exploration and visibility. Let’s quickly recap how it had been working up to that point for a single player:
Each hex keeps track of how many units it can be seen by, as well as whether it’s ever been explored. There’s also a flag that indicates that the visibility has changed, so that the shader can be notified. Every time a building is placed, or a unit changes hexes, the visibility of the hexes around it needs to be updated. If the unit can see the hex, we increase its visibility counter. If that counter equals 1, it means one of two things:
Firstly, it could be the first time the hex gets explored, in which case we set the explored indicator to true and update the minimap ranges.
Or, it had been explored before, but was in fog of war and is now re-explored, in which case we need to remove the fog of war.
For both of these we schedule a refresh of the cell’s overlay. This shows or hides the resources, buildings and units on the hex according to the visibility.
It could be that a specific hex is seen more than once in an update cycle, but we don’t need to refresh the shader each time – we just need the shader to update with the last value of visible. So, we flag it as soon as it is updated, schedule the shader update, and don’t schedule another shader update thereafter. The shader update has to run on the main thread, and as soon as it has, we reset the visibility updated flag, so a new cycle of updates can start. There’s a similar method for decreasing the visibility, and this would be applied to the hexes the unit could see on its previous hex change, yes, you heard right. There’s also a method for resetting the visibility to zero.
Now, we manage our visibility changes on a separate thread, so we have a method that’s set up to consume visibility tasks. Each visibility task has a reference to either a unit or building, which cell it relates to, and what vision range to apply. There’s a method we won’t go into now that returns a list of hexes that are visible from the unit’s location, given its vision range and the terrain elevation. We increase the visibility for each hex in this list. Then we decrease the visibility of the previous list of hexes for the building or unit. We also store the current list of hexes for the building or unit, for the next cycle.