[Cookies.net]

This post is geared towards Developers, there are working plugins, but they're possibly unstable, bug infested and/or feature incomplete, not to mention things may still change, a lot.
Opinions are welcome on the approach this project takes.

Hey guys

So, I've not really been on these forums for a long time, nor have I played TF2 or any other source engine-based games. So I guess it makes sense that I haven't been on here.

However, last week I got bored, got an itch to code and was haunted with thoughts of even more improvements to a plugin structure for my old FF2/VSH replacement, Boss Fight Fortress. Which has now resulted in this.

I've written all this from scratch in roughly 5 days, so on top of not really knowing what's going on in TF2 and progressions, or maybe lack of(?), in these game modes, do expect them to be largely feature lacking.

Roughly 2 years ago I was working on a game mode manager I called Gamma, and my first game mode for it was Boss Fight Fortress. These were meant to replace VSH/FF2 on the servers that I was affiliated with. However, I grew bored of TF2, had other things I rather wanted to do and thus they got shelved.

Anyways, during these 2 years I've constantly been getting ideas for improvements, and as I wrote earlier, last week those ideas started to get written in code.

So, what was the aim I had with this? Extensibility. I wanted it to be easily extensible, and in a way that promoted writing plugins instead of rewriting existing ones to add features, to aid maintenance work for server owners.

This project is split into 3 parts so far, the 2 main components being Definitions and Boss Fight Fortress, whilst the 3rd Gamma could become a convenience for multi-mod servers. A rough overview follows:

Definitions
Definitions is a plugin which manages, well, definitions from other plugins. Definitions are immutable data structures that can derive from other definitions, specializing them. Dynamic behavior in definitions are done through functions, which can be bound to them.

A sample of how a game mode definition could be made:

PHP Code:

creator = new DefinitionCreator("GameMode");
creator.SetFunction("CanStart", CanStart);
creator.DefineFunction("Start");
creator.DefineFunction("Ended");
g_hGameModeDefinition = creator.Finalize();

... somewhere else ...
public bool CanStart()
{
    return true;
} 


As you can see in the above code, we do the following:

1. We instantiate a DefinitionCreator for a Definition called "GameMode"
2. Set a function "CanStart" to a basic implementation that always return true (game mode can always start)
3. Define "Start" and "Ended" as functions, which means we don't fill them with data, but definitions deriving from the "GameMode" definition will have to have those functions set, before their definitions are of use.
4. The creation is finalized, and returns a definition, ready for use. The returned definition is immutable, it cannot be edited.

Something that happens behind the scenes when then definition is finalized, is that since we have some properties that aren't set, the definition is "abstract", not sure if template is a better word though. Just needed something quick, so went with my initial thoughts. Anyway, abstract definitions can be filtered when you attempt the get the child definitions, and they can also be reported as not valid when checking for Definition validity.
This allows to create definitions that provide functionality, but not necessarily complete usable functionality. This is useful when you have some very similar things, that could share a lot like multiple Boss game modes. Or when you have some somewhat similar things that could use the same bootstrapping, such as game modes.

Gamma
Gamma is, well, a Game Mode Manager. Nothing fancy here, it just does what it can to manage game modes, while keeping them from interfering with each other.
Gamma also needs something known as a "Round Manager", it's a plugin that tells Gamma when new rounds start and stop, without one Gamma will not function. The reason for this, is to easily provide support for other games, or create improved round management.
I prefer hooking "RoundRespawn" and "PreviousRoundEnd" for round start/stop respectively in TF2, but didn't add it at this time yet.

And lastly, the things that is most interesting on this sub-forum...
Boss Fight Fortress
Boss Fight Fortress is meant to be a highly extensible Boss game mode, and so far I think it does it very well.
It is implemented as a Gamma game mode, and relies heavily on Definitions it self.

Boss Fight Fortress is currently split up, as I said it relies heavily on Definitions, in that there's a base boss game mode definition, which does not provide a working game mode in itself, but instead provides the necessary tools to make a custom Boss game mode. The first being the well-known Boss versus All.
There are plans for a Bosses versus Bosses game mode as well, as I had that back in the days as well.

