Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration from single player FSA to multi-participant "coordination" #1

Open
drllau opened this issue Apr 26, 2020 · 3 comments
Open

Comments

@drllau
Copy link
Member

drllau commented Apr 26, 2020

Would like to merge the graphics of this Meta-skill repo with the game-play of jadbox.eth DAO RPG. Issues

  1. static vs dynamic scene - resolvable so long as implement a "range" component for archer/arcane attacks where the number of hexes (min/max) is adjustable
  2. round-robin turn to quasi real-time = first step is to implement a timeout, where after fixed interval assume player has paused, with 2nd stage need a gather/scatter graph sweep algorithm across visible room to ensure that all events are correctly collected and ordered for resolution. 3rd is trying to resolve the concurrency headaches (eg mutual destruction)
  3. tie in the multi-wallet economic aspects, identity, tipjar/stores etc ...
@drllau
Copy link
Member Author

drllau commented Apr 26, 2020

campaign_image

Every dungeon instance needs an authority, someone who sets the tone and grant the participants access, then closes the journey with reflective learning. As noted elsewhere, space is not a problem since you can always open up a trapdoor (or teleportation door that connects two hexes together for powerful mages). But sometimes a party may be too powerful/weak and you need to adjust difficulty parameters accordingly. Hence the scenario should start with a set of probing questions (perhaps silently in background) to judge the capability level and ensure that the gameplay is enjoyable, challenging enough to provide fear of failing, yet not impossible to win (though the BigBoss should retreat and regenerate where possible).

@drllau
Copy link
Member Author

drllau commented Apr 26, 2020

MetaGame-jadBox0

Next you have to set up the scene which is what area the time-dilation effects take place. What this means is that for multi-parties, they may be sectioned off a larger map and you need to ensure events (including notifications or dependencies) are constrained to avoid excessive wallet transactions or shard jumping, whilst catching up with external events afterwards. You implement this using map masks so you can see above, you're starting from the wizard cottage, but the movement space is shaded until the instance is over. Keep in mind also the field of view since normally you can only see 1 hex around whllst others (standing on that mountain to west) can see further or hear you coming (normally 2 hexes away unless noisy). The fog of war would prevent players from seeing where the minions or monsterBoss is normally.

@drllau
Copy link
Member Author

drllau commented Apr 26, 2020

image

Now multi-party has some issues:

  • existing rules on field of vision (visible hexes, fog of war, shroud, etc) still apply
  • players can see the joint superset of their perspectives
  • monsters also have similar detection rules, (note underwater sound travel further).

Unfair if archer can see 2 away but but need tank to be adjacent (play tag) ... I try get around this by allowing vision to be adjacent only (melee combat) but sounds (like projectile shooting) can be heard 2 hexes away which means AI monsters can move away or closer to the mage artillery, and of course flight rules !!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant