hexagram30 / mush Goto Github PK

Different than creator.

A continuation of the work in #19

Phase 3:

• Create a conversion for .adoc to SQL - #44
• Create game content loaders in hxgm30.game
• Update hxgm30.mush.app to load game data before any networked services are started up

Phase 4:

• Create game content .adoc writers in hxgm30.game (for preserving in-game edits in the file-based source of truth) - #45

Background:

• See Figure out long-term data plan

Blocks #42

Repo: https://github.com/SifoxDevTeam/epgl

Installation instructions: https://www.2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/

See:

• http://lisp.plasticki.com/show?24GC
• http://lisp.plasticki.com/list?24NX
• http://interweave-consulting.blogspot.com/2017/02/so-this-is-where-we-are-doctor.html
• https://sites.google.com/view/elizagen-org/the-original-elizas

Tasks:

• Define metadata for the story / game itself
• Define metadata fields for .asciidoc files that correspond to DB schemas; this needs to be done for
  • areas
  • unique items
  • generic items
  • NPCs
• Any area, item, or NPC may have zero, 1, or many media files associated with them
• Update schemas appropriately (the SQL files in the migrations dir)

Blocks:

• cnbb-games/undirvithr#5

Background:

• Implement hxgm30 game / story data format
• Figure out long-term data plan

Let's catch that error and send an error msg; the telnet connection should stay up until the DB is available again.

The following need to be taken into consideration:

• The external included apps that need to be started
• The internal external apps that need to be started
• The operations that need to be performed as part of system bring-up
  • verifying required configuration data is present
  • performing any required database migrations
  • checking for available games in configured directory
  • hashing all game files and checking against those in the db
  • loading any missing files into the DB
  • adding any updated content to the DB
• The order in which all of these should be done

