Ofp2 - source code release

[-style- 0]

Before I start, I would like everyone to know that I am not a very good programmer.  I know basic C++ and Java.  I am primarily self taught and do not know most of the proper terms and names in programming.

I have some experience modding FPS games.

I've modded/edited Half-Life, Jedi Knight 2, Tribes2, OFP, and several RTS games.

Currently, when I have free time I work on learning to use OpenGL.

I'm working on making a simple 3d game (flight sim or RTS).

I have it loading a heightfield off of a uncompressed 24 or 32bit TGA file, then break it into a quadtree.  Right now, I am working on getting the quadtree nodes to overlap at the edges to prevent gaps.

Thats all off topic though, just to give you a idea of what programming experience I have (not much), so if I make any mistakes in this post, please tell me so I can correct them.

Also, I don't want to see anyone attacking me on the grounds that I have not been a important member in the FPS modding communities.  I haven't had the time or skills to be able to join any MOD's or really publish my work.  I don't want to make a commitment I can't keep.  I just enjoy editing games on my own time, and I hope to be able to release a real MOD or join a team sometime in the future.

------------------------------------------------------------

I know that this topic has already been covered here, however, this was in only one thread.   It reached about 20 posts if I remember correctly, and this issue was not thoroughly(sp) discussed.  It was decided that a source release would add to cheating, and the discussion ended.

I would like to start a good discussion about OFP2 source code release.  I believe that with the input/support from leading modders, moderators, and the community, BIS will consider releasing source code for OFP2.

If you see problems with a code release, tell us.  Tell everyone about the good and bad effects that you think a source code release will have.  I want a good debate on this subject in the hopes that BIS will listen.

I know that this is a _huge_ post, and that the majority of you won't read it.  I'm just trying to fully explain  this, for those who don't know much about this, are unsure, or feel like reading a small book...

I apologize if this is difficult to follow for non-native English speakers,  I'm not a good writer.

If you don't read it, here's a quick summary:

OFP2 partial source code release will not make it easier to cheat.

There are only a couple of downsides to a partial source release, and a lot of huge benefits.

We'd be able to do pretty much anything in our MOD's, change AI, change flight models, make damage models, whatever.

Whatever BIS doesn't put in the game, we'd be able to add.

