Survarium: "All you'll see in the game will look as real" - exclusive interview
PC Games Hardware had the opportunity to interview Dmitriy Iassenev from Vostock Games and got some real nice answers on Survarium. As we are an hardware magazine, it's our mission to have a closer look at the technical site. So here is their promise: "All you will see in the game will look as real!"
Survarium is a free2play MMOFPS game set in the near future. The game focuses on the aftermath of a massive ecological catastrophe on Earth, the reasons behind which are only vaguely known. Impassable woods advance onto cities from every side, as maddened animals and birds attack industrial complexes, military structures, warehouses and power-plants. Strange plants and mushrooms grow through concrete and steel. Scientists all over the world haplessly try to cope with the anomaly expanding with terrifying speed across the planet. Countries collapse; anarchy spreads throughout the world. Now force dictates who can survive. The game is developed with new proprietary Vostok Engine technology and is planned for release on PC by the end of 2013. So let's ask some questions on the engine. Our imnterview with Dmitriy Iassenev!
PCGH: It could be read on your company's homepage that the technical base of Survarium is your inhouse technology, the Vostok engine. Why do you decide to build your own engine for the game instead of licensing a technology like the Unreal Engine 3, Cry Engine 3 or other middleware game engines? What are the general advantages when developing a game with inhouse technology?
Dmitriy Iassenev: Every engine has its own peculiarities: one is designed for development by a large number of people, which we can't afford to have; another requires a certain development approach which doesn't work for all games and all the developers. On top of that, we have generated a bunch of ideas to simplify the development pipeline, and we've seen no analogues of those solutions in the mentioned engines. To cup it all, we wanted to implement a very advanced network part and every engine has a pretty specific one.
Traditionally, we've set the technology bar real high, so the current engines could not any more satisfy our needs, and we didn't want to be a step behind too.
We summed up how much it would all cost us financially and decided that with the team we have on hands it would be more reasonable to develop our proprietary technology.
PCGH: How does the fact that Survarium will be an online Shooter influence the structure your base technology? Do you split up the code to a server and client version? Will there be a special engine structure resulting in the fact that the game is server based?
Dmitriy Iassenev: That fact highly impacts the game part structure. We have a separate library which is responsible purely for the game logic and that of the game objects. The library is used both by the server and the client. But the client needs visualization too. That's why on the client side we create the game objects which use the very same kind of logic as that of the server objects + they have the visual part.
PCGH: In the Q&A on your webpage you announced that Survarium will be a PC only game and that there will be no console version. What are the reasons behind this decision? Is the console's hardware not powerful enough or too outdated to run the game with acceptable visuals and a decent framerate? Will it be too much time consuming to develop a cross platform version of Survarium?
Dmitriy Iassenev: The minimal video card that we support will be 8800 GTS, and the current generation consoles do not match that level already. That's why yes, the consoles are not powerful enough for us. On the other side, developing under consoles would take us plenty of time, and to us the situation of not releasing on time or not releasing at all is practically equal.
PCGH: You promise that the engine "will be cutting edge technology". Besides the support for the DX11 API (see question concerning DX11) what are other important and very modern technologies that your engine has to offer? What are the features that make the Vostok Engine so suitable for the game? Are there any technologies that cannot be found in other game engines?
Dmitriy Iassenev: BRDF - we use a physically plausible formula to calculate lighting which uses the surface roughness, Fresnel coefficient and self-shading therm. For that a lot had to be changed in the consciousness of designers who were used to adjusting specular power, which is no longer in place. Now though, it makes a winning difference in the visual part: currently the level of surface glossiness depends also on the angle of your look at it, same as in real world. That drastically changes the approach to adjusting the materials and we are happy to have made the transition to that more advanced and true-to-life model of lighting calculation. There are multiple other changes too, but that one in particular will make Survarium visually different from any other game. At least currently .
PCGH: If you had to advertise the visuals Survarium what would you mention? Can you list some very modern and advanced rendering techniques that your renderer utilizes (Tesselation, HDR, SSAO, Parallax Occlusion Mapping, Soft Shadows, Depth of Field and Motion Blur, Deferred Lighting, Global Illumination or Tone Mapping and other post effects? Are there visual elements that are very special for your game?
Dmitriy Iassenev: Materials - all you will see in the game will look as real, it will not just differ by a defuse texture, but will be lit in a different way: metals, earth, leaves, cloths, skin and so on.
As for the technologies - everything listed, but for the Tesselation.
I'd like to particularly mention that we pay a lot of attention to the greenery and we have achieved some impressive results compared to S.T.A.L.K.E.R., but there is still room for improvement here.
PCGH: As already mentioned above you decided to utilize DX11 as API for Survarium. What are the visuals that can only be rendered with DX11? What are the DX11 rendering technologies (e.g. HQSSAO, Tessellation or Deferred Lighting) you utilize and how do they enhance the visual quality of Survarium? Can we furthermore expect a speedup for the rendering or features like Tessellation for level geometry or NPCs and maybe better texture streaming/compression?
We did not make the models which could be rendered in DX11 only, it's just that the interface allows us to unify the work both with DX10 and DX11 video cards, which is convenient to have. We started using Light Prepass, but returned to Deferred Shading as in our case it proved faster even on lower-end video cards that we support. Both methods work on the DX10 video cards too.
If taking the DX11 exclusives, we use compute shaders, plan on using tessellation, new texture formats.
PCGH: Do you try to optimize the technology used in Survarium for multithreading? If this is the case can you go into detail here: What different engine modules can be calculated in a separate thread? How does the work job structure look like? Do you use a thread scheduler? How do you handle the fact that the GPU in Survarium had a very heavy workload if this is the case?
Dmitriy Iassenev: A good question. All the hardware-dependent parts work in different threads for us: renderer, network, sound, reading from disk. Besides, the game logic, creation and management of resources also have their own threads. Additionally, we have a set of threads to perform the subsystems tasks. Thus, any subsystem can get paralleled in any spot. Ideally, we envision the work of subsystems as follows: initially we have a task created which spawns the subtasks and so on. Therefore, we will obtain maximal parallelism and a minimal number of synchronizations. Prior to that, though, we'd like to expand the game functionality and then go forward to optimize that way. To minimize oversubscription, every our thread informs the task system about it getting to sleep and waking up.
For now, we in no way use the fact that the video card will be very loaded in Survarium (and it will be). For that we'll need to profile all the subsystems together under the load - we have volumes to calculate, sound for example, requires plenty of calculations for reverbs and directions of where it came from to the player. If the processor is in rest, we will try to get part of the video card tasks onto it (software occlusion culling, for example).
PCGH: Will you offer a fallback for DX9 graphics hardware or will the game be DX11 only?
Dmitriy Iassenev: I think we will have the DX9 video cards supported, but only under Vista and up (so we could use the DX11 interface to work with them). If everything goes well, we plan to also implement a cross-platform OpenGL renderer, which will work as under Windows XP (which we don't support at the moment), so as under other OS (MacOS, Ubuntu). But those are only the plans for now. On the other side, in the shortest perspective we get our match servers ready to work under Ubuntu, so part of the code is going to be GCC-compiled and work not under Windows.
PCGH: Will Survarium offer an advanced physics simulation? If so, do you apply middleware or have you programmed you own libraries? What are the special physics features in the game? Can you give a description how physics are applied and can you tell us something about the technology behind it?
Dmitriy Iassenev: No, we will have pretty standard physics, at least at the start: we'll make sure the destructible parts in no way critically affect the gameplay. We use Bullet Physics. But more attention was paid to the sound.
PCGH: Will the physics simulation be completely calculated by your servers or will the physics engine run on the game's client, being installed on the player's machine? So far we do not plan to add the gameplay-sensitive physics, so all the calculations will be made on each client's side, i.e. physical simulation may differ on different user computers.
Dmitriy Iassenev: So far we do not plan to add the gameplay-sensitive physics, so all the calculations will be made on each client's side, i.e. physical simulation may differ on different user computers.