Proposal for a new Game Engine

[gossamersolid 155]

requests topics ends like trash usually,

"me want this, me want that, me want super-uber everything made tommorow" , making super engine would cost 100 milion dollars , 10 years, NASA computer, pointless topic

the only thing that Arma need is :

- halftruck for WW2 mods,

- melee weapons for medival mods,

- support custom skeleton to make different size species like it was in OFP

- multiple turret on plane (ww2 mod again)

- better cqb

- easier tool for map making (roads especially)

- more realistic dammage , another LOD like Materials_LOD etc. for simulate steel armor sheets or rework of FireGeoLOD and it's use in engine

I believe you can have multiple turrets on airplanes? I thought they snuck it in OA 1.60 or 1.62, one of those versions. I may be wrong though.

As for better CQB, ArmA 3's infantry movement has helped a lot with that. I'm not saying it couldn't use more improvement, but it's miles better than ArmA 2 in that aspect.

[ShotgunSheamuS 1]

Yes, one office. Of a company that has 2 products: the cryEngine and crysis game series.

Their overall staff (which works on the engine) measures in the 100's.

I guess you've never watched the credits at the end of any triple A title...

They typically have more people in their UI design departments than all of BI Studio has staff...

Fine, my bad, did a quick google on crytek that didn't prove useful, so here is much more accurate number for Crytek.

"GamesBeat: How large did your team get on this project? A couple of hundred people?

Yerli: Counting absolutely everybody, probably 250. It’s not any bigger than Crysis 2, though. Crysis 2 was actually a larger team, because we were building so much content for the console versions. We had no console experience at that point. A good 100 people or so were there to simply make up for that lack of experience. When I look forward, Crysis 3 has the kind of team size that I would expect for our next-gen games in the next five years or so. They’ll peak at 250 people, tops."

But I'm more of an Unreal Engine fanatic, hence my numbers were better portayed here as I am far more interesed and up to date:

"Epic CEO Tim Sweeney's revealed that around 40 people at the developer are currently hard at work on the new engine. Sweeney told IGN in September that the new engine wouldn't "see the light of day until probably around 2014," and a month later Epic President Mike Capps told Develop of Unreal Engine 4 on the next generation of consoles, "We need to be there day one or very early. That's my primary focus." But it was unknown exactly how many of Epic's 153 employees were working on the engine, until now."

Still far from your estimated ~600 man team. Now Bohemia coming in on a hefty 200 (taken from their linked in profile) I would say theres no excuse,

Edited June 28, 2013 by ShotgunSheamuS

[JdB 151]

Epic CEO Tim Sweeney's revealed that around 40 people at the developer are currently hard at work on the new engine.

Still far from your estimated ~600 man team. Now Bohemia coming in on a hefty 200 (taken from their linked in profile) I would say theres no excuse,

That's 40 people working solely on code for the actual engine. As DM pointed out BIS has around 10 people working on the RV engine, and getting assigned to other BIS projects (and I wouldn't entirely be surprised if they also had to do some scripting on the side). That's 4 times as many and that ratio probably translates to all other fields as well. CryTek, IW, Epic etc have the funds through their publishers to just take a group of programmers out of the main game development cycle and put them on dedicated development of their engine(s). BIS doesn't have those resources. On top of that BIS aims for more ambitious games that do not target the casual market as it's main target audience (especially true for ArmA) even if they do get succes in that segment with DayZ related ArmA2 sales, which means that development of the RV engine is like travelling an unmarked path with some specific problems related to the different needs from those mainstream engines.

[metalcraze 290]

Yeah and ironically UE is still a corridor engine with very basic AI. All that AAA dozens of men team - and for what?

[chortles 263]

It should be added with that the "200" number seems to conflate what Maruk described in a late August 2012 interview as "now about one hundred people on the gaming side, and about the same on the simulation side [bIS also produce military simulator training tech]", which I took as the interviewer simply mistaking BI and BISim as one-and-the-same -- and JdB did the breakdown on the "one hundred people on the gaming side" even further.

[ric 1]

As to the former part, well thats exactly what BI has been doing. The problem is they have a ~10 man programmer team, compared to the ~600 man team at Crytek or the however many 100s worked on the IW engine for CoD 234231. So any changes they make are much smaller on scale and slower on time.

On one hand you willingly excuse the age of the IW engine and CryEngines' core with the excuse "its been significantly rewritten", yet the same kind of rewrites (RV4 now uses directx 11, rv3 using dx 9, etc) on the RV engine don't count? Yes, the re-writes to RV have not been as significant, but see the reasoning above - 10 vs 100's.

come on DM....you can make all the excuses, justifications, reasons...etc you want but the truth is you have to invest,evolve or die...do you think those AAA studios invested in re-writes because some one lost a bet?...no they did because they know there competition is working on a better mouse trap and in order to compete they have to improve there product.

Look at the automobile industry, they will take an engine and body style and milk it for all its worth but there comes a time in order to remain competitive they have to redesign both to stay with current trends and innovations in technology and computer game engines are the same.

