Author Topic: Battlefield 4  (Read 20900 times)

Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #135 on: 11-11-2012, 10:11:46 »
Can Natty please elaborate why we can't have BF3 mod tools? Because that whole "too complex" thing the DICE/EA guys said is total bull, anyone can learn.

DICE Programmers have explained countless times why they didn't do mod tools for BC2 (fb 1.5) and BF3 (fb2.0)

Instead of madly screaming "gieef mod toolz! we can haz moddsss!" You should try to understand the situation and see it from all angles; Studio, Customers, Modders, Technology, Economy, Franchise.
As long as you only view it from the "Im a player I should be allowed to do what I want" then you will never understand.

Start by reading these posts in full - no skipping - and you have only scratched the surface of it.

Quote
Developing a game is developing a software suite, and a dataset that will go along with the software. Users will use the software (= run the game executable) to manipulate the dataset (= use mouse/keyboard/joystick to control the game).

A good game requires that the capabilities of the software matches the dataset that is being created. The software is usually refined in parallel with the dataset. In order words, the game engine and the game worlds are tailored to each other, to some extent.

The programming side of making a game corresponds fairly much to developing other kinds of software. You usually use mature languages, standardized tools, and techniques which were pioneered back in the 1960s to create a set of source code, which when built creates a single game executable.

Creating the content is less straight-forward. Sometimes there are tools that do the job well (Maya, Photoshop, SoundForge, Cubase etc). For other kinds of content, there are no good tools, so the game developers develop their own.

Raw source format is not a good format for distributing a game engine to end users. One could ship the code as-is, but that would require people to have the right compilers and software SDKs available on their machines. Distributing the code in the form of a game executable is more practical.

Raw source format is not a good format for distributing the game content either. It is convenient for editing, but the game engine will usually want the content in a different format before using it. The raw source format is often bulky, and the conversion step is lengthy. Therefore, game developers usually create custom tools which "cook" the data -- convert it from source format to something that suits the game engine better.



Cooking is good, and bad.

No cooking gives you the advantage that you can change a source file, restart the game, and the effect happens immediately in the game. It is usually easy to figure out which files on-disk contribute to what in-game.

With no cooking -- or just too little cooking -- you get very long loading times. You usually get more memory fragmentation. You also lack mechanisms to validate the integrity of the data; if you want to see that it's consistent, you have to play through the full game and exercise all aspects of the game.

Cooking gives you the advantage that you can do lots of sanity checks on the data before even starting the game. You can improve loading times a lot (especially off media with slow seek times such as DVD), and you get less memory fragmentation.

You can also create extra datastructures, which improve runtime performance. (A good example of this is the BSP & PVS trees that were used in FPses back in the 90s.)

With too much cooking, you find that it is difficult to change anything when data already has been cooked. If you want to edit just one tiny little detail, you have to re-cook ALL the data. It is difficult to tell which files on-disk contribute to what in-game.


Now let us consider the Frostbite engine and where it comes from.

It was initially used to create BFBC1. This game was released only for consoles. This means that the team which developed

BC1 had to do a certain amount of cooking - mainly to avoid excessive load times and memory fragmentation. The hard memory and performance constraints of running on a console also made it more important to pre-compute some things, and to package data into suitable archives.

With this foundation, we essentially had a game engine which solved a lot of time-consuming problems for us when we began on BFBC2 PC. Loading times would be under control, it's easy to figure out which files go into which archives, and which files/archives belong to which level. These are things which are often overlooked when not using a game engine that has been used to ship games on DVD.

We also wanted a way to automatically patch the game. Making an auto-patcher that works properly under Windows XP, Vista & Win7, knows about limited users & UAC, and can handle restarting mid-way through a patch at all takes a huge amount of time.

Therefore we took the auto-patcher from BF Heroes and modified it slightly. Voila, the game could now pull down updates from the internet and apply them to its own datafiles. We were all set.

Or so we thought.

