REDMOND, Wash. — Feb. 26, 2020 — As Microsoft closely monitors the impact of the COVID-19 health emergency, our top priority remains the health and safety of our employees, customers, partners, and communities. Our global health response team is acting to help protect our employees in accordance with global health authorities’ guidance. Worldwide, Microsoft employees are working to support organizations addressing the challenges on the ground. Microsoft also continues to make donations to relief and containment efforts, including directly providing technology to help hospitals and medical workers.

On Jan. 29, as part of our second quarter of fiscal year 2020 earnings call, we issued quarterly revenue guidance for our More Personal Computing segment between $10.75 and $11.15 billion, which included a wider than usual range to reflect uncertainty related to the public health situation in China. Although we see strong Windows demand in line with our expectations, the supply chain is returning to normal operations at a slower pace than anticipated at the time of our Q2 earnings call. As a result, for the third quarter of fiscal year 2020, we do not expect to meet our More Personal Computing segment guidance as Windows OEM and Surface are more negatively impacted than previously anticipated. All other components of our Q3 guidance remain unchanged.

As the conditions evolve, Microsoft will act to ensure the health and safety of our employees, customers, and partners during this difficult period. We will also continue to partner with local and global health authorities to provide additional assistance. We deeply appreciate the commitment of the people and organizations that have united to address this health emergency; our thoughts are with all those affected across the world.

About Microsoft

Microsoft (Nasdaq “MSFT” @microsoft) enables digital transformation for the era of an intelligent cloud and an intelligent edge. Its mission is to empower every person and every organization on the planet to achieve more.

Forward-Looking Statements

Statements in this release are “forward-looking statements” based on current expectations and assumptions that are subject to risks and uncertainties. Actual results could differ materially because of factors described above as well as:

• intense competition in all of our markets that may lead to lower revenue or operating margins;
• increasing focus on cloud-based services presenting execution and competitive risks;
• significant investments in products and services that may not achieve expected returns;
• acquisitions, joint ventures, and strategic alliances that may have an adverse effect on our business;
• impairment of goodwill or amortizable intangible assets causing a significant charge to earnings;
• cyberattacks and security vulnerabilities that could lead to reduced revenue, increased costs, liability claims, or harm to our reputation or competitive position;
• disclosure and misuse of personal data that could cause liability and harm to our reputation;
• the possibility that we may not be able to protect information stored in our products and services from use by others;
• abuse of our advertising or social platforms that may harm our reputation or user engagement;
• the development of the internet of things presenting security, privacy, and execution risks;
• issues about the use of AI in our offerings that may result in competitive harm, legal liability, or reputational harm;
• excessive outages, data losses, and disruptions of our online services if we fail to maintain an adequate operations infrastructure;
• quality or supply problems;
• the possibility that we may fail to protect our source code;
• legal changes, our evolving business model, piracy, and other factors may decrease the value of our intellectual property;
• claims that Microsoft has infringed the intellectual property rights of others;
• claims against us that may result in adverse outcomes in legal disputes;
• government litigation and regulatory activity relating to competition rules that may limit how we design and market our products;
• potential liability under trade protection, anti-corruption, and other laws resulting from our global operations;
• laws and regulations relating to the handling of personal data that may impede the adoption of our services or result in increased costs, legal claims, fines, or reputational damage;
• additional tax liabilities;
• damage to our reputation or our brands that may harm our business and operating results;
• exposure to increased economic and operational uncertainties from operating a global business, including the effects of foreign currency exchange;
• uncertainties relating to our business with government customers;
• adverse economic or market conditions that may harm our business;
• catastrophic events or geopolitical conditions that may disrupt our business; and
• the dependence of our business on our ability to attract and retain talented employees.

For more information about risks and uncertainties associated with Microsoft’s business, please refer to the “Management’s Discussion and Analysis of Financial Condition and Results of Operations” and “Risk Factors” sections of Microsoft’s SEC filings, including, but not limited to, its annual report on Form 10-K and quarterly reports on Form 10-Q, copies of which may be obtained by contacting Microsoft’s Investor Relations department at (800) 285-7772 or at Microsoft’s Investor Relations website at http://www.microsoft.com/en-us/investor.

All information in this release is as of Feb. 26, 2020. The company undertakes no duty to update any forward-looking statement to conform the statement to actual results or changes in the company’s expectations.

For more information, press only:

Microsoft Media Relations, WE Communications for Microsoft, (425) 638-7777, rrt@we-worldwide.com

For more information, financial analysts and investors only:

Michael Spencer, General Manager, Investor Relations, (425) 706-4400

Note to editors: For more information, news and perspectives from Microsoft, please visit the Microsoft News Center at http://www.microsoft.com/news.

Open source projects can use a variety of different models for deciding when to put out a release. Some projects release on a set schedule. Others decide on what the next release should contain and release whenever that is ready. Some just wake up one day and decide it’s time to release. And other projects go for a rolling release model, avoiding the question entirely.

