Modding API

Started by
5 comments, last by Xanather 10 years, 8 months ago

I am developing a 2D sidescroller similar to terraria and starbound, after 3 months I have written my own hard coded "engine" for the game that features lighting, tile management, world management, entity management, networking, input, user interface management, rendering, and some others...

My question is how would a modding API be developed, I have a feeling I am too far down the track for such an easy implementation. I am using C# 5.0 (.net 4.5) with MonoGame. This is also the first time of me having a shot at developing a real game, I still would consider myself "newbie".

Since its C# I am leaning towards reflection and importing local libraries, this seems like it would be a security issue however. I do not have much experience with reflection but I am sure I could easily pick it up.

Some technical aspects of that game are:
1. The game is completely server-based, hence at the moment there is no singleplayer mode since start of development has been for multiplayer.
2. Uses TCP for networking.

3. The client and server will be obfuscated, eliminating easy .net decompiled modding.

4. Some part of the game can already be modded only server-side to see client-side effects (even though the client executable was not touched).

5. The server has all authority.

Thoughts?

Advertisement

Why not just give them your code to have at it?

C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.

What kind of mods do you want people to be able to make, and what kind of mods do you want to disallow people from making?

Well, primary the ability to create additional NPC's, add items, add spells/abilities, adding tiles, nothing too big that would require large modifications.


Why not just give them your code to have at it?

I don't want a open source game.

A thought: could runtime code be generated on the spot depending on several XML files containing information about new spells/abilities, etc...? My only issue there would be both sides (client + server) would need to interpret both files differently.

You could go the Elder Scrolls way and provide a powerful graphical editor, plus scripting for more involved modding. No need to expose actual engine's functions.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

C# can be used as a scripting language from within itself, so if you were to integrate a C# scripting framework into your engine then you could implement a lot of your game logic in C# scripts, making it easy for others to modify behavior while being able to leverage the full featureset of C#. The only difference between scripts and your core engine code would be that scripts are compiled at runtime by the engine and executed in their own application domain, among other things, to isolate them completely and help prevent them from doing Bad Stuff. Other data for your game could go in XML, or JSON, or pretty much any other human-readable format that users can modify and extend. If you want to go all-out and write a separate editor, that's also a possibility, but probably not essential for smaller games.

C# can be used as a scripting language from within itself, so if you were to integrate a C# scripting framework into your engine then you could implement a lot of your game logic in C# scripts, making it easy for others to modify behavior while being able to leverage the full featureset of C#. The only difference between scripts and your core engine code would be that scripts are compiled at runtime by the engine and executed in their own application domain, among other things, to isolate them completely and help prevent them from doing Bad Stuff. Other data for your game could go in XML, or JSON, or pretty much any other human-readable format that users can modify and extend. If you want to go all-out and write a separate editor, that's also a possibility, but probably not essentially smaller games.

Yeah, thanks, I will probably go down that route, it sounds like a good idea. Never thought about runtime compilation.

This topic is closed to new replies.

Advertisement