Steel Beasts: Content Wish List

[Gibsonm]

The prospect makes it look easy.

If you speak with the people involved, it was an gargantuan effort with much time needed and the programmers of the different softwares beeing present to fix "sh*t".

It is not like you just do...plug and play.

Yep!

HLA and DIS talk big but the end result is everybody has a different interpretation of the "standard" and most are designed to be stand alone.

Systems integration is where the heartache is.

The other thing I'd say in the context of this list is be careful what you wish for.

When/if this works, as an extreme case, Steel Beasts could just focus on say AFVs and remove Infantry and Artillery (to use the Dutch example above) and just provide part of the solution.

You the customer then have to buy three products, each providing part of the solution all at a fairly large cost and then the software/box to make them all talk to each other.

So instead of "a" product that gives you say an 80% solution you need to buy four and each on their own only gives you part of what you want.

Then you'd have to create the respective parts of each mission in each piece of software and resolve issues/conflicts in all before it would work.

And of course in a multi-player context everybody involved would each need their own copies of the four products as well.

Have fun with that.

[Marko]

Yep!

HLA and DIS talk big but the end result is everybody has a different interpretation of the "standard" and most are designed to be stand alone.

Systems integration is where the heartache is.

The other thing I'd say in the context of this list is be careful what you wish for.

When/if this works, as an extreme case, Steel Beasts could just focus on say AFVs and remove Infantry and Artillery (to use the Dutch example above) and just provide part of the solution.

You the customer then have to buy three products, each providing part of the solution all at a fairly large cost and then the software/box to make them all talk to each other.

So instead of "a" product that gives you say an 80% solution you need to but four and each on their own only gives you part of what you want.

Then you'd have to create the respective parts of each mission in each piece of software and resolve issues/conflicts in all before it would work.

And of course in a multi-player context everybody involved would each need their own copies of the four products as well.

Have fun with that.

Not going to pretend to understand the huge complexity of such a undertaking.

I was thinking more inline with the DCS concept.

A developer builds a Graphic engine.

A Smaller more specialist developer then buys or licences the right to use that engine

Builds said product using compatible code. I realise it would then have to be beta tested Against every other module in said shared world.

The DCS engine probably would not in its current version be able to handle multiple complex Sims like SB Arma etc. and my guess it would take a super computer to run it

I am not even sure if such a engine exists that could.

But one thing is for sure the computers and the other technologies needed are getting more And more powerful. so who knows what the future holds for milsim fans.

[Ssnake]

Not going to pretend to understand the huge complexity of such a undertaking.

I was thinking more inline with the DCS concept.

A developer builds a Graphic engine.

A Smaller more specialist developer then buys or licences the right to use that engine

Builds said product using compatible code. I realise it would then have to be beta tested Against every other module in said shared world.

The DCS engine probably would not in its current version be able to handle multiple complex Sims like SB Arma etc. and my guess it would take a super computer to run it

I am not even sure if such a engine exists that could.

That's actually the rub. Rendering images (consistently) is a problem in itself, but of comparatively lesser complexity. Still, even if you consider that it's the easy part, you need

• identical, or at least correlated terrain databases
  The problem is that a naval simulation needs to pay attention to different things than a jet sim, a helicopter sim, a land vehicle sim, an infantry sim. If you pack everything into one common framework you may get a beautiful software architecture that performs really badly, if at all.