For Fedora, we go with a schedule-based approach. Releasing twice a year means we can give our contributors time to implement large changes while still keeping on the leading edge. Targeting releases for the end of April and the end of October gives everyone predictability: contributors, users, upstreams, and downstreams.

But it’s not enough to release whatever’s ready on the scheduled date. We want to make sure that we’re releasing quality software. Over the years, the Fedora community has developed a set of processes to help ensure we can meet both our time and and quality targets.

Changes process

Meeting our goals starts months before the release. Contributors propose changes through our Changes process, which ensures that the community has a chance to provide input and be aware of impacts. For changes with a broad impact (called “system-wide changes”), we require a contingency plan that describes how to back out the change if it’s broken or won’t be ready in time. In addition, the change process includes providing steps for testing. This helps make sure we can properly verify the results of a change.

Change proposals are due 2-3 months before the beta release date. This gives the community time to evaluate the impact of the change and make adjustments necessary. For example, a new compiler release might require other package maintainers to fix bugs exposed by the new compiler or to make changes that take advantage of new capabilities.

A few weeks before the beta and final releases, we enter a code freeze. This ensures a stable target for testing. Bugs identified as blockers and non-blocking bugs that are granted a freeze exception are updated in the repo, but everything else must wait. The freeze lasts until the release.

Blocker and freeze exception process

In a project as large as Fedora, it’s impossible to test every possible combination of packages and configurations. So we have a set of test cases that we run to make sure the key features are covered.

As much as we’d like to ship with zero bugs, if we waited until we reached that state, there’d never be another Fedora release again. Instead, we’ve defined release criteria that define what bugs can block the release. We have basic release criteria that apply to all release milestones, and then separate, cumulative criteria for beta and final releases. With beta releases, we’re generally a little more forgiving of rough edges. For a final release, it needs to pass all of beta’s criteria, plus some more that help make it a better user experience.

The week before a scheduled release, we hold a “go/no go meeting“. During this meeting, the QA team, release engineering team, and the Fedora Engineering Steering Committee (FESCo) decide whether or not we will ship the release. As part of the decision process, we conduct a final review of blocker bugs. If any accepted blockers remain, we push the release back to a later date.

Some bugs aren’t severe enough to block the release, but we still would like to get them fixed before the release. This is particularly true of bugs that affect the live image experience. In that case, we grant an exception for updates that fix those bugs.

How you can help

In all my years as a Fedora contributor, I’ve never heard the QA team say “we don’t need any more help.” Contributing to the pre-release testing processes can be a great way to make your first Fedora contribution.

The Blocker Review meetings happen most Mondays in #fedora-blocker-review on IRC. All members of the Fedora community are welcome to participate in the discussion and voting. One particularly useful contribution is to look at the proposed blockers and see if you can reproduce them. Knowing if a bug is widespread or not is important to the blocker decision.

In addition, the QA team conducts test days and test weeks focused on various parts of the distribution: the kernel, GNOME, etc. Test days are announced on Fedora Magazine.

There are plenty of other ways to contribute to the QA process. The Fedora wiki has a list of tasks and how to contact the QA team. The Fedora 32 Beta release is a few weeks away, so now’s a great time to get started!

Not long after the video game YouTuber Desmond “Etika” Amofah was found deceased last year, his fans banded together and painted a large mural of him in Brooklyn. Now, to add to this, the same location has been transformed into a PokéStop within Niantic’s augmented reality mobile-hit, Pokémon GO.

This is all thanks to the company’s recently launched Wayfarer tool, which recruits “Niantic Wayfinders” who then nominate and review new points-of-interest for Pokémon GO and other Niantic games. The goal, as previously noted, is to “inspire others to discover new places and things” while highlighting “positive and unique qualities” of a location or community.

After a push from GO players at level 40 – including the YouTuber Reversal, who called on his audience of over 350,000 fans – Etika’s mural was approved as a PokéStop by Niantic. Below is the description (note: JoyconBoyz are the fans):

Remembering the passing of Etika, JoyconBoyz forever

Amofah was best-known on YouTube for his focus on all-things Nintendo, so it’s somewhat fitting to see him honored like this.

Namya Joshi, a 13-year-old, loves training teachers.

The seventh grade student has been helping teachers of her school convert their class lessons into interactive Minecraft sessions.

“Minecraft is a great platform. If a child does not like reading books, for example, you can make them in Minecraft and get the child interested,” the student from Sat Paul Mittal School in Ludhiana, says very matter-of-factly.

It all started two years ago when her mother, who is the IT Head at the school, signed up to become a global Minecraft mentor, as a part of Microsoft Innovative Educator program.

“I didn’t know much about Minecraft when I signed up. I had some exposure in our school during Microsoft’s Hour of Code but that was all I knew about it. I started researching about it and was initially shocked to see how a game could be integrated into the school’s curriculum. I wasn’t convinced,” says Monica Joshi, Namya’s mother.