Some complex systems seem simple on the surface; it is only when you look under the hood that they turn out to be tricky.

The tools which "cook" the game's datafiles takes in a set of original files, which are roughly 80GB in size. Most of the files here are organized by function ("this is a mesh, this is a texture, this is an animation, ...") rather than location (on which levels it is used). The tools will process the dataset once per level, extract the subset that applies for the current level, and convert it to a format suitable for the game engine.

This allows the tools to do some per-level precomputations easily; for instance, since all the pixel/vertex shader combinations that will be used throughout the entire level is known, the tools pre-generate all these combinations and store them in a "shader database". (BF2142 generated & compiled the shader combinations during first load - that's one reason why first launch of a level was very slow there.)

After this is done for all levels, there are a bunch of archives for each level. This is ideal for quick loading times and no memory fragmentation, but it wastes diskspace unnecessarily. The result is probably about 15GB in size.

In order to make a better tradeoff between diskspace and load times, an extra processing step has been added; all the level-archives are compared, and any datafiles which appear inside many of these level-archives are moved to a level-common archive. So when loading a level, everything inside the level's own archives and the level-common archive has to be processed. This reduced the total data size down to about 6GB.

This technique allowed BFBC2 to fit on a DVD, both for the console and the PC versions. It is not perfect by any stretch, but dealing with these large amounts of data is time consuming, and therefore you don't try every idea under the sun - rather, try what seems most likely to work first, and then keep on until the end result is good enough.



So this is all awesome when shipping the game. Where do the problems begin?

When you begin creating patches.

First off, it turns out that the tools that "cook" the data don't produce binary-identical data all the time. The result after cooking is always functionally identical, but the bit-content may differ slightly. Items in unordered lists change order, uninitialized fields contain random data, that sort of stuff.

Why didn't this get caught sooner? Because you only notice problems of this kind when re-cooking the same data several times, from scratch. And re-cooking all BC2 data takes over 48 hours for a high-end computer. And locating & correcting all places where cooking isn't deterministic down to the bit level would take a lot of time (both calendar time and effective development time). Perhaps that time is better spent elsewhere?

So. If different "cooking" runs produce slightly different results, it is suddenly difficult to look at version A and version B of the data and answer the question, "what are the differences between these two datasets?". It's easy when looking at the source data, but when looking at the cooked data there are a lot of changes which have no effect on the final game experience.

There are about 40.000 source files, and this results in well over 100.000 cooked files. Going through those by hand is not an option. Writing a perfect filter, which knows which differences are benign and which are for real, will take as much time and effort as making the cooking 100% deterministic. Neither that is an option.

So you make a filter which does something in between; be smart, create rules for the file types you know about, and when in doubt - assume that the change is for real. Err on the side of caution.


Then you realize that those shader databases were never designed to be extendable. What happens when a new object is added to a level in a patch? Its mesh & textures are included, no sweat, but what about the shader combinations? How does one create add something to the shader database, when the shader database is an opaque binary block whose entire contents may change when just one object is added to the level?
(One shader database is about 5MB. There are three shader databases per level - one each for DX9, DX10 and DX11.)


And finally, the patch system itself. Yes, it can replace portions of files on-disk. But due to its heritage (from BF Heroes), it is not able to open BFBC2's archive files and apply differences to individual files within the archives.
The only straightforward way is to make all patched-in content arrive in archives on the side of the original archives.



Given the above scenario, we end up with the situation that we have today.

Each patch gets larger than the previous, because the game drifts ever further away from what was shipped on the DVD. Changes that require shader database updates make the patch balloon in size. And we have to be careful and clever when selecting which file types to include and which to ignore when creating the patch.

And that's where we finally ran into real problems. It was too difficult for one person to identify which changes were required and which were not, and how to update the patch generation process to accommodate the latest set of changes. Most of the delay of Client R8 was because there are very few people at DICE who have the in-depth knowledge of the far-spanning corners of the game engine *and* the cooking tools *and* the patch generation process, to work out what is going wrong, why, and how to fix it.

The new content did work a long while ago - but the patch was back then approximately 7GB large. The patch had to get down to less than 1GB, or else some customers in Australia and South Africa would not be able to download it due to bandwith caps.

[As an aside - how about distributing the patch as an installer, for those who prefer that option? We would love to do so, but creating an installer that does anything out of the absolutely most ordinary installer-y requires ridiculous amounts of development time.]


I think that we have a proper Client R8 patch ready for release, but the approach we have been using thus far has been taken as far as it can go. (A bit too far, considering the delays.) We want to continue supporting the game, but if we want to change anything else than the game executable itself, we will need to spend time on figuring out how to do so with a less error-prone patch generation procedure ... and preferably without generating as large patches.

This stuff keeps me awake at night. What are your demons made of?
- Kalms
« Last Edit: 11-11-2012, 10:11:01 by Natty »

Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #136 on: 11-11-2012, 10:11:53 »
Quote

     Zh1nt0 and you folks have asked about it, so here's a piece on the modtools situation for BC2 PC.

    Frostbite 1.5 consists of these components:

        The game runtime
        The editor runtime
        The content processing runtime (aka "the pipeline")
        and some plugins for Maya


    The game runtime is distributed outside of EA, but the editor + pipeline + Maya plugins are not.

    So let's take a look at some things that would need to be solved before we'd be ready to distribute the editor + pipeline.

    Pipeline operation

    Let's say that you tell the pipeline to build level MP_003.

    MP_003 is represented by an XML file, which references a bunch of other files. These in turn reference other files. If you follow this graph of references, you will find the level layout, heightmap, characters, weapons, vehicles, and all the content that you can see in-game. (The in-game HUD and related stuff might also be in the graph.)

    When the pipeline is about to build MP_003, it will first perform a consistency check on all content, and yell if any file that is referenced by any other is not present.

    If all files are present, the pipeline will attempt to convert all files referenced by MP_003. It uses the file system journal to determine which files have changed on-disk. Also, and any files that have already been converted have info on which files depend on it (so it has info like: "if file X changes, then files Y,Z,W will also need to be rebuilt").

    Building all content for BC2 from scratch takes something like 48-72 hours on a normal workstation. Half that time is spent building common content (such as character animations), half builds level-specific content.

    In addition, there's a caching mechanism: if the pipeline wants to build a specific bit of content, it will first check if the pre-built content is already available on a cache server and take the result directly from the cache server instead. The pipeline can also populate the cache if it builds something new.


    Pipeline issues

    So how does this work in practice? It's not ideal, but it's good enough for us to ship games on it.

    The pipeline is a bit overzealous with regards to rebuilding assets - sometimes it rebuilds stuff that it shouldn't need to.

    The pipeline will normally crash about 2-3 times during a full rebuild.

    You need to have Maya 8.5 (32-bit version) installed in order to convert any meshes.

    Any content in the cache expires after 3 weeks. After 3 weeks have passed, that content will need to be rebuilt and re-uploaded by a machine running the pipeline. The effect that this has on day-to-day development is minimized by having one or two machines dedicated to running the pipeline every time any content change is done. By running the pipeline, those machines will populate the cache, thereby speeding up the build process for everyone else. (The output form those content build steps is discarded.)

    In short: the pipeline + cache setup works better the more people are using it simultaneously.

    If there are content errors, you need to know a lot about the internals of the game engine to figure out what's wrong.

    Finally, in its current form, the pipeline + editor expects some specific IT infrastructure in place (most notably the cache server and a Perforce server).
    If it's not there then the pipeline + editor will behave strangely.
    The first time I tried, it took me about one week to get the full editor + pipeline setup to work properly outside of the DICE office. And that was when I had the option to call any of the other developers to ask for help.

    ... does this sound bad to you?

    Truth be told, this is approximately where the industry average is at for game studios' internal game engines. One of FB 1.5's weaknesses is specifically that its content processing is flaky, and the flakiness gets more problematic as the amount of content goes up. FB 2.0 is much improved in this regard, but FB 1.5 is what we're using for BC2 and that's what relevant in the current discussion (or monologue if you prefer).

    Content

    Both the pipeline and the editor takes in all content in its raw, original form. Anyone who is to build any content needs the full 80GB of raw data on their machine. We are not comfortable giving out all our animations, meshes etc in raw form.

    We are comfortable giving out the processed data - after all, that's what on the game disc - but that data does not plug into the editor/pipeline at all.

    Licenses

    The game, editor and pipeline all use commercial middleware. It is developed by Havok and several other companies.

    The licensing agreement for the middleware allows us to use that code in specific products, on specific platforms.
    If we want to release editor + pipeline, we need to license the middleware specifically for this. How much would that be? Perhaps $1M-$3M. I'm guessing wildly here.

    Stripping out that middleware would seriously hamper the functionality especially of the pipeline. We use Havok Physics, for instance. Without Havok Physics, the pipeline wouldn't be able to convert any of the physics meshes. We also use Granny. Without Granny, the pipeline will not be able to convert any of the character animations. Etc.

    Re-implementing the necessary functionality of the middleware ourselves ("let's make our own physics engine / let's plug in an open-source physics engine") would take literally man-years. Licensing is cheaper in pure $ cost and faster (it works now instead of by 2012).

    The pipeline also uses some code that is under GPL. Given that we do not want to release the full source code for the editor + pipeline, we would need to replace the GPLed code with other implementations.

    The GPLed code is less of a problem than the proprietary middleware.

    Editor

    The editor itself is reasonably stable and well-behaving. It is far from obvious how to set up the game logic for a level, but that is easily covered by releasing some example levels which contain the logic setup for the common gamemodes.

    Test-running levels

    First the level needs to be successfully processed by the pipeline. Then you'd want to be able to test it locally. That involves having a listen server around. We don't have a listen server neatly packaged. There's probably a piracy angle here too but I'm not going to discuss that.

    Distribution of levels

    Getting levels onto the RSPs server machines would likely not be any problem. However there's need for checksumming levels, so that game clients can know whether or not they have the correct version of level X on their machines. There's a whole bunch of other things (mainly UI-related) which will need cleaning up as well. Not difficult to do, just takes time and I'm listing it for the sake of completeness.

    Also, there are some complications wrt when we release patches that affect the base game's content. Whenever we release a patch, all existing levels will need to be rebuilt with a new set of original data. This is because some level-common data is stored inside of the level archives. I'm not sure at the time of writing, but that probably means that the only manageable way for us would be to invalidate any user-made levels when we release a patch of that form.
    Then creators of any user-generated levels would be required to run their levels again through the pipeline with the new base content supplied.


    So how about just a map editor?

    If it doesn't plug into the ecosystem above, then getting it to work involves some serious wrangling. Either it is a light-weight replacement for our existing editor - in which case all the challenges with the pipeline still remain - or it is a separate mode (think Forge for Halo). Developing an extra mod-layer that is sandwiched into the game would easily take 6-12 months.

    Synergy effects between FB 1.5 and FB 2.0

    So let's say that we would go through the procedure of making mod tools for FB 1.5. How much of that work would be reusable for FB 2.0?
    I don't have any firm figures, but the differences between FB 1.5 and FB 2.0 are pretty large by now. Given this and the fact that a fair bit of the FB 1.5-specific problems (where the devil often is in the details) don't apply to FB 2.0, I'd guess that less than half of the work would port over to FB 2.0.

    Conclusion

    In conclusion, my recommendation to the rest of DICE is not to develop mod tools for BC2 PC. There are too many hurdles to overcome. That energy is better spent elsewhere, be that on BC2 or other titles.

    - Kalms
« Last Edit: 11-11-2012, 10:11:22 by Natty »

Offline hitm4k3r

  • Developer
  • ******
  • Posts: 1.123
    • View Profile
Re: Battlefield 4
« Reply #137 on: 11-11-2012, 13:11:58 »
Your explainations are for BC2 mainly and why it is not reasonable to create modtools for BC2. The value for it in terms of the FB2.0 is just not high enough and too complicated. Might be understandable, but it doesn't answer the question completely why there are no modtools for BF3. Both engines seem to be different in the aspect of offering modsupport and the development of modtools.

If I read this stuff, and I really read it, it comes all down to one problem. If you try to develope a game for different platforms, you have to make compromises. Then I will ask you, why DICE didn't support the PC as the lead platform in first place as they staded it several times? The answer is easy: money, money, money ... not the fault of DICE, but other circumstances. There was never a plan to involve the community, so why bother with it? So why pretend to develope the game for the PC as lead platform over a long time?

That is a reason why PC only titles seem to be modable in a better way. Just take RO2 as example or the ArmA engine. It is understandable that there is no way of bringing games like ArmA II to a console of the current gen. The scale is just too big. And it is understandable. Though there seem to be exceptions like the CE3. At the end it comes down to the point, where DICE will have to think about whether developing a game for PC or for consoles in first place. At the end there stays a bitter taste that the player community got shit by the community managers. There are not only a few people who would like to see mods for BF3 and it was one of the first questions after the announcement of BF3.

I am excited to see how this will turn out for BF4 and the next gen consoles but I guess there won't be happen too much on the modding front. Some straight text would be nice and not this fragile statements. Modsupport and PC as lead platform is not the only example. BF1943 comes into my mind.  :-X

Good read though  ;)


Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #138 on: 11-11-2012, 14:11:22 »
Your explainations are for BC2 mainly and why it is not reasonable to create modtools for BC2. The value for it in terms of the FB2.0 is just not high enough and too complicated. Might be understandable, but it doesn't answer the question completely why there are no modtools for BF3. Both engines seem to be different in the aspect of offering modsupport and the development of modtools.

