My second and longer presentation at GDS 2011

My second and longer presentation at GDS 2011. I spoke about how I got from one-man-show development, to 1mil EUR investment, to a team of 20 fulltime developers.

Sorry, it's in Slovak language only.

Moreover, the audio quality is not only bad, it's awful. 

Interview with Marek Rosa, held at GDS 2011 by TV Show "Indian"

Interview with Marek Rosa, held at GDS 2011 by TV Show "Indian"

Czech-slovak speakers only. BTW, my interview is just a small part of the whole video.

http://www.zing.cz/indian/porad/indian-112-251/

I liked talking with the Indian crew. We had a good meaningful dialogue. Not like that other interview two months ago by other TV show.

My first and shorter presentation at GDS 2011

My first and shorter presentation at GDS 2011 - for Czech-slovak speakers only.

In this one I just presented Keen Software House and our products: VRAGE, Miner Wars 2081 and Miner Wars 2.5D

It feels so weird to see and hear myself :-)

Getting a 1 mil EUR investment was super-simple! (part 1)

Last weekend we had Game Developers Session 2011 here in Prague. My company Keen Software House was the general partner of the conference. We were showing Miner Wars, people enjoyed it and they were surprised by Miner Wars 2.5D (which we haven't officially announced yet) - and they seemed to be really interested in it. It seems to be a good concept!

Miner Wars 2.5D

I had a presentation and its topic was: Getting a 1 mil EUR investment was super-simple!

10 months ago I signed an investment deal with my investors. They have put 1 mil EUR into Keen Software House / Miner Wars. I spent only 3 months in the investor searching phase and at the end there were 3 different companies wanting to invest. Then it took only 1.5 month to finish legal papers and get the first money.

It was that simple! Super-simple.

Of course, it was that simple only because I did my homework and spent 2 years working on the prototype, released the pre-alpha and most importantly: sold a couple of thousands of preorders.

In the following blog posts I am going to recapitulate everything, from making the prototype to getting investors, to creating a dream team, to making an AAA game...

Upcoming chapters:

• History of Miner Wars
• How did I convince the investors?
• What wouldn't convince the investors?
• Relationship with my investors
• How we operate in a "lean startup" mode
• Changing role from programmer to enterpreneur
• How to pick the right developers and "fire" the others.

Gameplay programming notes

Last Friday we had an internal meeting on this topic: all engine features are already 99% done, so now we are focusing entirely on the gameplay. These are our notes for the next month of development:

Top priorities:

• Harvesting ore
• Building, protecting and upgrading space stations
• Fighting
• Traveling the solar system
• Inventory

Solar system and all its sectors will be procedurally generated

Small ship parameters – health, armor, ammo, inventory/cargo, radar, credits/money, etc...

Persistent world

Schedule solar wind

Dying, re-spawn, checkpoint

Factions – friend, enemy, neutral

Simulating actions and interactions on higher level (above real-time sector level) – e.g. faction A attacked factions B, hero X goes to kill enemy Y.

Mother ship

• If you own the mother ship
• Move stuff between your small ship and mother ship cargo – foundation factory, ammo, weapons, tools, etc.
• Traveling the solar system
• If you don’t own it
• Buy or sell stuff: prefabs (or maybe only the foundation factory), blueprints, ammo, weapons, ore, etc
• In both types
• Recharge small ship fuel, oxygen, etc. - Maybe automatic and free of charge?

Building your station and mother ship (in the editor "builder mode" – not the editor "god mode")

• Place a foundation factory somewhere and that is going to be the center of your container
• Foundation factory = current green cube in the center of a prefab container – but we will make some pretty prefab for that soon
• For all other prefabs you need to purchase their blueprints and also deliver required ore
• Creating prefabs requires time - first you place an order to your foundation factory, then it’s created and you can use it
• You can own more foundation factories

Later: transferring stuff between foundation factory and your small ship (e.g. if some prefab created new ammo for you or other stuff)

Basic “mission scripting” – the player needs to be pushed to actions

• You start the game and you will appear in some sector – as it’s right now
• Your mother ship will be somewhere close
• The enemy will attack you and your mother ship – you have to guard yourself
• After you kill them, new mission pops up – travel to some other sector and buy foundation factory
• You travel, buy, etc.
• You come back, place factory at desired location
• Start building your base, build prefabs if you have their blueprints and after you have collected required ore
• If you need better prefabs (e.g. more advanced ore refinery) – you can travel to other sectors and purchase blueprints from some other mothership

Later we will find a way how to add building into our MW1 story – because story doesn’t need it and we can’t just throw it out.

Default weapons needs to be user friendly

• Problematic aiming with auto canon
• Guided missile as default one? Make better HUD for it?

Try to make every in-game interaction generic – we never know if we decide to allow player to sell or buy a new mothership, whole prefab container ... and crazy stuff like that.

Inventory screen

• Buying and selling with other mothership or players
• Looting other players
• Transfer between the mothership or foundation factory and your ship

Finishing weapons and tools

Radar and HUD – ore locations, custom position marks

AI / bots

• Investigate current AI status, what’s wrong, what’s not finished
• Factions
• Spawn points
• Aiming, fighting, shooting
• Movement

Multi-player / networking

Destructible prefabs

KILLER feature of Miner Wars 2081

What feature is going to be the KILLER feature of Miner Wars?

This post is intended to open a discussion. My mission is to find the single thing that will make Miner Wars remembered for centuries.

Our team already has some ideas, but what we need is the voice of the people.

When I started Miner Wars project I knew I need some special feature, something that other games don’t have. At that time I didn’t care about genre or type (strategy vs. FPS shooter, car driving vs. space shooter...). The only important question for me was “what's the most original game feature?”.

Then I got this idea with destructible environment, mainly inspired by old DOS game Tunneler http://www.youtube.com/watch?v=8wcdIDr4jrU I felt that destructible environment is a cool and original thing, people will want to try it – and there was no other game that could offer that in those times.

Putting the game into asteroids field, adding open space world, in-game editor, epic story, etc. were just extensions to the original concept - destructible environment.

Now we got into a point where technology of Miner Wars / VRAGE is almost done and we can focus on the game play itself. So here's the question:

• What is the KILLER feature of Miner Wars?
• What will be the KILLER feature of Miner Wars?
• What should be the KILLER feature of Miner Wars?

To help you out, here’s a list of what I consider key features of Miner Wars:

1. Harvesting (mining)
2. In-game builder with prefab modules – you can harvest ore and build your own space station, in an open space or underground. Think about it as something similar to MineCraft, although I have never played it, so I can only assume.
3. Huge open world - free traveling in our solar system – from Sun to Earth to Mars and further – with landing too, although since all planets in Miner Wars world are destroyed, you will actually land on scattered ruins of the Earth.
4. Intuitive controls and fighting (FPS + third-person)
5. Realistic physics (Newtonian + inhibited)
6. Advanced rendering engine
7. Destructible environment – voxels, asteroids, prefab modules
8. Cooperative multiplayer mode and later MMO
9. Over 20 playable small ships
10. Trading and economy, living world

By KILLER feature I mean: one single thing that people will talk about, philosophers will convey never-ending discussions, minstrels will sing sonatas and players will die for.

Is there any brave soul who can give me an answer or an opinion?

Thanks,
Marek

We were in Czech Television!

The guy in the white shirt is me... although I can't believe I look so weird :)  Camera doesn't like me.

http://www.ceskatelevize.cz/porady/1095870977-game-page/211563242600028/?clanek=823

New Release Of Miner Wars & New Logo

Hi guys!

We have just released a new Miner Wars Test Build (and granted Test access to all our customers), so feel free to try the new version and post your suggestions, ideas etc. More information as to the current release as well as comming soon features is available in the official PR in our forum:

New October Miner Wars 2081 Release:
http://www.minerwars.com/ForumTopic.aspx?id=2069

New Logo:


Comments? Do you like it?

Miner Wars - Advanced rendering - Voxels, SSAO, HDR, shadows, image space LOD

Lately you have been crying and demanding a new footage. Since we like spoiled kids, here is a small demonstration of our latest advancements in VRAGE rendering.

All these phrases such as SSAO and HDR are almost a standard feature in current AAA video games - but I wanted to show them, because our lead rendering programmer Petr Minarik took a special care to make them extremely beautiful!

I am a modest person so I will just say: Miner Wars is now the best looking space simulation ever :-)