A Microsoft Expert Educator herself, Joshi thought she’d learn how to use Minecraft on her own gradually, but all that changed when one day she found Namya playing with Minecraft: Education Edition, a special edition of the game customized for the classroom environment, on her laptop.

“I’d seen Minecraft installed on my mother’s Windows 10 laptop and started trying it on my own. After understanding the basics, I watched some tutorials and got myself familiar with it,” Namya says with pride.

Recovering from the initial shock, Joshi asked her daughter to create her upcoming lesson in the Minecraft world. It was a creative writing lesson and Namya had to write about her recent trip to the hills. The result convinced Joshi about using Minecraft in her school.

The Pokémon Company and Niantic have already started this year’s Pokémon Day celebrations in Pokémon GO with a limited-time event featuring Armored Mewtwo, Clone Pokémon in Raid Battles and special party-hat Pokémon.

This all ties in with the Netflix debut of Pokémon: Mewtwo Strikes Back—Evolution on Pokémon Day:

Armored Mewtwo will return to Pokémon GO in five-star raids during the Pokémon Day Celebration event, and this time it’ll know the exclusive Charged Attack Psystrike!

The Clone Pokémon include Venusaur, Charizard and Blastoise, and the party hat Pokémon are Pikachu and Eevee. There’ll also be eggs (appearing in one-star raids) that hatch party hat Bulbasaur, Charmander and Squirtle, and there are even shiny variants.

Last but not least is a classic confrontation:

If you’ve ever played Pokémon Red, you might recall the iconic intro sequence that features Nidorino battling Gengar. That beloved moment will be honored during Pokémon GO’s Pokémon Day Celebration in a Raid Day event on Sunday, March 1, 2020, from 2:00 p.m. to 5:00 p.m. in your local time zone.

During this time, Nidorino wearing party hats will be appearing in two-star raids, and party hat–wearing Gengar that know Lick and Psychic will be appearing in four-star raids. If you’re lucky, you might encounter a Shiny Nidorino or Shiny Gengar wearing a party hat!

To out players during this period, you’ll be able to receive up to five Raid Passes at no cost during the Raid Day event by spinning Photo Discs at Gyms.

This event runs from now until 2nd March. Will you be booting up GO on your mobile device to celebrate Pokémon Day? Leave a comment down below.

Samurai Jack is making a comeback on Nintendo Switch, Xbox One, PlayStation 4 and PC in a brand new video game, due out this summer.

Samurai Jack: Battle Through Time by Adult Swim Games and Japanese developer Soleil Games is a 3D hack-and-slash title based on the popular American animated series, and takes place before Jack’s final fight with Aku – the evil entity that trapped him in alternate timelines.

As the player, it’ll be your job to guide Jack through multiple different timelines to reach Aku and stop him once and for all. Throughout the game, you’ll be able to wield a variety of different weapons – covering both melee and ranged attacks.

The 3D artwork retains the style of animated series and the development team behind the game is comprised of individuals who previously worked on the Ninja Gaiden and Dead or Alive series.

More details about this upcoming release will be revealed by the Samurai Jack series’ creator Genndy Tartakovsky and head writer Darrick Bachman at the Adult Swim PAX East panel later this week.

Jacques Kerner is a senior software engineer at Avalanche Studios.

We don’t talk enough about vehicle physics for video games. Articles on the net about vehicle physics for video games are few and far between, and are usually about how to get started. A video game vehicle programmer today finds herself or himself in a relative vacuum. Maybe it is because it seems too complicated to explain, or we are ashamed to expose the hacks, simplifications and shortcuts we make compared to ‘proper’ realistic simulations. Whathever the reasons are, video games have unique constraints when it comes to simulating vehicles, and this makes it worth writing about. It is a fascinating subject that mixes physics, camera work, audio, special effects, but also human perception and even psychology.

I chose to start talking about boats because, well, I recently worked on them, but also because I found that their dynamics is not fully understood even at the research level (although a lot is understood). When it is, the models or theories are formulated in such a way that makes them hard to apply directly to video games. Or they require very expensive simulation methods that are practically impossible to control and adapt to the capricious needs of designers and gamers. But it is possible to write a simplified model that captures the important features of a boat. There is definitely an art to it, a scary leap of faith involved and quite a bit of creative physics that would have a Kelvin or a Stokes roll in their graves.

In this series, I present an algorithm for calculating the most important forces acting on a boat in water. The main motivation is to develop a model which captures the major dynamic traits of boats in water, yet avoids resorting to complex and expensive fluid dynamics computation.

I constrain myself to a reasonable performance budget, say less than 1 ms per boat. The model must be robust enough to simulate boats of a wide variety of sizes and shapes evolving in calm to very stormy waters.

The first article in this series will be dealing with hydrostatic forces, but will lay an important foundation for calculating all the other forces involved in this model. The other forces are dynamic forces caused by the motion of the boat relative to the water. They will be the subject of articles to follow.

