Recent development has all been around ship combat, and most recently creating item drops. Next in that development is adding the UI interface to access item drops and choosing what you may want to move to your cargo hold, and the same interface will be used for gathering resources from the sea, such as fishing or whaling. Following that will be a similar interface for managing cargo at ports, and outfitting your ship, and after that is done work will begin on the market system for buying and selling items at port.
I call what I've been in lately "item hell", because even though these are central components of the game, they are not very satisfying to work on, let alone extremely complicated and delicate systems. After responding to a thread on the Unity forums about implementing a day/night cycle, I decided to go off on a tangent and do the same in Broadside right now instead of later. A day/night cycle was always in the required features list for Broadside, so this was getting done sometime soon no matter what. It also bothered me that this was the last remaining feature of the early prototype version of Broadside Online that has not been implemented in the current iteration.
Universal Game Time
So the world in Broadside is chopped up into a long series of zones, each managed by their own server instance. Broadside is a game that will cover the entire world, at least what is accessible from the oceans, so I wanted the day/night cycle to reflect that. So when you are in the same zone as London, it will be a completely different time of day than in Bombay.
Most zone servers though are not active at any given time. The world is so huge, that it is silly to be wasting server resources simulating a zone if no player is currently occupying it. So zones will be started and stopped all the time as players move around the game world. There needs to be some central authority on the time of day for the game world even when a zone server is offline, so it will know what time of day it is when it eventually starts up. The Tracker server mentioned in an early blog entry is that server.
So the Tracker server will maintain what I call Universal Game Time. This is the time of day in seconds at longitude 0. Effectively London time for this discussion. When the Tracker server starts up it will always be UGT 0, which is midnight in London, and the Tracker server continually increments this at a multiple of real time. Right now the plan is to have an entire day/night cycle take 2 hours, but that is easily adjustable when getting to the later polishing phase of development.
When a zone server starts up, it already makes a connection to the Tracker server for other reasons, such as player chat functionality and character skills updates. Now when a zone server first connects, the Tracker server will respond with the current UGT. The zone server then applies an offset to the UGT based on roughly what longitude the contents of the zone server represent. The zone server then increments its own local time independently using its TimeController. To avoid drift from UGT over long running periods, the Tracker server will periodically send updates to all active zone servers.
When a client connects to the zone server, one of the last things it does is spawn the player's ship object. This occurs after everything else is set up, including the client copy of the TimeController, so is the perfect time to tell the client what local time it is. Once the client receives the local time, it orients the directional light (the sun), and adjusts global illumination and fog colors to match the current time. The client copy of TimeController then increments local time on its own, receiving updates at noon and midnight from the zone server to correct any drift. The TimeController on the client continually adjusts the sun direction and all other day/night cycle variables, and also handles requests from objects with torches to tell them whether they should be lit or not.
Not too complicated, just thought you might think it was a bit interesting how the system works.