Other than that: the next big milestone is to finish playable sandbox single-player story mode. Once it's done, the game will finally start to live. Sectors will get filled with asteroids, debris, space stations, rats, mosquito and pedestrians. We are not far from that, maybe 2-3 weeks.

Yeah, regarding my "personal life" - I was finally able to spend a full weekend programming. Not just doing design and architecture, but actual programming. That's very refreshing. My mirth has disappeared at Monday morning - once there are people in the office, I am interrupted at least every 5 minutes. I don't know if people want to talk with me because of my friendly personality, or they just enjoy bothering me, or mix of these two... what do you think?

New Miner Wars logo is in the production (by our genius artist Filip Novy) - you can see the first sketch in the video above.

Angry German Kid finds Miner Wars

This is one older video made by Ansel. It reminds me of... myself! :-)

What has happened in last two-three weeks:

• We had guests from Czech Television (CT1), they made some short interviews with us for the show/documentary about computer games in the middle of October.
• Work on Miner Wars technology is finally nearing its end, so soon we will be able to focus entirely on gameplay mechanics.
• We are writing Miner Wars Encyclopedia, with list and descriptions of factions, solar system map, history till 2081, weapons, technology, life in Miner Wars...
• We hired some new guys and let go some other - it's actually very cool here in Prague: more developers want to work with us than we can actually hire. We can really keep up to my dream and have only the best staff we choose!
• Our in-game editor got many fixes and new features too: player can place large ship weapons that will start shooting at enemies, new light and particle prefabs, many new prefabs/models etc.
• We made 5 new small ships and one more is still in production and it will be a spherically shaped ship. I am curious how will that turn out.
• I know you don't want to hear this, but we have implemented HDR and environment mapping, although they need some tweaking. Also shading algorithm got some precision increase.
• Bots do auto-leveling according to player's horizontal orientation.