Buoyancy Force 101

Before I dive in the algorithm itself, I want to review a bit about buoyancy. All we need to be able to do is to calculate the magnitude and point of application of the buoyancy force on an partially submerged body.

When a body is submerged in a fluid, the fluid exerts a force on the surface of the body, due to the pressure in the fluid. The bigger the pressure, the bigger the force. The force is the result of the many water particles in movement in the fluid, colliding against the surface of the body in an elastic way – i.e. like perfect billiard balls. It is a microscopic force, its effect is felt even if the water isn’t flowing in any particular direction (current) or if the boat stays still, and it is therefore called the hydrostatic force. The net force of all these atoms or molecules hitting the surface is perpendicular to the surface. One other thing to note is that the pressure in water increases with depth (on a planet with gravity anyway), because a greater depth implies that more and more water is pressing down with its weight. However pressure doesn’t have a preferred direction in itself, and even if there is no fluid directly above a point in water, the pressure at the point will still be dependent on the overall depth nearby. (*)

The increasing force with depth is very important for buoyancy, because the overall buoyancy force is due to an imbalance in the vertical component of the hydrostatic forces on the surface of a body. The horizontal component of the hydrostatic forces all cancel out. Intuitively, this is because for every given small surface of the (closed) volume, you can always find another small surface facing exactly the opposite direction at the same depth. Since the magnitudes of the hydrostatic forces are the same but applied in opposite directions, they cancel out. On the other hand, the vertical component of the hydrostatic forces do not cancel out at all. Overall, because the volume is closed, surfaces which normal is generally pointing down will be found at greater depths than surfaces which normal is generally pointing up. So the pressure forces on surfaces which normal is pointing down prevail. The pressure force being in the opposite direction to the normal, the resulting force is pointing up and it can be shown [2] that its magnitude is equal to “the weight of the displaced fluid”, meaning the weigth of the volume of the body if it were filled with water.

Now we are still missing one piece of the puzzle: to have everything we need to work on buoyancy, we also need the point of application of the hydrostatic force. The point of application of the buoyancy force is the point with respect to which the moments of all hydrostatic forces cancel out. If we continue reasoning in terms of small elementary surfaces on the submerged body, things become a little less obvious. Since the hydrostatic force gets larger the deeper you go, the point of application of the hydrostatic force on a given non horizontal surface is generally found lower than the center of the surface. As shown in Appendix A, on a submerged triangle, which is particularly useful in games since we tend to triangulate everything, the point of application is always lower than the center. Yet somehow the sum of all the moments of all these forces applied generally lower than the centre of any surface still cancel out around the centroid of the volume. A formal proof of this is found in [2] by applying the Ostrogradsky-Gauss theorem (**), or divergence theorem. It can also be verified numerically. The reason I mention this is that if you were to divide the body in small surfaces, say triangles, and sum all the hydrostatic forces and their moments, you could be tempted to make the simplification to calculate the moments as if the elementary forces on each triange were applied at its center (easy to determine). If you do so however, you will not get the correct result. You will get the correct force, but you will get a residual moment around the center of the volume submerged, and the boat may tip on one side at rest, even on perfectly flat water. This is especially true if you use a low polygon count mesh to reduce performance cost, as the error made on each triangle is then relatively important. On the other hand, if you have many small triangles, the error caused by the simplification will be reduced drastically and the simplification may become acceptable. But there is a trade-off between the complexity of the computation of the correct center and the number of triangles in the hull. Appendix A gives the formula for the location of the point of application of hydrostatic forces on a submerged triangle.

Two ways to flip a boat

In light of what we just reviewed, there are two ways buoyancy forces can be calculated. The volumetric method: by evaluating the volume submerged and determining its centroid. The surfacic method: by determining the surface submerged, and calculating the force applied on it. The two methods, if applied correctly, should give the same result.

Both the volumetric and surfacic methods, without too much approximation, require us to determine the intersection of the water with the hull. This can be intimidating, especially when considering non flat water surface: it sounds expensive and complicated. This may be why the use of simple volume primitives is tempting to many. For instance, spheres: in contrast to intersecting a complex shape with the surface of the water, calculating the volume of a portion of a sphere submerged in water is fast and easy if the water can be approximated as planar around it. It can even be determined analytically, which means that, in theory at least, it is of infinite precision, or as precise as floating point operations will allow (yes, so many puns in this article). It also looks like the volume submerged will change in a continuous, progressive manner as the body moves in and out of the water, and continuity of a physical model is often desirable in games. But approximating the hull of a typical boat with spheres can quickly turn into a nightmare, as many spheres of different sizes may be needed. Because spheres are one of the worst choices for densely packing a volume, you will be left with significant gaps in between the spheres (figure 1). There is an upper bound to how densely the volume can be packed, even with spheres of different radii [5]. The presence of these gaps leads to noticeable irregularities in buoyancy. Spheres can also be made to overlap, but then the volume submerged will be overestimated. Finally, while it is easy to compute the intersection of a planar surface with a sphere, calculating the intersection of a sphere with an arbitrary water surface is much more work, and we might as well try and find a solution to intersecting the hull with water.

