Bioware are using an extensively modified U3 engine for the Mass Effect series, an engine renowned for its accessibility and versatility. Bioware devs have stated that there will be no SDK for mods due to bugs and glitches, on top of the networked distribution of the engine tools. I'm sure third party software and licensing issues also come into play there, too.
Some devs want to focus solely on game development and not on the mod scene, as good as it may be.
...
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.[/quote
The Lost Big Boss said:
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
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.
Paul, I've seen modders do some damn impressive shit, but just read the dev's post on the difficulties of using frostbite 1.5. Sometimes devs aren't just lying to make more money, sometimes it really is the case that a bit of software is too difficult to work with without serious investment and customised tools that they just don't have the time, money or inclination to make to allow third parties modding capabilities. Sure, it can be great to have mods for your game, but it's not the be-all, end-all, and really good, stable mods are quite rare on the grand scheme of things, even on platforms that go out of their way to support them.
Releasing the SDK for an engine that can be a pain to work with even for the studio that made it is just going to frustrate modders and fans, possibly creating bad publicity as people denounce the buggy engine; not worth the hassle, and I don't blame them.
Releasing the SDK for an engine that can be a pain to work with even for the studio that made it is just going to frustrate modders and fans, possibly creating bad publicity as people denounce the buggy engine; not worth the hassle, and I don't blame them.
I honestly don't think high profile devs can ever truly please a community. Just look at many of the comments here in this thread, despite information from DICE about the issues that prevented them from compiling FB 1.5 to an SDK for the mod community.
Bioware are using an extensively modified U3 engine for the Mass Effect series, an engine renowned for its accessibility and versatility. Bioware devs have stated that there will be no SDK for mods due to bugs and glitches, on top of the networked distribution of the engine tools. I'm sure third party software and licensing issues also come into play there, too.
Some devs want to focus solely on game development and not on the mod scene, as good as it may be.
Stating that No devkit exists because it is not consolidated into a single distributable program and would be too difficult to do so is a legitimate reason. That is the reason you didn't see BF:Bad Company 2 mods... there was no Devkit because the programs where tooled for console and where networked across several machines. it would be too difficult to compile it all into a single SDK for computers just for mods...
and i'm alright with that.
But stating that No devkit exists because the mod community is not skilled enough to use it is not an legitimate excuse... it is an insult.
Read his review... he is effectively saying 'We're not even going to Try because you all would be too stupid to use it...'
...
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.
Paul, I've seen modders do some damn impressive shit, but just read the dev's post on the difficulties of using frostbite 1.5. Sometimes devs aren't just lying to make more money, sometimes it really is the case that a bit of software is too difficult to work with without serious investment and customised tools that they just don't have the time, money or inclination to make to allow third parties modding capabilities. Sure, it can be great to have mods for your game, but it's not the be-all, end-all, and really good, stable mods are quite rare on the grand scheme of things, even on platforms that go out of their way to support them.
Releasing the SDK for an engine that can be a pain to work with even for the studio that made it is just going to frustrate modders and fans, possibly creating bad publicity as people denounce the buggy engine; not worth the hassle, and I don't blame them.
I'm not saying modding the engine for BF3 would be easy.
hell i've seen the specs for it and the demands it puts on a single computer, and i know that it would stress even hardcore overclocked user built rigs designed specifically for that kinda stuff.
Not having a devkit is not my problem
it is his reasons of why there isn't a Devkit that i'm having problems with.
He should of talked about how demanding the SDK is, how it would take days to compile maps or hours for simple adjustments such as panning a house 2 degrees. And this is all on top end computers.
but what he said:
'It is too complex for modders...'
A new fad that started probably 5 years ago when they started buying out a bunch of top quality developers and closing them and/or destroying their franchises.
As for this thing, it probably IS a lie but one out of ignoranc.e
That's just offensive to the dedicated modders and crews out there. Mods add value and longevity to games, and the best thing is, they're made by people who love the game enough to expand and improve on it.
Also, mods are free. That may not please the bean-counters trying to milk every last cent out of an IP.
It wouldn't surprise me in the next few years if developers start suing modders for 'reverse engineering and disassembly'.
A new fad that started probably 5 years ago when they started buying out a bunch of top quality developers and closing them and/or destroying their franchises.
As for this thing, it probably IS a lie but one out of ignoranc.e
A new fad that started probably 5 years ago when they started buying out a bunch of top quality developers and closing them and/or destroying their franchises.
As for this thing, it probably IS a lie but one out of ignoranc.e
A new fad that started probably 5 years ago when they started buying out a bunch of top quality developers and closing them and/or destroying their franchises.
As for this thing, it probably IS a lie but one out of ignoranc.e
A new fad that started probably 5 years ago when they started buying out a bunch of top quality developers and closing them and/or destroying their franchises.
As for this thing, it probably IS a lie but one out of ignoranc.e
I'll take that as some points for my non-existant hipster cred .
I was hating EA before it was En Masse cool.
It all started with CnC Renegade getting crushed after the acquisition was complete...and then watching Maxis fall apart, reaching the epitome of disappointment with SPORE.
Then once Bioware was bought out I knew they were a lost cause. Little glimmers shine from time to time but annoyances like being forced to get the DLC from their special "points" store, are just too much for me to handle.
I don't shit on others for liking them.
But I will probably not like EA till they stop buying every company I like and ruining them :/.
Sure, and reasonable people would accept that position if it was left at that. DICE aren't willing to spend all the time and money it would take to strip down to basics and rebuild their entire devtool set to make official modtools. That's perfectly fair. From the sounds of it that would be a massive amount of effort expended for no tangible gain. Doesn't sound like the best business plan, especially for a dev who has EA sitting on their shoulder.
Problem, as I see it, is that DICE went that one step further to be dicks about it all by basically saying "... and you don't have our giant space-brains to comprehend our tools." That's a slap in the face to the core modding communities that regularly show levels of ingenuity, resourcefulness and dedication that would surprise most people.
I'll take that as some points for my non-existant hipster cred .
I was hating EA before it was En Masse cool.
It all started with CnC Renegade getting crushed after the acquisition was complete...and then watching Maxis fall apart, reaching the epitome of disappointment with SPORE.
I'll take that as some points for my non-existant hipster cred .
I was hating EA before it was En Masse cool.
It all started with CnC Renegade getting crushed after the acquisition was complete...and then watching Maxis fall apart, reaching the epitome of disappointment with SPORE.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.