The first two are handled nicely by OTP releases, but the third will need some custom work and possibly the use of Erlang/OTP start phases (https://erlang.org/doc/design_principles/included_applications.html)

Blocks #46

A default god character needs to be created for high-level permissions on a new install.

(Maybe there should be a default character for each permission level, too?)

What needs to be preserved:

• in-game changes made to the structure of the world, including:
  • new areas
  • modification of area attributes (e.g., descriptions, new exits, etc.)
  • new NPCs
  • new items

What shouldn't be preserved:

• game-specific state, including:
  • item movement (pick-ups, drops, etc.)
  • character (PC and NPC) placement, attribute changes, etc.
  • creature movements, etc.

That being said, there should be an export feature for player characters ...

Due to the fact that this capability is DB-dependent, the feature was moved from hexagram30/story#5 to this repo. Code will live in hxgm30.store.story.

Tasks:

• Store user account email address upon change
• Store user account SSH public key upon change
• Store account confirmation upon successful verification
• Store user account completion status upon any update

• local Postgres instance
• configuration for DB connection
• define initial schema for project
• choose migration tool and run all schema changes through as migration increments
• long-running DB connection / connection pool
• initial API for storing
  • user registration data
  • account creation (post-verification)
  • character creation
  • session management (migrate to a faster store later; maybe mnesia?)

Scenario: many players are logged onto the game, interacting with each other, with NPCs, with the world, and making changes that impact all of the above and thus the overall game state.

Tasks:

• First of all, is PostgreSQL not fast enough? Test it!
• If the answer to that is "yes" then delete the hxgm30.world release app (will just use hxgm30.store instead)
• Can all of the game state reside in memory?
• What efficient data structures might be applied here? (e.g., RoaringBitmap?) What are the concurrency stories around those?
• Is the best answer to simply use Redis?
• If an in-memory state manager is needed, state changes will need to be pushed to the store eventually
  • we've been exploring WAL updates as an event stream (see #39) which push DB messages to the app -- we'll need to explore app messaging pushed into the DB for queued DB updates ...
  • would be nice to do this in-app, in-node and not have to add a full messaging system to the stack ...

(Additional tasks to be defined once the above questions are answered.)

Blocks #19

Tasks:

• Identify directory where stories / games / worlds will live
• Update sys.config with directory location for stories
• Add config function for easily getting the dir
• Add make targets for:
  • pulling in https://github.com/cnbb-games/undirvithr to the right dir
  • adding a git remote for the repo so that story changes may be pushed upstream
  • updating the story subtree with the latest from upstream
  • pushing local story changes upstream
  • resetting the story subtree and re-doing dir setup (in case of emergency)

This can be done via Logical Decoding Output plugins in Postgres and some WAL/replication configuration setup.

Tasks:

• Explore the basic features and possibilities
• Install wal2json and experiment with it (see #41)
• Install epgl and experiment with it (see #41)
• Decide upon a plugin
• Create a new server in the mush supervision tree that manages event data (see #42)

Tasks:

• When the user registers an email address, send confirmation code
• Store that code in the DB (not in the session!)
• Implement a verify or confirm command in the telnet shell
• Perform lookup and comparison after user submits code
• If verification fails, present error to user
• If verification passes, set user registration state as "confirmed"

We need to create a new server in the mush supervision tree that manages event data.

Blocks #39

Depends upon: #40, #41

Tasks:

• Examine simple pubsub options for Erlang apps
  • gen_event not fully applicable
  • gen_server
  • @rvirding's chat_demo <-- good stuff! This is basically "use gen_server" with lots of the thinking already done 😄
  • https://github.com/uwiger/gproc too much
  • https://github.com/cabol/erlbus too much and maybe not stable enough ...
  • https://github.com/cabol/west too much
• Implement a server based upon @rvirding's chat_demo (linked above)
  • just support running within a single node / release
  • provide an API for:
    • processes to subscribe to events
    • processes to receive events
    • processes to unsubscribe from events
  • integrate within existing supervision tree for hxgm30.mush or hxgm30.store
• Listen for DB changes
• Parse the results
• Perform actions based upon these (update game state? send messages to users? iow, utilize pubsub)

Tasks:

• support telnet access
• identify all required commands
• create help file for all commands
• receive and store data in the session:
  • session id
  • email address
  • ssh public key
  • confirmation status
• ensure that all commands that can work with session data do so correctly
• update service_user schema (add new/missing fields)
• extract DB errors and selectively display to users (e.g., if email address is already taken) - #21
• verify user accounts - #22
• store all session data in the DB - #23
• Keep user account table clean - #24

Blocks: #11

Right now, users just see "registration" ... not so great :-(

Right now, new content is added as part of a schema migration ... but as soon as content starts getting created in-game, what do we do? Genera DB dumps regularly? Convert those to migration files?

• player: no prefix
• moderator: %command-name
• builder: #command-name
• admin: @command-name
• wizard: *command-name

Rules could be:

1. no prefix is needed for player commands
2. if the command is unique (only exists in one role's command list), no syntax needed
3. if the command will take more than one line, use the prefix, enter as many new lines as necessary (hitting <enter> in the middle of the command will not complete entry); when finished, use the prefix as the last character before hitting <enter> at which point entry will be completed and the command will be evaluated
4. if no syntax is used, <enter> will complete the command entry
5. in all other cases, the prefix is optional; however, if used, it most be closed with it

Something like this was happening for the email command. Just need to dig in and see what's up.

Tasks:

• Start thinking about commands
  • examine Inform7 commands: hexagram30/shell#35
  • look at the PennMUSH commands: hexagram30/shell#18
• Implement a prototype game REPL
• Support ssh'ing into game shell
• Add readline support

Maybe simply a table of user id and area id columns?

Character's will be able to set various locations as their "home" where they can rest and heal. We'll need to add a current_home column that takes an area id.

Players will also be allowed to build a home for themselves, but only one. Once built, their entry in the DB needs to be updated to this effect.

Tasks:

• Add current_home column
• Add built_home column

Tasks:

• Add session record field for errors
• Append to session's errors field whenever in all parts of the code where an error is catched
• Append to session's messages field whenever there is useful info to share with the user from the backend
• In the shell, before the display of the prompt,
  • iterate over and display errors as well as update messages
  • send a clear-errors and -message to the reg server, and then
  • display the prompt per usual

These messages need to be the "user friendly" versions of them, too.

In-game maps, diagrams, images, and other artifacts should be possible in a purely text-based world by distributing out-of-band. For instance, when looking at a map or reading an in-game book, players could exercise the option of sending it to their registered email address.

(for verification emails)

Tasks:

• Do research on TTL columns in PostgreSQL
• Create function and trigger for deleting old, non-confirmed accounts
• Test and verify as working

Tasks:

• Support ssh'ing into game shell
• Run each shell in its own LFE process with its own state
• Set user data in that shell process' state
• Maybe perform various user look-ups as part of login (e.g., cache role-based data) so that DB queries may be avoided if possible -- store these in the login state, too
• Add readline support
• Enable only one instance of a single character logging in at a time
• Ensure multiple logins with different users work as expected

Probably best to finish the TCP registration server first ... (see #3)

• Fix links / badges
• Use Hexagram30 logo

https://github.com/eulerto/wal2json

Phase 1:

• Design v1 for the game data format - #20
• Create story repo - https://github.com/cnbb-games/undirvithr
• Copy data to story repo - cnbb-games/undirvithr#5
  • From existing DB inserts (in migration files) to .md files in story repo
  • Files should be navigable in Github via Markdown links
• Delete inserted data from migration files

Phase 2:

• Add game data to the MUSH (e.g., via git subtree) - #47
• Find a good Markdown parser (reader and writer) for Erlang that also supports Markdown metadata headers
• Repurpose the hxgm30.story repo for parsing story files, etc.
• Create functions for .adoc data -> Erlang data structures
• Create a generic data structure from parsed documents that can be used in the game

Background:

• See Figure out long-term data plan

Due to the fact that this capability is DB-dependent, the feature was moved from hexagram30/story#4 to this repo. Code will live in hxgm30.store.story.

Tasks:

• Add configuration for story/game directory
• Generate fast hash for game metadata (for use in determining if updates need to be applied to the DB)
• Update game table schema for new metadata
• Generate fast hashes for game content such as areas, npcs, items, etc. (for use in determining if updates need to be applied to the DB)
• Examine configured story directory for stories/game and import story metadata into game table
• Support areas
  • Create functions for importing one
  • Iterate through these in the story data and import to appropriate table(s)
• Support items
  • Create functions for importing one
  • Iterate through these in the story data and import to appropriate table(s)
• Support NPCs
  • Create functions for importing one
  • Iterate through these in the story data and import to appropriate table(s)
• Support creatures
  • Create functions for importing one
  • Iterate through these in the story data and import to appropriate table(s)
• Support monsters
  • Create functions for importing one
  • Iterate through these in the story data and import to appropriate table(s)

Also use Slack integration for sending notifications to the #cicd channel

To reproduce:

1. rlwrap telnet 127.0.0.1 2519
2. <CTRL-C>
3. quit

The shell will hang and not close the connection.

Better character stripping might solve this?

E.g., hxgm30.mush.shell:tokenize and supporting functions. Maybe put them in hxgm30.mush.parser? This way any shell can use them without weird referencing of one shell to another.

No server round-tripping; just call the verification code.

Zotonic has some code we can borrow for this ...

schema changes for area and pathway tables.