marrow / jikca Goto Github PK

This project forked from amcgregor/pyoomush

A modern MU* server implementation in Python 3 using asynchronous networking and MongoDB object storage, with integral web-based client.

License: MIT License

Python 98.37% Makefile 1.63%

interactive-fiction interactive-fiction-engine moo muck mud mud-server multiplayer-game-server mush mush-client mush-server mux text-adventure-engine

jikca's People

Contributors

Stargazers

Watchers

jikca's Issues

Persist accessible inventories on-screen.

As a User, in order to reduce repeated command invocation and bandwidth use, the accessible inventories should always be visible.

Accessible Inventory: The contents of locations within the user's current object search path. For example, the player's inventory, the player's location's contents, and the contents of any "open" containers within the player's location.

Work on: #2

Installable Python package architecture.

Initial project structure already committed is untested.

Identify and document user stories.

Implement underlying socket transport.

Automate common administrative actions.

User communication interaction stories.

Feature: As a user I want to communicate with other users so that we may organize and have fun.

Scenario: The user wishes to communicate to all other connected users.

Given the user is staff,
- When the user attempts to broadcast a message to all connected users,
  - Then all connected users receive the message.
Given the user is not staff,
- When the user attempts to broadcast a message to all connected users,
  - Then the user receives a generic 'command not found' error message.
  - And the request fails.

Scenario: The user wants to communicate to all other connected users within the user's location.

Given the sender is muted,
- When the sender attempts to communicate the sender's location,
  - Then the sender is reminded that they are muted and may not do so.
  - And the action fails.
Given the sender is deaf,
- When the sender attempts to communicate to the sender's location,
  - Then the sender is reminded that they are deaf, and will not hear any response.
  - And all connected users within the sender's location who are not set deaf will receive the communication.
  - And connected users within the sender's location who are set deaf will not receive the communication.
  - And connected users not within the sender's location will not receive the communication.
Given the sender is dark,
- When the sender attempts to communicate to a location,
  - Then all connected users within the location who are staff and not deaf will receive the communication with identifying its source.
  - And all connected users within the location who are not staff and not deaf will receive the communication without identifying its source.
  - And connected users within the sender's location who are set deaf will not receive the communication.
  - And connected users not within the sender's location will not receive the communication.
Given the sender is neither mute nor deaf,
- When the sender attempts to communicate to a location,
  - Then the sender is not reminded that they are deaf.
  - And all connected users within the location who are not deaf will receive the communication.
  - And connected users within the sender's location who are set deaf will not receive the communication.
  - And connected users not within the sender's location will not receive the communication.

Scenario: The user wants to privately communicate to a user-specified subset of connected users within the user's location # whisper

Given the sender is mute,
- When the user attempts to communicate to a user-specified subset of connected users within the user's location,
  - Then the sender is reminded that they are muted and may not do so.
  - And the action fails.
Given the sender is deaf,
- When the user attempts to communicate to a user-specified subset of connected users within the user's location,
  - Then the sender is reminded that they are deaf, and will not hear any response.
  - And user-specified subset of connected users within the user's location who are not set deaf will receive the communication.
**Given the recipient does not exist,
- When the user attempts to communicate to a user-specified subset of connected users within the user's location,
  - Then
Given the recipient is not present in the sender's location
- When
  - Then
Given the recipient not connected
- When
  - Then
Given the recipient deaf
- When
  - Then
Given the recipient has blocked the sender
- When
  - Then
Given the sender is not prohibited from sending a message,
And the recipient is present in the location of the sender, connected, and able to receive a message,
- When
  - Then

Does the user want to obscure the list (bcc) or is the list public to all on it?

Scenario: The user wants to privately communicate to a user-specified subset of connected users regardless of location. # tells

Given the sender mute,
- When
  - Then
Given the sender is deaf,
- When
  - Then
Given the recipient does not exist,
- When
  - Then
Given the recipient is not connected,
- When
  - Then
Given the recipient is deaf,
- When
  - Then
Given the recipient has blocked the sender,
- When
  - Then
Given the sender is not prohibited from sending a message,
And the recipient is connected and able to receive a message,
- When
  - Then

Does the user want to obscure the list (bcc) or is the list public to all on it?

Scenario: The user wants to privately communicate to a system-specified subset of connected users. # chat channels

Given the subset of connected users does not exist,
- When
  - Then
Given the sender is not a member of the subset of connected users,
- When
  - Then
Given the sender is a member of the subset of connected users,
And is restricted from sending to that subset,
- When
  - Then
Given the sender is mute,
- When
  - Then
Given the sender is deaf,
- When
  - Then
Given the subset of connected users exists,
And the sender is a member of the subset of connected users with send-access privileges and is not otherwise restricted from communication,
- When
  - Then send the message to all members of the subset of connected users who have not blocked the sender and are not deaf. # Do I need to check for deafness/blocked status in this scenario, or is this sufficient to indicate that must happen?

Do join, leave, and mute scenarios go here?

Scenario: The user wants to communicate in a longer, persistent form to a user-specified subset of users. # Mail