Figure 1 – Approximating the volume of a boat with spheres is not the way to go.

The volume of the body could also be voxelized, i.e. approximated by a collection of simple volume primitives like cubes. The voxels which happen to be intersected by water could be further voxelized, till a certain precision is reached. The problem with volume approximations is that they give a (somewhat coarse) answer to the question “what is the amount of water displaced?”, but are pretty much useless in terms of determining the waterline of the object immersed, which is useful for instance for water special effects such as splashes and foam, or for determining the shape of the surface in contact with water, unless you use an obscene amount of them.

Assuming we could compute accurately the surface of the hull submerged in water, we still have the choice between the volumetric and the surfacic approaches. With the volumetric approach, we must close the submerged surface of the hull to form a closed volume, compute its total volume and centroid, and apply the buoyancy force there. With the surfacic approach, we would calculate the hydrostatic pressure forces at each submerged surface element (triangles), and sum their linear and angular impulses around the center of gravity of the body.

The advantage of the surfacic method is that it is not necessary to close the volume, everything is prepared to directly sum forces. With the volumetric approach, the volume submerged could also consist of more than one volume. It’s easy to see in the case of catamaran hulls for instance. But even if the boat doesn’t have holes, the intersection with water could represent two or more volumes to close, and we would have to determine which submerged triangles contribute to which volume, which represents an additional complication to that approach. The surfacic approach is more robust in that respect, as it works regardless of the number and shape of volumes formed and doesn’t require any closing. It is the one I chose for the algorithm.

Structure of the algorithm

I’m now going to outline the structure of the algorithm with some of the key simplifications that allow it to run fast, yet give adequate results.

The first assumption I make is that the surface of the water is described by a triangle mesh of some sort, which vertices move each frame with the motion of the water. It is not always the case of course, but it is always possible to approximate the surface of the water by a triangulated mesh. Later in the article, I describe how to sample the water surface and prepare a triangulated mesh representation for it around the body.

The main objective is to determine the intersection between the surface of the water and the surface of the hull. After seeing the implementation by Edouard Halbert [1], I started by implementing an accurate solution taking into account all cases of the water surface intersecting a triangle. This problem is somewhat complicated because in theory there are lots of ways that a surface can segment a triangle. The surface could cut one triangle in several places, go through the center without intersecting any edges, or submerging any vertices. Each such submerged region needs to be triangulated, but those regions are not necessarily convex, so are harder (and slower) to triangulate. Furthermore, these cases are relatively common. Even in relatively calm waters they are very quickly encountered, and need to be properly handled in a way that doesn’t cause unrealistic discontinuities in the amount of surface considered submerged. After some effort spent implementing a perfectly accurate but very slow intersecting algorithm it became clear that I needed to find ways to simplify the algorithm without sacrificing too much of the general behavior. The algorithm I present here is the result of these simplifications. I will not present details of the first accurate algorithm because it is extremely tedious and boring, and ultimately the optimized algorithm works just fine and runs an order of magnitude faster.

The structure of the optimized algorithm is as follows: the floating body is approximated by a triangulated mesh: the hull. We determine the height above water of each vertex of that hull. If the height above water is negative, the vertex is submerged. Triangles which three vertices are above water are considered to be entirely out of the water. This is a simplification, in reality the water could be above some part of the triangle but below all three vertices, as show in figure 4. Likewise, we consider a triangle to be fully submerged if all three vertices are under the water, even though some part of the water could be sinking under the triangle in some of its area. When only one or two vertices are under water, we cut the triangle into one region under the water and one region over, as shown in figure 2. If the region under the water is not a triangle, we further triangulate it. I am making the bold (and theoretically incorrect) assumption that the surface of the water is cutting the edge only once between a submerged vertex and a vertex out of the water. Figure 3 shows some examples of cases not accurately intersected. We end up with a list of triangles, all of which are under water. We then calculate the hydrostatic and hydrodynamic forces acting on these triangles.

Figure 2 – The 4 simplified cases of triangle intersections with the water patch. From left to right, triangle with respectively 0, 1, 2 and 3 vertices submerged. With 2 vertices submerged we need to further triangulate the part submerged. Notice that the intersection with the water is not exactly accurate. It is due to another simplification which we will explain.

Figure 3 – Three examples of cases mishandled by the optimized algorithm. The red areas denote triangles which should have been considered under water, yet were missed. The two triangles on the left have intersections with the water, but none of their vertices are under water. The triangle in the middle is seen in perspective, it doesn’t even intersect the surface of the water on any of its edges, as the crest of the wave punches through the middle of the triangle. The triangle on the right has two vertices below the water, but the water also leaves the triangle at the edge between these two vertices.

