Full Solar System with an ability to land anywhere (part 2)

In this post I decided to clarify some numbers I touched in my previous post only slightly. Especially traveling speeds and times.

In Miner Wars we have two types of ships:

• small ships controlled by player

• large mother ships controlled by an AI

Of course, there also are sub-classes for each of them.

The current max speed of player controlled ships is 200 meters per second. We may increase it in the future and we may also set a different limit for each sub-class, but let's just assume that the max is 200 m/s.

EDIT: The reason why we chose 200 m/s is that every physical engine needs to have some limits due to "tunneling problem" - if the game needs to calculate 60x per second if objects collide with the environment and if you have one extremely fast moving object, there's a chance that the game will miss one collision check and your object will fly through an obstacle. There are ways how to solve this but they would demand more performance. Well, and there's also a second reason - we feel that the game play is going to require not that fast ships, otherwise players would have troubles aiming, chasing, following (just imagine an enemy who moves like a flash - how funny would it be to shoot at him?). BTW, there's also one more hack: we limit the speed but that's actually not possible in an open space - it contradicts first Netwton's law "The velocity of a body remains constant unless the body is acted upon by an external force". But we had to do it, otherwise players will be able to accelerate to infinite speeds.

Following table uses real distances between the solar system bodies and shows how long it would take to travel between them.

As you can see, it would be really impractical to do long journeys using your small ship. For long distances you have to use a mother ship. This is how it's going to work in the single-player Miner Wars 2081. Of course travelling can be accelerated using a "Traveling Screen" - nobody wants you to sit 15 hours in front of your computer and wait until you get from one side of the Solar System to the other.

However, in Miner Wars MMO it's going to be different. The universe will be shared by all players, so travelling speeds need to have some realism. Pure teleportation (instant traveling time) from Mars to Earth would certainly break a lot of game mechanics. At the same time, sitting and waiting for several hours in front of your computer is not much fun (at least not for me). So here we would probably use faster mother ships, which will almost reach or even cross the speed of light - but only for the sake of fun. E.g. traveling from Sun to Earth would take 2 minutes, but travelling from Earth to Moon would take just couple of seconds (or less...).

If you are curious what are the sectors in Miner Wars, you can look on the following picture. Each of those squares represent one sector. Of course, in this drawing the sizes are not real - it's just an abstraction. 

Sun light and dynamic shadows

On a different topic, last week Petr Minarik got to finish the implementation of dynamic shadows for the Sun.

Until now the game used a trick - the whole space was split into hierarchy of cubes where the smallest one was only few meters in size. The the game was calculating whether the cube is visible from the Sun and used this knowledge to put an object or voxels into a shadow. Advantage of this approach was that it was fast for rendering (almost free). Disadvantages were that it was static (although in case of voxel destruction, we were able to recalculate cubes stricken by an explosion - so it was dynamic) and also that we were able to put only whole object into a shadow. We were not able to say that only some polygons of an object are inside a shadow. This worked well for small ships and particles, but not that well for large ships and space stations. For example, we would never be able to put only half of a station into a shadow.

A few months ago we decided that objects in Miner Wars need to be completely dynamic. So we also needed dynamic shadows for the Sun. After analyzing few algorithms we decided to go with cascaded shadow maps. We use four cascades, each one is 1024x1024.

In next couple of days we plan to implement blending between cascades and do some optimizations - especially limit the number of objects rendered into each cascade.

There's also a chance that we may do seamless LOD transition inside shadow maps - rendering high-detail close objects in one shadow map, and low-detail distant objects in another shadow map, and then blending the result in Sun light-pass. Advantage would be that also very distant objects would cast shadows, and that you won't see any shadow popping when you come closer to those occluding objects.