Lots of small improvements

The last few months have focused on nice to have and quality of life added features, bug fixes, some visual improvements, and overall polish of the game.  Going forward for the next few months will be more of the same.  Adding somewhat minor features which make the game a more rich environment, add to the complexity of the gameplay, polish menus and the combat system, and fix any important bugs. 

In the next release (0.8.6) currently there are fixes checked in for a major bug with ship flooding and a minor bug with the teleport feature.  More known bugs are being targeted for this release, as well as some additional feature development.  Specifically the bug where on ships with multiple side gun decks sometimes when you switch decks it switches back to the previous deck is the next to be worked on (this was looked at over a year ago and unfortunately not correctly fixed). 

As far as feature development, ship fires, selecting ammunition types at sea, and adding the Heated Shot ammunition type, are the next features being worked on.  When that is done additional resource types and resource gathering will be added, specifically fishing.  0.8.6 will be released at some point during these features being added. 

After that, focus will switch back to the City UI, which while I thought it was somewhat innovative, play testers have reported it to be an initially confusing interface.  I'm going to experiment with switching the listing and moving of items to a drag and drop interface and replace tables of items with icons of items. 

Additionally the ship outfitting and customization part of the City UI (basically the current left size of the window) will be broken out into its own window.  Naming of ships will finally be added (the back end has supported it for a long time, but the UI interface for it was not implemented correctly).  Some additional ship customization features will also be added, such as Lieutenants assigned to ships which can be trained and provide ship bonuses. 

This is all in preparation for the start of actually promoting the game, raising awareness, and a eventually a possible crowd funding campaign to support eventual marketing and finishing its development. 

Texturing

Some experimental texturing.  This is Norway, how does it look?

Improved Smoothness

A problem with Broadside: Perilous Waters has been the smoothness of the client side movement of objects, such as ships and cannonballs.  When I replaced Unet with the in house JCGNetwork system, I wrote a script called JCGNetworkTransform, which basically fills the role of Unet's NetworkTransform.  Essentially it syncs the position of an object from the server to the client. 

Now the NetworkTransform component from Unet was poorly documented, buggy, and overall didn't work very well.  JCGNetworkTransform was marginally better originally but would result in jittery motion especially for objects at high speed.  It has several modes, but the one I primarily used I called SmoothRB.  It would sync the current position, rotation, physics velocity, and angular velocity.  The client would apply the two physics values and apply the position and rotation over time between receiving new updates. 

In theory it seemed like it would work well, but the result was updates from the server don't come in at an exactly regular rate, and it was difficult to smoothly transition between the last position and the new position while the client was applying its own physics simulation.  I worked around this issue at the time by maxing out the send rate to match the server side 25 FPS.  But this just shrunk the problem instead of eliminating it, and created a new problem where the maximum number of players per server would be lower. 

Now I've written a new simple Interpolate mode.  It works by maintaining a queue of incoming position/rotation updates on the client and tries to keep to a specific target count in the queue.  Currently the queue target is just 1 so it is more responsive, but sometimes I may want to target a higher queue.  A higher queue count would reduce the chance that the client attempts to move the object but the next update hasn't yet arrives, at the expense of being further behind the position on the server. 

So now the server in these updates sends the current time, and the client can then interpolate between the last update and the current update being processed for the same amount of time the server took between those updates.  If the client gets behind replaying these updates it ever so slightly increases the speed it processes them in order to catch up over time, and if it gets ahead it either pauses or slightly slows down the movement.  All physics simulation on the client side is now disabled when in Interpolate mode. 

This has resulted in a much smoother movement of object movements, both ships and cannonballs, than before.  I'm still tuning the system, but it is looking good.  I've also increased the server side FPS and physics updates from 25 FPS to 32 FPS, and reduced the position update frequency from 25 FPS to 16 FPS.  The former was done to address an issue with very fast moving cannonballs from long guns flying through the smallest ships at close range without registering a hit.  Originally it was set so low to help with a CPU usage problem on the server side, but other improvements to address this over the past few months have allowed a little more head room to raise this back up again a bit. 

Hope you found this at all interesting.  This stuff will be included in 0.8.1. 

0.8.0 Releasing today!

Big update with 0.8.0!  All of Europe is now ready, the world is on fire with a war centered around France, the Ottoman Empire is hostile to most of Europe, and there are now two Galley class ships which can use oars to go directly into the wind!

Very excited, as the game is coming along quite nicely. 

Adding Galley Classes

The next release will be 0.8.0, and with it will come the Galley.  This is a type of ship with an alternative form of propulsion, specifically oar power.  All galley type ships will have sails, but sail power is not the primary means of moving most of these ships.  You'll be able to get to high speeds, even directly into the wind, using oars. 