A good analogy for this would be those tuner cars you see in movies like the fast and the furious...you you can get 300 horse power out of those little 4 cylinders but there comes a point were the engine will just explode because it was not built to take suck hi out put but if you start out with something like a 426 hemi you have 425 HP to start with head room for more.

RV4 is already at the exploding point and you cant argue that BIS should not have invested in a re-write of the RV engine in 2008 that would have yielded a powerful engine capable of running A3 (and other games to come) with all the bells and whistles on high. Imagine RV4 is able to scale across 4 cores for maximum out put...BIS could right endless amount of games for the new XBOX/PS4 because there running at 1.8GHz in hexcore proc's but in its current state do you think A3 could run in the afore mentioned consoles? don't bother answering because you know it cant.

Oh, thats my bad, I'm too used to VBS (where 20k is certainly possible, and used regularly)

I'm sure you could edit the arma 3 cfg file in your user folder and have 20km view distance.

My original point is/was that all the other engines you've listed render a few hundred meters out to maybe a couple of km. The RV engine is quite capable of going even further.

have you run A3 with 20KM set? I ask because i see a lot of posts telling people to turn there view distance down to get there FPS up...im just curios what FPS you are getting at 20KM.

[chortles 263]

Literally the only civilian game licensee I'm aware of (VBS doesn't count) is Iron Front: Liberation 1944.

Also, dirty little secret: Arma 3 -- when defined as "broad-spectrum military-themed sandbox" (ruling out narrower stuff like DCS or Ground Branch) -- doesn't have competition to force engine changes by BI...

[ric 1]

Literally the only civilian game licensee I'm aware of (VBS doesn't count) is Iron Front: Liberation 1944.

Also, dirty little secret: Arma 3 -- when defined as "broad-spectrum military-themed sandbox" (ruling out narrower stuff like DCS or Ground Branch) -- doesn't have competition to force engine changes by BI...

your kidding right Chortles...nobody needs to force anything...if it does not work then it needs to be fixed and speaking of IF what did happen there? why did that game fail?

[dm 9]

Yerli: Counting absolutely everybody, probably 250...

...Still far from your estimated ~600 man team. Now Bohemia coming in on a hefty 200 (taken from their linked in profile)

Ok, so their project team for a single game is 250 people.

The company as a whole is around 600 - 900 strong (wiki lists closer to 600, based on information I know from people who have recently visited crytek the number is now closer to 900).

The team working on A3 at BI is closer to 60.

The "hefty 200" figure you've quoted is wrong (as pointed out by Chortles) and is a company-wide figure based on inclusion of BISim (who work exclusively on VBS), and all the other offices (who work on things like DayZ, Carrier Command, Take on Mars, etc etc)

So on both counts, the teams are ~4 times larger than at BI. And that does not give us a breakdown of how many people are programmers working exclusively on the engine. I'd wager a pretty high percentage at crytek...

"Epic CEO Tim Sweeney's revealed that around 40 people at the developer are currently hard at work on the new engine.

And as I said, no more than 10 people are working on the engine at BI.

Again, around 4 times the manpower.

come on DM....you can make all the excuses, justifications, reasons...etc you want but the truth is you have to invest,evolve or die...do you think those AAA studios invested in re-writes because some one lost a bet?...no they did because they know there competition is working on a better mouse trap and in order to compete they have to improve there product.

For real, and thats what they are doing, within the limits of the manpower they have available...

A good analogy for this would be those tuner cars you see in movies like the fast and the furious...you you can get 300 horse power out of those little 4 cylinders but there comes a point were the engine will just explode because it was not built to take suck hi out put but if you start out with something like a 426 hemi you have 425 HP to start with head room for more.

lol, crappy american car engines are crappy ;) Germany and Japan would like to teach you how to make proper car engines.

RV4 is already at the exploding point and you cant argue that BIS should not have invested in a re-write of the RV engine in 2008 that would have yielded a powerful engine capable of running A3 (and other games to come) with all the bells and whistles on high. Imagine RV4 is able to scale across 4 cores for maximum out put...

This is a most ridiculous statement...

I'll start my retort with my usual: If you know how to design such an amazingly perfect game engine, why don't you form a team and do it yourself. Oh wait, thats right, you don't...

1, who is to say (besides BI) that they even had the money in 2008 to invest in such a thing?

2, RV4 is a powerful engine

3, According to Marek, RV is already scaling across as many cores as it can, and using as much RAM as gives best performance. I'm not going to find the interviews for you, nor am I going to re-explain the technical aspects. But going 64-bit or offloading processing onto more cores is not a magical performance resolver.

BIS could right endless amount of games for the new XBOX/PS4 because there running at 1.8GHz in hexcore proc's but in its current state do you think A3 could run in the afore mentioned consoles? don't bother answering because you know it cant.

I know it can't, but unlike you I actually know the technical reasons behind why it can't.

