orendain / demeomods Goto Github PK

I make errors in my JSON rulesets which sometimes cause them to fail to load... However, I don't realise that has happened until after I've started a game.

It would be nice to display an in-game message as early as possible to say if a ruleset has failed to load. - Having to check the melonloader logs is not good UX.

Regarding making the rules more generic: I don't have a strong opinion at the moment. I've been working on the mod mostly in an agile way, with the belief that the right approach for a few different things will become clear as time goes on. IMHO, whatever we get to work, works for me! Especially for the first iteration of the mod.

Rules that require game patching (like multiple zaps), may be hard to generalize as the the code that needs to be patched may be generated differently by the game (i.e., either different methods need to be patched, or the routines to hook into are slightly different per ability, etc.) But rules that don't require an OnPatch method should indeed be much simpler to make generic.

With regards to when a rule can handle multiple cases:

• For the sake of static typing and efficiency, perhaps a typed structure (instead of JSON) would be beneficial as far as arguments to rule constructors go (e.g., using either straight up primitive types, a Map<String, String>, etc.).
• Thinking about down the road, if we want users to configure rules via, say, some text file, JSON or some subset of JSON makes sense. RulesAPI could parse the structure and then feed it to the rule's constructor in a more typed fashion (a Map).
• One concern may be input validation and ease of use. For example, it would be easier for users to type GuardianHealthAdjusted = 20 (and then again for each class), instead of trying to write some JSON/dict. But that's probably easily fixed with simple documentation.
  • Additionally, in order for RulesAPI to know that the user passed in invalid values (e.g., mispelled { Sorcrrer: 20 }), the rule will have to perform some validation on arbitrary strings and propagate an error which RulesAPI will have to catch and act on. That's not necessarily difficult, but does mean an additional layer of logic to maintain.