These ships will have very large crew compliments, and relatively small cargo.  When food/water becomes required to feed your crew this will make them not ideal for long journeys.  What they are ideal for are fast attacks near coastlines, especially inside inland seas.  Their large crews will also help when the boarding mechanic is eventually added to the game. 

Teleport and Scuttle

A requested feature is quickly moving yourself to another location on the map, similar to "podding" yourself in Eve Online.  This will be included in 0.7.14.  To use this feature, you click the Menu button, then click Teleport.  From the Teleport window you can save your current location as your saved teleport location, or click Teleport Now to teleport to that saved location. 

To teleport you must be sailing an Escape Class Dinghy.  It will not be available for any other ship class.  This is so you can quickly move yourself to where your ships are stored after a loss, so you can get back into the game rather than potentially sailing for hours in your dinghy. 

Another feature being added to 0.7.14 is the ability to scuttle your own ship.  You click Menu then Scuttle.  To scuttle means to intentionally sink your own ship.  This will immediately flood your ship, which will cause it to sink as if sunk in combat.  The ship will be lost, as well as crew and items, as in any ship sinking. 

The scuttle feature is probably most useful in combination with the teleport feature, allowing you to quickly get into an Escape Class Dinghy so you can teleport. 

Lastly, I'm planning to add an in game bug reporting feature.  A button has been added under Menu, though the feature won't be ready for 0.7.14, but will be added in the future. 

Networking Code Gets Complicated

Disclaimer: You'll only find this interesting if you're curious about network game programming.  Otherwise you might as well skip this one.  

So I noticed a couple months ago that there was a problem with the positioning of ships far away from the player.  Their position was not updating properly, or not at all, until the player gets within distance of about 2/3 the way to the edge of the minimap to them.  Then they suddenly snap to the correct position.  Now that is the distance as seen on the server, not the client.  The biggest problem on the client is when ships have moved far away from their starting position the player could approach what they believe to be a nearby ship and get right onto them, but that ship is actually very far away and the client is just not getting an update.  

So this was confusing to me, because this was not always the case.  When I originally wrote and tested the network API this appeared to be working fine.  I've also seen it working fine in Broadside previously.  But I have made some updates to the network API since then, and changes to the ships themselves, so I was not sure when this broke or why.  I did though know it had something to do with being subscribed or unsubscribed.  

Object Subscriptions

So to reduce network traffic and support larger numbers of networked objects I created a system built into the network API I call Subscriptions.  The way it works is periodically at a set interval the zone server checks range from all connected players to all other networked objects.  Any objects within that range the player's connection gets subscribed to, and beyond that range they are unsubscribed.  Networked objects are anything the server controls and syncs with the clients.  Ships and cannonballs are the best examples, but there's actually even more stuff.  

Currently I'm running the zone servers at a frame rate of 25 frames per second, and sending position updates for ships specifically every 1/25 seconds, or about every server frame.  That is the rate for subscribed clients.  If the client is unsubscribed to the object I was sending an update once every 2 seconds.  This significantly reduces the amount of data the server needs to send to each client, but shouldn't look that odd since those ships getting slow updates are far away.  

There's more to subscriptions than just that too.  Such as syncing specific variables only to subscribers like how much flooding a ship has, how many crew it has.  When a client gets subscribed all these "SyncVars" are automatically synced all at once to the newly subscribed client, so there's no difference really if it is information the client only needs when they are close to the object (those 2 specifically are just used for displaying above the ship at close range).  

Investigation

So I determined the positioning problem was only affecting objects the player was unsubscribed to, primarily ships.  What is going on with the unsubscribed ships?  Looking at the code I didn't pick up on anything obvious.  I first tried reducing the unsubscribed update frequency to once a second.  No change.  I found a bug that in certain circumstances could cause a network object which snapped to a new position on the client to be moved back to a previous position, which may appear that it didn't actually move.  That's the bug I fixed for 0.7.12 mentioned in the dev log.  That turned out not to be the cause though.  

