DICE Says No to Mod Tools For Battlefield 3

[The_Puppy_Prince]

It shouldnt matter if people are dedicated enough the SDK is good enough no?

 

[HyenaThePirate]

And with that single statement, Dice has effectively murdered any hopes they might have had of Battlefield 3 beasting Modern Warfare 3.

Back to cult fan status with the BF series.

 

[Togusa09]

Obviously they haven't heard that minecraft is generally modded by replacing classes in it and rebuilding the jar, or some of the things that have been done to mod oblivion...

Reguardles of how bloody difficult it is, a modder will do it, and then document it. The more will come and build tools...

It's rather an underestimation of their fanbase, but I suppose stating that it's "Too hard" guarentees that people will try to mod the hell out of it.

 

[RhombusHatesYou]

It's rather an underestimation of their fanbase, but I suppose stating that it's "Too hard" guarentees that people will try to mod the hell out of it.

Yep. Nothing gets a codemonkey motivated more than giving them a challenge that will gain them peer acclaim... okay, except one that offers peer acclaim AND cash gratuities.

Reguardles of how bloody difficult it is, a modder will do it, and then document it. The more will come and build tools...

Essentially. Someone (or a couple of someones) will break down the code and start combing it to discover all the functions and so forth and document it. As prime modding functions are discovered they or others will start experimenting with these functions, how they can be altered, replaced or fed external assets and document all that. Then people will start building tools based on this information. Slowly the library of 3rd party modtools will grow and as the library grows more and more complex mods become possible.

Basically, modders don't need tools that replicate the functions of the devtools per se as long as what tools they do create can produce content that works with the game engine. Even if the end result is an unholy mix of workarounds, quickfixes and kludges, if it works it will be used.

 

[lobster22221]

Obviously they haven't heard that minecraft is generally modded by replacing classes in it and rebuilding the jar, or some of the things that have been done to mod oblivion...

Reguardles of how bloody difficult it is, a modder will do it, and then document it. The more will come and build tools...

It's rather an underestimation of their fanbase, but I suppose stating that it's "Too hard" guarentees that people will try to mod the hell out of it.

Before people go and rage for no reason, read this.
http://forums.electronicarts.co.uk/battlefield-bad-company-2-pc/1350772-so-how-about-modtools.html

Spoiler

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.

Short version

It takes days to compile a map, and even then it will crash multiple times. Not including errors that only the engine developers could possibly debug.

Middleware would need to be rewritten in order for any mod tools to be released to public.
To make everything work, DICE would need to give out over 80GB of mesh, animations and a what have you, all of which is property of DICE.

This engine was never intended for use outside of DICE. It's too overly complicated for people who didn't build it or worked with it during its creation.




Aaaaaaaand Ninja'd