The base plugin also provides the Boss definition, in fact 2 of them. In order to lessen compatibility issues with other boss game modes, there's a Base Boss definition, as well as a Generic Boss definition. The Base Boss definition is meant to provide an entry point for making a definitions for specialized bosses for a specific game mode, while the Generic Boss definition is meant for bosses compatible all-across the board. Of course, whether the game mode creates it's own specialized definition, or ignores the Generic Boss definition is completely up to itself.

Final words
It's getting a bit late where I am now and I'm starving, so I'll stop writing now and say that you can ask me to any questions you have about this.

More over:
I'd like to know if this is something that you would be interested in as a possible replacement of FF2/VSH. It should be possible to make a Freak Fortress 2 compatibility plugin, once the features are refined a bit more. However, this'll definitely allow for more creativity in bosses than previously seen, if effort is put into it.

I'll be available for information on how all this works, helping with bug fixes and design/implementation of essential features, as well guidance for what I'd consider to be the right way to do things, at least until it has matured enough, but probably "always" to a certain extent.

An example for "right way to do things" is weapon restrictions, which should be a 3rd party plugin that listens to when Boss Fight Fortress starts, and then applies it's restrictions. Even better, it could be config based and work with any game mode that runs through Gamma.


The repositories, for those interested, can be found here:
https://bitbucket.org/CookiesIO/definitions
https://bitbucket.org/CookiesIO/gamma
https://bitbucket.org/CookiesIO/boss-fight-fortress

They're in the order of dependency, there are downloads for SMXs in the downloads section. For external dependencies there's the TF2Items extension and to compile properly you need the compiler shipped with the development builds of SourceMod (1.8).

[sarysa]

Is it compatible with existing VSH or FF2 bosses? Same criticism I levied toward FF2 2.0 and VSH Advanced...if it throws away all the third party work for the existing 5-year old plugin (read: probably thousands of bosses by now with at least a couple hundred distinct ability sets), it will never take off.

Plus, coming from someone who (used to) code for FF2...all but a select few limitations can be worked around if you're clever enough.

[Maximilian_]

just need allow all players pick some abilities, like in dota 2: brave jump, ubercharge, demopan's attack, add balance for abilities and allow all them make backstabbing and etc., in my opinion this will interesting

[friagram]

Originally Posted by sarysa Is it compatible with existing VSH or FF2 bosses? Same criticism I levied toward FF2 2.0 and VSH Advanced...if it throws away all the third party work for the existing 5-year old plugin (read: probably thousands of bosses by now with at least a couple hundred distinct ability sets), it will never take off. Plus, coming from someone who (used to) code for FF2...all but a select few limitations can be worked around if you're clever enough.

It's just a framework, and the effort required to port existing bosses and test them greatly outweighs benefit of switching. Main problem why ff2 has not been rewrittem, and why the newer versions have constant problems.

[Maximilian_]

Originally Posted by friagram It's just a framework, and the effort required to port existing bosses and test them greatly outweighs benefit of switching. Main problem why ff2 has not been rewrittem, and why the newer versions have constant problems.

laziness......

[Cookies.net]

Originally Posted by sarysa Is it compatible with existing VSH or FF2 bosses? Same criticism I levied toward FF2 2.0 and VSH Advanced...if it throws away all the third party work for the existing 5-year old plugin (read: probably thousands of bosses by now with at least a couple hundred distinct ability sets), it will never take off. Plus, coming from someone who (used to) code for FF2...all but a select few limitations can be worked around if you're clever enough.

I'll be honest, it was one of my initial thoughts as well that this wouldn't catch on, due to people being too attached to their current installations
It's not compatible with existing FF2 bosses, not sure what you mean with compatibility with VSH bosses though, yet. However, it should be possible to write a compatibility plugin at one point, to ease transition.

I'll also be honest and say I don't know how extend FF2, but from what I've skimmed it's a horrible implementation. It doesn't offer any sort of isolation for abilities.