I investigated if sending messages targeting unsubscribed clients in general was broken (I don't use this in many places in the code, so it was possible), but no dice.  The network API uses a channel system, where each channel has different settings.  Settings include whether to send with encryption, to send reliably, to hold short messages for a short time to allow for other messages on the same channel to be combined, etc.  The JCGTransformSync component that handles syncing positions actually is the only thing which uses channels 2 and 3.  Channel 2 is used for subscribed clients, and channel 3 is used for unsubscribed.  Almost everything else in Broadside is either on channel 0 or channel 1.  Ah ha!  Something might be set up wrong with channel 3!  

Nope, nothing wrong with channel 3.  

I looked at a lot more areas of code, more investigating, and today I finally found the issue as I was walking through all the code involved.  

The Cause

So the issue ended up being in JCGTransformSync itself.  Even though I send position updates 25 times per second to subscribers and now 1 per second to unsubscribed clients, I only do so if the object has moved since the last time an update was sent.  I send the update and save those values.  The next time I try to send an update I check if the object has moved more than a certain amount (very small amount) and only if so do I send the update.  This means that a large fleet, even if you are subscribed, actually generates next to no network traffic if they are not moving.  

The problem was I send the update to all subscribed clients, save the new position sent.  Then I try to send to all unsubscribed clients and first compare the current position against the last sent position.  Well it is comparing against the position just sent to the subscribed clients a moment ago, which is exactly the same as the position now obviously.  So no unsubscribed updates are sent to anyone.  

This bug though has been there since I originally wrote JCGTransformSync though, why didn't I see it back then?  I've only noticed the issue for a few months at most.  

Ahh, the bug has existed since Broadside 0.6.0, since September 2018, but it only became really noticeable starting in 0.7.2 when I changed the update frequency from every 1/10 second to every 1/25 second.  You see at a 25 FPS frame rate when sending updates to subscribers every 1/10 second there will be some frames when I don't try to send an update to subscribers but I do try to send an update to the unsubscribed clients.  The objects are all really distant so I probably didn't notice they weren't happening as often as they should, but the positions wouldn't end up that wildly off as they have been.  Now that I'm sending subscriber updates every frame (even when there aren't actually any clients subscribed it still runs through the code as if it is going to but just doesn't send anything out) there never is a frame when attempting to send to the unsubscribed in which I didn't already attempt to send to the subscribed.  

So now I changed the code so whenever it tries to update the unsubscribed it ignores if the object has moved or not.  It just sends them.  Sending an update every second or two for each object isn't a lot of traffic, but I may revisit this later to track last sent subscribed and unsubscribed positions separately.  But for now this feature should be working.  

Adding Zones

So I've been slow with the current work.  Last month I finished the feature of the master server spinning up and down the various zone servers.  This now makes possible the ability to fill out additional zones, as previously any zones in the game had to be started by the master server and couldn't be spun down.  This put a hardware limitation on the number of zones which could be running at the same time (around 5 on the relatively low spec test server, even though the current live server can support more than 3x that many).

Now I've been adding additional zones, currently I've been adding the Netherlands, North Sea, Baltic Sea, the Shetlands, and some ocean west of Scotland and Ireland.  The plan is over the next few months to add all of Europe and go out into the Atlantic towards North America.  I ran into a problem though with how I was triggering a zone transfer for the player.  What I had been doing, and was working fine up until now, is manually placing trigger colliders onto the map.  When the player enters a trigger collider for an adjacent zone the zone server would then attempt to send the player to that zone.

The problem though was in placing those trigger colliders by hand.  This was easy around the UK since the land provides some easy reference points.  When getting into borders between zones that are out to sea though there are no such reference points.  After struggling with this for about a week, I decided to redesign the system.

Now in code each zone is a list of bounding boxes, with a north west latitude/longitude point and one to the south each.  Already the zone server recalculates the player's lat/long position every second or two.  Now this will be checked against all zone bounding boxes, and if the location correlates to another zone then the zone server will attempt to transfer the player.

This should eliminate problems placing the trigger colliders, which when misplaced can result in the player transferring to another zone then immediately getting transferred back because of bad placement.  This will also eliminate the overlapping area between zone servers where two players can at the edge of a zone actually occupy the same location while connected to two different zone servers.

So I'm optimistic I will have this all completed within the next day or two and pushed out to the live server after testing.  After that I'll start working on the French, Spanish, and Portuguese coasts, and then the Mediterranean.  This will make for a much more expansive game compared to now, letting the player travel for hours discovering new lands.  :)

Edit:
The new zone transfer system and new zones are now undergoing testing in 0.7.11 and it has been very successful.  After additional testing is done, and some relatively minor bugs with the new zones are resolved, the build will be pushed to the Perilous cluster. 

Some gameplay footage

Here's just a bit of raw gameplay combat.  Click below to play the video.  This is a fight between British and French NPC's outside of London I sailed into and joined in.  Nothing special.  

Sometime soon I'll post some better videos with commentary.  But just a taste here for now. 

Things coming along, zones can be started/shutdown as needed

In 0.7.10 I'm now finishing the feature where zone servers can be automatically started and stopped as needed.  A while back I had implemented automatically starting zone servers when a player travels from one zone to the next, but it was never used because when you first log in the login server and the login client scenes still assumed the needed zone server was online.  So up until now all implemented zones have always been started and kept running.  This has limited further implementation of more zones. 

Currently there are 5 zones implemented, covering the entire British Isles region.  My development test server is an 8 core FX CPU, which can support running around 6 zones at most at the same time.  5 works better though.  So I've been maxed out in what I can test before pushing to the live server.  The live server has 16 opteron cores which each core is better performing, so it can probably support around 16 or more zones, but I don't do initial testing on that server.  The live server cluster will eventually have more servers added as well.  I'm targeting roughly 50 concurrent zones when the game goes public, maybe more. 