wrong. FB 2.0 is even more complicated than 1.5 to make mod tools for.

If I read this stuff, and I really read it, it comes all down to one problem. If you try to develope a game for different platforms, you have to make compromises. Then I will ask you, why DICE didn't support the PC as the lead platform in first place as they staded it several times?

uhh........ they did.

That is a reason why PC only titles seem to be modable in a better way. Just take RO2 as example or the ArmA engine. It is understandable that there is no way of bringing games like ArmA II to a console of the current gen. The scale is just too big.
RO2 is basically just a mod itself. I don't think you want to understand or accept this, so let me put it in pink. The reason there are no mod tools for BF3 has nothing to do with the fact that BF3 is also on PS3 and XBOX360
There it is.
Also, scale has nothing to do with the non-existent mod tools for BF3. And please don't compare the ArmA engine with frostbite... It's way more complicated than looking at ArmA and say "oooh so big maps, not possibru in battlefield"....

You seem to think an "engine" is something absolute? As if "frostbite" or "CE3" are like one, isolated "thing" which is either "moddable" or not. That is not the case at all. Frostbite is more than an "engine" which Mikael Kalms explains thoroughly. Stop discussing Frostbite because that is not what you want mod tools for, you want it for BF3 and it is impossible to make those, even if DICE wanted to.
Also, by experience, not worth it, since only a couple of mods would ever be released and it would take years for them to come out and only a couple thousands people max would play them, so what's the point?