So while I do know it's unlikely this gains any traction before a proper compatibility layer is in place, I'll also say that for improved maintenance, and more unique game play variation you'll need a more versatile system.

Originally Posted by Maximilian_ just need allow all players pick some abilities, like in dota 2: brave jump, ubercharge, demopan's attack, add balance for abilities and allow all them make backstabbing and etc., in my opinion this will interesting

That's not exactly possible the way I've currently done this, but I think I may be onto a setup that could allow for something like it. It's not a bad idea you have going though, as it does open up for ability reuse. And it could allow abilities to be used in other, non-boss fight fortress related, game modes too.
However as you explain it, it wont be a part of the core game mode, but I could definitely see this as a possibility for a game mode extension.

Originally Posted by friagram It's just a framework, and the effort required to port existing bosses and test them greatly outweighs benefit of switching. Main problem why ff2 has not been rewrittem, and why the newer versions have constant problems.

I already wrote my thoughts on this not really catching on, but you still try and look a bit further and see the possibilities it could also open up for. First and foremost I'll try and get the frameworks to a more usable state, however it would be appreciated if there was some constructive criticism and wanted features, that could aid increasing the chance of this catching on.

First and foremost, I'm planning some changes to Definitions that makes it more fool-proof to set up, and also makes it possible to more easily make Definition references, perhaps without them existing yet. This would allow a move to abilities being definitions, and only making the definitions relying on them valid when the abilities are actually created.
That would make definition-dependent definitions much easier to create, as they could be incomplete, yet still exist, just waiting for their requirements to load.

That'll help in many ways improving the current setup, sharing of abilities and such.

[Maximilian_]

this is only my suggestion

[friagram]

Originally Posted by Cookies.net I already wrote my thoughts on this not really catching on, but you still try and look a bit further and see the possibilities it could also open up for. First and foremost I'll try and get the frameworks to a more usable state, however it would be appreciated if there was some constructive criticism and wanted features, that could aid increasing the chance of this catching on. First and foremost, I'm planning some changes to Definitions that makes it more fool-proof to set up, and also makes it possible to more easily make Definition references, perhaps without them existing yet. This would allow a move to abilities being definitions, and only making the definitions relying on them valid when the abilities are actually created. That would make definition-dependent definitions much easier to create, as they could be incomplete, yet still exist, just waiting for their requirements to load. That'll help in many ways improving the current setup, sharing of abilities and such.

The problem is, the game needs to manage so many things, and a modular framework makes this hard.
We have weapon settings for non bosses to balance .. should be easy.
We have weapon bonuses when boss is hit by certain weapon or gets a cond.
For abilities, there needs to be an easy way to setup execution as well as flags for when they can be executed (on ground, not stunned, etc). Also need settings like hold to charge then execute at full or power based on percent, execute if rage is certain amount with min threshold , as well as button mapping. Ff2 does this, tho it is a bit sloppy by constantly filing the on ability forward.

Will need some forwards for boss events (spawn, death, disconnect, otd, voice action)
Will need easy to use natives to get various info on bosses.

If all of this stuff is not implemented in a sane manner, it's a lot of work to use.
Likewise, if stuff that is needed is missing or we have to code individually for each boss (like we do now)... it becomes not worth the effort.

[Cookies.net]

Originally Posted by friagram The problem is, the game needs to manage so many things, and a modular framework makes this hard. We have weapon settings for non bosses to balance .. should be easy. We have weapon bonuses when boss is hit by certain weapon or gets a cond. For abilities, there needs to be an easy way to setup execution as well as flags for when they can be executed (on ground, not stunned, etc). Also need settings like hold to charge then execute at full or power based on percent, execute if rage is certain amount with min threshold , as well as button mapping. Ff2 does this, tho it is a bit sloppy by constantly filing the on ability forward. Will need some forwards for boss events (spawn, death, disconnect, otd, voice action) Will need easy to use natives to get various info on bosses. If all of this stuff is not implemented in a sane manner, it's a lot of work to use. Likewise, if stuff that is needed is missing or we have to code individually for each boss (like we do now)... it becomes not worth the effort.