Again, I'm not going to waste my time explaining it to you (because it would be an incredibly long post) but suffice to say, my previous answer covers it: throwing more cores and more RAM at the problem is not the solution.

[Insanatrix 0]

I think the majority of the issue's with the RV engine stem from the SQF scripting and the extent to which it is used within the engine and the limitations of it. I realize BI want the game to be moddable and through SQF they can achieve that while still maintaining some closed source. Holding on to the scripting language simply so the game is extremely moddable at the cost of performance and functionality is not the way to go though. Correct me if I'm wrong, but isn't the interpreter limited to a single thread and is also limited to executing code every 3ms? If so, both of those are huge bottlenecks considering the scope of usage of SQF script for actual engine functionality. That means that there is already a resource limitation inherent to SQF as well as a processing limitation, irregardless of hardware.

I mean you're not talking about configuring some engine variables through script here and there, you're talking about running heavy simulations in SQF script rather than in compiled C. Running those heavy simulations in a scripting environment that is by it's very nature quite limited. Again, I get that they want those simulations to be moddable, but is the cost to be able to do so with the current scripting environment worth it?

At this point fixing the problems with the engine would require such a rewrite of the engine that you might as well start over from scratch, hence the unwillingness to really do it and just try to band-aid fix every problem and move on. It's just been compacted on since OFP, every SQF script for a new function has added on to the pile of what would have to be rewritten to fix the issue's. I truly believe the real question is, why do they need to fix it? Why would they need to fix the issue's when they have a loyal fan base that would buy pretty much anything they put out. I mean this engine could run average 2 fps and you would get tons of people on these forums talking about how the game runs great and they're having the time of their lives.

Also they have DayZ now, which will appeal more to the mainstream crowd. They've hinted around about wanting to get away from the whole Military Simulator genre and try some new things. Maybe ArmA 3 will be the last ArmA. Maybe that's why there was so much work put into the engine of DayZ and so little into ArmA 3. It's funny that people talk about how much work the engine changes are when it comes to ArmA and how BI doesn't have a big enough team, yet they are somehow managing to do it with DayZ by totally rewriting the engine for the needs of DayZ and it's closed source nature as well as it's heavy need for lots of AI and such. I guess that's some food for thought...

[ShotgunSheamuS 1]

All right, well I'm getting pretty tired of having to keep trying to be positive about the subject, When DM keeps being negative and justifying why he is happy with ARMA as it is, so fine, he is happy with it as it is, he isn't bothered by it's current state and limitations, so I will not try convince him otherwise.

Moving on, Insanatrix, you made some pretty good statements worth thinking about.

But also, I have been seeing some trends coming up, seems almost all major game engines will be getting a military simulator equivelent, CryEngine has one where $57 mil was spent on it, apparantly to replace the outdated VBS, but from reading, it seems both are in use, and it seems as of end of last year, UnrealEngine also got as similar project for the US military. So really the competition is there, and not only that, but it seems those engines might be able to do what VR engine does, maybe not the 20km+, but then again, really now who needs more than 5km? Which the frostbite engine is capable of already. 5km is more than enough, on 20km+ you are really wasting resources for a very detailed back drop anyway. Point being, If any of the above projects decide to go with a public license or convert to a public game, which given their current state look like it got more attention than a simulator needs, and seems to appeal more to gamers with its high quality graphics and design (I think thats an obvious hint), and they know there is a market because ARMA owns that market, then ARMA will have competition. Both those engines are equally supportive for modding as well, so... Maybe as you said, BI are wanting to move away military simulations, and play with other new IP... Is this perhaps a precaution because of these other projects? They probably know they don't stand a chance, so they don't want to be completely dependent on ARMA alone.

Still, they should compete even if there is no competitor for ARMA yet, but they should treat those products as competitors for ARMA! (they probably are in terms of VBS though), So really, even if they do have their 200 employees split up accross different projects, get them together and work on the engine, that will benefit all their projects. Then split them up and continue to make new IP and stuff.

[dm 9]

All right, well I'm getting pretty tired of having to keep trying to be positive about the subject, When DM keeps being negative and justifying why he is happy with ARMA as it is, so fine, he is happy with it as it is, he isn't bothered by it's current state and limitations, so I will not try convince him otherwise.

1. Oh noes, people on the internet have a different opinion to you! Life sure is hard...

2. Your comprehension of my posts is simply mind boggling...

Where did I state that I am happy with the current situation? Quote me saying that I am happy with the current status quo... Quote me saying that I do not want improvements...

Oh right, you cant, because I never said that.

All I am trying to get across is the actual situation of the company and what options it has for doing things. I'm trying to make you understand that simply stating "just rewrite everything like crytek did" is not an option for BI with their current staffing. Maybe they could roll back some of that delicious DayZ money into making these improvements, maybe Marek will just retire to a nice Caribbean island. We just don't know.

it seems those engines might be able to do what VR engine does, maybe not the 20km+, but then again, really now who needs more than 5km?