Figure 4 – An example of a case happening often with choppy water. The bigger lower right triangle of the hull is intersected in several regions, one of which does not intersect any edges. Worse than that, the intersected regions could have been concave, making them harder to triangulate quickly. Supporting all such cases consumes both development time and performance at runtime. Ultimately, it is somewhat pointless since, in all rigor, the surface of the water is itself modified by the presence of a boat.

For a boat model, those cases are less important than it seems. The sacrifice in accuracy is not a problem in practice, as long as the size of triangles of the hull is not too big compared to the amplitude and wavelength of the smallest waves we are interested in.

The main advantage of the proposed approach is that all vertices can be processed in a first pass, regardless of which three form a triangle. All the information is then available to process each triangle, which gives rise to 0, 1 or 2 submerged triangles. The triangle intersection part is very simple and fast. Most of the processing lends itself nicely to parallelization if need be. We also know the maximum number of submerged triangles we can get: twice the number of triangles in the body hull. This allows us to pre-allocate all the memory beforehand in a simple array.

In the next section, we present important details of implementation, such as how to approximate the water surface to optimize the water depth query, how exactly to cut a triangle which has only one or two vertices under water and how the buoyancy forces are calculated.

Details of implementation

Water patch

To determine the height above water of each vertex, we need a fast way to determine the position of the water under a given point. Here a lot depends on the way water is simulated in the target game or simulation. If the water is flat or described by a simple function, it may be fast to simply determine the height of the water by directly sampling it or evaluating it, at every query. In other cases though, the algorithm to determine the height of the water is expensive and only a limited number of queries can be made. It is the case of Fast Fourier based methods for instance, such as Tessendorf waves [4]. In such cases, I suggest sampling the water once and for all at equally spaced points around the body, therefore creating a height map which is used for all subsequent height queries. I’ll refer to this height map as thewater patch. The water patch needs to be at least as big as the vertical projection of the body. For instance, you can start with a square water patch which side is as long as the diagonal of the bounding box of the body. As in a traditional height map, the water patch consists of a rectangular area subdivided in bands which form rows and columns, intersecting at square cells (figure 5 and 6). Each cell is itself separated in 2 triangles. For each triangle, we compute the equation of the plane supporting it, which makes it very fast to determine the projection of a point onto it.

Figure 5 – A 4 by 4 water patch and the water line (cyan) seen from below

Figure 6 – A 5 by 5 water patch and the water line (cyan) seen from above

Cutting algorithm

When a triangle has some of its vertices under the water and some over, we need to cut the triangle into a portion which is fully over the water, and a portion fully under the water. There is a way to simplify the cut which is fast to calculate and continuous in behavior. By “continuous in behavior”, I mean that we want to avoid situations where a small change in vertices height introduces sudden large changes in the submerged area. This problem wouldn’t happen if we were accurately cutting the triangles in parts under and parts over the water, it is solely due to the approximation, and we need to find one which behaves nicely. This problem was one of my earlier setbacks, and would sometimes introduce instability in buoyancy where the body would suddenly jump or sink in noticeable ways, ruining the overall effect.

Calculating the hydrostatic forces

Once the cutting algorithm has been run on all triangles of the body’s mesh, we have a list of fully submerged triangles. The buoyancy force acting on the body is the sum of all hydrostatic forces acting on each fully submerged triangle. As far as the linear force is concerned, we can sum only the vertical component of the hydrostatic force since we have seen that the other forces cancel each other. The force on a submerged triangle is:

Remember that applying the hydrostatic force at the center of the triangle instead of at its real center of application results in a residual torque around the center of the volume displaced. If the number of triangles is low and it is important to not get any residual torque, it is necessary to calculate the point of application of the force on the triangle. Appendix A gives the formula for finding the center of application of the hydrostatic force on two types of triangles which base is horizontal, with the apex either pointing up or pointing down. An arbitrary submerged triangle needs to be further cut in two such triangles, and the two sets of hydrostatic force and centers of application are calculated and summed.

Piecing it all together

Figure 10 presents an overview of the algorithm.

Figure 10 – Outline of the algorithm

So we can summarize the structure of the algorithm as follows (we assume that the x/z plane is the horizontal plane and y is the vertical up axis):

• At each step of the simulation, we update the water patch position to follow the floating body. The water patch does not follow, the vehicle smoothly, as you can see in the animated gif of figure 11. When the boat moves horizontally, it drifts enough from the orginal position that the water patch looses a row (or column) on one side and gains a row (or column) on the opposite side. When this happens, the water patch coordinates (say, its south west corner) changes abruptly from what it was at the preceding step.
• Once we have determined the water patch coordinates, the water height of the water is sampled or calculated at each grid point.
• For each cell we have two triangles formed by the points on the grid elevated in the y direction by the height of the water, as in a traditional height map. We compute the plane equations of the triangles thus formed.
• We then calculate the height above the water of each hull vertex, by determining which triangle it is on top of, and using the plane equation of that triangle
• For each triangle of the mesh, given the height above the water of each of its vertices, we use the cutting algorithm to produce 0, 1 or 2 submerged triangles
• We finally iterate the list of submerged triangles to calculate the water forces (hydrostatic and hydrodynamic)