So, beyond insane performance requirements( even for top of the line computers) and legal distribution issues, unless they release a a dumbed down editor, which they are saying could add way too much to development time. I think thats actually a reasonable excuse.
However if they ever make a new engine from near scratch, they will hopefully base it so that models are exported individually(So that they don't have to distribute maya. Have a way to distribute the physics engine so that anyone can use it without licensing, and that should probably cover at least a few of the issues. (Also, height map based terrain with mesh terrain as an alternative)

 

[Soviet Heavy]

Okay, so how long until the homemade Modding Tools are released? EA also said that Dragon Age 2 wouldn't have mod tools released, and look at what happened there.

 

[Clive Howlitzer]

Sorry all I heard was "We don't want you to be able to make your own levels because then we can't charge you for level packs!"

 

[The Random One]

Man, I bet it would have mod tools if it ran at 60 FPS.

Seriously though, they're either too lazy to create the mod tools, or trying to make more money off DLC. Which is too bad, since as the newspost says a mod was what brought the WWII game to the modern theatre for the first time. Still, it's not stopping the modders, and it ain't making the game worse.

 

[Scizophrenic Llama]

I'm betting EA put them on this, as no mods adds incentive to get DLC for more content.

 

[Plazmatic]

the source engine is hard as balls to mod, i couldn't even fathom modding a frostbite engine.

it would actually be easier, better engine, the only hard part is dealing with the variables on maps, and dealing with the new lighting/ texture mapping techniques, but that's just speculations, if thats no the case it can ONLY be easier. Other than that, if you aren't updating the graphics, then it really is a whole lot easier.

 

[Wicky_42]

Um, guys, has no one noticed that Bad Company 2 doesn't have any mods either? It's not like this is some new unexpected slap in the face, or that they charged for maps for BC2, it's just that they don't seem to want people to play with the Frostbite engine.

Seriously, chill out and get your mod fixes elsewhere :/

 

[Wicky_42]

...
But while it will undoubtedly be a hindrance, the lack of official tools is unlikely to stop the mod community; if they want to mod the game, they will. If anything, Söderlund's comments might actually spur them on to make more content, just to prove him wrong...

Well, it didn't work for Bad Company 2, doubt there's gonna be a huge wave of support for Battlefield 3. It really seems like Dice know what they are talking about when they say that it's too difficult for modders to have their way with Frostbite, and judging from the free maps for BC2 it's not some insidious cash-grab exercise like many are suggesting.

 

[actar411]

I'm excited for these mods! Git 'er done!

 

[Royas]

I've often found that some of the mod community manage to make better scenarios than the developers. Too complex indeed! That's about one of the stupidest things I've ever heard a dev say. Dude, if you can get your brain around the engine, I guarantee there are dozens, hundreds of modders who can do it too. DICE doesn't have a monopoly on brain power or skill, which is what this statement seems to be insinuating.

 

[catfishtuna]

This is disapointing, There have been more great MOD's on Battlefield engions, than games I would pay full price for, since Battlefield 1942 first launched.

I hate the way tactical shooters are being castrated for the Console Audience. I feel like the Graphical arms race has regressed on itself, now that graphics look so clean and crip devolpers are scrambleing to distort and obscure the gamers vision with frustration particle effects. I understand sometimes theres fog in the real world, but what the appeal about hidding your graphics behind obscuring lence flairs and smoke. I want to see the enviroment I want to see the enemy, I hate feeling clostraphibic inside a video game when I can just go out side. ANd hey its a beautiful clear day. It made sence when games couldn't render very far beyond the players emidiate vision. BUt what the Fuck is with BattleField BAD company 2. The snow levels was just a solid white screen.

 

[Pyro Paul]

...
But while it will undoubtedly be a hindrance, the lack of official tools is unlikely to stop the mod community; if they want to mod the game, they will. If anything, Söderlund's comments might actually spur them on to make more content, just to prove him wrong...

Well, it didn't work for Bad Company 2, doubt there's gonna be a huge wave of support for Battlefield 3. It really seems like Dice know what they are talking about when they say that it's too difficult for modders to have their way with Frostbite, and judging from the free maps for BC2 it's not some insidious cash-grab exercise like many are suggesting.

the problem is that their statement is a load of hogwash.

A games community is often Smarter, faster, and better at design then the acctual studio and can often spawn great peices which really add or evolve a game. To opt out and simply say 'its too smart for you guys' is near insulting...

the Reason 'Bad Company 2' didn't support mods was because there was no PC side program. Because BC2 is effectively a Console port. Sure you had half a dosin programs which could edit and mod the game... but they where spread out across 5 computers in diffrent offices and all designed to manipulate Console code, not PC. a PC master program was never compiled, which is why you don't see any mods for it.

from the way they are speaking now though.
They have a master program... they just don't want to share it because they think us too stupid.

 

[]DustArma[]

Obviously they haven't heard that minecraft is generally modded by replacing classes in it and rebuilding the jar, or some of the things that have been done to mod oblivion...

Reguardles of how bloody difficult it is, a modder will do it, and then document it. The more will come and build tools...

It's rather an underestimation of their fanbase, but I suppose stating that it's "Too hard" guarentees that people will try to mod the hell out of it.

Before people go and rage for no reason, read this.
http://forums.electronicarts.co.uk/battlefield-bad-company-2-pc/1350772-so-how-about-modtools.html

Spoiler

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.

Short version

It takes days to compile a map, and even then it will crash multiple times. Not including errors that only the engine developers could possibly debug.

Middleware would need to be rewritten in order for any mod tools to be released to public.
To make everything work, DICE would need to give out over 80GB of mesh, animations and a what have you, all of which is property of DICE.

This engine was never intended for use outside of DICE. It's too overly complicated for people who didn't build it or worked with it during its creation.




Aaaaaaaand Ninja'd

So, beyond insane performance requirements( even for top of the line computers) and legal distribution issues, unless they release a a dumbed down editor, which they are saying could add way too much to development time. I think thats actually a reasonable excuse.
However if they ever make a new engine from near scratch, they will hopefully base it so that models are exported individually(So that they don't have to distribute maya. Have a way to distribute the physics engine so that anyone can use it without licensing, and that should probably cover at least a few of the issues. (Also, height map based terrain with mesh terrain as an alternative)

Reposting for justice, it's like people are actively avoiding to read the post DICE devs made because that would completely destroy their whining about no mod tools

 

[Andy of Comix Inc]

"I DARE SAY, PEASANTS, YOU DO NOT HAVE THE INTELLECT REQUIRED TO MOD OUR INGENIOUSLY DESIGNED ENGINE! Stop convincing yourselves you're any good at game design, and go and license the Source engine, twats!"

I'm okay with "we won't have mods", as long as the game is good enough. But I'm not okay with this supremely offensive and elitist attitude. Modders "aren't good enough"? Your engine is just that good, eh? ...yeah, that'll win you customers that way, you morons.

Edit: Okay I just read that post from the DICE devs. I'm still not convinced the words "not good enough" should ever be uttered from the developers to their customers. However. I'm not a technical genius or anything, but that does look like a right legal mess to get the required mod tools for.

 

[feather240]

I'm betting EA put them on this, as no mods adds incentive to get DLC for more content.

No, DICE did this because the Frostbite engine is a clusterduck.

Spoiler

Click the blue link.