Gravitas

After holding on to the domain for ages without really having anything on it, I’ve now launched GamesWithGravitas.net.

It is currently an archive of content related to Gravitas.

After finding YouTube doesn’t support moving videos between channels, I figured I should try to organize things properly sooner rather than later. Also, here is a brand new freshly recorded video of the original Gravitas on Xbox 360.

Games with Gravitas on YouTube.

Unity has a pretty cool feature called “gizmos”, that are things rendered only in the scene view of the Unity editor. Many built in game object types render a gizmo of some sort, but you can freely add your own. This can be very useful for debugging.

This is a visualization of the gravity (more precisely it’s the low resolution grid of gravity mentioned in the previous post).

The direction of the line is the direction of the gravity, and the length is the strength.

The most important feature in Gravitas is clearly the gravity, so getting it right is crucial. One important principal to be aware of when making games though is that “right” doesn’t necessarily mean “technically perfect” or “scientifically accurate”. “Feeling right” and being fun to play with is often more important. Despite that, the gravity in Gravitas is essentially correct. By correct, I mean a numerical approximation of Newton’s law of universal gravitation. The formula for calculating the gravitational force between two masses is:

where:

• F is the force between the masses;
• G is the gravitational constant (6.674×10−11 N · (m/kg)2);
• _m_1 is the first mass;
• _m_2 is the second mass;
• r is the distance between the centers of the masses.

For simplicity and performance reasons, there are a few things to be aware of though. Firstly, I decided not to worry about real world units since the planets, ships and torpedoes are not realistically scaled to each other (either by size, mass or distance from each other). This means I can decide that my torpedoes have a mass of 1, thereby eliminating a multiplication for the most common case. This also means I can choose the value of G to be whatever looks or feels right.

This is still quite a significant calculation that has to be performed every frame for every torpedo/planet pair.

As it turns out though, the maximum number of torpedo/planet pairs is quite low. Based on the limits of the previous version of Gravitas, there were at most 9 ships, firing at most 3 torpedoes, with at most 11 planets. This means 9 × 3 × 11 = 297 times to calculate the strength of the gravity each frame. In practice I don’t think I ever saw so that many torpedoes (every ship using a triple-shot special power at once).

But then I wanted to add dust. By dust, I mean a trail from the torpedoes, that is also affected by gravity. At a minimum this should generate one particle per frame and be at least a couple of seconds long at normal torpedo speed. This means each torpedo could easily have a hundred dust particles all needing the same gravity calculation. All of a sudden there could be 300,000 gravitation calculations per frame. On my laptop it ran fine. On my phone, not so much.

There are a number of possible ways of solving this issue, but the one I settled on is based on the principle that accuracy of simulation of the dust particles (as opposed to the torpedoes) is not so important. That is, if the dust particles don’t behave perfectly, it doesn’t really matter. One thing to notice about the gravity is that the only dynamic data it depends on is the position of the dust. The mass of the dust is fixed, and the position and mass of the planets are fixed (at least per round).

My solution was to pre-calculate the strength of gravity on a dust particle for all the positions in a low-resolution grid. This means I can “calculate” the gravity by doing a relatively cheap lookup.

Gravitas is rapidly approaching something playable, now that ships can be destroyed and new levels are generated. “Something playable” is still quite far away from being an actual game. In terms of features required for even an alpha release, it still needs: scoring, match state, player lobby, AI, and better level generation. Some other features I would rather have but aren’t strictly required include: special powers (especially warping, to get players out of impossible situations), better UI feedback for touch controls (which was not necessary for the original) and some match options. But overall, progress is good.

There have been quite a few mechanical additions since my last update, but the most significant thing in my latest video is it is the first on a non-Windows platform.

Unity has a large list of platforms it supports and a lot will work on all of them with no effort. For example, Gravitas currently builds and runs on Windows (Win32 and Windows 8.1 Store), Mac, Android and WebGL. With the exception of adding some settings (the Android package name for instance) I didn’t have to do anything platform specific for any of it. Although there are very few hard limitations on what can be done on the different platforms, the wildly different performance characteristics mean you do have to think about different problems.

A more straightforward problem I recently solved (after the Day 20 - Android video was made) was to decide how to deal with different mobile device orientations. My general philosophy is to try and support everything, so although landscape feels most natural for Gravitas, there isn’t really a reason not to support portrait. In fact, since the camera will adjust its zoom level to keep all the world on screen, it already supported portrait, albeit rather awkwardly. The dynamically generated levels are designed to have approximately a 16:9 aspect ratio. This means in portrait you get massive empty space above and below the planets, while making everything smaller than necessary. The solution? If the aspect ratio is less than 1, rotate the camera 90 degrees. This not only means portrait is supported, but in fact a far more general case of portrait-like aspect ratios is supported (and even better, has no mobile specific code at all).

First, a video of the latest progress. Now includes aim lines. Second, if you aren’t using Unity Cloud Build, you should be. Over the past few years, the importance of automated builds in software development (and the wider concept of continuous integration) has grown in importance. In my day job, setting up automated builds is one of the first thing that happens on any project. The details tend to be different for different platforms and it generally requires a fair amount of maintenance. The good news is, Unity do most of the hard work for you, and across most of their platforms, and surprisingly, for free.

Writing a blog post (nearly) every day is not something I can maintain. But making quick videos of my progress is apparently easier.

In software development (and product development in general) is a concept called MVP or Minimal Viable Product. According to Wikipedia it is “a product with just enough features to gather validated learning about the product and its continued development”. My plan was to develop a Gravitas MVP in Unity and release it as quickly as possible. After reading a bit about some of the cool things I can do with Unity quite easily that would have been hard before, I inevitably got distracted. But it’s okay, since technical spikes are also an accepted part of software development (again thanks to Wikipedia: “a product-testing method that is used to determine how much work will be required to solve or work around a software issue”). Specifically, one of the things I wanted to do in Gravitas was add a real lighting model, probably using normal mapping on the sprites. I had read up how to do this in MonoGame, but decided to see how quickly I could do it in Unity. The answer was about 2 hours. That includes the time to create the normal map for the ship (and finding a tool to help do that). The tool I used incidentally is Sprite Illuminator from a company called CodeAndWeb. If you plan to do any 2D games I suggest you check them out. Their tools all come with trials, and the only reason I haven’t bought it is yet, is I’m deciding which bundle to get (I’ve already used Sprite Illuminator and I’ll almost certainly use Texture Packer. Physics Editor is probably less useful to me, but is only £10 extra with the other two).

For a long time, I’ve avoided Unity. The biggest reason was inertia from working with MonoGame, but I was also put off by the prospect of old versions of Mono and C# as well as being generally suspicious of development being so “editor focused” (I’ve tried quite a few drag-and-drop game development tools and ultimately found them frustrating).

But I’ve decided to get over it and have a go.

The number of amazing games released that have been made with Unity has persuaded me the last point is not an issue (or perhaps no longer an issue). More importantly, there have been a few specific recent developments that have piqued my interest.

Unity joined the .NET Foundation. Unity’s .NET support always worried me a little. Using old versions of Mono and C# was bad, and their support for JavaScript made me a little worried they might just drop C# altogether. This is obviously not going to happen now (at least in the near future).

Related to the previous point (but more to do with Mono being released under a permissive license) is that they really are pushing forward with an updated version of .NET.

The final reason is the discovery that Distinctive Games, a mobile game developer I used to work for have decided to use Unity for (at least) one of their upcoming games, Downhill Extreme 2.

The net result of this is that I have started working on another version of Gravitas in Unity. And after about half an hour I have a star field, and a ship (with a colorizable section) that rotates when you press left and right.