Will Day wrote:
>Okay, let me see if I'm following. It sounds like the basic path is:
>
> compiled plugin <-> titan core <-> game driver <-> game engine
>
>Where:
>
> - Compiled plugins are C,C++,Delphi,Java.
>
> - Titan core provides a generalized API to the compiled plugin, which
> could encompass:
>
> - Game-related hooks (HL's DLLAPI, NEWAPI), ie routines provided by the
> plugin, and called by the game.
>
> - Game-related functions (HL's EngineAPI), ie routines provided by the
> game, and called by the plugin.
>
> - Utility functions (motd?), routines provided by a plugin, and called
> by another plugin.
>
> - Game driver translates the generalized API to the game-specific API.
Yes, this is pretty close. I just didn't think about dividing up the TITAN Core with a Game Driver between it and the game engine. I suppose it would make for re-useable sense. Although, couldn't both be compiled into the TITAN Core, which would be the server-side game engine hook anyway?
>>plugin support (small language) and create a TiTan plugin out of it, which
>>would enable AM plugins to adapt to TiTan. This becomes more of a TiTan API
>>to AM API integration plugin.
>
>So, it sounds like this would then have:
>
> smscript -> amxplugin -> titan core
>
>Where:
>
> - Smscript would be a Small script, compiled into an amx file.
>
> - Amxplugin would be like Olo's AMX Mod?, exposing the Titan API to Small
> scripts.
Yes, this is what I had in mind anyway.
>
>Or do you mean:
>
> AMscript -> AMplugin -> titan core
>
>Where:
>
> - AMscript would be an existing AdminMod script
>
> - AMplugin would be like porting AdminMod to Titan.
>
>Or, I suppose, both. The first is more generally useful, and I guess the
>latter is intended to provide immediate transition to running under Titan.
Yes, to get immediate adaptability, you would need both. Basically, the AMX TITAN Plugin and the AdminMod TITAN Plugin will both be integration translators that re-map the existing API in each to the TITAN API.
>Right, so basically porting them to Titan, while providing the same
>functionality to the user.
Yes. We really want to get out of duplicate functionality. There's no sense why CM should try to add in plugin support when a better solution can be developed. So, with TITAN, the nice config scripting features of CM and the "small" plugin features of AM could be provided and work together. We're all busy with full-time work in RL and spend all this time developing addons on the side.
With more addons duplicating features (e.g. the console MOTD, which can be found in HLG, CM, SM, AM and others) it makes more sense to just pool the resources together and develop a game server addon framework system and then each can code specialized plugins with unique features.
I'm more of an advocate for re-use than reproduction of work. Although, some will argue that this project is re-inventing many wheels, I'd like to refer to it as evolving the many wheels into something more beneficial to addon developers and the server admins.
/me moves on from his rambling...
>There would definitely have to be a decision on how much functionality is
>bundled into the core, versus functionality provided by plugins, with the
>general tendancy to modularize to plugins where feasible.
Agreed. I don't want to over-burden the core and turn it into bloat ware.
>The steps I see are:
>
> - Design Titan plugin API, which should:
> - Attempt to expose existing game engine functionality (HL and others).
> - Also, Idealize a desired game plugin API, which game developers could
> be encouraged to use. :)
>
> - Implement (design, develop, etc):
> - Titan core which provides this API to plugins.
> - Titan game engines for HL and others.
> - Ports of existing Metamod plugins to Titan.
Nice breakdown.
HoundDawg
|