What's next:

• This week we are going to fix persistence of the game world, therefore we will finally be able to populate our story mode with asteroids, stations and enemies - and give it some real life!
• Implement multi-material voxels, so harvesting will make sense (again!)
• Finish kinematic prefabs - doors, fans, rotating generators...
• Implement toolbar into in-game editor, making it more user friendly
• Implement our own particle editor, which will give more power to artists and take the burden out of programmers.

How to show scale and real world proportions in space

In Miner Wars we always had issue with how to show to player the real size of objects around you? How can you "feel" that a tunnel is wide 20 meters and not 2 meters or even 200 meters?

In standard FPS games this is much simpler, because you know that you are a person and how tall an average person is, you also know how large are buildings, doors, windows, cars... all that helps you perceive the dimensions and scale easily.

In Miner Wars and in space in general it's not that simple. You may encounter huge objects, corridors or docks, but since you have no comparison with objects of daily use (ie. grass, people, trees), they may seem much smaller than they really are. Some of the large prefab modules - chambers - may have 300 x 200 x 150 meters (= 9 000 000 m3) or even more. And consider the whole space stations made of several these chambers and hundreds of smaller ones.

Our current approach is to introduce helper markers and objects. We will be putting these markers on walls, next to doors and entrances or as 3D holographic objects in space to show the player how big the objects actually are. Look on these pics, they will show you more than my words.

We really want to hear your suggestions and ideas on this topic. Should we make also another type of marks? What type? What should it show? Or other type of 3D object? Or some virtual grid showed in HUD? Or sphere around your cockpit?

Release Postmortem & Public Build vs. Test Build & New Logo

Release Postmortem

The last release on the 30th/31st August was the first one after 8 months of awkward silence. Now it's the time for some reckoning.

What went right:

• the in-game editor was finished up to the usable state
• the new renderer was finished up to the usable state
• we survived switch from a small team to a medium sized team 
• we went over 20,000 registrations, sold over 8700 sold copies
• switched from .NET 3.5 to 4.0, and XNA 3.1 to 4.0 without any major issues

What went wrong:

• the P2P auto-updater and setup downloader were not finished on time, so we had to remove them from the release just a few hours before the deadline and let the users download a new setup file
• no multi-player yet
• standard misunderstanding between the Test and the Public Build led to confused users, hatred and even wars!
• there were more bugs than what am I used to and what can I personally accept - so this is a big area for an improvement. One of the steps we took was hiring a new part-time tester.

We have chosen a route where we want to keep doing frequent releases. That's very risky thing, because we have no time to stop the development and focus entirely on fixing and stabilizing. There's still an ongoing development. We could easily damage our reputation with having not-so-stable releases. But I am sure we will figure out something and our releases will be stable again!


Public Build vs. Test Build

Since we have such a great community I decided to use your help in deciding whether we should open Test Build for every paying customer.