PC modding is dead, R.I.P. It had a good run, now it's over. Either license an engine and start a project, or make your own engine, or use a free engine, or use Kickstarter. The "free ride" on using other games playerbases doesnt work anymore.

I am excited to see how this will turn out for BF4 and the next gen consoles but I guess there won't be happen too much on the modding front. Some straight text would be nice and not this fragile statements. Modsupport and PC as lead platform is not the only example. BF1943 comes into my mind.  :-X

yepp, completely different thing. If it's worth it, Im sure DICE will think about it, but tbh I don't see any gain in doing this. What, as a "favor" to people buying the game? I mean, what is the actual reason for releasing a mod tool? I mean it's cool to see what people can do etc, but really... Shouldn't mods stand on their own legs, cut the navel cord and design something of their own instead?
In 1999-2005 there weren't many good free engines around, now there is. It seems like the only reasons modders want mod tools is so they don't have to do all the basic work themselves, like designing a game.. they only want to "tweak" it so it plays like "they want"... Aim higher is what I say, build your own community, get fans, create a universe, make your own thing

Install and start designing, today --> http://unity3d.com/
« Last Edit: 11-11-2012, 14:11:34 by Natty »

Offline hitm4k3r

  • Developer
  • ******
  • Posts: 1.123
    • View Profile
