thegrandmother / mud Goto Github PK

Rework the WorldBuilder object in the generalobjects.worldbuilder package to use JSON for items and rooms.

We need to write down a proper specification of the connection protocol.
What orders are what messages supposed to be sent and what the messages needs to contain in order to establish a connection.

Logging in and registering from the client does not handle the errors received.
And btw: When a player registers he is also automatically logged in.

When a socket is closed the connection is not removed serverside!

The players inventory must increase with the players level.

Otherwise everything is just plain silly.

Server sends both a GENERAL_ERROR and a REGISTRATION_REPLY on a failed registration attempt.

I think its best if it only sends a registration reply.

What should the graphical design and general layout of the interface be?

Server occasionally crashes on registration.

[8:59:5][INFO] A new connection has been established! IP: 130.243.249.10
[8:59:13][INFO] IP: 130.243.249.10 sent message: c2VydmVy;cHBw;HANDSHAKE;null;1450101553471;
[8:59:15][INFO] IP: 130.243.249.10 sent message: c2VydmVy;cHBw;REGISTRATION;null;1450101555559;cHBw;cHBwcA==;
[8:59:15][FINE] Received message from client. Calling execute action.
[8:59:15][SEVERE] null
Stack trace:
org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:573)
org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:550)
ioopm.mud.communication.websocket.WSServerAdapter.sendMessage(WSServerAdapter.java:194)
ioopm.mud.game.GameEngine.broadcastToRoom(GameEngine.java:73)
ioopm.mud.game.GameEngine.handleRegistrationRequest(GameEngine.java:164)
ioopm.mud.game.GameEngine.handleMessage(GameEngine.java:112)
ioopm.mud.Server.<init>(Server.java:84)
ioopm.mud.Main.main(Main.java:54)

Font know why, nothing weird with the input. Appears to be the broadcast to room that screws it up.

We really should fix so that the server logs the messages in plain text.

Dude. You should definetly add a .trim() to all the input strings in the client. Right now if one writes "say "
one gets a "incorrect message". I dont have time to fix this right now :P

We need to provide help for players. Right now there are only two people in the world who knows how to play this game.

Add support for websockets in the MUD, this will allow webbrowsers and other stuff to connect to the server and play the game.

Clients never gets removed or timedout. I logged in a bunch of users like 30 minutes ago and they are still active :/

We need to write a new user interface since the console based one was really silly.

With a user interface written in javascript we can achieve a lot more nice functionality than using ANSI codes in the terminal.
Scrolling and asynchronous display of events without interfacing with the user input field will be trivial.

This issue is predicated on issue #8

It's currently possible to inject Javascript code in the chat.

The game engine is horrible.

There is a lot of functionality that needs to be moved to smaller functions.
Such as a general validate action method for both all different types of actions instead of having tonnes of checks in each action type.

This was due to everything being so beta when the actions where implemented.

Make sure that no action can affect or send messages to a player not logged in....

I forgot to add a timeout in clients. Currently the old clients does not terminate the connection if the server does not respond to their messages.

If a client refreshes/updates their page their new connection gets closed when their old connections times out. A possible fix to this would be to limit clients to only have one connection per IP-address.

We have to add support for admins and admin commands.
Commands:

• Ban
• Make Admin
• Kick
• Mute
• Teleport
• Broadcast (broadcast to all players on the entire server)

Currently it is not possible to use the web-based client due to the new modal input when using it through firefox. The input field does not accept the input it is given. I.e. pressing enter does nothing.

IF we where to continue down the hardcore nerd and Vim path i have an awesome idea...

Adding user configurable macros <3

Imagine if we have something like a register. The user could then send a message on the form:
record reg_a {arg} <message> # <message> # <message> # ....

An example of recording a macro performing a combo attack could be:
record reg_a {target} unequip # equip axe # attack {target} # unequip # equip knife # attack target

We could add level restrictions on the macros as well. Such as the number of messages in the macro and the number of arguments is somehow proportional to the users level.

And the most awesome part is that this would not be incredibly difficult. It would actually only require some minor refactoring of how the messages are handled in the game engine.

I recommend that we assign this to the version never.ever release milestone.

I have recently discovered taiga.io and it is really cool! Basically it supports both kanban and scrum, as well as having a really nice issue tracker and more goodies.

The best part of it is that it is completely compatible with both gitlab and github with webhooks!

More on it:
https://taiga.io/support/github-integration/
https://taiga.io/support/changing-elements-status-via-commit-message/

This is a dummy issue. Used to circumvent only having one milestone per issue.

Make Message.deconstructMessage() to parse messages using regular expressions instead of the current implementation. This should enable for a more declarative definition of the layout of messages and make future refactors and redesigns easier.

akjsdjfhlksjdlkfsa
fsdfö

Currently the old client is only used for testing. It is no longer needed for users and can be refactored out.

The real client inside the MUD.jar get stuck in the terminal if the connection is refused. The prompt is stuck on "Pleas wait...." instead of asking for an alternative URI.

We need to re add hearbeats to the game to detect all disconnects. Currently the game wont detect when a player refreshes the webpage or simply closes the browser/tab. This can be fixed by re-introducing heartbeats to the MUD.

Provide auto complete in normal mode.

Rewrite the communication package to use websockets instead of raw TCP sockets.

It is possible to inject messages inside messages. We need to escape all input from the user before we construct the messages! An example for this can be seen in commit e212d98

Well this is tied in and in a bit of a conflict with issue #26.

We need to have a way of making the connections persistent when one reloads the web page.
Unfortunately that is not possible to do with javascript.

We some how need to add a connection id so that the the server can detect when the same client gets a and remove the old one.

This should happen seamless. This might be hard to implement but in the meantime I could add a warning pop-up when someone tries to leave or reload the page.

How should the combat system work?

How should the damage dealt be computed?

How should the level difference between the players affect the outcome?

How should the difference between the users level and the weapons level affect the outcome.

What should happen when one player kills the other player?

Implement bCrypt to store passwords.

We should add an editorconfig-file to the repo. This will allow us to define a coding standard that will be consistent for all collaborators, assuming they install the editorconfig plugin for their text editor / IDE.

Take a look at http://editorconfig.org/ for more info about the plugin.

I move that we remove the whole ioopm/mud/ part of the source tree.

It makes no sense since the IOOPM course is but a fading memory and we are not going to have any more Java than just the mud.

We could hold out with this one until the database and admin branch have been merged into master.

Have the authentication give back more information than just a boolean. Right now a client has no idea why a login/registration was unsuccessful when there are several reasons why a login/registration might fail

This issue is tied to isse #9. I suggest we hash the passwords using BCrypt.

Add a persistant storage to the MUD to store users and stuffz. Consider a SQLite3 database for easy management.

The old tcp sockets are no longer needed after the switch to websockets. They can be removed entirely.

Enable the option to use encrypted communication over the new websocket connections. This should be an easy fix but is not very high in priority.