New release - TEST BUILD - is out!
Get it from here: http://www.minerwars.com/ForumTopic.aspx?id=1998
Tuesday, August 30, 2011
Sunday, August 28, 2011
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.
Monday, August 22, 2011
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:
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.
In Miner Wars we have two types of ships:
- small ships controlled by player
- large mother ships controlled by an AI
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.
Wednesday, August 17, 2011
Full Solar System with an ability to land anywhere (Earth, Moon, other planets, moons, asteroids...)
Limitless and fully dynamic environments in Miner Wars!
Recently I started looking more into how are we're going to generate the environments for Miner Wars. The game is going to be played within the whole Solar System, an area which has about 1000 million kilometers in a radius, real planets and moons, real travel speeds, no boundaries and a fully dynamic environment.
Before I continue - when I say “real planets and moons” - I actually mean pieces of planets and moons scattered all around after the disaster of 2071. You will get more details on this later in our story.
The player will be able to fly to Earth, visit its ruins, land at any place, destroy whatever they please, then fly to the Moon, Venus, Mercury, or even burn themselves in the Sun (if he wants to). I believe this is going to be the first game where you will have this kind of freedom – free-roaming the Solar System with the ability to land anywhere and destroy anything! :-)
We can’t manually design all these objects, there’re going to be millions of them. We have to generate them procedurally.
Positioning objects – objects will be placed on a roughly real positions (e.g. the distance between Sun and the Earth will be 149 million kilometers). Other not important objects will be placed on semi-random positions - something like fractals.
Object types – voxel asteroids, space stations in open space, space station inside asteroids, static and indestructible asteroids, dusty areas, debris fields, space cities, etc.
Voxel asteroids – current max size is 8x8x8 kilometers, although I believe we will be able to increase it in one of the next development iterations. There’s one idea I got just recently – if interior parts of an asteroid will be non-destructible, than we can save a lot of memory by compressing those places and we can support much larger asteroids than if they were totally destructible. Also procedural generation of asteroids is simple, we have about 100 basic shapes and the only thing we need to do is to randomly merge these shapes. If you do a couple of additive and subtractive merges, you get an almost unlimited variety of asteroids.
Space station in open space – these will be handcrafted--as we don’t believe we are able to procedurally generate stations that would be fun to visit--they need to be done by a human designer.
Space stations inside asteroids – same as space stations, except we need to dig tunnels into an asteroid before we place a space station inside.
Dust clouds, debris field – these are simple to generate procedurally.
The game doesn’t render all these millions of objects in each frame; that would be impossible. Instead we split the space into a regular grid of sectors, where each one is 200 x 200 x 200 kilometers in size. The game holds objects only within the current sector. When players travel from sector to sector, the game has to reload all objects from a new sector. This isn’t a burden at all because it takes about 16 minutes to travel from one side of a sector to the other.
Memory requirements – the game is designed to fit within 1 Gb of RAM therefore we need to save memory as much as possible. For voxels it’s achieved by using many levels of real-time compression. For space stations it’s similar, each one is made from prefab modules and the game needs to hold just the position, orientation and type of a prefab module. If we place 100 prefab modules of same type into a sector, it doesn't increase memory requirements by factor of 100, only by a fraction of it.
What about objects in the background - since the game only really renders objects within the current sector and remaining objects needs to be put on screen too, we pre-render them into a cube texture, which is then rendered on-screen. This texture doesn’t change while you are in a sector, only from sector to sector.
And here comes a new challenge: Because a year ago our plan was to have just few of these standard backgrounds with the Sun, Earth, other planets, some galaxies and stars... but we have changed the story a little and now it’s possible to travel to the Earth, Moon, near the Sun, etc., so we now need an arbitrary number of backgrounds. You need to see Earth's ruins while you're traveling to it--even if you're sectors away. I don’t know yet which way are we going to choose: whether we possibly pre-render them in-game during the loading phase, or maybe during the offline game build process; alternatively we may just generate them in 3DSMAX using a script. It’s still open. I just know that the backgrounds need to look great!
EDIT: I forgot to mention that all objects are stored only on our servers and client downloads only what's in his close proximity (in his current sector). Therefore no worries about having gigabytes of data on your local hard drive.
EDIT: I forgot to mention that all objects are stored only on our servers and client downloads only what's in his close proximity (in his current sector). Therefore no worries about having gigabytes of data on your local hard drive.
Monday, August 8, 2011
Miner Wars - development progress - 8th August 2011
Rastko Stanojevic (3D Artist) works on the intro video for Miner Wars 2081. I don't want to spoil too much so here's is just a small preview - not revealing the details!
Filip Novy (3D Artist) has prepared these great scenes - just by configuring in-game prefab modules. It took him only 15 minutes. Every Miner Wars player will be able to do the same thing very soon!
Next release of Miner Wars is coming this month - we are stabilizing and finishing as many features as possible. Not really adding new stuff, just making existing features stable and polished.
We've also been taking care of a few garbage collection issues: For those who don't know, if you allocate new object, depending on your situation in heap, it may trigger garbage collector to free up unused memory - which can show up as a small halt in execution. The game would just stop for couple of milliseconds.
Our goal is to avoid these situations, so we have very simple rules:
Here's list of those we use:
What I usually do is launch the profiler, let it attach MinerWars.exe, and look for new allocations. If that's not possible then I make a memory screenshot, wait 1 minute, make another memory screenshot, and let the profiler compare results. Final report shows the list of objects created between the first and second memory snapshots. Next, track down the code where those allocations were executed and let know the programmer about it.
The lucky thing is that we don't need to do performance profiling, the game is running really well. But just for curiosity I did the analysis, and to my surprise the most expensive method we use is the calculation of sound occlusions. That's our own method which calculates "visibility" between a sound and the player. The result is then used to set DSP/RPC parameters to the sound - so those who are behind an obstacle are more "occluded" to the sound.
Filip Novy (3D Artist) has prepared these great scenes - just by configuring in-game prefab modules. It took him only 15 minutes. Every Miner Wars player will be able to do the same thing very soon!
Next release of Miner Wars is coming this month - we are stabilizing and finishing as many features as possible. Not really adding new stuff, just making existing features stable and polished.
We've also been taking care of a few garbage collection issues: For those who don't know, if you allocate new object, depending on your situation in heap, it may trigger garbage collector to free up unused memory - which can show up as a small halt in execution. The game would just stop for couple of milliseconds.
Our goal is to avoid these situations, so we have very simple rules:
- don't allocate new objects during gameplay
- allocating objects during loading time is OK, the player won't see any halting
- allocating structures is fine, because that's done on the stack.
- using LINQ expressions
- enum as a key to a dictionary
- casting collection to an interface and then iterating via foreach
- Or they just make a mistake and don't realize the code is being used within gameplay
Here's list of those we use:
- Scitech .NET Memory Profiler - very good, we can see real-time allocations per second and see the call stack that led to the allocation
- Yourkit Profiler - same as Scitech, but cheaper
- Microsoft CLR Profiler - free and also very useful, although not real-time data and not as user-friendly as Scitech and Yourkit
- Equatec Profiler - only performance profiling, but with very good and transparent results
- ANTS Performance Profiler - probably the best performance profiler, although not that cheap
What I usually do is launch the profiler, let it attach MinerWars.exe, and look for new allocations. If that's not possible then I make a memory screenshot, wait 1 minute, make another memory screenshot, and let the profiler compare results. Final report shows the list of objects created between the first and second memory snapshots. Next, track down the code where those allocations were executed and let know the programmer about it.
The lucky thing is that we don't need to do performance profiling, the game is running really well. But just for curiosity I did the analysis, and to my surprise the most expensive method we use is the calculation of sound occlusions. That's our own method which calculates "visibility" between a sound and the player. The result is then used to set DSP/RPC parameters to the sound - so those who are behind an obstacle are more "occluded" to the sound.
Monday, August 1, 2011
Miner Wars - development progress - 31th July 2011
Another week of Miner Wars development is behind us. I bring you some insights into our progress.
Slobodan got a new camera, so we took a photo of the development gang. Only people available in Prague were shot - you can't see Dan, Nick and Ansel (they will be faked-in in an official version that's gonna be released shortly).
It has been a long time since we played Miner Wars on a really old hardware. We have one computer just for this purposes, an as old as hell - GeForce 6600 with only 128 MB video memory. I was extremely surprised to see Miner Wars running smoothly at 20-30 FPS. Not even on LOW settings, therefore executing GPU-expensive algorithms such as SSAO or our own (yet simple) post-processed anti-aliasing.
Our proprietary Image Space LOD (level of detail) is really a miracle! Guess who is the author!
In-game editor is shaping nicely, although still needs some touch-ups to make it mega-intuitive. For this purpose we are going to organize a series of "usability" test sessions - right here in the office. We will call random people (e.g. the president of the country, or that crazy guy dancing on the bus station who also claims to be the president), let them play with the editor, and observe how they are doing.
The physics engine has been almost completely rewritten. It's stable, even for objects at large positions (tens of thousands of meters from the point zero). It's multi-threaded - we use custom-made parallel tasks library. One of the features that still needs to be changed is the new way of 'head-shaking' and some of the 'head-acceleration-reaction' equations.
Actual GUI looks cool, we decided to go with 'holographic design', transparent, futuristic, satanistic and saturated colors. This way it looks sci-fi. We wanted to avoid 'stone design'.
We had an interesting issue in the part of the engine holding the list of active objects (voxels, player ship, mother ships, AI). Someone made a mistake, and every object was loaded twice! We found it when we noticed that every object and its ghost version (which wasn't supposed to be there) were colliding -- we had hundreds of collisions per frame. Of course it's fixed now, but it did get us to implement one nice feature (added into developer screens that you can use in TEST build) - we can display every collision in the game HUD as a navigation point!
Actually there are so many cool options in debug/developer screen. Cracker's paradise!
I finally got to play Prototype (on PC). That game has such a perfect controls (occasionally there are some glitches, but who cares?). I really like all the jumping on skyscrapers, gliding, throwing trucks and people -- this is how gameplay and game mechanics make a great game.
The following week will be mainly about stabilizing base code and making sure that what's implemented is perfect and looking fantastic. The next big release is knocking on our doors!
Slobodan got a new camera, so we took a photo of the development gang. Only people available in Prague were shot - you can't see Dan, Nick and Ansel (they will be faked-in in an official version that's gonna be released shortly).
It has been a long time since we played Miner Wars on a really old hardware. We have one computer just for this purposes, an as old as hell - GeForce 6600 with only 128 MB video memory. I was extremely surprised to see Miner Wars running smoothly at 20-30 FPS. Not even on LOW settings, therefore executing GPU-expensive algorithms such as SSAO or our own (yet simple) post-processed anti-aliasing.
Our proprietary Image Space LOD (level of detail) is really a miracle! Guess who is the author!
In-game editor is shaping nicely, although still needs some touch-ups to make it mega-intuitive. For this purpose we are going to organize a series of "usability" test sessions - right here in the office. We will call random people (e.g. the president of the country, or that crazy guy dancing on the bus station who also claims to be the president), let them play with the editor, and observe how they are doing.
The physics engine has been almost completely rewritten. It's stable, even for objects at large positions (tens of thousands of meters from the point zero). It's multi-threaded - we use custom-made parallel tasks library. One of the features that still needs to be changed is the new way of 'head-shaking' and some of the 'head-acceleration-reaction' equations.
Actual GUI looks cool, we decided to go with 'holographic design', transparent, futuristic, satanistic and saturated colors. This way it looks sci-fi. We wanted to avoid 'stone design'.
We had an interesting issue in the part of the engine holding the list of active objects (voxels, player ship, mother ships, AI). Someone made a mistake, and every object was loaded twice! We found it when we noticed that every object and its ghost version (which wasn't supposed to be there) were colliding -- we had hundreds of collisions per frame. Of course it's fixed now, but it did get us to implement one nice feature (added into developer screens that you can use in TEST build) - we can display every collision in the game HUD as a navigation point!
Actually there are so many cool options in debug/developer screen. Cracker's paradise!
I finally got to play Prototype (on PC). That game has such a perfect controls (occasionally there are some glitches, but who cares?). I really like all the jumping on skyscrapers, gliding, throwing trucks and people -- this is how gameplay and game mechanics make a great game.
The following week will be mainly about stabilizing base code and making sure that what's implemented is perfect and looking fantastic. The next big release is knocking on our doors!