the US military

Thats who needs 20km+

I think some interesting news will surface soon about that. But that is for a different thread...

So really, even if they do have their 200 employees split up accross different projects, get them together and work on the engine, that will benefit all their projects. Then split them up and continue to make new IP and stuff.

You are a business genius, BI should hire you to make all of their long-term strategies! [/sarcasm]

You think they haven't already considered something like this, even if it were possible with the different company structures/ownership/etc?

[chortles 263]

What I got from my interpretation of the BI/BISim difference is that in reality, Maruk has at most half of that "200 employees"... and that also means that "dealing with RealTime Immersive" is Peter Morrison's "turf", not Maruk's.

Speaking of which, there's a rather interesting comment by a BISim dev about RTI as so-called "competition" for VBS, posted earlier this year (mid-February)... here.

Edited June 29, 2013 by Chortles

[Deadfast 43]

I think the majority of the issue's with the RV engine stem from the SQF scripting and the extent to which it is used within the engine and the limitations of it.

To what extent is it used within the engine? If you think any of the simulation is done using SQF you're mistaken. Sure, some of it can be, if you want, but then it's your responsibility to make sure it works properly.

Correct me if I'm wrong, but isn't the interpreter limited to a single thread and is also limited to executing code every 3ms?

You are correct the interpreter runs in one thread but you are completely wrong on your second point. The limitation is the interpreter is limited to running for 3ms per each frame (with exceptions). This was a change introduced in A2 to make sure scripts cannot affect the overall game performance.

If so, both of those are huge bottlenecks considering the scope of usage of SQF script for actual engine functionality.

Again, SQF doesn't do engine stuff. Yes, it is used to run missions and yes, there is some included functionality to help you with that but the rest is native C++.

That means that there is already a resource limitation inherent to SQF as well as a processing limitation, irregardless of hardware.

There is an inherent limitation to SQF, when producing scripts for your missions/mods it is your responsibility to deal with it.

I mean you're not talking about configuring some engine variables through script here and there, you're talking about running heavy simulations in SQF script rather than in compiled C. Running those heavy simulations in a scripting environment that is by it's very nature quite limited. Again, I get that they want those simulations to be moddable, but is the cost to be able to do so with the current scripting environment worth it?

What heavy simulations?

At this point fixing the problems with the engine would require such a rewrite of the engine that you might as well start over from scratch, hence the unwillingness to really do it and just try to band-aid fix every problem and move on. It's just been compacted on since OFP, every SQF script for a new function has added on to the pile of what would have to be rewritten to fix the issue's.

Given SQF didn't even exist in OFP that simply cannot be true.

Maybe that's why there was so much work put into the engine of DayZ and so little into ArmA 3. It's funny that people talk about how much work the engine changes are when it comes to ArmA and how BI doesn't have a big enough team, yet they are somehow managing to do it with DayZ by totally rewriting the engine for the needs of DayZ and it's closed source nature as well as it's heavy need for lots of AI and such. I guess that's some food for thought...

Totally rewriting the engine? They made adjustment to the network protocol. I don't know, maybe those adjustments required some degree of rewriting but I can assure you the degree was nowhere near everything. As for the AI, the advantage of zombies is they're dumb as bricks, so any changes there would involve just turning off some of the AI simulation.

[chortles 263]

Pfff yeah, one of the points that Rocket talked up about going standalone was that it would specifically be 'zombie AI' and not just adapted Arma 2 AI, that the standalone would be built with zombies as the only sort of AI (at initial release) and thus the engine only having to support that 'level' of AI.

[PuFu 4600]

Pfff yeah, one of the points that Rocket talked up about going standalone was that it would specifically be 'zombie AI' and not just adapted Arma 2 AI, that the standalone would be built with zombies as the only sort of AI (at initial release) and thus the engine only having to support that 'level' of AI.

Dayz Ai is , irc, built upon the A2 animals' AI. That is, a lot less brainy (pun intended).

@Insanatrix: if you know nothing about what you are talking about, then don't. simply put, the game is NOT made out of SQF scripts as you suggested.

EDIT:

Oh, love when i see these sort of thread with their nifthy thought out titles (Porposal for a new Game Engine)...especially considering the knowledge of the ones starting'em

Edited June 29, 2013 by PuFu

[Insanatrix 0]

To what extent is it used within the engine? If you think any of the simulation is done using SQF you're mistaken. Sure, some of it can be, if you want, but then it's your responsibility to make sure it works properly.

Well scripting is like a script in a play, it tells the engine (Actor) what to do and has the flexibility to be changed, where as hard coding it in C++ would mean that you have to open up the source and make your changes and then recompile, which would give access to the entire source. The fact that any simulation from the actual engine is completely guided by SQF script, and therefor as fast as the core engine written in C++ is, it's still limited by the speed of the SQF interpreter in handing it instructions from the script. So my wording was poor, SQF "Guides" the engine in what to do and what to simulate.

