ECO Mod/Plugin System Design


  • Introduction

    ECO is designed to be both a specific simulation in the short term and a platform for simulations in the long term. One key feature required for this is a comprehensive and flexible modding system provided as a first-class feature. Examples of existing mod systems for similar (and I use similar to mean dynamic voxel-style worldbuilding sandboxes) can be found in various stages of development. See the following:

    Forge (Minecraft)
    Space Engineers
    StarMade

    When I say 'first class' I mean that modding is integral to the product, intentionally designed and intended for others to build upon it. Contrast to Forge, which was not designed in to Minecraft and has had to work largely in parallel with and separately from the development of the game itself. A first-class system should have excellent support, deep ability to alter the product and be well documented and easy to use.

    A good modding API is also not just something that is useful to third-party developers. If ECO is a platform and the Mod API is well done, then the game itself can be written largely in terms of mods on top of the fundamental mechanics. That is an excellent test of the modding system

    Framing the Problem

    So we have a platform we wish to mod. What separates the platform from the mods? The platform provides the base functionality upon which the mods build. In ECO, the platform includes such things as:

    • A network communication system for interacting with clients and servers
    • A terrain generation system for providing the initial set of voxels
    • An entity management system for providing non-voxel entities
    • A storage system for persisting game state
    • A visualization system for rendering content the user can interact with
    • A set of built-in behaviors for all of the above
    • A plugin system allowing the game to be extended beyond the above built-in behaviors

    When we speak of the modding system, we are concerning ourselves with the shape of the last bullet point, and ensuring that the other bullet points provide some interface which allows the mod system to alter the behavior of the other aspects of the system.

    Breaking the problem down

    The problem space for what mods could do is effectively limited by ones imagination, but to realistically implement a system, we need to break the problem down into smaller, more limited problem spaces. I'll submit an initial list for consideration:

    Classes of Mods

    • Terrain generation mods
      • Mods of this class alter the way the voxel terrain is generated. For example, a mod which creates volcanoes during world generation would be one. If terrain can be generated once the game is already running (for example a volcano erypting where none previously existed) that might also fall into this class of mod.
    • Block (voxel) mods
      • Mods of this class create new kinds of blocks with possibly novel behaviors. For example, a new kind of stone, or possibly a new kind of fluid. These are distinguished from entity mods in that blocks exist as voxels in the world (even if as in Minecraft they might also have an entity representation in some cases) and generally can be considered part of the terrain and can only exist at voxel-quantized locations. Terrain generator mods may use blocks during terrain generation even if they come from mods.
    • Entity mods
      • Mods of this class represent non-block items in the world, such as players, vehicles, animals, arrows, some kinds of dropped items, and any item which is not otherwise considered part of the terrain.
    • Simulation mods
      • Mods of this class represent the ongoing interactions between entities and blocks in the world. Erosion, pollution, plant growth and propagation, animal population change, etc are all simulations. A simulation mod often depends on specific blocks or entities whose interactions represent inputs to the simulation.
    • UI Mods
      • Mods of this class represent visualizations of the game, typically on the client but possibly also on the server console or a web browser. These also include client interactions through things like the chat window, such as providing additional commands to users or admins.
    • System Mods
      • Mods of this class provide whole new systems of behavior and capability. A mod which allows pulling data from GIS systems on the fly, or one that allows users to record their actions on the server for later examination would be examples of these. These mods may often provide foundational services to other mods (think of the "Liquid API" provided by some mods in Minecraft). An explicit definition of what these mods could and could not do would be beyond the scope of the modding system - instead the mod system would simply provide a way for the existence of these mods to be registered and queried and a way to access their APIs, which would be defined by the mod author. If the other mod classes are limiting the problem space to be manageable, this class is for everything that isn't otherwise covered.

    Each of the above classes will have particular requirements on the API necessary for a mod of that class to be implemented, and this API will differ substantially from the API necessary for mods of other classes. For example, a Block mod will need to be able to provide information about how it is treated in the world vis-a-vis its interactions with other blocks, where its placement is allowed or not, what happens when it is placed or destroyed, if and how it is part of terrain generation, what state must be maintained with it when saved or transmitted and how it is rendered in a visualization. An entity mod has some of these features (visualization and state communication for example), but also must be able to control things like movement and interaction with the terrain and other entities as the entity evolves. As we consider the API, we must consider which behaviors each class would require to implement.

    Mod Life Cycle

    Each mod also has a life cycle which the modding system must support. This means having established startup and shutdown procedures, a mechanism for the mod to save and re-load its state and transmit state to clients if that is necessary. Mods may require other mods in order to function (such as a simulation which requires specific kinds of blocks) and the system must be able to enforce these requirements.

    Security

    Security for mods is a serious concern - a mod author with access to the file system of the host machine can wreak all kinds of havoc. Implementing appropriate security will depend a lot on deep technical details if the system is to provide this functionality rather than deferring to the judgment of the users. I recommend leaving this for a separate discussion except inasmuch as it may influence the design of certain APIs..

    How do we start

    One way to make this intellectual exercise into reality is to spitball some mod ideas from each class and implement them. In some cases, existing behaviors of the system may serve as examples of mods of a given class (like the existing rabbit entity could be an example of an Entity mod, and serve to help define what behaviors that Entity API must expose.) Community ideas and attempted implementations of mods will serve to refine the API over time and bring it closer to the functionality desired by release. The more of ECO which is implemented in terms of the mod API, the more likely the API is to be complete and useful to third-party developers.

    As we go, documentation (even in outline form) needs to make its way to the Wiki for review and use by the community.


  • modding 8 api 3
    7
    Posts
    7550
    Views
    Log in to reply


  • @ChronosWS said:

    Security

    Security for mods is a serious concern - a mod author with access to the file system of the host machine can wreak all kinds of havoc. Implementing appropriate security will depend a lot on deep technical details if the system is to provide this functionality rather than deferring to the judgment of the users. I recommend leaving this for a separate discussion except inasmuch as it may influence the des

    When it comes to security I also ask myself how deep mods should be able to interact with clients...
    UI-Access from Server to Clients would be great. So we can write Server-Mods which for example, implement an health-bar to the clients.
    Or a money-value or any other stats-bar.

    I dont care about the security of server-mods, since I as admin can look into them for my self.
    But stuff like passing full scripts from server-mods to the gameclients would be very problematic.
    Since players could join a modded server then, which could run code on the client machines to download trojans and stuff or
    even transmit local files from client machine to the server or any ip, without any antivirus recognizing it.

    Do you like my mods? I would be thankful for a small donation^^.
    ETH: 0x24d8FCA487EF62d58f0e926c4c7E21B3ca10f782
    Doge: DQrTnvtf8qPe6dzCLZUpbkEAC1DfAsmzHN
    Eco-Coin: EqQQEGe89dgG3F9893rODI (just joking)



  • @R4mbo said:

    @ChronosWS said:

    Security

    Security for mods is a serious concern - a mod author with access to the file system of the host machine can wreak all kinds of havoc. Implementing appropriate security will depend a lot on deep technical details if the system is to provide this functionality rather than deferring to the judgment of the users. I recommend leaving this for a separate discussion except inasmuch as it may influence the des

    When it comes to security I also ask myself how deep mods should be able to interact with clients...
    UI-Access from Server to Clients would be great. So we can write Server-Mods which for example, implement an health-bar to the clients.
    Or a money-value or any other stats-bar.

    I dont care about the security of server-mods, since I as admin can look into them for my self.
    But stuff like passing full scripts from server-mods to the gameclients would be very problematic.
    Since players could join a modded server then, which could run code on the client machines to download trojans and stuff or
    even transmit local files from client machine to the server or any ip, without any antivirus recognizing it.

    From the perspective of types of mods which one can write, I think the notion is that you could write a mod package that implemented client features and was distributed from the server, particularly if the mod had both server and client functionality (think a new animal with special behaviors.) That would include any kinds of visualizations that go along with the mod.

    Security on the client side is tricky. At a minimum we will want to notify people of the presence of mods which would be uploaded by the server before they are uploaded and acknowledgment of the risks involved. From a technical standpoint it would be nice to be able to sandbox the mods, but there are serious limitations on what can be accomplished in the Mono runtime and Unity. We might be able to do some sort of scanning for disallowed API usage (think file system, process execution.) All remains to be seen but we are definitely aware of the problems.



  • I think the best scenario will be for the client to let you know which mods you want and it offers to either auto download them or get the mods and install them yourself.

    Mods will then need to have a versioning system to make sure they are running to proper mod with the proper mod version.

    Security is crucial when it comes to modding a game server and client with auto updates etc.

    If the game auto sends the scripts, to their clients, the clients will be very vulnerable to any kind of spyware or malware.



  • Would it be an idea to offer a central modding platform where mods will need to be reviewed and signed?

    The only problem I would see here is the not very small amount of work in reviewing mods and signing them and then who would be responsible if a security issue hasn't been seen while reviewing the mod?



  • @Klaas said:

    Would it be an idea to offer a central modding platform where mods will need to be reviewed and signed?

    The only problem I would see here is the not very small amount of work in reviewing mods and signing them and then who would be responsible if a security issue hasn't been seen while reviewing the mod?

    What I would envision is that there are basically three tiers:
    "Official Mods" - Mods which are written by or directly approved by SLG, which are tested and known to have appropriate game balance, etc.
    "Certified Mods" - Mods which have been reviewed by the community (probably open sourced) which a server operator can be reasonably certain are ok to use
    "Everything else" - Anything which doesn't fall into the other two categories.



  • @ChronosWS said:

    "Everything else" - Anything which doesn't fall into the other two categories.

    For the last category I would see all mods which can be downloaded anywhere. Maybe with a security warning when enabling them.


modding 8 api 3
7
Posts
7550
Views
Log in to reply

Internal error.

Oops! Looks like something went wrong!