Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Python Used as Modding Language for Battlefield 2

Zonk posted more than 9 years ago | from the snakes-and-guns dept.

Programming 41

Dutch Dopey writes "In an interview with Lars Gustavsson of DICE, it was mentioned that Battlefield 2's modding tools are going to be delivered with the game, and that the tools are the same ones used to develop the game. The modding language in use is Python, and will support all aspects of the language.

cancel ×

41 comments

Sorry! There are no comments related to the filter you selected.

Python's too slow for gaming (1, Insightful)

MentalMooMan (785571) | more than 9 years ago | (#11643066)

For mods, it's OK, but it's simply too high a level code for the main game. Battlefield already runs too slowly on my computer (UT2k4 works 10x better). I don't want it going even slower!

Re:Python's too slow for gaming (1)

JohnFluxx (413620) | more than 9 years ago | (#11643552)

Why is this modded interesting? It's just the same old myths again.
The speed in games is not influenced much by the language that the high level logic is written in.

Re:Python's too slow for gaming (4, Insightful)

sholden (12227) | more than 9 years ago | (#11643622)

That hasn't stopped Troika Games using it for Greyhawk or Irrational using it for Freedom Force. Not for the entire game engine but as the level scripting engine. The bit that actually matters in the game, the bit which makes the *fun* stuff rather than the pretty stuff.

And of course there's BaseGolf which is completely implemented in python.

The problem I see with using python as a modding language is that it makes it very difficult to enforce safety in mods. It'd be nice if the modding language was sandboxed so that you could download a mod and know it won't format your hard drive.

But it makes sense to use an existing language engine instead of creating yet another scripting language for the level designers to use. And python is much easier for non-programmers to write in than lua, in my opinion anyway...

Re:Python's too slow for gaming (3, Informative)

BeBoxer (14448) | more than 9 years ago | (#11644158)

The problem I see with using python as a modding language is that it makes it very difficult to enforce safety in mods. It'd be nice if the modding language was sandboxed so that you could download a mod and know it won't format your hard drive.

Yeah, that's one of Python's shortcomings I think. There is the 'rexec' module which is meant to do this, but it apparently it has unspecified holes in it. The 'pickle' module has similar flaws. You could do some neat RPC stuff passing around picked objects, but only at the risk of introducing security holes. Oh well.

Re:Python's too slow for gaming (1)

sholden (12227) | more than 9 years ago | (#11644358)

It's a shortcoming in any language which wasn't designed with doing exactly that in mind from the beginning.

Hacking it in is very difficult, and none of the python attempts I've seen actually work.

Just think how many languages which have been designed with that in mind end up with bugs/flaws that result in holes - it's hard to get right when it is designed in from the start...

Re:Python's too slow for gaming (1)

smitty_one_each (243267) | more than 9 years ago | (#11645043)

As long as the mods are open source, why not do the following: make a list of regular expressions matching unsafe calls, tokenize the mod source, and check it for naughtiness?
Might not be the quickest, but so what?

Re:Python's too slow for gaming (1)

KDR_11k (778916) | more than 9 years ago | (#11645462)

Might make more sense to simply offer the game API and some basic functionality as a module and prevent the user from importing any other modules. Mods won't need most of the modules, anyway.

Re:Python's too slow for gaming (4, Informative)

snorklewacker (836663) | more than 9 years ago | (#11644889)

The holes in rexec have been acknowledged to the point where importing the module throws an error about its complete lack of actual security. Expect it to be removed entirely in some future version. Pickle is importing arbitrary code, which can do arbitrary things. There really isn't a sensible way to protect against this in a dynamic environment.

It's not like lua lacks file and system access primitives either, though those tend to be easier to hack out if necessary (which it usually isn't, since it's the game logic that's written in lua, not third party mode). The appeal of lua is the smaller footprint.

Re:Python's too slow for gaming (0)

Anonymous Coward | more than 9 years ago | (#11661594)

Changed in version 2.3: Disabled module.

http://docs.python.org/lib/module-rexec.html

Re:Python's too slow for gaming (0)

Anonymous Coward | more than 9 years ago | (#11647806)

I don't think it's a huge shortcoming considering that many games have used DLL files for modding. Now if THAT isn't a security hole....

Re:Python's too slow for gaming (2, Interesting)

Chyeld (713439) | more than 9 years ago | (#11647618)

Do what Blizzard did with LUA and only implement the core functions and libraries you consider 'safe' and leave the others out.

Of course, the scope of a mod for a full game would be greater than the scope of just a quick add-on to the UI to keep track of the number of copper bars you are carrying around, but there are still limitations to what you can specificly expect a mod to use. How many mods can legitimately claim a need to be able to write to files outside the game's own folder? Implement your version to be automaticly 'jailed' to that folder. How many times, legitimately, can a mod claim to call an outside program. Remove the ability to do that. etc. ad nausium.

Re:Python's too slow for gaming (2, Interesting)

thedustbustr (848311) | more than 9 years ago | (#11650027)

The builtin modules (c modules created by the interpreter) are enough to fsck up a computer (pun intended). This is hackable, of course (I heard a rumor that Zope has its own custom sandboxed python interpreter, but for some reason you can't use it without the rest of zope?), but beyond the scope of most projects (if security is a concern, I've heard that lua and javascript sandbox quite easily).

A hackish way to implement security in python is to check every untrusted line with a custom parser, not allowing anything to execute certain builtins, but this is very undesirable - how much of a pain would it be to disallow file opening only for files outside of the root folder?

Enough rambling. It would be interesting to see how Freedom Force et. al. handled untrusted python code... maybe they HAD to roll their own interpreter.

Homeworld 2 (1)

theolein (316044) | more than 9 years ago | (#11669118)

Homeworld 2 uses LUA as well for modding, and in fact for all config files. I prefer it to Python as the whole whitespace thing in Python drives me crazy.

I don't want to miss the opportunity to give propz (2, Informative)

Deekin_Scalesinger (755062) | more than 9 years ago | (#11643108)

To those who made BF42 so much fun:

Desert Combat - http://www.desertcombat.com/

Battlefield 1918 - http://www.bf1918.com/

Forgotten Hope - http://forgottenhope.bf1942files.com/main.html

These three mods (and many more out there) took BF42 to new places, especially DC. Glad to hear that they are giving modders even more tools with BF2 - I can't mod or skin my way out of a paper bag, but I am grateful to those who can and give their talents to their community gratis.

Re:I don't want to miss the opportunity to give pr (1)

Leroy_Brown242 (683141) | more than 9 years ago | (#11643289)

BF 1918?

Peopel shooting at eachother from trenches 100 yards away from eachother or so?

That sounds as dumb as BF 1860.
Marching in formation, shooting eachother in nicely formed colomns.

Re:I don't want to miss the opportunity to give pr (0)

Anonymous Coward | more than 9 years ago | (#11644942)

That sounds as dumb as BF 1860.
Marching in formation, shooting eachother in nicely formed colomns.


More like 1680, not 1860. They didn't exactly line up in formations during the civil war.

Re:I don't want to miss the opportunity to give pr (2, Interesting)

Deekin_Scalesinger (755062) | more than 9 years ago | (#11646049)

It's more like you run up and light a fuse, then see if a cannonball explodes 5 minutes later. Nah - it's not as bad as that :) They have early versions of tanks and armored cars, trench combat, flyable zepplins and biplanes, etc. Yeah it is indeed an adjustment from the normal "set plasma cannon to 50 megawatt range" that most FPS give you, but it balance out when you realize the other guy as equipment as arachic as you. Moreso, serious war history buffs spend a lot of time critiquing the accuracy of layout of this vehicle or that, which some people get into...

Re:I don't want to miss the opportunity to give pr (1)

Lord_Dweomer (648696) | more than 9 years ago | (#11653571)

Except don't expect to get Desert Combat for free when Battlefield 2 comes out. Dice has hired the DC team, and there will be no more free DC. Sellouts.

Re:I don't want to miss the opportunity to give pr (1)

DerWulf (782458) | more than 9 years ago | (#11679271)

They given you what basically amounts to a free game and now they dare trying to make some money off their talent? Shame on them! Way to go on the name calling. Don't stop the rage. PS: What the hell would you need DC for in BF2? Seeing as BF2 spends most of its time in the desert, doing combat.

so.. (2, Funny)

newr00tic (471568) | more than 9 years ago | (#11643412)

.

Ok... Is it safe to assume that the _whole_ game is coded in Python then?

.

Re:so.. (1)

MentalMooMan (785571) | more than 9 years ago | (#11643593)

I seriously doubt it

Re:so.. (0)

Anonymous Coward | more than 9 years ago | (#11643821)

Disclaimer: I love to write python code. The game is almost certainly not written in all (or even mostly) python. I'd wager that the graphics code and physics is all done in C (or C++). Python isn't up to snuff for *real time* 3D graphics/physics unless it's very basic. However, python interfaces very well with C. So, it's fairly easy to call C or C++ code from python. What they've probably done is written python wrappers for those bits of code that had to be done in some other language for speed reasons.

So, why python? Because it's easy to write. Inexperienced coders will have an easier time creating mods than if they had just released some C++ SDK. While experienced mod makers should be able to create new mods faster than before.

Re:so.. (4, Insightful)

Jerf (17166) | more than 9 years ago | (#11644839)

Ok... Is it safe to assume that the _whole_ game is coded in Python then?

Not in the slightest. Python integrates well with C and C++. (Some other languages do it without somewhat less boilerplate in the integration code, but Python is one of the languages that basically integrates 100% feasibly.)

In fact, quite the opposite; it's safe to assume only the high level is in Python. That's Standard Operating Procedure for high-performance code in the Python world.

Python/C API (1)

Craig Ringer (302899) | more than 9 years ago | (#11727963)

Well, Python integrates tolerably with C and fairly poorly with C++. It's clumsy, verbose, and annoying, but the end result does work well.

Libraries like Boost::Python and tools like Pyrex help a *lot* when trying to make Python/C integration a bit less excruciating.

Opensource tools (5, Interesting)

petteri_666 (745343) | more than 9 years ago | (#11643723)

from the article

Modifications
FZ: When Valve released Half-Life 2 last year criticism quickly arose due to the fact that they assumed people wanting to do modifications would have access to the commercial compiler and IDE Microsoft Visual C++ .NET 2003, which costs several hundreds of euros. What tools will be required to fully modify Battlefield 2 in addition to the tools that DICE will provide?(Steven Svensson)

LG: We have greatly enhanced our support for modders by giving the option to create modifications through the script language Python. This means that there will be no requirement to have access to Microsoft Visual C++ as you mentiond in your question.

This is perfect use for python language. Nice to see this kind of solution in a commercial game.

Re:Opensource tools (1)

lineman60 (806614) | more than 9 years ago | (#11657970)

assumed people wanting to do modifications would have access to the commercial compiler and IDE Microsoft Visual C++ .NET 2003
why can they not use gcc/g++ and IDE like dev-cpp? the programing class im in right now uses it for SDL.

Troika used python for the scripting in Bloodlines (3, Informative)

JimmehAH (817552) | more than 9 years ago | (#11643814)

It uses the Source engine (the Half-Life 2 one).

Vampire: Bloodlines [vampirebloodlines.com]
Source engine feature list [valvesoftware.com]

Re:Troika used python for the scripting in Bloodli (0)

Anonymous Coward | more than 9 years ago | (#11644444)

Did you even read the pages you linked to? Troika added a Python interpreter to the engine.... along with cloth simulation, a scriptable particle simulator, a dialog system, melee combat, and hundreds of other things that an RPG requires that a vanilla FPS doesn't.

Re:Troika used python for the scripting in Bloodli (1)

JimmehAH (817552) | more than 9 years ago | (#11645743)

Hummn. I seem to have implied that the python interpreter is a feature of the Source engine and not something Troika added themselves. Sorry.
It is a very impressive game and I enjoy playing it a lot (even though it could've done with some more time for bug testing).

I just wanted to let people know that Battlefield 2 wasn't the first big game that used Python for its scripting.

EVE Online (4, Informative)

Winterblink (575267) | more than 9 years ago | (#11643934)

The developers of EVE Online [eve-online.com] utilize Python for their game logic. Linkage [eve-online.com]

Good choice. (3, Informative)

jericho4.0 (565125) | more than 9 years ago | (#11644233)

There are several reasons why Python is a good choice for such a thing. The Python licence allows any commercial project to embed it without releasing code. So rather then develop a custom solution (ie; UnrealScript), one comes ready made, and complete. And there are lots of reference books about. I did some modding in UnrealScript, and documentation was _very_ hard to find, and incomplete when you did find it.

Python intergrates well with C/C++. Amazingly well, actually, and I think any C/C++ coder should go through the tutorial [python.org] , and see what python can do for you. Yes, I know other enviroments promised the same thing before, but Python delivers.

Python is powerful, but easy to learn. Personally, I think we should be teaching kids Python in elementary school. And if it's your first language, you won't get all hung up on the whitespace thing.

Anyone coding an app that could benifit from a scripting language needs to take a look at python.

Re:Good choice. (1)

BlurredWeasel (723480) | more than 9 years ago | (#11650263)

Both of my brothers in high school have gone through beginning python class. Just to let you know, your idea is reality at least somewhat (Fort Collins, CO)

Re:Good choice. (1)

SilentStrike (547628) | more than 9 years ago | (#11656476)

So what do you use to bind Python and C/C++? I tried using the Python/C API and that was damn painful. Python is my favorite language, and I can code well enough in C++ to make it to the ICPC world finals, but I honestly struggled through making some very simple binding between C and Python. It's much nastier than programming in vanilla C. It seems to combine the worst parts of both C and Python.

Re:Good choice. (1)

kraut (2788) | more than 9 years ago | (#11666022)

If you're using C, you can use SWIG (http://www.swig.org/)to automatically generate Python bindings. Well, some manual work is probably required if you go beyond the trivial, but not that much.

Sadly, SWIG breaks for more complicated C++ stuff, so you're better off using boost::python (http://www.boost.com). Very nice.

Re:Good choice. (0)

Anonymous Coward | more than 9 years ago | (#11695986)

Another alternative is Pyrex [canterbury.ac.nz] ; Pyrex is essentially Python augmented with C data types.

Great News (2, Interesting)

boeserjavamann (655642) | more than 9 years ago | (#11644775)

I really like Python, its a well designed language (ruby would be the best non-typesafe language, but the syntax sucks a little in the eyes of a java freak :)) and its increasing popularity (check http://www.tiobe.com/tpci.htm) is surely a good point for using it as a modding language.

CIV 4 is also using Python (3, Informative)

ShaggusMacHaggis (178339) | more than 9 years ago | (#11645346)

Sid Meirs Civ 4 will also be using python and xml for its scripting language.

Python Ideal for Game Logic (4, Interesting)

MiceHead (723398) | more than 9 years ago | (#11645766)

We've used Python in a few projects, from a relatively simple action/puzzle game, TapDown [dejobaan.com] , to a larger, multi-user game [dejobaan.com] . As jericho4.0 points out, it binds well with C, so for both projects, we wrote C/Python binders for the Fastgraph [fastgraph.com] graphics library and the BASS [un4seen.com] audio library. I find that it's much easier to prototype in Python than in C, so, for example, when we wanted to implement a modified Perlin Noise algorithm for the larger project, we modelled it in Python first, then optimized the processor-consuming bits by implementing them in C.

I'd jump at the chance to use Python as a the scripting language in a first-person shooter. The Conitec engine [conitec.net] uses something called C-Script, which is nice, but not nearly as sexy as Python is. Some drawbacks come to mind, (just off the top of my head, it may be tricky to have an entity sit around in the middle of its script), but its ease-of-use, combined with the simplicity of dropping down to C for the lower-level stuff makes it very appealing for all sorts of games.
_________________________________________________
Inago Rage - Create, fight, and fly in a first-person shooter. [dejobaan.com]

TOOWTDI (0)

E_elven (600520) | more than 9 years ago | (#11649591)

So there will be one single mod, ever?

The language doesn't matter... (2, Interesting)

Cap'n Steve (771146) | more than 9 years ago | (#11650022)

...it's the documentation that's important. Look at all the great stuff made by the bf1942 community, and then realize that until the release of Battlecraft 42 (which was actually created by a modder, who was then hired by DICE, which delayed his tool for months), there was absolutely no help from the developers.

If you read some of the first posts on the modding forums, it's mainly people trying to figure out the format of the level archives and then write a program to extract them.

We've heard that one before (1)

Snaller (147050) | more than 9 years ago | (#11651159)

Not about the python, but about the modding tools, they kept promising it for Battlefield 1 and people waited and waited and waited and waited and waited and waited and waited and waited and waited and waited ...
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?