You are correct the interpreter runs in one thread but you are completely wrong on your second point. The limitation is the interpreter is limited to running for 3ms per each frame (with exceptions). This was a change introduced in A2 to make sure scripts cannot affect the overall game performance.

That is even worse then. Just because the interpreter can run only for 3ms per frame, doesn't mean that a script can't affect game performance. It just means that one script can't hog the interpreter for more than 3ms and it also means that if a script running actually affects any type of simulation or rendering done by the engine, then it definitely will affect game performance. You put an artificial limitation in to quell bad scripting and at the same time gimp your own engine in the process... *golf clap*

Again, SQF doesn't do engine stuff. Yes, it is used to run missions and yes, there is some included functionality to help you with that but the rest is native C++.

Like I said above, it guides the engine in what to do. If you took all SQF scripting out, this game would not run. The engine is dependent on it to run. It's not simply just a mission/mod tool.

There is an inherent limitation to SQF, when producing scripts for your missions/mods it is your responsibility to deal with it.

What about the scripts used to connect you in mutliplayer and sync you with other players, or that control how the AI behaves, or when you're gun's audio file should play after clicking your mouse button? Is it also an inherent limitation to those things? Script's aren't just for missions and mods, they're used throughout the entire game to actually make the engine function.

What heavy simulations?

You do realize the AI FSM's are written 100% in SQF right? And every FSM is run independently per AI or group of AI right? That's a pretty demanding and pretty heavy simulation to put on a single threaded interpreter that can only run every 3ms per frame.

Given SQF didn't even exist in OFP that simply cannot be true.

It's little brother SQS did, http://community.bistudio.com/wiki/SQS_syntax

Totally rewriting the engine? They made adjustment to the network protocol. I don't know, maybe those adjustments required some degree of rewriting but I can assure you the degree was nowhere near everything. As for the AI, the advantage of zombies is they're dumb as bricks, so any changes there would involve just turning off some of the AI simulation.

I guess we will see....

Responses in bold.

Arguing about it at this point doesn't matter because nothing will be done to fix it. Whether it stems from the fact BI doesn't have the resources to fix it, or they just don't want to.

Edited June 29, 2013 by Insanatrix

[ric 1]

lol, crappy american car engines are crappy ;) Germany and Japan would like to teach you how to make proper car engines.

woooosh..right over YOUR head huh DM....

This is a most ridiculous statement...

your right and SONY and Microsoft are wrong...shall i tell them or would you like to?

I'll start my retort with my usual: If you know how to design such an amazingly perfect game engine, why don't you form a team and do it yourself. Oh wait, thats right, you don't...

your right I don't...but some one does....

Deep Down is Capcom’s mysterious project that uses the incredible possibilities of the new game engine called the manufacturer Panta Rhei. According to a company representative, the engine is able to use all the processing power of the new

PS4 console

1, who is to say (besides BI) that they even had the money in 2008 to invest in such a thing?

2, RV4 is a powerful engine

3, According to Marek, RV is already scaling across as many cores as it can, and using as much RAM as gives best performance. I'm not going to find the interviews for you, nor am I going to re-explain the technical aspects. But going 64-bit or offloading processing onto more cores is not a magical performance resolver.

1, invest-er

2,powerful? really..is that why the number 1 issue (and old one) is performance..guys with $2000 rigs and low end laptops getting the same FPS?

3,just because Marek said that does not help or change the performance issues...

I know it can't, but unlike you I actually know the technical reasons behind why it can't.

Again, I'm not going to waste my time explaining it to you (because it would be an incredibly long post) but suffice to say, my previous answer covers it: throwing more cores and more RAM at the problem is not the solution.

since you seem to know so much dazzle us with the solution if in fact available hardware is not the solution....

p.s did you see this

http://forums.bistudio.com/showthread.php?157096-Software-Data-Spreading-Leveraging-Distributed-Caches-to-Improve-Single-Thread-Perfo&p=2419978#post2419978

[Deadfast 43]

Well scripting is like a script in a play, it tells the engine (Actor) what to do and has the flexibility to be changed, where as hard coding it in C++ would mean that you have to open up the source and make your changes and then recompile, which would give access to the entire source. The fact that any simulation from the actual engine is completely guided by SQF script, and therefor as fast as the core engine written in C++ is, it's still limited by the speed of the SQF interpreter in handing it instructions from the script. So my wording was poor, SQF "Guides" the engine in what to do and what to simulate.

Thank you for informing me what a script is, I already knew that though. You didn't actually answer my question what is all this simulation being done in SQF.

That is even worse then. Just because the interpreter can run only for 3ms per frame, doesn't mean that a script can't affect game performance. It just means that one script can't hog the interpreter for more than 3ms and it also means that if a script running actually affects any type of simulation or rendering done by the engine, then it definitely will affect game performance. You put an artificial limitation in to quell bad scripting and at the same time gimp your own engine in the process... *golf clap*

It cannot affect the engine because unlike what you seem to believe the engine isn't 99% SQF. And to believe SQF has anything to do with rendering or could in any way affect it is beyond insane.