Re: Battlefield 4
« Reply #139 on: 11-11-2012, 16:11:31 »
When I was talking about the scale of ArmA, it had nothing to do with the map size. It is the gameworld as a whole that matters. And in this terms ArmA is certainly not suitable for a average console player with a gamepad. It is the whole complexity that matters. Thatswhy most simulators are for PC only. I can't think of any simulation that is available for a console. The most "simulastic" console games that I know of are GT or Forza. But they are no pure simulations either.
Codemasters tried to achieve this with their last Op. Flashpoint titles and they heavily failed. And that there are no modtools for BC2 is basicly rooted on the fact, that the engine was designed for consoles and that it is an evolution of BC1. It is in the first step of your posted statements. You can't ignore this, it is an important fact and I wouldn't overlook it in the whole matter.

If you say that modding is dead, then why are gamestudios or software developers creating open source engines or games with modding possibilties? You mentioned the mod RO2 yourself. DayZ is one of the recent succesful projects in the gaming world, and it is a mod. Why is there a flood of news about mods on moddb every day? You can argue about the results, but the modding process is still there and people want it.
The question is, whether you really want to involve the community or not. And in this departement other developers are doing a better job. Either you shut the doors and say we are doing our own sh*t and
give clear points, or you try to trick the community with statements like "the PC is the lead platform". I hope you see the problem. If there is a clear path with BF4 visible then I am OK with it, but not those vague statements that we had over the last 1-1.5 years.

Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #140 on: 11-11-2012, 16:11:20 »
And that there are no modtools for BC2 is basicly rooted on the fact, that the engine was designed for consoles and that it is an evolution of BC1
But Frostbite isn't "designed for consoles" just because BC1 was the first game and it happened to be console only.