• Just a thought exercise: If in the future, for example, if there were a UI that could expose settings for all rules, it would need well-defined rule parameters in order for it to automatically generate a view with the name of the rule and each rule parameter to tweak.
  • For example: It could tell, via reflection, that for GuardianHealthAdjusted rule, there is a single int parameter labeled health. And it could generate that entry in the UI appropriately.
  • It would be more difficult for it to know what to generate if the rule took in a JSON or even a typed Map<String, String>. One way around this could be using well-defined structs (like classes or what C# calls records) instead of JSON/maps. However, that in turn make instantiating rules slightly more difficult and verbose.

Hmm ...
Perhaps a good in-between solution could be for rules to accept only primitive types (i.e., int, string, double, etc.) and only as direct parameters. But with as many parameters as it needs.

• The health adjusted rule could then be implemented with a constructor signature of something like SomeHealthRuleName(int guardianHealth, int sorcererHealth, ...) (and could set defaults if need). That way:
  • We're still very statically typed, allowing RulesAPI core to know what parameters, and their types, are expected, without requiring rules themselves to perform validation.
  • The flattened parameter list doubles as documentation (IMHO, easy-to-document code is directly correlated with it's simplicity and maintainability).
  • User input via config can still be in some JSON-like format, with the key-value pairs corresponding exactly to the names/types of the parameter list.

By different criteria:

• Game type
• Current floor
• Number of players in room

So hosts can send link to players, and players can read what the ruleset they're playing currently does.

Unfortunately, there's no way (that I've found) for the host to send this kind of arbitrary information across to other clients. No implemented chat feature, for example.

Inspired by @jimconner's tweaks, as shared in the Demeo modding wiki.

The following rule may be a good reference point, as it too makes adjustments to a PieceConfig : https://github.com/orendain/DemeoMods/blob/main/Rules/Rule/BallistaActionPointsAdjustedRule.cs

If game/level is not completed within the specified number of rounds, game ends.

On each round, print number of rounds left.

Ran out of time, left room results unpaginated.

@Buruko had a comment here #24 (comment) which I'm moving to top-level as that thread is being closed.

Could this be leverage to perhaps Difficulty Settings?

Like a rule set for 'Easy'

    No monster spawn
    Scaling reduced by 1 (so 4 players is like 3 and so on)

Then 'Normal' is well normal

Then 'Hard'

    Scaling increased by 1

This is also another very much requested feature

Having to edit melonprefs.cfg is a pain. Would be great if the rulesets saved in the HouseRules folder could be found and listed in the in-game menu by default.

Increasing from 4 rounds means the bard does not need to be on constant rebuff patrol. Move + buff, move + buff ... does not give the bard much flexibility.

E.g., changes the cards that players get from chests and mana.

Could be used by rulesets that want to expand the availability of cards, or limit them.

To account for new mods, so that release pipeline doesn't cause conflicts.

Target input could be something like:

- HeroClass: string
- Array of cards to grant
  - cardname: string
  - isReplenishable: bool

The code to patch doesn't deal in strings, but rather enums (i.e., integers).

It's trivial to map hero classes to their respective enum, given there's only 4 of them. But with so many abilities/cards, I propose to just take ints as input.

Resulting in:

- HeroClass: string
- Array of cards to grant
  - abilityKey: int
  - isReplenishable: bool

Either a rule per hero, or one rule to cover all players. Perhaps for simplicity, a single rule for all players makes sense here.

Check if its possible to, upon a user joining the hosted game, list of loaded rules are printed to the screen via Demeo's chat system.

Either QoL changes, or perceived "fixes".

• +1 starting strength for Sorc
• 0AP Zap
  • Or double zap cards and +1 dmg
• 0AP Bard song
• Increased bard song duration
• Or 3x3 bard song aoe

Adjustment to amount of mana (card bar) earned for actions (kill, card, chest open, etc) to generate more mana per round

Rulesets more akin to gamemodes rather than adjusted vanilla settings.

There have been a number of Weekly Challenges posted to the Demeo discord channel which involve playing the game with some extra challenge added. It could be nice to nice to rules/rulesets to for these challenges where we're able.

To date there have been about 10 challenges announced.

Some of the challenges are out of scope for modding as they are within the normal game rules:

• 'Play in an all hunter group'
• 'Play an all assassin group'
• 'Play an all sorcerer group'
• 'Kill any rats you see'
• 'Destroy all lamps'
• 'Destroy all fungi'
• 'use as much poision gas as possible'
• 'set fire to as many tiles as possible'
• 'speedrun'
• 'befriend as many enemies as possible'

Some of the challenges would require changes to the game's logic - theoretically possible, but not easy to implement.

• 'you cannot exit the level until all doees have been opened'
• 'the next card you use is the last card you picked up'
• 'instantly use any card you gain from card meter or chests'
• 'sudden death - complete the entire book without a single player being downed once'
• 'beat the boss without killing anything except necessary enemise (e.g. keyholder)'
• 'complete any action within 5 seconds'

The remaining challenges seem quite feasible

• No Gold for You
  Use the current GoldPickedUpMultiplied rule to set value to zero?

• No Chests
  Use LevelPropertiesModifiedRule to remove all the chests?

• Get ready to put your friendship to the test! Never cast a card on yourself and rely only on help from your teammates.
  This could be implemented with a new rule to Set Ability.mayTargetSelf = False for all player abilities.. (maybe for enemy abilities too)

• Play with a maximum of 5 cards instead of 10 (9+replenishables)
  -Not sure where, but we must be able to set this somewhere.-
  This is now catered for by CardLimitModifiedRule #81

• Complete Realm of the Rat King without using any torches
  This is catered for by CardClassRestrictionRule - this rule allows for the torches to be assigned to a non-player character such as 'mushroom' which will then prevent players from ever recieving this as a card.

Strength, Speed, MarkOfAvalon(weakness), ReplenishArmor and ReplenishBarkArmor all have an AdditiveBonus which can be used to adjust the effect of the respective potions/speels. This can be used to make strength potions give you +3, Weakness be less crippling etc.

It would be nice to have a rule to adjust these settings.

A rule failing to patch/load can be considered unhealthy and thus may be dangerous to allow be used during runtime. These rules should be disabled, and either skipped when included as part of a ruleset or any dependent ruleset should also be disabled.

@jimconner discovered that the Configuration mod doesn't fully run when the game runs via the Oculus PC app (runs fine on Steam).

From my minimal research and experience, this seems to be a compatibility issue between the .NET standard supported by Oculus and the one required by system.text.json, the package we use to do JSON de/serialization.

I don't know enough about .NET to know immediately know where to make changes, so this issue may not be fully fixed for a while.

From what I can tell, a few things may be in play:

• TargetFrameworkVersion the mod specifies is v4.8 (don't know how .NET Framework 4.8 relates to .NET standards)
• Unity version that Demeo uses is 2019.v4, which lists .NET versions it supports.
• Different versions of system.txt.json target different versions of .NET.

Will need to do some more reading during free time.

Mod in private use that allows players to go berserk under similar monster-berserk circumstances (e.g., health < 50%). By itself, this mod seems odd for a player to enable.

Consider bundling it with other game mechanic changes as a custom game type, or just a custom ruleset.

I'd prefer to use scene indexes, but since I don't have the Oculus version, I'll settle for checking against the name of the scene. Lobby scene name loaded on Oculus is Lobby.

Torches last for 9 turns by default and the radius of light they emit decreases with each turn. It would be nice to be able to configure different settings for this.

Seeing the game is a focus on pen & paper play the term 'House Rules' seems to jump to mind as a neat way to harken back to that style of play in this virtual environment. Purpose changing mod title to 'House Rules' to suit.

Thanks to @Buruko for noticing that pre-defined rulesets (e.g., easy/hard/legendary difficulty rulesets) interfere with eachother.

Note: This does not affect rulesets loaded from configs.

The issue is for rules that store config values in static variables. The last rule to be created will set the value, even if it's not the rule that's loaded. Use of static variables in some cases was a known crutch, due to some limitations in the mod loader (and Harmony patcher requirements).

I'll have to think about how to properly isolate rules from each other moving forward. In the meantime, predefined rulesets that use the same IPatachable rules may interfere with eachother.

However, rulesets defined in configuration are still 100% fine.

Short-term fix (or perhaps exactly right): #56

E.g., chests spawned, gold spawned, healing spawned, gold pile amounts, etc.

Rule to allow for endless floors with perhaps additional rules or challenges added per floor

Exmaple:
Floor 1 ~ 3 normal
Floor 4 ~6 Increase monster health
Floor 7 ~ 9 Increase monster damage, add player cards
Floor 10 ~ 12

Currently, for dev purposes, RulesAPI uses the first ruleset in the list of registered rulesets.

Perhaps store desired ruleset in config.

V 1.12.143299 of Demeo released a few minutes ago, so I gave it a quick test to check.

I have discovered that when exiting a private Heros Hangout session you are returned to the main menu but it no longer displays the RoomFinder or HouseRules menus.

Add a total room count to the panel somewhere.

Low-priority.

Issue:

• Due of limitations on how patching can be done (requires a static patch method, thus static field variables), it makes sense that only one instance any type of rule exists (multiple instances will only operate on the same static fields).
• However, this limitation means that even rules without patching requirements (e.g., OnPatch()) are limited to a single instance per class.

There are several reasons for why it would be beneficial to have multiple instances per rule type:

1. Increased granularity. Instead of a single large PieceConfig rule, can have multiple PieceConfig rules (e.g., 1 per piece type).'
2. As a result of more granular (although still generic) rules, printing rule descriptions can incorporate value changes rather than just generic descriptions.

Proposal:
Splitting rules into static and non-static would look like the following:

• Rules with patch requirements (e..g, Onpatch()) would be one rule sub type, and those without would be another sub type.

The rules to either multiplayer label, or not, based on multiplayer testing:

Y = yes
M = no, but might work if board state was resync'd to update values of affected pieces
N = no, host only

AbilityActionCostAdjustedRule.cs - Y, but info isn't updated on card
ActionPointsAdjustedRule.cs - Y
CardEnergyFromAttackMultipliedRule.cs - Y
CardEnergyFromRecyclingMultipliedRule.cs - Y
EnemyDoorOpeningDisabledRule.cs - Y
EnemyRespawnDisabledRule.cs - Y
GoldPickedUpScaledRule.cs - Y
LevelPropertiesModifiedRule.cs - Y
StartCardsModifiedRule.cs - Y

Note: The following chunk can now be considered safe with the introduction of #151.

AbilityAOEAdjustedRule.cs - M
AbilityDamageAdjustedRule.cs - M
EnemyAttackScaledRule.cs - M
EnemyHealthScaledRule.cs -M
PieceConfigAdjustedRule.cs - M
StartHealthAdjustedRule.cs - M

Note: The following are still not considered safe for multiplayer environments. For sure, CardLimitModifiedRule seems impossible given current client-side code. The other two could probably be reworked using another approach, but doesn't seem pressing.

CardLimitModifiedRule.cs - N
CardSellValueMultipliedRule.cs - N
RatNestsSpawnGoldRule.cs - N

After loading a room list any subsequent click of refresh joins a public game instead of just refreshing the list

Could be considered a prerequisite for #1.

• Player starting health adjusted #47
• Pots have AoE effect #93
• Sorc has 2 zaps#35
• non-class cards allowed when mana hits 100 #110
• Players start with specific cards. #106
  • start w/ chest card.
• assassin has reusable arrow card #106

Universal Player game mode:

• Players start with all starting class cards (or random mix). #106
• All players can get all class cards. #110
• Increased card hand count to compensate. #111

Hunter's paradise game mode:

• Only pets + turret cards + hunters mark + lures #110
• Increased mana gain. #61

Godmode but timelimit:

• Players have godmode and/or uber powers. #106
• Game ends if players don't complete game within X rounds. #112
• On each round, print number of rounds left. #112

For example, when multiple mods each generate their own lobby menu and real estate needs to be preserved.

Solution could mean having a "stack" of views that a user can flip through. New stacks, and their position/scale/rotation could be registered, and views could be added to existing stacks without having to have been developed by the same author or be part of the same mod.