Let me repeat why not everyone gets into the test build: we want to upset our customers! Yes, that's step one. Step two is ***. And finally step three is profit.

But really - the only reason was that we wanted to limit the number of people who get into the test build and see the unstable and unpolished version of the game. We didn't really realize that many people who can't get into the test build would feel cheated and betrayed this way.

So right now we are considering to open the test build to every paying customer. Probably starting with the next release.


New Logo for Keen Software House

Let me know which logo do you like most. And don't tell me they all look "nazi".

Public Release Featuring Editor

New Pre-Alpha Public Build featuring in-game editor is out!

New features: www.minerwars.com/ForumTopic.aspx?id=2004

Download at: www.minerwars.com/Downloads.aspx

New release - TEST BUILD - is out

New release - TEST BUILD - is out!

Get it from here: http://www.minerwars.com/ForumTopic.aspx?id=1998

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:

• 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.

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.

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:

• 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.

Programmers sometimes incidentally use code that internally allocates new objects. For example:

• 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

I can't track all these places manually by analyzing the source code, so I use "Memory Profiling" tools.


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.

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!

Miner Wars - development progress - 24th July 2011

I've decided to start writing a progress report on Miner Wars development. You will be able to see what we did last week, what we're up to right now, and expectations of the forthcoming weeks.

I will cover everything and all Miner Wars development staff.

Richard Waldron (Head Writer)

Richard is currently working on the introductory Miner Wars novelette - a short story which is supposed to introduce our fans to the Miner Wars universe. Other than that he's redesigned texts on the Miner Wars website and prepared some press releases.

Dan Wentz (Audio Director)

Dan just finished recordings of all generic, non-story wingmen and enemy fighters - Union, Patriots, Russians, etc. It's about messages like "Please don't kill me!" or "F*** that, I am outa here--". Here are some of the photos from a recent shoot at the sound studio.

Slobodan Stevic (Art Director)

Slobodan has recently finished the final list of all prefab modules (3D models that are going to be used in to build levels, space stations, space ships); also a few rooms/chamber models. Next week he's going to work on tunnels and other prefab types.

Rastko Stanojevic (3D Artist)

Rastko is working on the first intro video for Miner Wars (there are going to be three cinematic sequences in total). This first one is about massive-scale destruction, desperation, and introduces players to the Miner Wars universe in 2081.

Filip Novy (3D Artist)

Filip just finished three chamber/room models -- they are very large -- about 500 meters in length each!

Ilja Hubalek (2D Artist)

Ilja has finished the first stage of our new GUI. This one look more futuristic, has cold colors, and looks glowy and holographics. Right now he works on new Keen Software House logo, and we're trying something that's a combination of old style (Gothic fonts) and sci-fi armors. In next days he is going to finish the ammo selection system and HUD.

Petr Minarik (Programmer)

Petr works on our second generation renderer which is based on deferred rendering - but more importantly, our popping-free LOD (level of detail) transition. Our trick is that we render close scenes into the LOD0 render targets, then distant scenes into LOD1 render targets (these are low-poly models), and then blend LOD0 and LOD1 into final render targets which are later used for lighting, SSAO, and everything else. The best feature is that the transition between LOD0 and LOD1 models is seamless, practically invisible - even if they have different silhouettes. We needed this for the voxel LOD because that's generated on the fly and artists can't 'handcraft' it.

Ondrej Storek (Programmer)

Ondrej continues to work on network serialization, framework that will help us with multiplayer development. On Friday I saw the first working prototype - him and Michal were flying their ships in the same sector. It was very jerky, but it was the first multiplayer in Miner Wars!

Jozef Kral (Programmer)

Jozef works on prefab container merging - an optimization for prefab modules rendering. We bake hundreds of prefab modules into a few large lists (by material/shader), so the rendering is faster, fewer draw calls, fewer GPU switches. Previously, Jozef's task was upgrading our auto-updater - new version is going to work over P2P too, speeding up the download and saving bandwidth on our servers.

We plan to release this feature-rich version of the auto-updater as a separate product.

Michal Stefan (Programmer)

Michal did many tweaks to GUI and right now he's continuing to implement the first 5 missions of the campaign. In practice he works on the first mission, building the sector, placing bots, implementing basic game-play. The reason for this is that we want to test gameplay and game mechanics before we start actual development of all remaining missions. There are open questions such as: how funny is it to fly 10 minutes in open and boring space area... how to design interior levels in space stations, etc. This is actually a very interesting topic.