• correlation of entities
  "Entities" are vehicles, soldiers, bullets, life forms (e.g. wild animals). How do you make sure than Sim A has the same set of entities in its database as Sim B? If you have an infantry sim specialist, how would he know the difference between a 120mm M829A1 and M829A3?
  So the infantry sim has poisonous snakes as random lifeforms, should the heli sim include that? What if in one sim the free-roaming Cobra slithers into a landed Chinook and takes off with it, then decides to enter the cockpit where hilarity ensues - shouldn't that have an effect across all platforms? Where do you draw the line?
  How do you ensure that the granny in Sim A with a green skirt also is a granny in Sim B, AND also has a green skirt? You need to force all the different sim vendors to somewhat share their (proprietary) artwork - good luck with that. EVEN IF (and that's a big if) they were all willing to play along, their model artwork has been developed to different standards. So every developer then needs to sit down and fix the "errors" in the other sims' model databases for himself. And then Sim C decides that they are going to introduce new standards for their object library to support a cool new feature. The maintenance load becomes a real problem here.
• Behavior correlation
  Now that all the entities are identical across all platforms, make sure that you also transmit what they are DOING. That's simple enough for vehicles but quickly gets messy if you include infantry, civilian characters of all ages, and animals. In one sim the characters can jump from trucks with a somersault. Should now all other simulations be forced to implement such an animation? If yes, what about pogo sticks? If no: Careful! Player 1 of Sim A might want to describe target X to player 2 of Sim B as a means of identification "The guy that just made a somersault!" - "Whaddya mean? Everybody is standing!"

So these are just some (very real) examples of what's going on with this integration. A common engine might address some of these issues, but not all of them. And then you get into the really messy field of who should make certain (implicit) design decisions like whether you want to use a hit point based damage model. Nice an simple, but horrendous from a "serious simulation" point of view. Physics engine - should there be one, and if so, which one? How much of an overhead does the physics engine create, now that you need to define for every single object its mass, elasticity, surface friction, viscosity, thermal absorption characteristics, light reflectivity, radar cross section, buoyancy, acceleration, turn rate in sex degrees of freedom as a (nonlinear) function of their velocity in each dimension, ... oh, and some of these data are highly classified. What do you do now?

All this is simply bogging down the development, swamping the network with additional messages, creating additional computational load, etc.

Not saying that it's impossible to solve, but if (independent) software developers are expected to do all that without (powerful) coordination from a common customer, under the constraints of commercial (=profitable) software development - that's the challenge. Right, and you also wanted to have a game that's still fun to play, performs with constantly 60 (better 140) frames per second, doesn't cost more than 60 bucks and no subscription, works on- and offline, is highly moddable (what did I just say about coordination?!), and would you like fries with that?

[Tacbat]

...and would you like fries with that?

How about onion rings?

[Rotareneg]

sex degrees of freedom

Wait, what kind of sim are we talking about here?

Here's a couple suggestions that were brought up after the TGIF last night:

Some kind of indication in the pop-up menu for IFVs to show what type of unit the infantry squads are (rifle team, ATGM team, etc.) As it is now, it just shows their unit ID:

Another one was an casualty percentage which could be used for events, conditions, or scoring. That could be really handy if the mission designer wanted to balance the survival value of troops vs tanks, for example.

[dejawolf]

yeah, just the unit designations can be pretty confusing.

you pretty much have to dismount the team in order to find out what they are.

[Marko]

That's actually the rub. Rendering images (consistently) is a problem in itself, but of comparatively lesser complexity. Still, even if you consider that it's the easy part, you need

• identical, or at least correlated terrain databases
  The problem is that a naval simulation needs to pay attention to different things than a jet sim, a helicopter sim, a land vehicle sim, an infantry sim. If you pack everything into one common framework you may get a beautiful software architecture that performs really badly, if at all.
• correlation of entities
  "Entities" are vehicles, soldiers, bullets, life forms (e.g. wild animals). How do you make sure than Sim A has the same set of entities in its database as Sim B? If you have an infantry sim specialist, how would he know the difference between a 120mm M829A1 and M829A3?
  So the infantry sim has poisonous snakes as random lifeforms, should the heli sim include that? What if in one sim the free-roaming Cobra slithers into a landed Chinook and takes off with it, then decides to enter the cockpit where hilarity ensues - shouldn't that have an effect across all platforms? Where do you draw the line?
  How do you ensure that the granny in Sim A with a green skirt also is a granny in Sim B, AND also has a green skirt? You need to force all the different sim vendors to somewhat share their (proprietary) artwork - good luck with that. EVEN IF (and that's a big if) they were all willing to play along, their model artwork has been developed to different standards. So every developer then needs to sit down and fix the "errors" in the other sims' model databases for himself. And then Sim C decides that they are going to introduce new standards for their object library to support a cool new feature. The maintenance load becomes a real problem here.
• Behavior correlation
  Now that all the entities are identical across all platforms, make sure that you also transmit what they are DOING. That's simple enough for vehicles but quickly gets messy if you include infantry, civilian characters of all ages, and animals. In one sim the characters can jump from trucks with a somersault. Should now all other simulations be forced to implement such an animation? If yes, what about pogo sticks? If no: Careful! Player 1 of Sim A might want to describe target X to player 2 of Sim B as a means of identification "The guy that just made a somersault!" - "Whaddya mean? Everybody is standing!"

So these are just some (very real) examples of what's going on with this integration. A common engine might address some of these issues, but not all of them. And then you get into the really messy field of who should make certain (implicit) design decisions like whether you want to use a hit point based damage model. Nice an simple, but horrendous from a "serious simulation" point of view. Physics engine - should there be one, and if so, which one? How much of an overhead does the physics engine create, now that you need to define for every single object its mass, elasticity, surface friction, viscosity, thermal absorption characteristics, light reflectivity, radar cross section, buoyancy, acceleration, turn rate in sex degrees of freedom as a (nonlinear) function of their velocity in each dimension, ... oh, and some of these data are highly classified. What do you do now?

All this is simply bogging down the development, swamping the network with additional messages, creating additional computational load, etc.

Not saying that it's impossible to solve, but if (independent) software developers are expected to do all that without (powerful) coordination from a common customer, under the constraints of commercial (=profitable) software development - that's the challenge. Right, and you also wanted to have a game that's still fun to play, performs with constantly 60 (better 140) frames per second, doesn't cost more than 60 bucks and no subscription, works on- and offline, is highly moddable (what did I just say about coordination?!), and would you like fries with that?

And a coke. LoL

I remember reading the manual of the first M1 tank platoon game way back in the ninety's

The author apologised for the small number of AFV's the engine and the then computer Technology could handle. and thinking to my self one day computers will have the power to accurately represent tank warfare.

Now we have sims like SB that can handle massive amounts of AFV's on huge maps and you don't need a super computer to run it.

I remain hopeful for the future of the milsim market although the day of the bedroom Developer is all but over IMO. the modular system would give start up firms a chance

A good example of this was a module made for DCS world.

It was built to a very high standard by three guys. with a small budget and a passion for what they wanted to create. I hope the gaming industry doesn't end up like the movie industry where unless you have a budget in the millions you have little or no chance of Success.

[Gibsonm]

I remain hopeful for the future of the milsim market although the day of the bedroom Developer is all but over IMO. the modular system would give start up firms a chance

A good example of this was a module made for DCS world.

How about just adding a link to the previous exhaustive posts about adapting the DCS "model" to here or adding aircraft (rotary or fixed) to here - its pretty much the same argument.

That would save us all a bunch of re-typing.

Edited May 24, 2015 by Gibsonm

[Ssnake]

I remember reading the manual of the first M1 tank platoon game way back in the ninety's

The author apologised for the small number of AFV's the engine and the then computer Technology could handle. and thinking to my self one day computers will have the power to accurately represent tank warfare.

Now we have sims like SB that can handle massive amounts of AFV's on huge maps and you don't need a super computer to run it.

Applying Moore's law to the power of PC's back in summer 1989 with a 21 month period to double the processing power, when Steel Beasts 1 was released we had approximately 100 times the power of the 386 processor available for which M1 Tank Platoon was designed. Even acknowledging that CPU computing capacity no longer follows the exponential growth in the last years, todays' PCs still wield about 10,000 times the computing power than that 386 back then. So, in a way, you DO need a super computer to run Steel Beasts. It's just that such supercomputers have become normal.

I would also like to point out that we are skirting the edge of what today's PC hardware allows us to do. Further expansion of simulation capability will largely have to come from increases in code efficiency; we can no longer count on hardware capacity growth to bail us out.

Like I pointed out in my previous post, it may not be so much the lack of computing power (although it certainly is a factor of concern), but the weight of code maintenance that makes the all-encompassing "Über Simulation" a pipe dream. We can approximate some of the desired aspects in limited areas, and occasionally the lowest common denominator will still deliver a net increase in training value. Also, perseverance will as always yield results over time, and it seems to me that both software developers, integrators and military customers alike do persevere. Still it's much easier and faster to dream up the end result than actually achieving it by continuous, hard work. It is difficult to overestimate the amount of effort that is actually required to make it happen, just like PCs that work at all are nothing short of a miracle too, given the complexity of what a computer is and does, and how many independent vendors contribute chips, memory, mainboards, GPUs and whatnot to the overall product.

[Marko]

How about just adding a link to the previous exhaustive posts about adapting the DCS "model" to here or adding aircraft (rotary or fixed) to here - its pretty much the same argument.

That would save us all a bunch of typing.

Well the post started about simulation integration.

The above post was about small developers or even start up firms trying to Complete In a market dominated by a few big firms. and what the future holds for the Milsim market some on this site find the subject interesting.

But I agree its off topic for the wish list thread.

I will start a new thread.

[OrangeFr3ak]

I'd like to see the M1A1 (AIM) as used by Australia and the LAV-25 complete with TOW.

[Ssnake]

Well the post started about simulation integration.

The above post was about small developers or even start up firms trying to compete in a market dominated by a few big firms.

If you count Eagle Dynamics or eSim Games as one of the "big firms" we should start the whole discussion with what a "big firm" actually is.

[dejawolf]

Well the post started about simulation integration.

The above post was about small developers or even start up firms trying to Complete In a market dominated by a few big firms. and what the future holds for the Milsim market some on this site find the subject interesting.

But I agree its off topic for the wish list thread.

I will start a new thread.

Esim is far from big. we just have a strong market position currently.

and there's still room for the small developers. smaller developers just need to think smaller to grow big, that is all.

[Kingtiger]

My (combat engineer) wishlist:

• Ability to add mines to ENG APC/IFV as weapon loadout (and be able to decide what kind of mine as well). - This so ENG Squad can use them to do following:
  
• Being able to lay surface layed mines and dug in mines during ingame time. (mining smaller roads etc are all within normal scenarios time limits).
  
• being able to create abatis during ingame time. (And ofcourse have them mined).
  

Oh, and Bv410 (BVS10 mk II)

:luxhello:

/KT

[Vacquero]

How about an overlay option in the mission editor to see individual vehicles when you click on a platoon, or even during planning.

[Marko]

If you count Eagle Dynamics or eSim Games as one of the "big firms" we should start the whole discussion with what a "big firm" actually is.

No, I was not portraying esim/ED as the big guys.

My point was how difficult it would be to replicate your success from humble beginnings in Todays environment and cost base, even to buy a graphic engine would be prohibitive for a start up firm trying to produce a niche milsim simulation.

I cant put a fiqure on it but I would hazard a quess it would require a low end seven figure Sum Considering the huge complexity involved.

I regularly see start up company's attempting kick starters to raise funds.

Most don't get off the ground.

Regarding The DCS module I referred to in my earlier post the developer was very upfront About the sacrifices he personally made to complete the module. He worked seven days a week and had not seen a pay check in over twelve months, his Other staff had full time jobs One was a Mig pilot. it took that level of commitment just to build one HI fidelity model. Just to clarify I am using SB/ED as examples as I have followed there progress for many years

[Ssnake]

My point was how difficult it would be to replicate your success from humble beginnings in Todays environment and cost base, even to buy a graphic engine would be prohibitive for a start up firm trying to produce a niche milsim simulation.

No, it's not. There are even free engines out there, or you simply have to find an investor who's willing ti risk the bucks. Not every start-up must be done from a garage/basement at mom & pop's house. The question is more like what your market size is. Just look at WoT, they started as a no-name company and grew to a massive size due to their "freemium" MMO concept.

Regarding The DCS module I referred to in my earlier post the developer was very upfront About the sacrifices he personally made to complete the module. He worked seven days a week and had not seen a pay check in over twelve months, his Other staff had full time jobs

Boo-hoo, Al Delaney worked for four years without seeing a buck, I was working sixteen hour days (seven days a week, no vacations) for three years to get Steel Beasts off the ground while I had a number of day jobs.

Not sure if I would have decided to try it if I had known in advance how much work would have been involved, but in hindsight I'm glad that I was oblivious enough to not give a damn and just try it. In a way I'm still in that mode, I just want to know how far I can get, and I hope that the rest of the team has a similar kind of motivation.

I'm not sure if this kind of self-exploitation is the best way of doing things, but the market overall certainly profits from myriads of people taking unreasonable risks, with most of them failing for all kinds of good and bad reasons, sheer luck (or its absence) being one of the more influential factors that few seem to acknowledge. I mean, there's a severe "success bias" in that we usually get to hear the stories of successful entrepreneurs who like to attribute their success to character traits rather than admitting that it could just as well have gone the other way. Those who lose, they usually don't tell their story, and even if they do few people want to hear what they have to say even though their experiences arguably are more important than those of people "who made it". Because you learn more from failure than from success. Success just feeds the illusion that you made no mistakes when you may actually have made just as many (if not more) than others but simply had more luck.

But I digress. The point I'm trying to make is that the market for serious simulation is small. Armies seem to have pockets of unlimited depth in theory, but practice is MUCH different unless you seem to have exactly what they want at the exactly right moment - and none of your competitors has something similar to offer. IOW, you need sheer luck or an uncanny talent to see the future. Or you pick a game formula that works well so you can have a large market size, but then "serious simulation" is typically a guarantee to bomb at the box office. OR, again, by sheer/dumb luck you hit a nerve with the audience where, all of a sudden, milsim type games are back in fashion and you can sell millions of copies of your framework simulation that still needs a lot of add-on modules like MS Flight Simulator, just more successful (and already we are in some bizarro fantasy land because MSFS was incredibly successful by the numbers of copies it sold plus the size of the aftermarket/add-on module eco system that it created).

And still, Microsoft, after 20 years of faithfully supporting its own title, canned the entire franchise because it wasn't successful enough.

[OrangeFr3ak]

Besides the LAV-25 with TOW and Australian M1A1 (AIM), I'd like to see the AAVP7A1 added in future too!

[Hedgehog]

Australian M1A1 (AIM)

The Aussies use the M1A2 SEP minus the CITV.

(Unless they uncover a few hundred grand to pay for a bespoke model, this is what they're happy with.)

[OrangeFr3ak]

I thought it's the A1? The ADF website says it .

[Gibsonm]

I thought it's the A1? The ADF website says it .

Yes in RL its the M1A1 AIM SA.

In Steel Beasts, we use the M1A2 SEP (with the CITV disabled) as a good enough proxy.

Hope that helps.

[OrangeFr3ak]

How can I get the CITV-disabled Abrams?

[Gibsonm]

Well of course if you are interested in Australian kit, come to BG ANZAC or failing that ...

Damage the "Commander's Sight".

[Grenny]

How can I get the CITV-disabled Abrams?

I'd recommend reading the manual.

In the section about the scenario editor you'll find all answers and more...and quicker then waiting for answers in the forum.

Or, get into Teamspeak. It is easier talking you through your problems then typing piece by piece...

[Tjay]

Boo-hoo, Al Delaney worked for four years without seeing a buck, I was working sixteen hour days (seven days a week, no vacations) for three years to get Steel Beasts off the ground while I had a number of day jobs.

Not sure if I would have decided to try it if I had known in advance how much work would have been involved, but in hindsight I'm glad that I was oblivious enough to not give a damn and just try it. In a way I'm still in that mode, I just want to know how far I can get, and I hope that the rest of the team has a similar kind of motivation.

I'm not sure if this kind of self-exploitation is the best way of doing things, but the market overall certainly profits from myriads of people taking unreasonable risks, with most of them failing for all kinds of good and bad reasons, sheer luck (or its absence) being one of the more influential factors that few seem to acknowledge. I mean, there's a severe "success bias" in that we usually get to hear the stories of successful entrepreneurs who like to attribute their success to character traits rather than admitting that it could just as well have gone the other way. Those who lose, they usually don't tell their story, and even if they do few people want to hear what they have to say even though their experiences arguably are more important than those of people "who made it". Because you learn more from failure than from success. Success just feeds the illusion that you made no mistakes when you may actually have made just as many (if not more) than others but simply had more luck.

But I digress. .

I do so love your digressions! Have you thought of becoming a motivational business guru? Probably more money in that than in military simulatios. (Insert smiley for 'Genuine comment, not an ironic or sarcastic remark').