is the sender restricted # how does this differ from mute?
does the recipient exist
has the recipient blocked the sender # cannot block staff
is the message missing a vital attribute [subject, content]
is the message of malicious size # maximum file size?
send message
store message
sender is notified their message has been sent
if online, recipient is notified they have received a message
if offline, recipient will be notified upon next connection that they have a message

** Do read scenarios go here? **

Scenario: The user wants to communicate in a longer, persistent form to a system-specified subset of users. # Mail List

does subset exist
is user a member of subset (with sending privileges)
is the sender restricted # how does this differ from mute?
does the recipient exist
has the recipient blocked the sender # cannot block staff
is the message missing a vital attribute [subject, content]
is the message of malicious size # maximum file size?
send message
store message
sender is notified their message has been sent
if online, recipient is notified they have received a message
if offline, recipient will be notified they have a message upon connection

** Do read scenarios go here? **
** Do join and leave scenarios go here?**

Scenario: The user wants to communicate in a longer, persistent form to a system-specified subset of users. # BB

does subset exist
is user a member of subset (with writing privileges)
is the sender restricted # how does this differ from mute?
is the message missing a vital attribute [subject, content]
is the message of malicious size # maximum file size?
post/store message
online members of subset are notified there is a new message
offline members of subset will be notified there is a new message upon connection # if they have not muted notifications?

Scenario: User wants to mute communications. # all channels/deaf
Scenario: User wants to reinitiate communications.
Scenario: User wants to mute a subset of users. # block an individual, all tells, one chat, all chat, notifications for mail or bb
Scenario: User wants to unmute a subset of users.

Architect mush client service.

Single-player experience.

Story

As a player who is forever alone, in order to simulate social interaction, I want to play within game worlds in a non-server interactive experience.

Notes

Interactive "simple" interface (a la Telnet) as MVP.
Urwid ANSI / Curses / Ncurses rich interactive client, similar to web client in layout and behaviour as ultimate goal.
Such a front-end could then easily be recycled for use as a "console" for a running server, as well.

Relevant Libraries

aioconsole — asynchronous I/O adapter for interactive (STDIN/STDOUT) use.
Urwid — text-based "graphical user interface" toolkit for interactive terminal applications.

Work on: #2

Architect web service.

User authentication and session management.

Scenario: User authentication and session management.
	Given an authenticated user connection.
		When the user wishes to terminate the connection gracefully,
			Then they should be presented a message saying farewell.
			And their connection should be terminated.
		When the user sits idle with no I/O for a given period of time,
			Then they should be presented a message saying good riddance.
			And their connection should be terminated.
		When a member of Staff adds the user to a blacklist
			Then the user should be presented a blacklist message.
			And their connection should be terminated.
			And the relevant details of the act should be sent to an audit log.
	
	Given an anonymous user connection.
	And an existing account.
		When authentication is requested by a non-VIP while VIP is enabled:
		Or invalid VIP credentials are provided while VIP is enabled:
			Then the request should fail.
			And no session should persist.
			And the user should be notified of the reason.
			And the user should be disconnected.
		When authentication is requested with invalid credentials while VIP is disabled:
			Then the request should fail.
			And no session should persist.
			And the user should be given three opportunities before being disconnected.
			And a notice should be written to an audit log.
		When authentication is requested with valid credentials while VIP is disabled:
			And the user is present on a blacklist
				Then the request should fail.
				And no session should persist.
				And the user should be notified of the reason.
				And notice should be written to an audit log.
				And they should be disconnected.
		Or valid VIP credentials are provided while VIP is enabled:
			Then the request should succeed.
			And the account should be logged in.
			And the act logged to an audit log, ensuring sensitive materials are not stored.

	And no account exists.
		When attempting to create a character with an invalid or reserved name:
		Or attempting to create a character with a name that already exists:
			Then the request should fail.
			And the user should be given a message advising they have selected an invalid user name.
			And the connection should remain open for successive attempts.
		When attempting to create a character with a password below minimum requirements:
		Or attempting to create a character with data reaching malicious levels of memory consumption:
			Then the request should fail.
			And the user should be given a message advising them of password requirements.
			And the user should be prompted to enter a valid password at most 3 times before being disconnected.
		When attempting to create a character with valid credentials
			Then the request should succeed.
			And the account should be logged in.
			And the act logged to an audit log, ensuring sensitive materials are not stored.
			And their email should be confirmed.			
		And character creation has been disabled
		Or VIP access is enabled:
			Then the request should fail.
			And no session should persist.
			And the user should be notified of the reason.
			And the user should be disconnected.

Model core data structures.

Persist room description on-screen.

As a User, in order to reduce repeated command invocation and bandwidth use, the room description should always be visible.

Work on: #2

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.
Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TensorFlow

An Open Source Machine Learning Framework for Everyone
Django

The Web framework for perfectionists with deadlines.
Laravel

A PHP framework for web artisans
D3

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
web

Some thing interesting about web. New door for the world.
server

A server is a program made to process requests and deliver data to clients.
Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization

Some thing interesting about visualization, use data art
Game

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft

Open source projects and samples from Microsoft.
Google

Google ❤️ Open Source for everyone.
Alibaba

Alibaba Open Source for everyone
D3

Data-Driven Documents codes.
Tencent

China tencent open source team.