Lukas Zdenek (Programmer)

Lukas is working on top secret project, and if I tell you what it is, I would have to...

So I won't say much, only that all progress he makes looks very interesting and you all will be happy.

Martin Barton (Programmer)

Our new addition. Works on large ship weapons - so they can spot and start shooting at an enemy.

Nick Miller (Marketing Director)

Practically at stand-by mode. Right now we're focusing primarily on game development and are leaving business developments on the side. Although, of course, we keep in contact with existing and new partners - agents, publishers, HW manufacturers, etc.

Ansel Leos (Community Manager)

Right now at stand-by mode as there's isn't much movement in our community - everybody is waiting for our next release.

Marek Rosa (me)

Well, where should I start...

• I have been writing rendering architecture
• Analyzing one annoying feature of XNA 4.0 - requirement of DX10 hardware, even if our game doesn't need it - I will talk about this more in the future
• Coordinating the whole development - constant discussions with everybody in the office
• Hiring new developers - especially programmers
• Business development meetings and calls

In next week I really have to finish these:

• Re-validate current project plan
• Go over our current Editor and check if it's as user-friendly and as bug-free as we always wanted
• Finish design of the new Miner Wars and Keen Software House websites
• Finish rendering architecture document - if I won't finish it today
• Rewrite our business, marketing and sales plans
• Finish design of rewards for our developers
• Visit GDC Vault and finally watch some of it
• And finally - PLAY some games - I made scores of purchases on Steam in previous week (when they had those big discounts), but haven't had time to really play them. And as ancient Aztecs always used to say: every game developer needs to play games!

Lucky I don't have to do any boring administration at this moment (lawyer stuff, etc.) :-)

Goodbye, 

Marek

Transitioning from Programmer to Leader

Before I went to E3, our team had only about 6 (or so) full-time developers. I was able to dedicate 30-50% of my time to the actual production work - programming Miner Wars.

Upon return from E3, we had nearly doubled our staff. About 11 people in Czech office and a few more abroad. I had to make a quick decision – is my future that of a programmer or a leader?

Luckily, I’d had experience as a leader before, and felt confident about a transition.

While on the flight from the US to Prague, I re-read a book on the topic: Team Leadership in Game Industry. It made me think more about the prospect of running a ‘team’; right after I arrived back to Czech I strode into the office in my new role - LEADER.

Here are some of the larger implementations I’ve made:

• Production work is left to the production staff: I no-longer do the actual programming - I have to delegate all production work to other team member. Reason: if I sit down and start implementing new features, fixing code, looking for bugs... it would stop me for X number of hours, all of which could be used to perform leadership duties, and ensuring the production staff is able to keep on track.
  
  
• I do everything in my power to not be a bottleneck to the team. Reason: developers can't wait on my decisions.
  
  
• I try to lead, not manage, and especially not micro-manage. We tried hard to hire only senior developers who can work independently.
  
  
• We rotate places in our office very often (almost every week) and everybody spends his first week in the same office as I. Reason: everybody in the team gets to work with me, know me, and vice-versa, then they all get to work with each other together and ingratiate themselves; there are no separate groups and we are just a bunch of happy friends. But we still have professional discipline, follow deadlines and I rule using iron hand! :)
  
  
• I let developers to add their contribution to the design too. I don't try to design every little detail. My job is only to wrap it all up and make it move in the desired direction.

 

This whole transition (Marek Programmer -> Marek Team Leader) was very fluid, especially because I was dropping more and more programming duties during the months pressing on, so actually very little has changed to me – I’ve just made that mental switch.

Finally, I’d like to add that I’m very surprised how our team turned out. Everybody is enthusiastic and they all seem to love their job. Everybody is dedicated. I didn't expect this would work in all cases – looks like we did good job during hiring process.

The first attribute we looked for in a new applicant was his/her passion for the project. I consider this the most important attribute.

------------------------

A Post-Mortem on Administrative Tasks:

A hard lesson learnt early-on was the value of administration/secretary’s role. It is, of course, important to save money, especially as a start-up business. But the time programmers, artists, and other developers had to spend on unrelated tasks ended up yielding a cost higher than which would have been saved if we had simply hired an administrative officer in the first place.

Next time we’ll be hiring a secretary the day the office opens its doors.