Please don’t do this. It represents a dead end that will only use up development time that could be applied to what I would consider “proper” modding support.
INS is creating a game called Battlescape. To create it, they have to create ship objects, station objects and so on. Each such object will have certain capabilities. Properly done, those objects are composed as in an object-oriented fashion with properties, methods and events. Standard software development stuff.
Now document and publish the properties, methods and events. That’s your modding environment. Everyone who can write .NET code can modify the game.
INS wouldn’t publish the .NET code for Battlescape itself, but they would publish the interface for accessing the same objects that were used to create Battlescape. Modders could then either add new code that runs on their Battlescape server, or they can whole new games. The new games would all be space games, and be limited to the assets that INS created for Battlescape, but the rules of the game would be of their choosing.
INS wanted to sell their engine. Nobody went for it. But if you create another software layer on top of that engine, one that doesn’t require as much expertise, then you’re covering a whole lot more ground. And the beauty of doing that is that each game created using Battlescape’s modding capabilities is another reason for people to buy Battlescape.
This is the Bohemia/ARMA model and I consider it to be genius. Bohemia would probably have sold a couple thousand copies of ARMA if they didn’t have modding. Their basic game is just a single-player campaign worth about 10 hours of gameplay. It’s pretty much an aside to the real reason that people buy ARMA, which is to play on the modded servers. Single player, multiplayer, cooperative, competitive, you name it. People have cranked out countless game modes. And ARMA has sold countless more copies of the basic game as a result.
INS could certainly create a configuration file with specific options, and they’d have to implement each of those options. Such a system would require even less expertise on the part of the person doing the modifications, but the payback is just as limited. You’d have lots of simple variations on a theme instead of enabling talented people using the Battlescape building blocks to produce results that people are really drawn to. Results that people who wouldn’t play Battlescape itself would buy a copy of Battlescape to play.
Consider the videos that @SpaceJay has created for Battlescape. That’s work that somebody did for free. It saved INS the need to do it, it enhanced the appeal of the game, and it’s better than anything they can do - if for no other reason than they don’t have the time to do it.
I’d never buy ARMA to play ARMA’s campaign. I don’t care about that at all. I also wouldn’t buy it to play countless modifications of the game. But there is a game mode of ARMA that was created a few years ago that I really enjoyed called Invade & Annex. It’s a cooperative multiplayer game mode. I enjoyed it so much that I played it for a year or two, then worked with another guy to create a similar cooperative multiplayer game mode called Strongpoints. It’s a full-fledged game built using Bohemia’s miliitary game building blocks. Soldiers, tanks, aircraft and so on.
Note that INS should not duplicate Bohemia’s awful implementation. Bohemia created a custom scripting language that isn’t object-oriented at all. There are thousands of operators that work on their various in-game objects, and they have a complete mishmash of notations. The only data structure is the array. The only development environments for it are fan-made - because Bohemia didn’t piggy-back anybody else’s work.
The one thing that Bohemia’s implementation does provide is security. You cannot write code to run on a player’s client that will just go around deleting the player’s files because there is no way to express that in their scripting language. In contrast, if you let loose with .NET, then custom code on the client could do anything it wanted to your machine - unless there are ways to sandbox the client. Last I heard, .NET was removing whatever support they had to address this issue and I haven’t looked into it in a while.
If INS goes with a .NET object model, then people can use free Visual Studio tools to crank out .NET code. There would be a development environment that would really help people to crank out new functionality based on the Battlescape object set. Certainly all the existing open source .NET code and help sites (e.g. Stackoverflow) could be brought to bear on adding all sorts of things to the Battlescape environment.
Where this leads is that INS sells not a generic game engine or a specific game, but instead a toolkit for creating any number of variations of a genre of game. It can almost be thought of as a game engine in game clothing.
I’ve been modding ARMA for the past year and I’d be more than happy to provide details to the INS folks about my experiences there.
and sorry for my english too ^^ ) , there are a lots of creations like this one ( or better