There are of course lots of optimizations we could do. For instance, we could first project the vertices of the hull vertically to determine exactly which cell triangles are involved, and compute the plane equations only for those triangles.

Figure 11 – Dynamic response of a boat subjected to hydrostatic forces only, on perfectly flat water. It would get pretty messy in there with a fishing line. It’s clear that resistance forces play a big role in reality.

Conclusion

This article presents an algorithm for intersecting an arbitrary mesh with the surface of water and for calculating the hydrostatic forces acting on the body described by that mesh. If you were to write a program which does only that, you would get a boat oscillating up and down as if it were on a spring. The boat will be pushed out of the water into the air, then fall because of gravity, dive back in and be pushed out again into the air. What is needed to stabilize the system is damping. The hydrodynamic forces which are the subject of the next article are very effective at damping the system, as they are in reality. But it is possible to cheat and just apply heavy speed based damping in all directions of motion, or especially in the vertical dimension, to get a sense of what you get with the hydrostatic forces as calculated with the algorithm we just described.

Notes

(*) If the pressure were smaller for some reason at a point of a given depth relative to other points at the same depth, water from these neighboring points at the same depth, being subjected to a larger pressure, would flow very quickly to the point with less pressure and reestablish uniform pressure at that depth. The only thing preventing water at a higher pressure at a greater depth from flowing up to a lower pressure at a smaller depth is gravity, which is why there is a gradient of pressure, increasing with depth.

(**) By the way, when taught the theorem in France, it was named the Ostrogradsky theorem. Later I discovered that it was also known as the Gauss theorem. I wonder (half jokingly) if it’s because the French are reluctant to attribute too many theorems to the Germans and, given the choice, will gladly go with the Russian equivalent. Americans favor practicality and avoid the whole debate by simply calling it the divergence theorem.

Appendix A: Hydrostatic Forces on a submerged triangle

To calculate the hydrostatic forces and moments on an arbitrary triangle completely submerged, it is useful to cut the triangle in two smaller triangles, each of which have one edge which is perfectly horizontal. The reason for doing so is that it is much easier to calculate the hydrostatic forces acting on a triangle with a horizontal edge: it can be cut in (practically) rectangular horizontal bands on which surface the pressure is the same everywhere.

References

1. Simship. Edouard Halbert. 
2. “Buoyancy”. Joel Feldman. 
3. Hydrostatic forces on a plane surface 
4. Simulating Ocean Water. Jerry Tessendorf. 
5. Upper Bounds For Packing Of Spheres Of Several Radii. David De Laat, Fernando Mario De Oliveira Filho, Frank Vallentin.

This interview is part of our Road to the IGF series. You can find the rest by clicking here.

Elsinore places players in a time-looping vision of Hamlet, having them guide Ophelia through a living, active world as their decisions shape its tragic conclusions.

Gamasutra had a chat with Connor Fallon of Golden Glitch to speak about fleshing out the world of Hamlet with their game, creating a cohesive world that moved outside of the player’s actions, and tasking players with deciding what matters to them rather than what will give them the ‘best’ ending.

We’re Golden Glitch Studios. We’re a group of friends who met online during nights and weekends for six years in order to develop this game. Bios for each of us individually can be found on our website.

We started this project when we were a bunch of chumps fresh out of college that had made some hobby-level games or had done a few internships. Now, a significant portion of us are full-time game developers. We’ve learned a lot over the course of the project about how small game businesses are run, which is a very different experience from the larger-scale development many of us are used to in our day jobs. Elsinore also allowed us to flex some skills we normally wouldn’t in our roles, such as marketing, production, user research, and outsourcing management.

Elsinore was initially started from a “Shakespeare” jam theme in the game development club at Carnegie Mellon University. It began as an Adventure Game Studio prototype and was meant to be a simple branching exploration of Hamlet where the player could try to make different choices to watch the outcome of the plot change. They could replay the game if they wanted to and try different decisions, and there were only a few of them. But we didn’t end up making anything very compelling for that jam week, and we set the project aside for a while.

We picked it back up in 2013 after some of us worked together on a Molyjam summer project, and a lot of the elements that would define the game (like having events that could happen at any point in the time loop if conditions were satisfied) came in then. It went from being more of a choose-your-own adventure to a true simulation game at that point.

The most important development tools we used were the ones we built to support writing the game content and story. Designing and managing the narrative simulation and and its complex moving parts was a major challenge. We built an in-house scripting language for writing Elsinore scenes, which was built in F#.

