New release – TEST BUILD – is out

New release – TEST BUILD – is out!

Get it from here:

Upcoming release and moving to a cloud

Upcoming release – 30.8.2011 and 31.8.2011
Finally after 8 months of a release silence, we will have a release! First one will go 30.8.2011 to the test build environment and the day after to the public build environment.
We are not going to announce it loudly because first we want to test the new auto-updater functionality. All of you who watch our forum will be informed soon enough and you will get a list of new features, screens etc.
One of the new features is peer-to-peer downloading. What does it mean? Until now, when you downloaded the setup file for Miner Wars or when you launched the game and it detected an updated version and then downloaded it – all these data came from our server at Amazon S3 and we had to pay for every single byte.
Not anymore! From now on, everyone who runs our setup or auto-updater seeds the data to other people. This helps us to keep low traffic costs.
The good thing about this is that you will be seeding only while setup or auto-updater runs. After it’s done, no more uploads for you – we hope to use this function especially for after-release traffic peeks, when many people download the new release at the same time.
Saved money goes to charity and our pockets. By charity I mean more money for development – better and greater features. Everyone will be happy.
If you are interested how much money we speaking about, here is a simple math: we pay roughly $0.090 per GB. If we assume that one customer generates about 1GB of traffic by downloading the setup file and then a couple of updates, then 100,000 users generate costs of $9,000! That’s not a killer, but I am personally scared to death by a vision of having 1,000,000 users and paying $90,000 or even more, because things can go only worse – people can start downloading like crazy, uninstall, reinstall, update, and all that would generate a lot of traffic.
EDIT: The new peer-to-peer setup will be postponed to next release due to some difficulties we have encountered during the last testing phase.
Moving to a cloud
On Friday we started having outages on our server. Very strange thing, monitoring tools didn’t show any hardware or software failure. Server just kept restarting every couple of hours.
We knew that one day we would need to move to a more reliable environment, not depending just on one piece of hardware. However, there were other priorities, so we were postponing it. But now we were pushed by upcoming release, so we had to make a quick and brutal decision.
How to pick up a cloud server provider in 1 hour and during weekend? Well, that’s simple – I already knew RackSpace and their portfolio of products, that their clouds have persistent storage, that they support people online 24/7 etc. – so I just visited their site, made the registration, created and configured new cloud server and within 30 minutes we had a new server. Then we moved there our web sites, databases and game services within a couple of hours.
The best thing about the cloud server is that when the physical hardware it runs on dies, they restart our server from the image within a couple of minutes. No worries about configuration, backups, etc.

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:

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 1024×1024.

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.