We might just want to import/include Winston in the client(?).

These are animals that are (pseudo-randomly) distributed throughout the map. They attack players (and maybe even each other). It would be cool to have different types/levels (with different AI's!).

Related to vision in #24, should we an ability-based line-of-sight bonus (i.e. you can see into neighboring rooms)? I think this might be cool, but also possibly unfair and may be difficult to implement properly.

It seems that we have open connections, even when all the sockets in a Server's this.sockets are disconnected (i.e. socket.disconnect(true)). This is likely causing the hang in #30 .

So, I tried VSCode this morning. It's pretty decent, and I noticed that there's a lot of support for TypeScript and other JS-related infrastructure stuff. @zthomae if you want to move to TS or whatever, I am definitely open to it.

Add a Counter Strike (and Spelunky?)-type store/merchant to the starting room if people want to buy additional supplies with their in-game gold. For example, even if your character class doesn't start with a gun, you could buy one.

The message output list is not correctly scrolled when new messages are added. See addMessage in client.ts.

Echo messages displayed in the client should have a styling (color? background-color? border?) to hint at the communication that was sent (e.g. a shout message might have a red outline on the sender's screen).

This will function as both the roadmap of the project and the actual rules for playing the game.

main.css is quickly becoming a monolith. It would be nice to break it up into smaller files. Since we have to build the TS code to JS, we might want to move to Sass and then compile that to CSS, as well.

Preferably the Google spec of JSCS 😄

See the Wiki for modifier info

Post choices in this thread

The lobby behavior should resemble the game's behavior of stripping messaging prefixes (like /t) if they are the start of the message.

Maybe there should be no default talk behavior for the lobby (i.e. maybe it should behave exactly the same as the game, just without the character-based restrictions on communication). Feel free to discuss...

• jshint (dev dependency?)
• jshint dotfile
• npm run lint task

After a game is finished, the currentContext should be set back to Lobby, which then proceeds to a Game and so on. I think a lot of this infrastructure is in place, but it should be throughly tested an make sense and work smoothly from a client/UI/UX perspective.

These are things like poisoned, addicted, on fire, and more. When this issue is actively being worked on, I will update the Wiki to discuss Effects.

Gracefully handle any interrupt key sequences that may kill the server while it is running. main.ts should be the only file affected.

I was thinking of something along the lines of Minecraft -- needing to carry torches and matches, etc to be able to get better room descriptions (especially if there is a look command). I could see this adding extra challenge ... or cruft. What do you think?

Instead of having a combination of helper function and executed code all in client.ts, I think it might be nice to create index.ts, which would only contain the executed code (i.e. call onDocumentReady). This leaves client.ts as an easily-testable function library!

We need to replace console.* with a logger that is better for testing, collecting data, etc.

My vote is for something like Travis since it is free for open source projects.

This might raise the question of deployment, but we can address that as necessary.

Clearly, not all packages should go in devDependencies

Currently, character creation (where a character object is assigned to a player's character property) is done on Game construction, which is OK, but not great. I was thinking that when a player says they are ready, they can pass arguments for their character class (maybe allegiance and modifiers too?). If no additional information is given, then it should be pseudo-randomly generated, but the option to choose should exist.

A discussion/critique/evaluation of all things UI/UX/client.

Another way to suggest that players act a certain way. Main importance is to keep players from leaving the cave early (e.g. "Chef must set up camp within a five room radius of the treasure room before he can leave."

https://docs.npmjs.com/files/package.json#people-fields-author-contributors

Feel free to add yourself if you are still interested in helping with this!
@zthomae @lwdinh @mhorowitzgelb @Rustynub

One of the goals of this project is to make the Game and all associated objects (like Characters, Items, Actions, etc.) immutable. To accomplish this, we will use the Immutable library. I've already started to "hit my head" on mutation errors with things like CharacterClasses (i.e. corrupting data by mutating pointers instead of "separate" objects). By using Immutable and its types, we can hopefully avoid these errors by having immutable "blueprints" that create separate objects (with unshared pointers), and avoid the overhead of classes. What do you think @zthomae ?

We need to hammer out allegiance bonuses to make sure they are fair (and also worthwhile to have in the game).

Testings should be ran as npm run test. I'm enforcing (:sunglasses:) that we use Mocha, Chai, and Sinon for testing (as devDependencies). The testing directory test/ structure should mimic exactly the structure of dist/ (which mimics src/ via Babel).

I think it would be better to compute proxies for these states off of certain available on the Player interface instead of having these pseudo-enum variables.

Since communication "commands" aren't actions but are still valid, we need to handle them.

See here

I've done most of my development on OSX using Chrome, but I recently ran the client in Firefox on Ubuntu and the blatant white scrollbars weren't too sexy. It might be nice to have some sort of coherent, cross-browser styling using this jQuery library. It might even be cool to put a "Page Map" scroller over the client map.

This should be some sort of tabular view component so players can see others' information (e.g. name, character class, allegiance, etc.). This would also be used for communication (e.g. clicking on another player's name instantly creates a chat/talk command for the player to fill out).

Is this something we would want? I'm fine either way, as I don't know too much about React.

I like the whole Fraktur style. Maybe a simple Fraktur "X"?

What colors/color scheme should we use? (See main.css for some options.)
What fonts should we use? DEFINITELY needs to be monospace, so I was thinking one of these.

Once the game is in a respectably playable state, we should create a GitHub page for the project.

By implementing a special character class and tinkering with how messages are handled, singleplayer could be a viable feature.

Even better would be to package an in-browser Server+Game for an easy-to-launch singleplayer experience.

In addition to dueling and general combat, we need some way to frame general interaction between players (this does not include :to chatting/whispering, shouting, etc. which are "global" to the game state). For example, an interaction might be the doctor/medic healing (or poisoning) another player, or two players trading items.

This would be a generic interface (Grid<T>) that would be used instead of T[][]. It would allow for better abstraction and code de-specialization/clumping/copying.

Should cleanly display game state information for debugging (and possibly spectating later on)