In addition to the base scripting language, we built various tools to help manage content. Our tools would check for obviously contradictory narrative states – in the way a compiler might check programs for errors – to catch things like “dead characters who could be referred to as living” or “character you are currently in a relationship with responding like they don’t know you.”

In 2011, Groundhog Day-style time loops were not as popular a concept, but a few of us were reading visual novels like Umineko no naku koro ni and watching anime like Steins;Gate – the concept has been popular in Japanese storytelling for much longer. So, when we picked the project back up in 2013, the idea to add time loops into the choice-based Hamlet game sort of made sense.

Many games are essentially time loops in that you try something repeatedly hoping for a different outcome – usually success. The only difference with Elsinore is that information carries over from loop to loop. This allows us to do a few interesting things. For example, we can have characters go through enormous personal change, like the death of a loved one or a reunion of two lovers, which allows us to push them to dramatic extremes in interesting ways. In a more linear game, a player might spend hours waiting for that kind of dramatic character moment. However, we don’t have to actually pay that off in the “long term” narrative because the world gets reset and those characters are effectively wiped clean, so the player can see many interesting character developments in a relatively short time.

The time loop also allows us to develop Ophelia as a character. In one time loop, she might be sharing deeply intimate, warm moments with someone who she knows is capable of doing awful things in other time loops. Her reaction to that is, as you can imagine, complex. Once you understand that someone is capable of both enormous kindness and enormous cruelty, how do you continue to have a relationship with that person? That’s what we try to explore through Ophelia’s views.

Hamlet is one of the best-known stories in western literature. Outside of the Bible, it’s arguable that “to be or not to be” is one of the most widely-known quotes from any text. It’s also a super malleable story; it’s been molded into some very different adaptations like The Lion King, and many people are familiar with the core concept of “young boy seeks revenge against the uncle who killed his father.” Many of us also have a personal interest in taking things which are normally inaccessible, like Shakespeare, and making them understandable and learnable for all kinds of people. This mix of factors made Hamlet a great candidate.

Often at gaming conventions, we’ll meet people who are tagging along with a friend that doesn’t play games themselves. However, they’ll come see the Elsinore booth and get really excited. “I know Shakespeare!” It helps us connect with a totally different type of person.

We also knew we had a great protagonist in Ophelia, who is often ignored or treated as a small side character in many Hamlet adaptations. There’s so much about her personal background, her motivations, and her history with Hamlet that isn’t really expounded upon in the original text, so we thought she would be a great opportunity for us to fill in the blanks.

Our goal with Elsinore was not to seriously modify the world of Hamlet such that it would be unrecognizable to someone who knew the story well. Rather, we did a lot of work to expand and clarify things which are left undiscussed in the original play (Hamlet got captured by pirates? Who was Ophelia’s mother? Why does Horatio describe King Hamlet’s assault on King Fortinbras as though he were a soldier on the battlefield? What was Hamlet like before his father died?) and add our own twist on them. The real major additions are extra characters like Irma and Brit, which helped flesh out an overwhelmingly male cast, and other Shakespearean characters like Othello and Peter Quince.

Additionally, we knew we wanted to make the story accessible to a modern audience. Shakespeare told stories that were intended to appeal to all kinds of audiences, and that has been lost over time. Elsinore was a chance to open the story up once more.

One of the most common sentiments from people after they watch static-story tragedy, like on stage or in film, is “if the characters had only done X, they would have avoided the tragedy.” If the Titanic hadn’t been sailing too fast, it wouldn’t have hit the iceberg. If Romeo had just waited a little longer, Juliet would have awoken. We wanted to put that power of “if I’d done X” into the player’s hands and let them try that resolution for themselves. But the truth is, the world is full of flawed people and circumstances which can’t be so easily solved with quick fixes. This is true of Elsinore, too.

After describing the game to someone for the first time, the most common question we get is “So you’re trying to get the good ending where no one dies?” That question reveals both that people usually know what we’re trying to do, and also that they understand how much of a trope it is for games to have a “correct” path with the “real” ending that is “objectively” better than the other, failure endings. Games have pretty thoroughly trained players to expect a Golden End.

Many people appreciate a game that forces them to instead make decisions about what they value. Elsinore is not about solving a tragedy and making everything okay. It’s about grappling within the free will we all have within the confines of a bad and ultimately-inescapable situation.

The largest difficulty in creating any simulation is maintaining a sense of logic and cohesion. In Elsinore, characters are often forming dramatic plans that won’t make sense if another character is dead, so we need to check for all those cases. Sweeping methods to remove edge cases, like hearsay no longer being presentable if it’s fundamentally invalid, or characters being upset and unwilling to talk to you if you’ve told them something really extreme, were essential in keeping the possibility space manageable.

On the other hand, what’s nice about a simulation is that once you’ve been working on it for a while, solutions start to present themselves. If you already have behavior for Polonius when he’s lost all hope, it makes sense to link into that behavior from other places. The dynamic, shift-able nature of the story elements means we are able to pull in consequences at all sorts of points.