Difficulty scaling

One thing that I have remarked, is that scenarios may be found too easier or difficult depending on crew experience. Why not add a difficulty option that scenarios may optionally take into account by the means of a new getDifficultyRating() function. I would see a Accessible/Normal/Challenging options, which would be translated into 1/2/3 in the difficulty_rating variable.

For instance :
--- spawn Kraylor attack wing

-- if not in easy, spawn additional fighter
if getDifficultyRating() > 1 then

-- if in difficult, spawn additional fighter
if getDifficultyRating() > 2 then

Thoughts ?


  • I like this, because it gives the missions designer a lot of control over what the difficulty levels mean for their scenario, and what sort of encounters they want to happen in each level.

    As opposed to just having a global "damage scaling" slider or something, which in most games just makes the battles very tedious on hardest as you slog through enemy hit points.
  • Yes in most games, I too think that damage scaling feels at best forced. The solution I'm suggesting, in my opinion, presents several advantages :
    - Designers can chose to ignore it altogether.
    - Greater flexibility in what difficulty means, as you mentioned it, and give the ability to create situations that challenge the strategic sense of the Captain instead of his "pew pew" : for instance instead of more enemies, spawning another group that attack a different target would force the crew to make meaningful decisions.
  • My main issue with any type of scaling is feedback to the players. And balancing it all out.
    For example, look at the artemis difficulty details:
    http://artemiswiki.pbworks.com/w/page/62217089/Difficulty Settings

    Suddenly there are features that are only thrown at you at certain difficulties, but without the above list, you wouldn't know that this is happening. For example, when we played it, the "Invisible to Main Screen" ability is not only an odd one (you wouldn't expect it). Because it's an unknown feature suddenly thrown at you at a certain difficulty level, it feels alien, and like a bug instead of a feature.

    Now, with difficulty on scenario scripts, you have the problem of not being implemented equal. Some designers of scenarios will ignore it (causing no difference) and some will do large differences while others will do small differences.

    I think the best "middleground" would be to have an option for scenarios to have different "variations". Where selecting a different variation sets a few variable differently when initializing the scenario. Scenario descriptions could be linked to this to explain better how much the variation does.
  • We at least agree on what we think of Artemis-style shamanism ^^

    Indeed, feedback to players is important, they should know what to expect from selecting a difficulty, and what I suggested is indeed lacking in this.

    I'm not sure on what variations should modify however. Would it be set by the scripter ? For instance, if a variation does something, would it be linked automatically to description ?
  • You could do this now by just making an 'Easy' and 'Hard' version of each scenario script. I think the request was for an option in the startup screen that tells the scenario script which variation to run, so they can be in one Lua file, and one button in the scenario list.
  • On the variation idea. Let me take the "waves" scenario for example.

    The header could be changed to:
    -- Name: Waves -- Description: Waves of increasing difficult enemies. -- Variation[Hard]: Effectively starts at difficulty of wave 5, and increases by 1.5 every defeated wave. (Players are quicker overwhelmed) -- Variation[Easy]: Decreases the amount of ships in each progressing wave, making for easier progress and easier waves. (Takes longer for the players to be overwhelmed)

    In the script, at https://github.com/daid/EmptyEpsilon/blob/master/scripts/scenario_01_waves.lua#L97
    if getScenarioVariation() == "Hard" then totalScoreRequirement = math.pow(waveNumber * 1.5 + 4, 1.3) * 10; elseif getScenarioVariation() == "Easy" then totalScoreRequirement = math.pow(waveNumber * 0.8, 1.3) * 9; else totalScoreRequirement = math.pow(waveNumber, 1.3) * 10; end
  • Oh okay, I see now. Having custom variations would be indeed better for both players and modders.
  • image

    Getting the variations names and description from file is rather easy, as well as adding these options on the option menu. Now is the time to add a script function to add, but I'm having a seriously confounding issue.

    Adding, at the end of gameGlobalInfo.cpp :
    static string getScenarioVariation(void)
        return gameGlobalInfo->variation;
    /// getScenarioVariation()
    /// Returns the currently used scenario variation.
    Gives me this : ..\SeriousProton\src\lua\lua.h|350|error: invalid conversion from 'string (*)()' to 'lua_CFunction {aka int (*)(lua_State*)}' [-fpermissive]|

    It seems that the REGISTER_SCRIPT_FUNCTION wants only a int as type of the function. As I want to return a string, this can't do. I'm obviously lacking basic understanding of the C++ <=> LUA interface.

    Could anyone provide me a hint on how to solve this situation, please ?
    Thanks in advance
  • The C++ to LUA interface for static (not related to object) functions is less advanced then the one for object function bindings. And requires you to do the lua handling yourself. (instead of it being handled by lots of magical templates)
    static int getScenarioVariation(lua_State* L)
        lua_pushstring(L, gameGlobalInfo->variation.c_str());
        return 1;
    /// getScenarioVariation()
    /// Returns the currently used scenario variation.
  • Ok, thanks for the information and code ! :)
    I'll tinker some more when I get back.
  • There is a crash when selecting GM console. I thought it was due to what I modified, but even compiling the latest unmodified sources, it also crashes. Tested independently with kwadroke's latest auto-built binaries, the crash is also present. I'll open up a github issue for that.
  • crash is fixed in latest code now. (My mistake)
Sign In or Register to comment.