But these new changes are the most important step for adding new surrounding zones.  So now, when the master server starts up it automatically starts expected high traffic zones only, which are the national capitals.  Currently that is just London (zone 0).  Then as needed other zones are spun up.  When a zone is idle with no players for 30 minutes, it reports this to the master server.  If the master server is in the normal auto mode, it then tells the zone server to spin down.  Later when a player needs that zone again the master server will spin it back up. 

So after this functionality is all tested, this will allow me to expand the game to further areas.  The plan is to do northern Europe, the Mediterranean, out into the Atlantic, and down the African coast, eventually getting to India.  That will be a pretty large area and cover over half of the nations.  Then tackle east Asia and the American east coast to finish adding all nations.  After that it will just be a process of finishing the entire world map. 

Broadsides now implemented

In 0.7.8 you can now fire a broadside either port or starboard using the buttons on the cannon tab in the bottom left.  When you fire a broadside you do not need to be looking down the sights of the cannons on that side of the ship.  You can even be in 3rd person camera mode when doing so. 

How this works is you have to go to Battle Sails.  After 6 seconds at Battle Sails the broadside activation buttons become available.  When you fire a broadside all cannons are fired parallel to the sea, straight left or straight right from the ship.  If you are aiming the cannons, your aim is ignored.  You cannot manually fire cannons on that side of the ship until the broadside has completed. 

Cannons are fired in highly rapid succession, much faster than manual fire.  If your ship has multiple gun decks on each side, ALL GUN DECKS ARE FIRED AT THE SAME TIME.  The ships with 3 gun decks on each side get the most benefit from this.  Even on the largest ships, all guns are typically fired in around 1.5 seconds.  Ships with fewer guns even faster. 

The biggest negative is since you cannot aim guns up/down, ships with guns mounted high above the water may shoot over small ships.  In that case you should continue firing cannons manually instead of using a broadside.  Firing a broadside is most effective against larger ships.  Large Frigates vs large Frigates, or between Ships of the Line. 

Faction Warfare

Now that the nationality system is largely in place, the AI ships' behavior is going to be changed for 0.7.6 to take advantage of this.  Up until now the AI attacks any players, and are all of the Pirate faction.  Starting in 0.7.6 the AI will instead find targets based on relations, including targeting other AI. 

As far as the Pirate faction, you won't notice any change, since Pirates are at war by default with all nations.  What will be interesting is AI will be implemented for other nations, not just pirates.  Most of the AI ships in high populated areas, such as the English Channel, will be replaced with ships relevant to the area, such as Britain and France.  More remote areas will continue to primarily have Pirates.  

Part of the fun will be that Britain and France will often be in conflict, as they were historically.  You'll get to watch these AI fight each other, participate in it yourself, if chased by Pirates you'll see them come to your rescue if you're in range.  Going to make for a much more lively world, where things are happening on their own that you can join in, rather than all the content revolving around the players.  

Flotillas and Taking Prizes

Flotilla Basics

The plan now is to add a pretty fun feature called Flotillas.  These will be AI ships owned by the player, which follow the player around.  Effectively these allow the player to lead their own mini fleet.  This can be a force multiplier for players who wish to play solo, as well as allow for much larger squadrons of players. 

The entire feature isn't planned out yet, but the idea now is that the number of flotilla ships a player can control will be based on their Command skill level.  Maxing out at around 3 AI ships. 

Taking Prizes

This feature will also be the key for capturing ships.  There has been a plan to add boarding enemy ships, but without a way to take control of the ship the only options from a successful boarding would be to take the cargo and release the ship or scuttle the ship.  I wasn't happy with this, because historically boarded ships were often taken as a prize. 

So the plan now will be that flotilla AI ships will need to be ships the player's character has sufficient skills to operate themselves.  Bonuses from the character's skills will not be applied to flotilla ships (so they will operate like all AI ships as if they have no skills).  A boarded ship taken as a prize will follow the same rules.  Once successfully boarded you will get several options:

• Take any/all cargo and fittings
• Release the ship
• Scuttle the ship
• Take as a prize

To take a ship as a prize requires the player's character to have skills to operate that ship.  All surviving crew will be pressed into your service.  I'm probably going to include an option to transfer crew at this point to/from the prize ship.  Any fittings which the player's character does not have skills for will be transferred to the ship's cargo.  For example, if you take a prize ship with guns you don't have skills for, they will be removed from the ship's fittings and end up in the cargo hold.  The prize ship then gets added to your flotilla.  You won't be able to take a prize ship if it would exceed your flotilla limit. 

More Flotilla Stuff