The question is, whether you really want to involve the community or not. And in this departement other developers are doing a better job.

But we involve the community a lot in FH2, why do you take up FH2 in this thread? I'm confused here... Didn't we just add six 762 admins as betatesters? Isn't that "involving the community"?

Offline LuckyOne

  • Hero Member
  • ****
  • Posts: 2.722
  • Purple Heart Collector
    • View Profile
Re: Battlefield 4
« Reply #141 on: 11-11-2012, 16:11:55 »
But we involve the community a lot in FH2, why do you take up FH2 in this thread? I'm confused here... Didn't we just add six 762 admins as betatesters? Isn't that "involving the community"?

I think he was reffering to DICE/EA, not FH 2 there. FH 2 is a great example of what can be done when community is part of the creative development process. (Actually whole BF 2 and its modding scene is).
This sentence is intentionally left unfinished...

Offline hitm4k3r

  • Developer
  • ******
  • Posts: 1.123
    • View Profile
Re: Battlefield 4
« Reply #142 on: 11-11-2012, 18:11:58 »
Lucky got it. I was reffering to DICE and not FH2, though he is right about the example how working with the community can be done in a more positive way as you do it with your own mod. Ofcourse it is difficult to compare a mod like FH2 with a gamestudio like DICE working on a AAA title with the business plan in mind, but it shows how you can keep players/moders and devs happy in the long run as there is always a contribution to each other. I don't know how many people bought ArmA II just for DayZ.

