Hi, I’m Rodrigo Braz Monteiro, and I’m a senior games developer at Bossa Studios. I’ve been working on both client and server-side programming for Worlds Adrift, and today I’d like to talk a little bit about how the ships will work. In Worlds Adrift, one of our primary goals is to have fun and emergent physical gameplay in a multiplayer environment. Reconciling physics with multiplayer is well-known to be a difficult problem, due to small differences in synchronization quickly escalating to very jarring discontinuities in the simulation, very much like a “butterfly effect”. We’ve partnered with Improbable to tackle many of the technical challenges of having reliable and high-performance physics in a persistent world, but the ships have been an interesting aspect of the problem. We quickly established that we wanted fully-physical ships. That meant that ships should be able to crash, both into each other and into the environment (or any other physical object, for that matter), and react appropriately. If you crash badly enough, you could end up with an upside-down ship. The controls of the ship are also fully physics-driven. The ship floats in mid-air due to an anti-gravity core that you can install on the ship, which provides an upwards force, and it’s controlled around by applying forces on the engine propellers (sort of, more on that in a bit), and torque on the ship centre of mass itself. The core also provides an automatic stabilization system that behaves similarly to the buoyancy force acting on a seafaring vessel, attempting to keep the ship upright. This buoyancy force is balanced so it’s powerful enough that the ship will be mostly steady normally, but will still rock and tilt if hit by external forces.

The first interesting problem comes from the way we allow players to build ships in whichever way they want. Because you can place any part anywhere on the ship (as long as it fits, of course), you will easily end up with slightly asymmetrical, unbalanced ships (this is good, by the way – we want the ships to feel personal and handmade, and allow good shipbuilders to distinguish themselves by making beautiful ships). If we applied the forces directly on the positions of the propellers, the engines would have to be perfectly symmetrical around the centre of mass of the ship (itself affected by the position of every single component of the ship) to prevent the ship from veering to a direction. That is perfectly fine in a game doing realistic simulation of ship building, but this is not Kerbal Space Program, and veterans KSP players will be able to attest how difficult it can be to balance a spaceplane to account for such matters (our problem would be much harder, of course, because we don’t want editor gizmos to build the ships; rather, we want to give players the feeling of installing the parts physically). Our solution is to collect the forces of every engine, plus their individual torques, and compute the physically correct torque generated from that. Then we fudge the resulting forces to be more forgiving for the pilot, and the placement of engines. Your ship will still spin out of control if it’s massively asymmetrical, either because it was built poorly, or because one of the engines was lost… Which brings me to the second interesting problem, which is how all the parts are connected to each other. The straightforward approach is to simply have each part be a physical object on its own right (i.e. a “rigid body”, in physics engine jargon), connected to each other via joints. This approach has the advantage of providing the most emergence of behaviour, but it has three severe downsides. One, the performance of a ship flying around with hundreds of rigid bodies, all interacting with each other, is quite poor, to the point where a collision between multiple such ships could easily bring the physics engine down to its knees. Second, the stability will be questionable at best, leaving the attachment of parts up to the often capricious wiles of the physics engine. Nobody wants to spend hours building a beautiful ship, only to have a physics glitch tear it apart. Third, an agglomeration of rigid bodies will not necessarily have a physically correct centre of mass (this has to do with the way physics engines work), making the aforementioned engine torque fudging not reliable. So that approach is not ideal. The alternative is to have the entire ship as a single rigid body, with all the parts merged into it as it’s built. It immediately solves all three of the above problems, but creates a new one: how do you get interesting behaviours, with ship parts breaking off on collisions? Fortunately, this is an easier problem to handle, and we algorithmically determine the location and force of an impact, and then propagate it through the ship, determining which joints are damaged, and potentially destroyed. This solution ends up being better than the pure physical one, as it also gives us finer game design control over how the ships break. The result is that we can have high-performance ships, flying around the world in a physically believable way, and breaking in a fun, spectacular manner.   Desktop 02.12.2015 - 18.37.38.03.mp4.Still001   The last problem with physics-driven ships is probably the most difficult, and it’s related to how the players move on top of the ships. The players themselves behave according to physics; however, a technique known as “client side prediction” (or CSP) is used to allow for responsive controls, while maintaining the integrity of the physics simulation. Due to latency between the client and server, though, the position of players and ships can only be estimated, which makes moving responsively on a ship with while still keeping everything synchronized a very difficult problem. CSP is a big topic, though, and is best left as a subject for another blog post. With this game, we’re striving for flying ships that are more advanced than generally done in multiplayer games. Though there were many challenges in accomplishing this goal, I believe that we have already surpassed most of the challenges, and have ended up with something that is accessible (but still challenging), fun, and surprising – we keep finding new tricks to pull with the ships that not even we expected. You can fly through a stack of blocks and send them flying in the air, crash on the mountainside and rip off a wing, collide head-on with another ship, attach a grappling hook to a flying ship and swing around it, and much more that we’ll reveal in the coming weeks. So this is the current state of development with the ships. I hope that it was insightful. Thanks for reading, and I’ll leave you all with one thing to ponder:  harpoons. Rodrigo