Flotillas will not allow the player to directly control the ships, but will allow some general orders, such as to follow you or attack enemies.  Otherwise the ships will generally run themselves like any other AI ship.  They will need to be fed with ammunition, and can be sunk, like any other ship.  When the player joins a squadron with other players, flotilla ships will also join the squadron. 

Flotillas can be used in a variety of ways.  Certain ship types are not recommended to sail solo.  The most obvious examples are Carracks which lack the firepower to defend themselves and often carry a large amount of valuable cargo, and Ships of the Line which are vulnerable to swarms of smaller vessels.  A flotilla makes these ships more practical for solo players. 

You can sail a Carrack full of cargo and have several Frigates or Corvettes in your flotilla as escort.  Or you sail one of the Frigates and let the AI play online trucker simulator with the Carrack.  Similarly you can sail your Ship of the Line with Frigate and Corvette escorts.  When capturing of cities is eventually added, I imagine flotillas full of Gunboats (such as Ironclads) will be popular for their defense. 

One additional benefit of a flotilla is when sailing solo and your ship is sunk, you get placed into a dinghy and must return to a city to grab a real ship.  Instead you will be transferred to another ship in your flotilla if available.  This helps you stay in the fight longer, and allows the possibility of scooping up your own loot. 

Well, I'm pretty excited about this feature, and expect to have it implemented within the next month or two after the nationality system.  I'm hoping this helps Broadside: Perilous Waters stand out against other similar games. 

Nationality

So I wanted to implement different colors in the minimap for ships which are friendly, part of your squadron, at war with, etc, but realized I need to fully implement the faction relation system first.  So I've started working on that at this point. 

The way you get assigned a faction, or referred to as "nationality" or "nation" in game, is when you create your character you choose your character's nationality.  Then there is the simple concept of "effective nationality" which is displayed in the Character Info window when viewing a character.  Basically, if you are a member of a trade company, your effective nationality is the trade company's nationality.  Otherwise it is your character's nationality.  So at any point you wish you align your character with another nationality, you just need to join a trade company of that nationality. 

The various nations though will have relations with each other, from friendly to at war.  Players will be able to attack any ship of a nationality they are at war with at any time, while attacking a ship of a friendly nationality will be more restricted (haven't decided on the specifics of this restriction yet, but most likely your cannonballs just will have no effect in some zones, like near major ports, but still debating whether to go Eve Online style and just have a mass of AI attack you or otherwise have some other negative effect). 

These relations will be set by the developers, and used as special events to stir the pot a bit to have a little fun with when they change.  Britain and France will often be at war, but this can periodically change.  Everyone will be at war with the pirates most of the time, but a nation could theoretically be at peace temporarily with the pirates, making even AI pirates no longer attack those players. 

After this system is fully implemented, then I can get back to my original task of the minimap colors :)

0.7.3 is out

Another relatively small list of changes for a new build to get it out quickly.  Primarily this was done to reduce the AI ships attacking the new player spawn area near London.  But the major features added are the wind directions now change instead of always coming from the south west, and the squadron chat box has been implemented. 

Increased update rate

Released 0.7.2 with just a change to increase the server send rate for updating the position of ships and cannon balls.  This smooths out the previous jitters you'd see with ships moving. 

0.7.1 now live

Version 0.7.1 is now live, with lots of bug fixes, network improvements to protect against problem network packets, an important ship speed bug fix, small feature improvements, a refactoring to improve script performance, and more challenging AI spawns.  The squadron and private chat features didn't make it in yet, as well as coloring the minimap ship icons, but they will be in a future build. 

There was enough work already in this that I thought it was worth releasing without those additional features ready though. 

Cleaning up some technical debt

Well, there's been a growing problem that has finally been resolved with about 8 hours of work.  That problem is the GetComponent call, or more specifically bad early design resulting in the overuse of it.

So somewhere around 1/3 of the code in this game sits on two GameObjects, which are core to the function of the game.  There is the Player GameObject, which handles authentication, represents your character, and contains all of the client to zone server RPC's.  Then there is the Ship GameObject, of which there are various versions of it, representing of course the ships themselves.  Pretty much all of the code related to the ships is attached to these Ship objects (more code than you'd think).

The problem was that the main reference on the client to the Player GameObject was to the GameObject itself.  This created a problem because whenever something like a UI window needed to talk to the Player GameObject it needed to do something like this:

PlayerObject.GetComponent<Player>().DoSomethingCool();

I tried to limit the number of these calls, and cache the reference in other scripts sometimes, but these GetComponet calls were still all over the place.  To make maters worse, even the scripts on the Player object itself when needing to talk to other scripts on the same object would usually use GetComponet as well.  This was all done early on for expediency of development, but since GetComponent is a relatively expensive call compared to using a cached reference, this is a performance problem.

Even worse though was the Player script maintains a reference to the player's Ship GameObject the same way.  Now there are a ton of scripts attached to the ships, and several months ago I created a ShipComponents.cs script which has references to all the other scripts on the ship, and every ship script has a referernce to ShipComponents, so there was no problem there.  But since your ship can sink or be swapped out in a city, I can't just cache a reference to components on the ship.  I have to check all the time if the ship has changed in various scripts and then update cached references.  This gets expensive.

Stuff like this was happening, and sometimes a lot worse:

PlayerObject.GetComponent<Player>().ShipObject.GetComponent<ShipComponents>().ShipMovementComponent.TurnOrSomething();

So long story short, I went and added references in Player.cs to all other Player object components, and the reverse as well.  I then changed the main reference to the Player GameObject maintained to a reference directly to Player.cs.  Then I changed the ShipObject reference that is maintained in Player.cs to a reference to its ShipComponents.cs script.  This cut down around 95% of the GetComponent calls related to these two GameObjects.

This resulted in close to a thousand lines of code rewritten carefully to avoid breaking any existing functionality to fix this issue. 

Yeah!!! :p

Trying to turn up the fun

So the latest testing is showing the game is too slow paced still.  Part of that is that players aren't yet interacting with other players (seeing that the game hasn't launched yet), but part of that is the very large maps are just too slow to get across and fights with AI ships are too spread out.

So I'm going to yet again increase all ship speeds significantly, and increase AI spawns.  Also, going to add more AI ship classes and make it so AI ships that have not moved in hours will disappear, which will trigger them to respawn at a new random location.  The last part is to address an issue where AI ships on far off edges of the map might not ever be interacted with, and they tie up one of the available AI spawn slots basically.

Additionally, a yet unexplained issue with server crashes is occurring that is being investigating.  The symptoms are after 4+ days of run time the server processes randomly exit with no log message.  This is occurring on both server clusters, so is not hardware related.  The original plan has always been to shut down and restart the server processes each night, but currently to do so is a manual process (connect with the Command Console app, order cluster auto shutdown, wait 5-10 minutes for shutdown, and then run the startup script).  For 0.7.1 I'm going to make this an automated process.

edit:
Added a couple new AI ship spawns, rebalanced all the spawners, and increased the number of spawners per zone.  Also the 20 ship AI fleet spawner has been reintroduced (was previously removed for performance reasons, but performance has been partially addressed in 0.7.0).

Found a possible bug in some ship speeds not matching what was expected, where the "fun factor" speed multiplier was not being applied properly.  This should be resolved, and will tweak speeds in the future as needed. 

0.7.0 Going Live

Version 0.7.0 is now going live.  The squadron feature and player info features are now included.  A few sub features of squadron are not yet available, such as squadron chat even though the chat box is there, and you can't kick other squadron members.  The player info window also has non-functional company invite and private conversation buttons, but the squadron invite button does work. 

In 0.7.1 those missing features will be implemented, as well as color coding the ship icons on the minimap for squadron members. 

I'll also try to get in some of the resource gathering, such as fishing and whaling. 

Until work on 0.7.1 starts, I'm going to put 0.7.0 up on Steam for testers, and the download link outside of Steam will be available on this site as well. 

Hind Class Galleon

A lot of exciting changes going into 0.7.0

So 0.7.0 is getting more than the usual amount of work for a new build.  The Squadron system is already mostly functional now.  Mostly UI work is still going into it.  The Player Info window is already done.  A bunch of minor fixes are also going in. 

Work has started on Trade Companies, but this build is going to go out before that work is complete.  So expect that to be working within a few months. 

This though will be the first build to be pushed to Steam for better access to beta testers.  Currently I'm just putting the builds in a self extracting archive and posting a drop box link, which will still happen when this build is ready.  This is problematic because the builds are quite large already, and will continue to get larger.  0.6.14 was 419MB.  When all the other terrains get added, we are probably looking at several GB eventually.  Repeatedly downloading new builds is a hard ask for some testers, especially when on metered connections. 

Steam though uses a diff like update process, where it only sends the changes from the previous build instead of downloading an entirely new build.  This will save a whole lot of tester hassle.  Relevant Steam keys will be provided to testers. 

Adding Squadrons, Trade Companies, and Steam

Squadrons

Squadrons are player created temporary fleets for organizing players together.  They are used for players to cooperate together, generally for some temporary goal.  For example, a bunch of players want to form up to fight another group of players.

Squadrons will label all members with a squadron color, which overrides other colors for the purpose of determining if the player is friend or foe.  Squadrons have their own chat channel, and all members can see all other members' location and ship class.  Any member of a squadron can invite other players to the squadron.

Trade Companies

Trade Companies are player created organizations, often called clans in other games.  These are semi-permanent and meant for long term cooperation of players.

