sir-galahad / galamud Goto Github PK

The proof-of-concept as it exists uses telnet for a client and I've made a number of concessions to the over all experience toward that end, but i don't think i can reasonably go further down that road. I'm not interested in implementing a full telnet server, and much of the way I want to go with the user interface will be simplified if i can have a client handling the presentation. Not to mention it wouldn't hurt off loading the "commands" (not the actions) to the client to take some of the load off the server.

Because the methods to execute the action queue and the methods to add a player to a room both lock the lockobject if two players cross paths moving from room to room both room threads will hang holding on to their lock while trying to get a lock on the opposite room.

The simplest solution is probably to add a join queue to the rooms.

As it stands right now character actions are executed in the order they are registered in, and NPCs always register first. This means in a scenario where an NPC and a player each have 1 hp left they player's action for that turn is moot because they already doomed. Solution move player actions into a list and execute them in a random order so that in the situation mentioned above players will have a fair shot at survival.

At some point here i'm going to want to make a much bigger dungeon than that in the current proof-of-concept. right now i'm imagining a simple program that will generate a dungeon of any X*Y size with an interface that lets me move from room to room setting the room description, room type, enemies, and exits and saves it in a file of some sort, xml seems reasonable enough for that right now.

Additionally i'll need to support a way to load that file to instantiate the dungeon