Like I said above, it guides the engine in what to do. If you took all SQF scripting out, this game would not run. The engine is dependent on it to run. It's not simply just a mission/mod tool.

It doesn't, it would.

What about the scripts used to connect you in mutliplayer and sync you with other players, or that control how the AI behaves, or when you're gun's audio file should play after clicking your mouse button? Is it also an inherent limitation to those things? Script's aren't just for missions and mods, they're used throughout the entire game to actually make the engine function.

No such scripts exist. Well, you could argue on the AI part but I will address that in the next point.

You do realize the AI FSM's are written 100% in SQF right? And every FSM is run independently per AI or group of AI right? That's a pretty demanding and pretty heavy simulation to put on a single threaded interpreter that can only run every 3ms per frame.

No, I didn't realize that. Because FSM != SQF. Also, how did you arrive to the conclusion that the script interpreter only runs 3ms per frame? And don't say because I said so, I didn't. I wrote "with exceptions" there for a reason. The FSMs don't actually drive the AI, the engine does. The FSMs issue simple commands to adjust the engine simulation, everything else is in native C++. Unless, of course, you can point me to a_star.sqf.

It's little brother SQS did, http://community.bistudio.com/wiki/SQS_syntax

But that isn't SQF.

[ric 1]

Dayz Ai is , irc, built upon the A2 animals' AI. That is, a lot less brainy (pun intended).

@Insanatrix: if you know nothing about what you are talking about, then don't. simply put, the game is NOT made out of SQF scripts as you suggested.

EDIT:

Oh, love when i see these sort of thread with their nifthy thought out titles (Porposal for a new Game Engine)...especially considering the knowledge of the ones starting'em

why don't you explain it to us then PuFu..or are you just more comfortable being arrogant?

maybe these nifthy threads would not get started if the ""new"" engine did not have the same old issues as the ""old"" engine...

DM and Pufu your endless barrage of excuses will not help BIS sell product nor bring in new customers..there is a problem and its a major one as noted by the recent explanation of why the TOH flight model was not be added as it dropped the FPS by 10....

@deadfast if insantrix is wrong then YOU tell us what it is...

Edited June 29, 2013 by ric

[dm 9]

woooosh..right over YOUR head huh DM....

No, seems to be right over your head actually.

Your analogy is crap. A hemi engine is not powerful because it is good from a technical standpoint. A hemi 426 is powerful because it is large (7L infact). Meanwhile, other engines (specifically Audi, BMW, Mitsubish, etc) are producing WAY more power for the same 1.6L 4 cylinder. Jaguar, for instance, have just released a concept (but actually manufactured it) engine thats 1.6L and produces more than 500hp (supposedly over 800 when combined with electric motors). Kinda blows your shitty hemi away really. (tho this is way past the original point of the topic, cant help it if your analogies are crap tho...)

Anyway, if anything, the RV engine is more like the hemi than the tuned engines - it has a huge amount of overhead available for expansion into. Just because the current chassis/drivetrain/wheel&tyre technology can't cope with the torque doesn't make it a bad engine...

your right and SONY and Microsoft are wrong...shall i tell them or would you like to?

I'm not saying multi-core is not good technology.

What I'm saying is (and has been explained by Maruk and Suma), simply throwing more cores at the problem does not equal an instant performance fix.

Say you split the AI across 2 (or more) cores. Great. Core 1 does its calcs and has results, but if core 2 is stuck doing something complex, you'll still have to wait for it to finish, then you still have to combine those results back together.

Same goes for physics, same goes for pretty much everything.

your right I don't...but some one does....

And until its actually out there and tested independently, its just PR bullshit.

1, invest-er

2,powerful? really..is that why the number 1 issue (and old one) is performance..guys with $2000 rigs and low end laptops getting the same FPS?

3,just because Marek said that does not help or change the performance issues...

1. I think you'll find its spelt investor. And you think it is easy to magic one out of thin air? In the financial climate we've had for the last 5 years? If BI struggled to find a publisher (typically the investor in game development) what makes you think it would be easier to find an independent financial backer?

2. Yup, it does more than pretty much any other engine out there. That a bunch of chuckleheads with more money than sense struggle to get good performance on their expensive rigs (for the record, I get a stable ~30 fps on my 4 year old, $900 rig) because they automatically try to max everything out. Well thats their problem, not mine or the engines'. Protip: you can max out 99% of other engines because they are designed with the limits of the xbox 360 and/or ps3 in mind.

3. I don't know how to respond to this... Both Marek and Suma (the guys that wrote the engine...) have stated that "spreading RV out across more cores will not magically provide more performance", yet here we have you saying that they should spread it across more cores because it will give more performace. I know who I'm inclined to believe...

p.s did you see this

http://forums.bistudio.com/showthread.php?157096-Software-Data-Spreading-Leveraging-Distributed-Caches-to-Improve-Single-Thread-Perfo&p=2419978#post2419978

