Steel Beasts Dynamic Terrain Will Come After New Terrain Engine

[Asid]

At least things are moving forward 

[Rinix]

http://www.steelbeasts.com/topic/4546-steel-beasts-content-wish-list/?page=215#comment-173821

So, it is a really big task that requires a dedicated development. That in turn requires that we give it a suitably high development priority, which I just don't see possible at the moment. We are committed to working first on the high resolution terrain engine, next on dynamic terrain and the countless implications that it has for units navigating in it. It has implications for data handling, hardware requirements (particularly data storage I/O - if you're planning to buy a new computer, think of large enough SSDs), and some of these changes have implications for the user interface. Only after all that has been dealt with will we have the capacity to even think of something else.

[Asid]

Thank Rinix 

[Rinix]

http://www.steelbeasts.com/topic/11302-eta-on-terrain-patch/?page=3#comment-174233
I get that eSim Games shouldn't rush the upcoming release. But after giving a preorder time frame of "probably still a few weeks away, though" all the way back in May, and , you'd think Ssnake could actually tell us if they're behind schedule, rather than getting defensive. It's got me worried that there's something seriously wrong with the upcoming release.

[Asid]

I get that eSim Games shouldn't rush the upcoming release. But after giving a preorder time frame of

This can cause problems. When you give people a date or time frame and miss it then their is at least disappointment, at the most anger.

[Rinix]

http://www.steelbeasts.com/topic/11688-1973-war-idf-damaged-tank-survey/#comment-174330

Well, obviously a low resolution terrain database that still looks natural cannot offer "micro cover" - small but sharp variations in the terrain that are sufficient to mask a combat vehicle at least partially, or in full. Real life is full of these micro cover elements; it starts with walls and fences in large numbers in urban areas, there's irrigation and drainage ditches, and most prominently, most major roads will have a significant lengths in the form of ramps to smoothen elevations, or when leading up to overpasses - or they cut into slopes when running parallel to mountain slopes.

All these elements require a higher resolution than a 30m grid, which is still the standard for most of the maps in SB Pro PE, even if the Steel Beasts mesh width offers an almost six times higher resolution (12.5m grid). The lack of micro cover will therefore tend to expose vehicles to each other at longer ranges, and for longer durations. This in turn leads to longer engagement ranges than is often observed in real-life training, and the impact locations are almost evenly distributed between hull and turret. You can easily observe that when groing through your own saved AAR files, or, more coarsely but with a probably much broader base of samples, check out the HTML formatted tabulated mission reports that Steel Beasts generates for every. single. scenario that you have every played since first installation. You can open these tables with pretty much any contemporary spreadsheet program. There, above the event list, you can see both the distance for every shot taken, and a coarse description of the hit location. If you would do a quantitative statistical analysis you could see what the average engagement range in all your scenarios was (you could even filter it by weapon system/ammunition type to sort 120mm gun rounds from TOW missiles and 25mm autocannon fire), and you will probably find a distribution of 60% turret hits to 40% hull impacts.

My prediction for future games with the high resolution terrain engine, where the scenario played is based on a high resolution terrain (like LIDAR scan), the balance will shift from 60:40 to 95:5, at least as far as human vs human engagements are concerned. This is at least what the first tests suggested that were reported during the Steel Beasts Conference this year, and it seems to have been confirmed in other, independent tests since then. I think it's safe to say that the introduction of high res terrain databases will have a profound impact on the way how Steel Beasts will be played, and experienced.

[Frankie]

What's the 'Steel Beasts Conference'?

[Asid]

As usual, Thx Rinix 

[Rinix]

What's the 'Steel Beasts Conference'?

It's a conference that apparently is run by eSim Games, Terranis Systems has mentioned it: http://www.terranis.se/en/news-5609627

As usual, Thx Rinix 

You're welcome.

[Rinix]

http://www.steelbeasts.com/topic/3762-map-request-thread/?page=14#comment-174489

I'm not going to be making anymore community request maps until the New Terrain engine is closer to release. Partly because I don't have the time at the moment. The other factor is that there is little point making maps for 4.x, with the NTE they will all need converting to new formats. I have enough of those to do without making more work for myself.

Dark's comment suggests that the new terrain engine might be coming sometime soon.

[Frankie]

It's good that he doesn't keep us in the dark.

[Asid]

Big thanks to Rinix for keeping us updated 

[Rinix]

http://www.steelbeasts.com/topic/11302-eta-on-terrain-patch/?page=3#comment-174597
Finally, some meaningful communication:

We identified one last issue. As the map sizes grow bigger - something that cannot be helped with higher resolution - this has a number of user interface implications. Aside from a number of network game setup/coordination issues we basically concluded that you also need an option to put your maps on a different disk drive than the one mandated by Microsoft's multiuser guidelines (which essentially offers no alternative to "C:\ProgramData").

So, this is the last feature to implement, a non-command line parameter option to set a different file path for the map directory, so the maps won't clog your small SSD C: drive (unless you're a filthy power user and have a really big SSD for C:\ ...). The command line parameter already exists, so our internal version of SB Pro can already handle that. What's needed is a proper file browser that lets you pick a non-standard directory. That's being worked on. Also, we're converting all the official legacy maps, one by one so you won't have to do that. Aside from the sheer CPU time to convert each map (a few hours) we also try to determine which version of a map actually works best as the base map, and we try to fix all the (missing, or wrong) map meta data (e.g. if a map isn't properly georeferenced the virtual world would sometimes show a night sky when your chosen time of day is 10 am., or the time zone settings would be all wrong; finally it also has an effect on the star patterns on the night sky). So we can't simply batch convert all maps, which turned out to be one factor (among others) why we aren't ready for a release already. And without the map conversion process being complete we don't know the size of the (separate) map installer, which will determine how many DVDs we need for it, which has a direct consequence on the production plans for the new installation disk set.

Dependencies, dependencies...

We covered about 95% in our project plan, but some things you only discover once that you're running the first practical tests.

[Asid]

Most people are used to games being 20,40, 70+ GB. Software just seems to get bigger.

Thx for the post Rinix 

[Rinix]

Most people are used to games being 20,40, 70+ GB. Software just seems to get bigger.

Thx for the post Rinix 

You're welcome. The rise in size for Steel Beasts is because of the maps. It reminds me of Titanfall, where 35 GB of the 48 GB it takes up are uncompressed audio.