Trade Companies have their own separate city storage, can control entire port cities, and have their own separate chat channel.  Only the CEO or Directors of the company can invite new players to join.

Steam

Broadside: Perilous Waters will be available through Steam.  The game has already been added to Steam, but not yet uploaded.  Work is starting soon to add the Steam API to the game client.  After that is done then game testers will be provided the appropriate keys for accessing the client through Steam instead of having down manually download a new client version each time there is an update available.


Edit:
A lot of this is entailing some unfinished work on the Tracker server.  Currently implementing a feature where the Tracker server gets repeated updates on the status of all online players.  Without this functionality at this time there is no way to know exactly what players are currently in the game.  But this will be a central location where all player movement is tracked.  The Squadrons system leverages this, because the Tracker server will also continually send squadron updates to all zone servers which have players currently members of that squadron. 

The squadron updates contain the locations of all other members of the squadron as well as what ship class they are sailing, which is then sent to each of those players on a regular basis.  This will allow the squadron UI window to display fairly up to date statuses of all other squadron members, so everyone will know how far away other members are and what their capabilities are. 

Something similar will be available for trade companies, but will likely update on a less frequent basis. 

Eventually when the private chat message is added, this will also leverage the player tracker, so chat messages are routed to the correct zone server to be sent to the player. 

Adding new ship classes

0.6.13 was successful, and testers are having a good time with it.  0.6.14 is going to focus on adding new content.  Currently adding the Hind Class Galleon.  After that is added, going to add one of the early Frigates, another Caravel, a Carrack, and possibly an early Ship Of The Line.  Should bring the total supported ships from around 7 to 12.  Going to also add AI using some different ships.

After that going to focus on improving item drops (currently only drops from cargo instead of items fit to the ship), and after that improving the AI's weak combat ability.  Make them much more likely to connect hits.

Edit:
The following ship classes have now been added, and ready to use in the next build
Santa Clara Class Caravel
Santa Maria Class Light Carrack
Hind Class Galleon
Essex Class Race Built Galleon
Niagara Class Corvette
Nantes Class Early Frigate

Latest Development

Current development for 0.6.13 will be:

1) Add ability to switch between the Perilous and Development servers
2) Add effects of bonuses for all skills - currently skills only work for unlocking new items and skills, but any bonuses aren't yet implemented
3) Add effects for Bilge Pumps, Reinforced Hull, and Copper Plating - currently they can all be installed on your ship, but they don't provide their advertised bonus
4) Further adjust ship speeds (likely increasing full sail speed again, while keeping speed while under combat sails to keep the speed approximately the same as now)

New Live Server

Up until now all testing has been done using an internal dedicated server.  It has been difficult keeping beta testers interested in playing because I frequently take the server down to upload new test builds, making the client testers have no longer usable until I build and send them an update.

Starting this week though while all development testing will be on the same internal server, a dedicated server has been rented for use with game when it goes live to the public (eventually it will be a cluster of physical servers, but that is not necessary at the moment).  That new server will host the public version of the game and will be updated far less frequently and remain running all of the time.

Edit: Now referred to as the "Perilous" cluster, the new server is now in use with 0.6.12's release.  Internal game play testing is now using this server instead of the development server.

Adding New Zones

I've been stuck for a while trying out various tools for implementing terrain from around the world over the past 6 weeks.  Mostly these take hours for a single attempt, so take days to repeat to try to fine tune.  This has been in an effort to improve the work flow better than what was used to bring in the original terrain for zone 0's English Channel.  In the end I've had to return to the original workflow. 

This makes it more difficult to plan out what terrain will end up in what zone, but it still is a relatively fast process (minutes instead of hours), is smaller in disk space than the other tools I tried by orders of magnitude, and still produces an acceptable resulting terrain. 

So now I'm pushing forward with generating all the zones that represent the British Isles, and have most of the code already written for transferring players between zones.  Over the next week I'll be tying this all together.   After that I will continue adding more zones to cover Europe all the way around Africa to India, and a lot of the surrounding relatively empty ocean.  I think this will put the territory of the game in a good place for really testing the long distance trade aspect of the game.  Even though the game will still only have a small fraction of the total planet covered, it will still feel like a very large and open world at that point. 

To recap on zones, the game world for various technical reasons is being split up across hundreds of separate server instances, each one is a zone server.  As players hit the edge of one zone they will be transferred to the next zone.  Zones take approximately 60 - 90 minutes to cross, depending on the size of the zone and the speed of the ship.  The British Isles for example will be covered by 4 separate zone servers.   

Pleasantly Surprised

I'm currently in Germany for work this week, and I live in California where the Broadside test server is located.  This gave me an opportunity to personally test the game with some higher ping times without trying to artificially create such normal latency.  I have to say I'm quite pleased with the game's network performance even from the other side of the world.