It is the same like the contribution between Tripwire and the Rising Storm devs. It started as a mod but now they will be able to sell it as an expansion.

Btw: did I say that the FB was designed for consoles only? No. My intention was to show that it was a engine designed for multyple platforms atleast, for consoles in the very beginning. So you could not use the strength of PC hardware only, you also had to think about of the charactersitics of the different platforms. I think you won't disagree about this. But this multy platform support has one problem. It requires a architecture that makes modding too complicated. Now it would be interesting to know, if BF3 would had been moddable if it would have been developed for PC only without those restrictions and compromises that come with multy platform support.

Btw: when I play BC2 I still feel the console game in it, though it was designed for multiple platforms. (UI, controlls, graphic setting etc.).
« Last Edit: 11-11-2012, 18:11:41 by 5hitm4k3r »

Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #143 on: 11-11-2012, 20:11:59 »
Lucky got it. I was reffering to DICE and not FH2
OK, a bit confusing as you were adressing me, as "whether you really want to involve the community or not"... makes it sound as if you're talking about FH2

So you could not use the strength of PC hardware only, you also had to think about of the charactersitics of the different platforms.
No, the games were made separately. The PC version of BF3 wouldn't have looked any different if BF3 was a PC-only game. This is a myth that internet trolls (not refering to you) like to use, because it's their strongest "card" to use against DICE, the very company that created the culture of which they are fans of... The bottom line is; BF3 and BC2 as well are as they are because that was the games that the designers wanted to do, nothing else. And sales, metacritic, playernumbers and hundreds of world-wide awards proof they made the games the players want and wanted.

Would BF3 have had a greater chance of getting mod tools if it was a PC only game? No idea. But I still doubt it would be any point... Look at BF2. Only a couple really meaningful mods released, and a couple of years after release only 2 mods lasted with any playerbase (FH2 + PR) Not really be worth it for BF3 would it? First BF3 mod would be released in 2014 perhaps, and tbh, wouldnt really be able to form any playerbase. It would generate alot of entries at ModDB and alot of forum with many words and enthusiastic threads,  and galleries with many renders, but very little actual game experiences.

We all know this, don't we?
« Last Edit: 11-11-2012, 20:11:36 by Natty »

Offline NTH

  • FH-Betatester
  • ***
  • Posts: 3.146
    • View Profile
Re: Battlefield 4
« Reply #144 on: 11-11-2012, 20:11:46 »
That was an interesting read by Kalms. Creating and maintaining complex applications is part of what I do for a living. So I feel some of his pain there.
I must say the whole setup that he described for the FB software suite doesn't sound that complicated. And in these days of Amazon cloud you can buy dedicated systems to deploy the whole Software suite and get it up and running.
I bet that the FB Software suite would even be improved in no time by some of those whizz kids that spend their life on the Internet  ;)

Now here is why I think modding for BF3 would have a hard time. Patching just like Kalms said. You remember those days when there were only one or two big patch's per year and you had to do regression testing to check if nothing broke in your mod. That was doable.
With BF3 they have online patching, which would strain a mod team to do full testing and rebuilding of the mod every time a patch is released.
The frequency of patches being larger in BF3.

Also you would have cracked servers in no time if they released the ded. server tools with it.

@5hitm4k3r
The whole software suite would be the same even it was just for PC. How is a cache server, listener server, Maya and their editor specific for a console?
Dice switched focus to console during the development of BF3, they didn't throw away all their building tools because of it.
« Last Edit: 11-11-2012, 23:11:30 by NTH »


Milton Gault roared, "Roffey, I know bloody well that Jerry knows we are here but you don't need to advertise the fact!"
(From: First in the Field, Gault of the Patricias by Jeffery Williams, page 72.)

Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #145 on: 11-11-2012, 21:11:57 »
Yes precisely :)

