Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

Extensions rework #38

Open
wipe2238 opened this issue Feb 4, 2019 · 0 comments
Open

Extensions rework #38

wipe2238 opened this issue Feb 4, 2019 · 0 comments
Labels
enhancement New feature or request extensions Things related to game extensions (.dll/.so)
Milestone

Comments

@wipe2238
Copy link
Member

wipe2238 commented Feb 4, 2019

What?

Replace using dynamic libraries, loaded on demand, with static libraries linked with core applications.
Keep a clear line between engine and game code; extensions must be possible to use without manual changes to any part of engine repository... and if it does need them, it's no longer an extension, but a candidate for a pull request or fork.

Why?

  • Simplifies engine changes
    Even smallest reordering in any public part of script classes (Critter, ItemCl, etc) requires FOClassic.h edits, .dll/.so recompilation, and so on, and so on... additional work for exposing new stuff, fighting OS limitations, bla bla bla.
  • Allows game developers to utilize engine to much greater extend
    FOClassic.h no longer being a bottleneck, allows games to use everything engine uses to function. Starting from not exposed class members, thru direct access to SScriptFunc, helper classes (Text, FileManager), etc.
    Additionally, it opens a way for features which would most likely never go into old system, such as utilizing Debugger.cpp to track game-specific data, customizing game window, adding new datafile formats, custom protocol messages, etc.

When?

v7 forward, interrupting #15 process. I don't have neither time or will to deal with all kinds of .dll issues, so it will go live ASAP.
Extensions are dead, long live extensions.

How?

First version most likely will be pretty close in structure to "old" extensions, with GameOptions* adjusted here and there to keep at least part of old extensions code working as-is. Due to infamous check_look, extensions must be able to consume reserved functions; this have to be addressed by #29.
But. We'll see how it goes 😈

Later, class will be expanded to provide deeper customizations which cannot be done within extensions.

As usual, CMake will be responsible for pre-configuring everything, with CMakeFOClassic.txt being able to not only add, but also remove any item from list. There might be stock extensions in future, but final decision about including them (or not) should be left to game developers. Stock extensions, if any, needs to be enabled by developers.

B-but...

  • Project is open-source, everyone and their cats can modify it at will.
    While it's true, it's not always a smartest move if you want to keep updating engine; own changes will often end with fighting conflicts during bigger reworks. That time could be used to improve the game itself, instead of maintaining "alien" code.
  • It will be harder to write game extensions.
    That's probably true. FOClassic.h made sure developers don't use something they should't; being "forced" to use engine sources it's easier to shoot own foot. It's up to devs to decide if they want to use safety net which GameOptions* will try to provide, or go wild.
@wipe2238 wipe2238 added enhancement New feature or request extensions Things related to game extensions (.dll/.so) labels Feb 4, 2019
@wipe2238 wipe2238 added this to the V15 milestone Feb 4, 2019
@wipe2238 wipe2238 pinned this issue Feb 7, 2019
wipe2238 added a commit that referenced this issue Mar 26, 2019
- initial version of cmake setup for extensions
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request extensions Things related to game extensions (.dll/.so)
Projects
None yet
Development

No branches or pull requests

1 participant