(only for gameplay, we wouldn't be able to tweak the engine or graphics)

------------------------------------------------------------

The release of source code for OFP2 modding is one of the best and most important things BIS can do for the OFP community.  It will allow us to make much better MOD's, and it will let us create/tweak/MOD thousands of features into our OFP2 MOD's that we otherwise couldn't have created.

I have noticed that many of you believe that a OFP2 source release would be bad, your primary argument being that it would make it easier/possible(!) for crackers to create cheats and hacks for OFP2.

This is incorrect, a source release would not make it easier to cheat, for several reasons.

First of all, there are several types of source code releases for FPS games.

With a "Total Code Release", all of the game's C++ (java, C, whatever) source code is released to the public.  Obviously, these releases would make it a little easier for crackers to make cheats for the game.

http://www.gamedev.net/directory/links/category.asp?catid=24

However, a game developer does not need to release all of a game's source code in a code release.  For example, with a "Partial Code Release", the developers would release only some of a game's source code.  This is what Valve did with Half-Life, and is probably going to do with Half-Life2.  

http://www.valvesoftware.com/hlsdk.htm

Lots of games have partial source releases.  JK2, SOF, RtCW, Serious Sam, Quake3, UT2003, etc.

http://www.3dgamers.com/news/class/source/

Cheaters can't use the released code for cheating in a partial code release, there is no net code, rendering code, or anything they can pervert for their purposes.  

You could look at a partial source code release as a _highly_ advanced scripting system (easier than actually making a scripting system too) that lets us change any gameplay feature.

I believe that BIS could easily do a partial code release for OFP2, like Valve did with Half-Life.

For those of you who haven't played Half-Life, or don't know much about it, this is how Half-Life works...

------------------------------------------------------------

With Half-Life, the game's source code is broken up into three main areas.

game.dll (name varies)

client.dll

engine (lots of files)

The game.dll file contains code controlling the weapons, monsters, in game objects, player, and game rules (scoring/respawning/gravity/etc).  This is open-source.

The client.dll file contains code controlling some client side effects, such as the HUD, VGUI menus, and particle effects.  There is no code to control the actual rendering of the game here.  This is also open-source.

The engine contains the rendering, netcode, core engine code (object lists, bsp code, file loading, collision detection, major physics code, etc), main menu, and anything that isn't in the other two areas.  This code is completely closed, only Valve has this code.

First I will explain how Half-Life MOD's work, then why you can't use the released code to cheat.

Half-Life MOD's are stored in subdirectories off of the main Half-Life folder.

(C:\whatever\Half-Life\myMOD)

All MOD content goes in here, such as the new game.dll, models, and maps.

The original Half-Life content is stored in the valve subdirectory.

(C:\whatever\Half-Life\valve)

When you run Half-Life, the engine will boot up, and load the main menu.

When you load a MOD (from menu, or command line param), the engine will then load the main menu background and extra menu options from that MOD's folder.  The game.dll, client.dll, and all game content is loaded as you initialize a game (join/host).

When you run a MOD, it will check it's subdirectory for any game files it needs (maps, models, etc).

If it cannot find the file(s), then it will check the valve subdirectory for that file.

Note: as far as the engine is concerned, the original Valve game is the same as any other MOD, it just gets picked by default if other MOD's aren't specified.

Say you attempt to join a online game with "MOD-A" loaded.  If the online game is running MOD-A, everyone will be happy.  (checksums and stuff are run to help prevent cheating).

If the server was running "MOD-B", the engine will load MOD-B and then attempt to join, if you don't have MOD-B, you'll be informed and cannot join the game.

There are MOD's known as 'server-side' MOD's.  These MOD's do not require any special game files, and use the normal Valve models and maps.  When you join a server running one of these MOD's, it will play with different game rules than normal Half-Life, for example, the shotgun might shoot explosive shells, and the "MP5" could function as a semi-automatic sniper rifle.  Essentially, you are joining a game running a small enough MOD to download it on the spot.  If the MOD requires a client.dll, or special models, then you must download it and install it manually.

The released code does not make it easier for people to cheat in Half-Life.

For example, if you try to join a Half-Life server with a modified game.dll, you will get errors and be disconnected.  Same thing with the client.dll.

I do not even know if having a game.dll on your PC is actually necessary to join a game, because the server uses it's own game.dll.  The server tells you how fast the weapon fires, how much health you have, and how much ammo you have remaining.  Even if you made weapon fire requests way faster than you are supposed to, the server won't let you fire any faster than it's game.dll allows.  It tells you if you have shot the weapon, hit the enemy, or taken damage.

I think that the only purpose for having the game rules on your machine might be to do client-side prediction, and possibly to aid in interpreting the server communications (simplistic example:  what would 'rocket at location xyz' mean to you if your copy of the gamerules had no 'rocket' objects?), I believe it controls some precaching type stuff as well.

Lets assume that somehow you got past all the mismatch errors, checksums, and all the other things that prevent you from playing with modified game.dll and client.dll files and somehow managed to play with a modified client or game.dll.  (extremely difficult imho, but for the sake of the argument...)

Your "god mode" code wouldn't work.  Why?  The server controls everything.  If you try to jump or shoot when dead, the server won't let you, and you won't move.  

So you code it to allow players to run super fast?  Your prediction would be off and it'll look like some major lag to you, you think the players zip across the rooms, they don't, they see everything normally.  You may see yourself run super fast, but you'll get that lag effect as the server tells you you're way back in a different room, and puts you back there.   The game wouldn't be affected for anyone but you.

The client.dll?  All it does is control the HUD,  your in-game menus, and sometimes some fancy client side particle effects (stuff that you can turn off in the graphics menus anyway).

Again, even if you got through the checksums and other anti-cheat measures, what would this do for you?  You might be able to have a different in-game menu, or HUD, but what would that do?  So your health bar would be in the upper right corner, or, you may make yourself a "choose spawn weapon" menu.  You still won't spawn with those weapons.

You could possibly code it to show yourself as killing everything in sight, that still doesn't help you because the server doesn't think you can do that, you'd still function normally as far as anyone else is concerned.  The other players will laugh at you, because you'll be stumbling around shooting off into the air, and walking into walls.

//(!)

However, if you made your own server-side MOD and hosted a game, but tricked people into thinking it was standard Half-Life, your cheat attempts might work.

You would basically be playing a MOD with unfair game rules, maybe with something like this in the player spawn code:

if (player.name == "cheater")

player.health = 100000;

else

player.health = 1;

This type of cheat is very, very easy to defeat.  All the developers would need to do is make it obvious that the server is running a MOD (could have the MOD name next to the server name).  For example, if you see a server with it's MOD name set to be "Normal 0FP2", while it is obviously running a MOD (mod icon/colored server name/etc), you'd know something strange was going on and hopefully stay away from the server.  However, I have never encountered this with Half-Life or any other FPS game, I believe there are other mechanisms in place to prevent this.

//(!)

Remember, the MOD's themselves almost never release their game.dll and client.dll code.  While it is just modified Valve code, you can see how much has been added and changed with MOD's such as "Counter-Strike", "Natural Selection", "Day of Defeat", and "The Specialists" (hey, TS has working slow-motion in multiplayer games.  The timer code for Half-Life is part of the engine (closed source) as well, its not something simple like just tweaking the time compression, as in OFP scripting).

So now you don't have the game.dll and client.dll code to use when you attempt to cheat at a MOD, like Counter-Strike, but people still manage to cheat, right?

As far as the cheater is concerned, Counter-Strike, Day of Defeat, and all those other MOD's  are closed source games.  The only open source MOD I've ever seen is "Open Source Jail Break".

------------------------------------------------------------

Here is some stuff on how people really cheat.

Note that none of this has anything to do with the released source code.

http://www.counter-hack.net/content.php?page=typesofhacks

http://www.counter-hack.net/content.php?page=howhackswork

http://www.counter-hack.net/content.php?page=halflife

http://www.3dactionplanet.com/features/editorials/speedcheat/

http://www20.tomshardware.com/game/20030517/index.html

http://www20.tomshardware.com/game/20030517/cheating-01.html

http://www20.tomshardware.com/game/20030517/cheating-03.html

------------------------------------------------------------

------------------------------------------------------------

I believe that BIS should follow Valve's example with OFP2.  It will allow us control over nearly every aspect of the game in our MOD's.  We would be able to change the flight models, code more advanced AI, and improve the game in numerous ways.  How about a working OICW/SABR or OCSW?  Can't do that with scripting.  I've created a simple OICW airburst grenade for Half-Life, pretty simple too.

http://www.geocities.com/random_number54321/

I have thought about this some, and a partial source code release might hurt the modding community a little too, though the benefits far outweigh the drawbacks.

How?  It could drastically change the structure of the OFP modding community.  This may be good, or bad.  "Addons" might not work in the way they do for OFP1.

More formal "MOD teams" would likely be needed (good and bad).

------------------------------------------------------------

My suggestion for OFP2:

Remember, this is a suggestion, I know there would be a better way to do this.  Just think about this general idea.

Break code into two modules

game - contains weapon code, player code, game rules, all in-game-object-code, higher level user input.  Maybe even some base physics and collision detection/time compression code.  Also has non-essential client side code, such as the map, compass, watch, action menus, etc.

engine - rendering, net code, file system, collision detection/handling, main game loop, direct user input, all that stuff.  Tracks all objects the player is aware of, stuff that could be used for cheating.

Obviously, game code would be released to the community, while engine code is not.

My idea on organization:

c:\whatever\OFP2 -main directory, contains engine files, stuff like that

c:\whatever\OFP2\bis -default directory, contains BIS code, models, maps, etc

c:\whatever\OFP2\mymod -my mod directory, contains mymod code, models, maps, etc

Basic scripting in addition to the code release would help some as well.

For example, the current scripting system, or even a simpler scripting system, would allow for mappers to create basic stuff in their maps, such as spawning troop formations and moving them around on a large scale, area triggers to kill a player leaving combat zone, simple stuff that shouldn't need it's own MOD.

(MOD's could introduce their own unit-states and scripting commands too)

------------------------------------------------------------

While it may be easier to have the weapons/vehicles hard-coded into the game code (Thats what I would want do.  Easier for programming modders), instead of included in separate text files, it would be possible to keep a addon system similar to OFP's through the code release if that was desired.

Addon vehicles and weapons could probably work similarly to what is available now.  The addon could be created and distributed with it's own text file describing how it behaves (hp, speed, what OFP has now).  This would allow it to be dropped into non-MOD specific maps and used like addons are now.

Again, MOD's could introduce their own unit attributes (something like "wheel durability", for example).  MOD specific addons could then use these attributes, and would probably be placed in the mod's subdirectory to avoid confusion with standard/generic OFP addons.

The standard/generic OFP2 addons could be used in MOD's with new code too, simple "default standard wheel durability" fields in the MOD code would fill in new attributes based on the vehicle type (APC/truck/etc).

Generic addons could go in a C:\whatever\OFP2\addon directory.

This would allow mappers who don't want to learn C++ to easily make maps utilizing non-standard vehicles/weapons.

------------------------------------------------------------

Another point I know someone will bring up.

I know that the code and comments won't be in English, but thats fine with me.  I can cope with that.

It should be pretty easy to make a program to translate the code if it was needed anyway.

Just a simple loop through all the code, replacing 'riffle' with 'rifle'.

Repeat with different terms until satisfied.

I also know that it might take the BIS coders a couple weeks to change the structure of their code to allow for a partial source release, however, this shouldn't hurt OFP2.  It is being release over a year from now, right?  BIS has plenty of time to make this change...

(the sooner the better, of course, but they do have plenty of time...)

------------------------------------------------------------

With a decent partial source code release, we will be able to do almost anything in our MOD's.

We could make functioning OICW's, we could allow passengers to fire their weapons from moving vehicles, and use BMP firing ports.  We could make realistic aircraft, functioning AV-8B Harriers, V-22 Ospreys, and more.

Want a working aircraft carrier, that you can drive, spawn planes on, reload at, and sink?

Realistic parachute physics if BIS doesn't add this, 'sqaure' chutes too...

We could make those "Micro-Air-Vehicle" remote control airplanes, and let players stick them in their packs and use them at will, could even add battery/fuel functionality.

We could make a decent Mechwarrior style MOD if we wanted, with animated walking Mechs, cool damage models, and more.

We could add weather, animals (some people seem to want a "Deer Hunter MOD"), usable trained guard dogs, whatever we want.

With some work, we could make highly advanced soldier and squad level AI that defeats the player through tactics, not reaction time/computer advantages.

Without access to collision detection/handling code this might be hard, but we could tweak it to allow players to walk around in the back of moving vehicles if BIS doesn't code this for us.

A whole lot more would be possible.

------------------------------------------------------------

Partial source code releases are fast becoming standard for FPS games.

By the time OFP2 comes out, it will be abnormal for developers to not release some code.  Heck, Relic is releasing source code for their new Homeworld2 game _engine_ (RTS), this was a huge suprise for me...

Look at Valve, their success is only due to Counter-Strike.

Without Valve's code release, Valve would have crashed, and no one would know who they were.

I suggest that you download and look at Half-Life's source only SDK.

You'll see how capable it is, without making it easier for cheaters.

http://www.valvesoftware.com/hlsdk.htm

I'd like to see all the constructive criticism you guys can come up with.

Especially people with programming experience:  If I made any mistakes explaining Half-Life or programming stuff, please correct me.

Obviously, be careful if you use the quote function.

[canukausiuka 1]

Wow, that must have taken a long time. I did read it all, and it makes sense, but it's BIS's call. I'm buying the game either way

It really does sound like a good idea, but I imagine that BIS may have some misgivings about it. But good job putting that together anyway. Long posts usually ramble, know what I mean

[ralphwiggum 6]

just for connectivity between threads,

the old thread(now closed)

[whisperFFW06 0]

Problem is : OFP2 architecture.

Does it resemble to HL architecture? Can it be broken into the same parts, with the same effects?

Seeing JIP netcode issues, scripting system and how it handles in MP, I bet OFP architecture (and OFP2) is nowhere near HL and other classical FPS.

And partial code release could very be the entrance for cheaters. No one can be sure.

[Jinef 2]

Well, remember we are dealing with the OFP community here.

Most of us are not small kiddies who think that if they cheat they will have more fun. Most of us probably play in little groups of people that we know quite well and one of us cheating would be extremely detrimental to the individual more than the people around him. I think a partially open source code is a great idea, if cheaters could be found to exploit it then the community could find a way to block it.

I think that on the whole the OFP community is against cheaters and would not let them ruin the game community if people found it advantageous to cheat, but then i mostly play COOP, the thing that annoys me is clown faces, that screw up my screenshots and immersion.

Maybe i just don't understand the whole concept of cheating yet, i have never experienced it in OFP, all pvp is with and against people i know and all else is coop. I would much prefer to have a fantastic SP game with hundreds of very good innotative additions and great gameplay, a superb multiplayer game with all this with the little community i know and then the occasional public PvP game where someone decides to make himself a 900 round magazine just to look good on the kill ratio.

Btw, you guys who play PvP, the best way to 'train your reflexes' is to play a good coop with difficult unit placement and super AI.

[whisperFFW06 0]

Well, some see OFP MP other than you, and use public servers. And it's a world where cheaters exist. I had to ban one last week, damn CS kiddies!

I'm like you, I do prefer coops and PvP against known pple/friends, but we are not the whole community. A whole lot of pple are open to public playing.

BTW, it seems that OFP2 MP will be more "public server" friendly, with features like JIP. With the OFP editor, this would permit some incredible permanent, non ending mission, I can't even imagine it. Cheaters in such missions... and everything is just f*d up.

[-style- 0]

Thanks for the replies.

I understand that the OFP2's architecture is probably very different from Half-Life's. Thats why I estimated several weeks to make the change to a partial source release format.

Unless the BIS coders are extremely stupid, the 900 round magazine cheat wouldn't work, even with a full source release.

With modern FPS games, the client never controls any important variables such as health or ammo. If this info is stored on the client, the client can change it, even without having source code.

Servers never trust what the client tells them.

Old games, like Doom and Quake1 had a problem because of this. I haven't heard of any games that stored these variables on the client for a long time.

I think that the problem with a full source code release is mainly that it leaves the whole netcode and rendering code open to these crackers that make cheats.

------------------------------------------------------------

Again, crackers don't use the released code to make their cheats. For the most part, I believe that they edit the exe in assembly, connecting it to their cheat programs.

I've done a little research on this, I won't post any links for you, but I suggest you do some research on your own. You'll be surprised at how easy it is to find this information.

I'd advise you to stay on trustworthy sites, whitepaper type stuff.

It seems to me that most 'cheat' sites are populated by script kiddies and hacker-wannabes. These people tend to try to damage your system using exploits and security holes on web browsers. You can usually tell what kind of site you've found from the description/snippet that yahoo/google will give you.

You should also read the links on cheating I posted earlier, they do a good job of explaining cheating for the basic player.

------------------------------------------------------------

I encourage you to download the Half-Life source only SDK and take a look at it. You don't need Half-Life to look at the released source.

http://www.valvesoftware.com/hlsdk.htm

As always, any good, thought out, feedback will be appreciated. Support is appreciated too.

[-style- 0]

No one has anything to say?

I'd appreciate it if a couple of you would post a opinion on this, you don't need to read the whole thing, I made a quick summary in the original post.

Scripters: don't you realize that all those scripting requests would be unnecessary if code was released?

Ralph "connectivity" Wiggum, no opinion?

Suma, you've at least glanced at this post, could you give us a answer? Any thoughts? yes/maybe/no/hellno? w/short explanation? anything? please?

I've let this thread sit for a couple weeks since I've posted last. I'll just let it die if no one shows up, but I'd at least like to see some interest in this.

Still looking forward to OFP2, even if we can't mod it.

[Acro 0]

I think that the source code of game is like a art work. If I had been working hard with this art work I wouldn't just give it away to be modified. Maybe I am bit selfish but...

Good long post btw. It was interesting to read.

[deathguy 0]

really nice post you did there -style-

I agree totally with you and would encourage too BIS to get a partial source code release for OFP 2.

[suma 8]

Quote[/b] ]Suma, you've at least glanced at this post, could you give us a answer? Any thoughts? yes/maybe/no/hellno?

No.

We do not plan source code release, as this would create significant security and copyright risks.

We plan to provide extensibility via scripting in OFP2, as with OFP (the scripting language will be much enhanced, though).

[Lt_Damage 0]

Sounds fair to me

[-style- 0]

Oh well, it was worth a try.

Thanks for the answer Suma.

I'll guess you won't come back, but have you looked at the Half-Life partial source release, or any other game's partial release?  

Quake3,2,1, JK2, Serious Sam, a lot of other games have had partial source releases too (some have had full source releases since then).  I just use Half-Life as an example because everyone (+/- 20 people) has seen it, and the Counter-Strike mod saved Valve...

I'll admit, I don't see security risks in the way Valve or the other companies handled it, but I'm still a newbie programmer.

Good luck with OFP2, still looking forward to it.

[Guest]

Well that's fair enough I think. Just make sure your Network is secure Suma....unlike certain other game companies that shall remain nameless  

[deathguy 0]

and the Counter-Strike mod saved Valve...

well anyway, I don't see why BIS would need to be saved, like HL was great because of CS, OFP is great because of OFP, and I don't think that OFP2 will need a mod to save is butt since i'm pretty sure it will be so great like the first that it's gonna make some big noise everywhere around the world

but I still agree on your argumentation -Style-

[GabKa73 0]

Sorry to wake this old thread but I was just roaming around and stumbled in here.

I just want to point out that comparing games like Half-Life or Serious Sam with ofp or ofp2 is absolutely pointless. The games you mentioned all have extreme limitations (small maps, stupid AI, no controllable AI, no real vehicles, the list goes on and on and on ...) and modders probably need parts of the source of these games to get things done that haven't been seen in the original game.

OFP is scriptable and pretty much open enough to get things done you haven't ever seen in any other mod of any other game (let's just wait for ofp2 - I'm sure it will still be the modders heaven). Look at RTS3, MFCTI, FDF, CSLA, some custom campaigns and the trillions of single addons.

You don't have to release ANY source code if you make your game realy modable out of the box.

And think about this one: For ofp (and sure ofp2, too) you don't need to know anything about programming, compiling, etc to get a real mod/addon done.

Sorry again for the late post, but I sure would have posted this earlier if I had known about this thread before.

[hellfish6 7]

I'll allow it... you added something worthwhile.

[wolfbane 0]

I don´t think there need to be a partial engine source code release for Ofp2 to be highly modifiable. I think there´s another way to do it without exposing the underlying code and prevent the copyright problems.

Here´s my idea:

Besides a powerful scripting system with predefined functions like ofp has today you could have an api (in the form of special header- and library files much like the directx api) to get access to some more advanced parts of the game engine, like physics, ai etc. This could be used to create plugins in the form of dlls for the game.

The dlls could contain custom userdefined functions to alter physics, ai, effects and object properties etc all via the interfaces/functions provided by the api. This could be used for example to overload ai functions with custom ones to get different ai. The usercreated functions in the plugin could also be tied to scripts via some special scripting functions to get access to the new functionallity of the game that the plugin provides. These new custom functions could then be used in the same way that we use the predefined script functions in ofp today.

Maybe it could look something like this when you create a plugin using the api and tie its new function to a script. I´m not terribly good at programming but i hope you get the general idea of it..

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

------------------------------------------------------------

// MyPlugin.h

#include "ofp2api.h"

class MyPlugin : public Ofp2Plugin

{

 public:

           MyPlugin();

           ~MyPlugin(void);

           SomeCustomFunction();

 protected:

           IOfp2Api m_Ofp2Api;

};

------------------------------------------------------------

// MyPlugin.cpp

#include "MyPlugin.h"

MyPlugin::MyPlugin() : OfpPlugin()

{

 m_Ofp2Api = GetOfp2Interface();

}

MyPlugin::~MyPlugin()

{

}

MyPlugin::SomeCustomFunction(Ofp2Pos position, int numparticles)

{

 for(int i=0; i<numparticles; i++)

   m_Ofp2Api->CreateParticle(position);

}

------------------------------------------------------------

// SomeScript.sqs

particle = GetCustomFunction("myplugin.dll","SomeCustomFunction")

particle(getpos player, 10)

exit

------------------------------------------------------------

[GabKa73 0]

Great idea, I really think that future games will be more and more open in that way (on the long run, since games like Far Cry or Doom III are more a step back than something progressive in my opinion - just analyse the gameplay mechanisms, especially in MP - it looks like they have only concentrated on the looks and totally skipped gameplay. And they still need to release an sdk, how stupid).

I believe that BIS made a step in a direction with its open type of game, thats potential is not fully realized yet by the games industry.

Let the player decide how the game looks like and how he wants to play it and let him work with it. That will keep him around and he will not put it back on the shelf after a couple of weeks or months (I don't think I'll play Far Cry again any time soon and I definitely won't buy joint ops or söldner without major changes to their general gameplay design).

I'm really looking forward to how BIS is gonna make it with ofp2.

[shinRaiden 0]

Certain widgets like the Immersion Foundation Classes (IFC22.DLL) and such DirectX/DirectInput libraries are licensed components that would not be openable.

Another good example is the quake2 sdk system. That's how half-life came to be anyway, and that is a wonderful way to learn how to code. In Quake2 dev, there was a couple mod groups exploring a similar plugin structure where the gamex86.dll could be split into a set of modular plugins. I don't think they got very far because of RL issues.

Anyway, right now we're seeing some serious fragmentation of unique mod's using incompatible config.cpp's and such. My concern is that an open SDK could easily exacerbate that problem.

Implenting a plugin system with an open API in OFP could be beneficial by allowing different developers to create targeted plugins, similar in fashion to how we currently add objects to root classes.

While this may sound good in theory, considering the fights over to JAM or not, I expect that there would be as much avoidance of standards commonality with an open SDK, as there is without, which would negate the entire intent and purpose of the exercise.

On the other hand, I'm not familar with the internal structure of the OFP engine and development of course, and I could justifiably presume that there is IP sensitivity in regards to physics and AI modeling and methods.

The other difficulty is that to effectively explain why a component will not work would likely require an explanation of how that component works, which would involve function disclosure.