There are two myths that I hearby will bury, may them rest in peace and thanks for all the fun they gave some people while they were believed

1. The myth that EA or DICE didnt release mod tools because of "fear" that it would "impact sales of DLCs" - dead
2. The myth that EA or DICE didn't release mod tools because BF3 was "made for consoles" - dead

There, feels a whole lot better with those two out of the way


Offline Smiles

  • FH-Betatester
  • ***
  • Posts: 2.088
  • Boooo Auto-Spot! Booo
    • View Profile
Re: Battlefield 4
« Reply #146 on: 12-11-2012, 00:11:03 »
haha no way im gonna read this again. The crusade is strong, burn everything!
I'm taking my own freedom
puttin' it in my song
singing loud and strong
proving all day long
I'm takin' my freedom
puttin' it in my stroll
I'll be hop-steppin' y'all
lettin' the joy unfold

Offline Cheesus Krighst

  • Jr. Member
  • **
  • Posts: 192
  • Zi's Iz mein Flammenwerfer! And it Werfs Flammen!
    • View Profile
Re: Battlefield 4
« Reply #147 on: 12-11-2012, 10:11:19 »
Anyone ready to lock this one up and label it "TL:DR Useless argument about Overrated Engine"?

Please stop wasting your lives and keystrokes on proving how the engine just plainly sucks eggs in the modding department and use d'em fingers to make some FH2 magic.

For the people who did not read the freakishly huge novel above. Any engine that is past BF2's Refractor engine= no mods = no community content = no FH3 on the future BF engines = Most likely not in your best interest to use 60+ dollars to buy a new BF3/4 game. Tadah.

Just wait for about 6-8 years until EA get's tired of milking BF3/FB engine and some computer whizzes conjure up an unofficial modding kit.

I blame DICE and EA for creating such a "pretty" looking engine with obviously scripted destructibles... dynamic destruction, puhlease. You'd imagine with all of that advanced technology we'd be playing 200 vs 200 player battles by 2014, but nope. Just pretty Eye candy and CoD perk gameplay. :( They just need to fallback on the original plan on their most original game. BF1942. Balance, fun, lots of players (200), and hopefully add more realism.
« Last Edit: 12-11-2012, 10:11:49 by Cheesus Krighst »

Offline Natty

  • Developer
  • ******
  • Posts: 3.170
    • View Profile
Re: Battlefield 4
« Reply #148 on: 12-11-2012, 10:11:35 »
very elaborate trolling there, my tin-foil hat's off to you  8)

In 5 paragraphs you didn't really manage to say anything substantial of that of value to this conversation at all. It also contains pure lies  ;D "scripted destruction" grab your shame-pillow folks, the guy just started tech-talking about things he does not understand, hilarious!

I think the so-called "computer whizzes" you talk about should spend 6-8 years making their own engine, dont you think? Or aren't they whizzy enough to do that? is it in fact so, that they can't really do anyhing except "tweak" already done games, games done by professional "whizzes"?

*smoked*

Offline hitm4k3r

  • Developer
  • ******
  • Posts: 1.123
    • View Profile
Re: Battlefield 4
« Reply #149 on: 12-11-2012, 16:11:53 »
But in one point he is right and that's what I tried to say with my argumentation: the FB sucks in the modding departement because of it's architecture. That was a point that, you Natty and nth missed a bit.

How the content for the game is created is quiet similar to any other game and there is no big fuzz about it. The problem lies in the editor and in this pipeline and how all the content is processed in this engine. And this has certainly to to with the architecture of the FB engine and it's function to be suitable on different platforms. It is the evolution of this engine. Kalms himself even describes this evolution  and why this FB engine is build up as it is. That the FB engine doesn't work the same way on all three platforms is quiet obvious. There are too many different components in the different hardware configurations.