Now it is not perfect, as there is some work with ship turning I need to smooth out, but overall I could barely notice much difference at all compared to sitting right next to the server.  This is some pretty good news for the game's performance.

Now I do have several people who are involved with testing the game in other parts of the world, and they have reported good performance as well, but nothing quite beats seeing it for myself.

----------

Now that enough of the Broadopedia is implemented in order to be able to properly plan things like your skill training, I'll be pivoting back towards more fundamental gameplay development.  There's 3 areas that need immediate development in order for the game to really be fully playable as a real MMO. 

* Zone transfers - When reaching the edge of the map it needs to transfer the player to the adjacent zone.  What is really missing still is the functionality of the Master Server to spin up and down the Zone Servers as needed, but most of the ground work was already done for this back in 2017.  I just need to actually hook everything up. 

* AI aiming - Currently the AI has absolutely horrible aim with their cannons.  I have an idea of where the bug in the current implementation is (when the ship is leaning from the wind I think it is compensating with aim the wrong direction, putting cannonballs straight into the water next to the ship, or aiming too high and over shooting.  Instead of fixing this bug though I'm actually going to redesign the entire way the system works to much more intelligently hit their targets. 

* Buy/Sell orders - Right now you can both buy and sell items on the market, so long as an NPC order exists for the item.  The in game economy though can't function properly until the players can add persistent orders to the market for other players to use.  Mostly what is missing is just the UI windows for creating the orders and managing existing orders, as all the backend functionality was implemented already with the rest of the market system. 

After all the above I'm going to start implementing more zones, starting with the British Isles, followed by Europe as a whole, and then expanding from there. 

Ship Types

While working on the "Broadopedia", which is a store of all the information you would need to know about the game (a play on Civilopedia from the Civilization game series), I've been going over all the information going into it.  I thought people might be interested in all the types of ships planned.  

So there are planned over 40 unique ship classes across 10 types of ships (11 if you count the Escape Class Dingy which you end up in if your ship is sunk).  Here's the 10 types.  

Cog - 2 ships

Cogs are lightly armed outdated trade vessels.  Though lacking in speed, they have sufficient cargo capacity for their purpose, and are pretty cheap.  When you first enter the game you start in a Bremen Class Cog.  

Caravel - 4 ships

Caravels are a good upgrade from the basic Cog.  An old design built for trade, exploration, and fleet escort.  While not extremely fast by today's standards, they are far faster than Cogs and are armed equally or better.  

Carrack - 3 ships

These are the long haul heavy transports.  Being another old design, they can't fit any of the more modern larger armament, so ill equipped for fighting other ship types of their size.  Still, their enormous cargo capacity means they are still as relevant today for global trade as ever.  

Galleon - 3 ships

These are jack of all trades ships built both for trade and combat.  While not the best at either, they are a good compromise for the player who wants to captain a flexible ship that can serve a variety of roles.  

Galley - 4 ships

Galleys are ships with sails but can also be propelled with ores.  This allows a tactical advantage in combat by rowing directly into the wind.  

Junk - 1 ship

The Junk is a truly ancient design traditional to east asia.  A sturdy and multipurpose ship.  

Corvette - 5 ships

Purpose built combat ships that are very fast and maneuverable.  They make excellent scouts, can act as escorts, and in groups can threaten lone ships of larger types.  

Frigate - 9 ships

The most versatile type of combat ship in Broadside.  Built to seek and destroy opposing shipping, they can sail alone, act as fleet escort, or even be the lead ship of small fleets.  A mid sized ship with good armament.  

Ship Of The Line - 9 ships

The heaviest of the heavy combat ships.  These have massive firepower, thick hulls, and a crew to patch up damage as it comes in.  They are built to both deal damage and take it.  

Gunboat - 2 ships

These are small Corvette sized ships with a small number of oversized guns typically found on Ships Of The Line.  They are built for coastal bombardment, city defense, but can be effective when swarming much larger ships.  

Added skills system

So the implementation of the skill training system is now complete.  All skill books are currently available for purchase in a country's capital port, and are treated like any other item until you use them.  When you click Add to Library it removes the skill book from your city storage and adds the skill to your character's skill list at level 0.  You can then select it for skill training. 

All skill requirements for all items that are currently in the game have been implemented as far as listing those requirements in code, and showing all items you don't have skills yet for as the item in a slight red color. 

Next in the skills system is implementing restrictions on actually using items if you don't have the skills to do so.  After that, some skills provide bonuses such as faster ship turning, faster water bailing, etc, and those will all be implemented.  The last part (which I may actually work on first), is right now the skill requirements aren't actually displayed in game beyond you have them fulfilled or not, but not what you need for each item.  I'm going to implement the Broadopedia feature which will have detailed information about every item, every feature, every game concept that is in Broadside.