Let's see, if I can help a bit here, with what it currently does (I probably should've mentioned this in the OP):

An example of setting up an boss with a charge ability that allows him to fly whilst using his charge (from the current sample boss, used it to test for errors and the Continuous charge ability mode):

PHP Code:

public void OnDefinitionCreated(Definition definition)
{
    if (definition.IsDefinition(BFFBOSSGENERIC))
    {
        BffBossCreator creator = new BffBossCreator("Sample Boss", TFClass_Spy, GetMaxHealth, EquipBoss);
        creator.SetChargeAbility("Look I can FLY!", ChargeMode_Continuous, 15.0, 20.0, OnChargeStart, OnChargeReleased);
        creator.Finalize();
    }
}

public int GetMaxHealth(float multiplier)
{
    return RoundToFloor(Pow(512.0 * multiplier, 1.1));
}

public void EquipBoss(BffClient client)
{
    client.RemoveAllWeapons();
    client.GiveWeapon(574, "tf_weapon_knife", "156;1");
}

public bool OnChargeStart(BffClient client, float cooldownPercent, float cooldownDifference)
{
    if (cooldownPercent == 1.0 || (cooldownPercent >= 0.2 && cooldownDifference >= 0.1))
    {
        SetEntityMoveType(client.ClientIndex, MOVETYPE_FLY);
        return true;
    }
    return false;
}

public void OnChargeReleased(BffClient client, float chargePercent)
{
    SetEntityMoveType(client.ClientIndex, MOVETYPE_WALK);
} 


A full list of what you can currently do for boss customization is:

PHP Code:

SetDisplayName(const char[] name)
SetNameFormatter(BFF_NameFormatter nameFormatter)
SetCustomModel(const char[] model)
SetChargeAbility(const char[] name, ChargeMode mode, float chargeTime, float cooldownTime, BFF_OnChargeStart onChargeStart, BFF_OnChargeReleased onChargeReleased)
SetChargeFormatter(BFF_ChargeFormatter chargeFormatter)
SetSpecialAbility(const char[] name, SpecialChargeMode mode, int cooldownDamage, float cooldownTime, bool cooldownCustom, BFF_OnUseSpecial onUseSpecial)
SetSpecialFormatter(BFF_SpecialFormatter specialFormatter) 


If you want something above that, currently, you have to code it yourself. I am of course interested in knowing what is wanted from developers. As I said, I wanted to opinions, constructive criticism and ideas for improvement.

More over, if there's some sort of special behavior you need often, you could always make a base definition that your bosses then inherit from.

For the abilities, I currently have 2 modes of charging, however once I make it simpler to make definition references, custom charging options for abilities aren't unlikely to be added:

PHP Code:

// Normal charges up from 0% to 100% when activating, while Continuous uses up charge from 100% to 0% when activating
enum ChargeMode
{
    ChargeMode_Normal,     // Normal charge mode, once used starts recharging from 0%, can only start charging once 100% recharged
    ChargeMode_Continuous, // Continuous charge mode, goes from 100% to 0%, it's "always" ready and it's depleted at 0%, when you let go it'll recharge from the percentage you left it at
}

// How the different special cooldowns are taken into account
enum SpecialChargeMode
{
    SpecialChargeMode_Assisting, // Assisting means all helps each other towards the goal
    SpecialChargeMode_Competing, // Competing means the highest cooldown rules them all!
} 


I'm going to get rid of OnDefinitionCreated and make a native that makes you able to subscribe to one or more definitions you need, thinking along the lines of:

PHP Code:

RequireDefinitions(DefinitionsAvailable, "MyFirstRequirement", "MySecondRequirement", ...);
...
public void DefinitionsAvailable()
{
    // setup definitions
} 


When using definitions you have a load of options to use as well, these are for when creating definitions:

PHP Code:

DefineInt(const char[] property);
SetInt(const char[] property, int value);

DefineBool(const char[] property);
SetBool(const char[] property, bool value);

DefineCell(const char[] property);
SetCell(const char[] property, any value);