Nope, I tend to avoid most of the bullshit threads :)

DM and Pufu your endless barrage of excuses will not help BIS sell product nor bring in new customers..

And nor does your bullshit drivel of "put it on more cores!!1!!11!!"

there is a problem and its a major one as noted by the recent explanation of why the TOH flight model was not be added as it dropped the FPS by 10....

No shit adding more complex calculations to the simulation adds more overhead to the processing cycle.

Going back to your car engine analogy, thats like putting your hemi into a big rig, and still expecting it to be able to move 40 tons of cargo around with the same performance as when its in a normal car...

Edited June 29, 2013 by DM

[oyman 0]

There are some big paragraphs in here.

[Insanatrix 0]

Ok, I'm wrong, You win.

[ric 1]

No, seems to be right over your head actually.

Your analogy is crap. A hemi engine is not powerful because it is good from a technical standpoint. A hemi 426 is powerful because it is large (7L infact). Meanwhile, other engines (specifically Audi, BMW, Mitsubish, etc) are producing WAY more power for the same 1.6L 4 cylinder. Jaguar, for instance, have just released a concept (but actually manufactured it) engine thats 1.6L and produces more than 500hp (supposedly over 800 when combined with electric motors). Kinda blows your shitty hemi away really. (tho this is way past the original point of the topic, cant help it if your analogies are crap tho...)

Anyway, if anything, the RV engine is more like the hemi than the tuned engines - it has a huge amount of overhead available for expansion into. Just because the current chassis/drivetrain/wheel&tyre technology can't cope with the torque doesn't make it a bad engine...

crap?..no it was spot on your just splitting hairs...was Audi, BMW, Mitsubish, producing these engines in 1970? no they were putting lawn mower engines in golf carts and calling them cars...let me shorten the analogy for you hemi=power with headroom, tuner engine (RV)=Maximum limit reached and as you have said (per the writers of the engine) throwing more cores at it wont help with performance...why is that DM? unlike you analogy of the 1.6L producing 500HP RV is not cutting edge..because if it was we would not have to constantly turn up the clock speeds along with turn that off turn this down...etc

Say you split the AI across 2 (or more) cores. Great. Core 1 does its calcs and has results, but if core 2 is stuck doing something complex, you'll still have to wait for it to finish, then you still have to combine those results back together.

your right , as RV is right now this wont help...however

Vector Fabrics parallelized the idTech4 game engine that is used in first-person shooter games

like

Doom 3

. This world-famous game engine was heavily optimized to run on single-core

machines. The source tree contains roughly 500,000 lines of C/C++ source code.

Using dependency analysis and loop-reordering, the Vector Fabrics

Pareon

tool came to good

suggestions on where to optimize the existing C++ code even further for multi-core systems,

which are omni-present nowadays on PCs and also increasingly on mobile devices.

Based on Pareon’s suggestions we introduced parallelism and improved the performance of

parts of the main loop in the rendering framework by 3.8x and 1.8x on a 4-core machine. This

resulted in an impressive 15% frame rate increase during the playback of a demo scene. This

frame rate increase is really significant, considering that this is one of the most highly opti-

mized game engines available. This amount of frame rate increase usually is only achievable

by buying a newer generation graphics card: spending $300 instead of $80.

The engineer who undertook the optimization was totally unfamiliar with the concept of game

engines and had never seen the game before. Yet he came to the aforementioned 15% frame

rate increase with about three weeks of effort

http://www.vectorfabrics.com/assets/pdf/VFP-201242.pdf

And until its actually out there and tested independently, its just PR bullshit.

whether you think its bullshit or not the new consoles are here ...there 1.8GHz and companies will be adapting or writing engines to use this architecture.

1. I think you'll find its spelt investor. And you think it is easy to magic one out of thin air? In the financial climate we've had for the last 5 years? If BI struggled to find a publisher (typically the investor in game development) what makes you think it would be easier to find an independent financial backer?

2. Yup, it does more than pretty much any other engine out there. That a bunch of chuckleheads with more money than sense struggle to get good performance on their expensive rigs (for the record, I get a stable ~30 fps on my 4 year old, $900 rig) because they automatically try to max everything out. Well thats their problem, not mine or the engines'. Protip: you can max out 99% of other engines because they are designed with the limits of the xbox 360 and/or ps3 in mind.

3. I don't know how to respond to this... Both Marek and Suma (the guys that wrote the engine...) have stated that "spreading RV out across more cores will not magically provide more performance", yet here we have you saying that they should spread it across more cores because it will give more performace. I know who I'm inclined to believe...

(I think you meant performance)

1, so you telling me a well known and established company like BIS could not find investors in what in an industry to generates hundreds of millions in revenue? the fact that they are here after 13 years profitable and well known tells me you are wrong.

2, its no longer about hardware when people with low and highend rigs are getting the same performance ..its about the engine.

3, agreed and that is paet of the problem the engine is not equipped to take advantage of what is there