DefineFloat(const char[] property);
SetFloat(const char[] property, float value);

DefineString(const char[] property);
SetString(const char[] property, const char[] value);

DefineFunction(const char[] property);
SetFunction(const char[] property, Function func); 


And are available in all Creators (as long as they inherit from DefinitionCreator, which they should), more over I'm planning to add:

PHP Code:

DefineDefinition(const char[] property, const char[] parentDefinition, bool allowAbstract=false)
SetDefinition(const char[] property, const char[] definition, bool allowAbstract=false) 


For definition references, they're referenced by name instead of by definition, so they're able to be created without the definitions existing yet, to aid definition referencing. That'll allow a very easy setup of say, pre-made abilities. It could get as easy as doing something like:

PHP Code:

bossCreator.SetChargeAbilityEx("SuperJumpAbility"); 


Although there would probably be some slightly more work needed if you want it customized, likely through creating a child definition with properties overridden.

For Definitions, you have get versions of all the defines/sets that exists in the Creator:

PHP Code:

bool GetInt(const char[] property, int &value);
bool GetBool(const char[] property, bool &value);
bool GetCell(const char[] property, any &value);
bool GetFloat(const char[] property, float &value);
bool GetStringLength(const char[] property, int &length);
bool GetString(const char[] property, char[] value, int maxSize);

int GetIntEx(const char[] property, int defaultValue=0);
int GetBoolEx(const char[] property, bool defaultValue=false);
int GetCellEx(const char[] property, any defaultValue=0);
int GetFloatEx(const char[] property, float defaultValue=0.0);
int GetStringLengthEx(const char[] property);

bool StartFunction(const char[] property);
bool AddToForward(const char[] property, Handle fwd); 


And again, there will be GetDefinition and GetDefinitionEx for definitions as well.

Definitions are type checked, so you can't make mistakes without noticing.


So just saying again, I just need to know what's in peoples interest and then I'll do what I can to make it, or help make it. I've been out of this game for so long I don't know what needed, and I'm not going to look through VSH/FF2 for clues, as there is likely more features that people want access to that could be a part of the core, while there are things that do exist in VSH/FF2 that do not belong as a part of the core.

Finally I do have to say, I need specific requests on what's wanted and what's not though.

[sarysa]

Originally Posted by Cookies.net I'll be honest, it was one of my initial thoughts as well that this wouldn't catch on, due to people being too attached to their current installations

I'll be honest myself in saying the question was a bit rhetorical...already knew what the answer was even though I only skimmed the original post. It's harder to get people to use a similar but incompatible plugin than it is to get someone to use an original but super niche plugin. (a little self-reference there)

Originally Posted by Cookies.net It's not compatible with existing FF2 bosses, (...) However, it should be possible to write a compatibility plugin at one point, to ease transition.

You'll want to do this first, if you want your plugin to get an audience...particularly an audience of developers, which is what you really would need.

Case in point: The VSH Advanced person just dropped a bunch of code on us and said "here's my framework, please build on it." Then came back about 8 months later and found that nothing had changed. Coders are egotistical, disagreeable and territorial...myself included.

Lets say hypothetically (as in percentages pulled out of thin air) that 0.1% of gamers are competent coders. Out of those coders, maybe 2.5% of those may be seeking to get involved with the CORE DEVELOPMENT OF someone else's project *and* put up with the stylistic and structural differences of the project compared to their own personal preferences...because most of us would rather start our own project. (maybe 10% would at least be inclined to be subplugin developers, like I am) If your plugin can't garner an audience from the work its creator puts in, it'll never attract the coders needed to keep it going.

And yeah, my DF plugin was a bit of an ego trip along with "3d danmaku in TF2...why the hell not?" ;)

Originally Posted by Cookies.net not sure what you mean with compatibility with VSH bosses though

Neither do I. ;) I think Chdata added some level of extensibility to VSH...but despite how mature VSH is I've already invested too much effort into FF2 to even dream of switching. Not to mention I have outside-of-TF2 coding projects and "real life" things to also occupy my time.