Nope, I tend to avoid most of the bullshit threads :)

really..well let me help you out again.

ThreadedS Solution description:

Phase 1: Acceleration Assessment

The performance advantages of multicore systems vary by application. Some applications have great potential for parallel processing, while others are dependent on sequential processing. Either way, the first step to multicore performance is understanding the acceleration potential of your application. ThreadedS engagements begin with an assessment of the acceleration potential of the specific application. TMT experts apply their knowledge of multicore programming to accurately determine the opportunities for parallelization in the application and the return expected from the effort. Using the results of this assessment, TMT creates a roadmap for application acceleration and a project plan for parallel programming implementation.

Phase 2: Application Acceleration

The ThreadedS solution upgrades an existing software application to multicore performance. Using the project plan developed in the acceleration assessment, TMT converts the single-threaded application to SequenceL and uses the SequenceL compiler to generate parallel, multi-threaded C++ code.

ThreadedS uses a simple process to accelerate existing applications for multi-core

Step 1: The customer designs their application in normal engineering terms and formulas

Step 2: TMT writes portions of the application in SequenceL and confirms the application performs as designed

Step 3: The customer may read and audit the SequenceL code

Step 4: TMT compiles the application to parallelized C++ and ensures optimized performance

Step 5: The application is delivered to the customer development team for integration into the customer's application or system

ThreadedS Features

Fastest path for upgrading existing software to multi-core & many-core

Delivers parallel, multi-threaded C++ code

Increase application performance and capability

Reduce compute time

Reduce energy costs and improve carbon footprint

Optimized investment in parallel code development

Fixed-fee engagement, avoids costs of repeated manual parallelization efforts

Frees internal software developers to focus on core application features

Provides extensive testing and debug of application performance

Produces reusable and transportable parallel code

Expert services for parallel code optimization

Parallelize just the sections of an application with most of the processing load

Build improvements into the application while adapting to multi-core

Design in new features optimized for parallel processing

Uses SequenceL compiler and parallelized math libraries

ThreadedS Benefits

Delivers outstanding multicore performance

Reduces development costs

Enables integration of parallel code into existing applications

Shortens time-to-market for multicore performance

Eliminates the risk of multicore migration

And nor does your bullshit drivel of "put it on more cores!!1!!11!!"

your timing is off.. and asking people to turn down,off options and quality or jack there CPU to 5GHz is no answer either..

---------- Post added at 23:03 ---------- Previous post was at 22:59 ----------

Ok, I'm wrong, You win.

I still want to hear his take on what the issue really is.

[PuFu 4600]

why don't you explain it to us then PuFu..or are you just more comfortable being arrogant?

Explain you what? That ArmA *insert number* is not made out of SQF scripts? Something else? Be so kind and say what it is you fail to grasp and i'll try my best to explain it to you, in an easy and digerable manner, so even you could, finaly, understand it.

maybe these nifthy threads would not get started if the ""new"" engine did not have the same old issues as the ""old"" engine...

there is no new engine. It is an iteration (just like many others out there). And yes, it has problems, and constrains, and some things needs workaround.

but there is nothing out there (unfortunately) to compare it to.

Now, from a bussines POV, trashing the existing code and creating a new engine from ground up is pretty much out of the question, just as much as licensing another engine designed for something else is. And that is something I and DM (and some others) do understand, unlike yourself.

Does this engine have issues. Of course it has. And any game out there aiming for the scale, scope and openess would. Could BI improve on it. Yes, i am sure they could (and they most likely would).

Regarding TOH: of course it dropped the framerate. In the end, the engine needs to take into consideration a lot more variables, on top of the existing ones. I really don't see the problem here.

Such threads as in proposal for a new engine are funny from the get go, mainly because, all things considered, it is so unfeasible. Anyone who thinks otherwise has little knoledge regarding what software development is, and how the video-game industry work, or any bussines for that matter.

DM and Pufu your endless barrage of excuses will not help BIS sell product nor bring in new customers..[/quote

I have no excuses for the product, not for BI. I am saying, here, in this funny thread, one single thing: the next iteration of this game will be based on the same engine for obvious reasons. There is nothing to replace it with, and there is no way 15+ years of engine development would go to waste because some lad on a forum started a thread called "proposal for a new game engine"

---------- Post added at 02:18 ---------- Previous post was at 02:11 ----------

crap?..no it was spot on your just splitting hairs...was Audi, BMW, Mitsubish, producing these engines in 1970? no they were putting lawn mower engines in golf carts and calling them cars...let me shorten the analogy for you hemi=power with headroom, tuner engine (RV)=Maximum limit reached and as you have said (per the writers of the engine) throwing more cores at it wont help with performance...why is that DM? unlike you analogy of the 1.6L producing 500HP RV is not cutting edge..because if it was we would not have to constantly turn up the clock speeds along with turn that off turn this down...etc

you really are going to defend a car industry as poor as the american one? And that is no matter if it was 60s, 70s 80s etc or today?