Ref1: C. Horstmann, G. Cornell, 2009, "Core Java: Volume I - Fundamentals", 8th Ed.
On the Client side, a pop up window or frame will be needed. A dialog
box may work since the quest acceptance is yes/no.
Check out how the Magic Map works to get its diplay up. This has to be message based, so trace its data flow from Server to Client.
Cleaned up and put in some messages..this should work now for greeting
Players when they enter and if they stay in the room.
Just need to add to inventory of a room, same as Zombie.
Add to MudMain.properties
item.questNPC001.description=SgtPhilips, the local quartermaster.
and add to OfficeLL5824
and it almost works. The timed response works, but the message on arrival
Still had the 50% follow active..deleted that and added a sayGoodbye task to trigger on GO..still have to check for that
Player leaving to close the screen, else it would close if anyone left!
Also added an AskTask for the ASK command...don't know if this the way to do this yet.
Well, the ARRiVE task now works, but the ASK doesn't..hmm..got pop up to show by not testing the command for the NPC
name. Seems the alias list is not being generated for the class..hmm..these derived classes have a test on the alias before sending to MudObject to add to the alias list..going to remove for now..hmm..can't, breaks the structure..so making MudObject.addAlias public and calling it after super()..that did it..ASK command works now...woo hoo
Add toLowerCase() to msg string also..capts in name now work..back to fixng up the Client.
Added the ButtonPanel class (from ch 9 pg 456 )
Well, it sort of works..four buttons used to indicate the selection. The buttons can be replaced with components, but they still show up along the bottom so just going to use the butons.
The dialog box is modal though, i.e. output stops while it is open, but the game doesn't. This causes the text box to 'catch up' once the dialog is closed. Be fore warned.
If you "ask phil" then the dialog pops up. Now to work on the Channel system to support the four types of questions. (see ImplimentingChannelsForZMUohmy.html)
Well, seems Channels is not the way to go. So, adding com.sun.sgs.darkmud.messages which is a message module from another game I was doing. It uses the Message Factory concept that I first saw in the sgs-tank demo game and appearantly is a common means of message management. Its operation and use is described in ZMUohMy_MessageFactory.html. This method will be used for all messaging in the game, so time for a major rewrite of Server and Client message operations....wonderful.
Well, that took a bit longer than expected, but the MessageFactory system is in place to send messages from the Server to the Client. Going from the Client to the Server is a bit more problematic due to the way all messages are treated as commands. May work through that while working on the overll problem of User / NPC interaction.
The core problem is linking this NPC to the User that issues the ASK
1. User uses ASK <name> command to trigger a AskMessage to be sent to their Client.
2. The NPC and User ManagedReferences are added to a Contacts Hash list <QuestNPC, MudUser>
3. A new Message class NpcMessage is use to send messages from the Client. When this type of message is recieved by the Server, it checks the Contacts list and routes it to the NPC associated with the User.
4. The NPC responds to the message as needed.
4a. The NPC maintains a state machine kind of logic to manage the dialog with the User.
4b. The NPC maintains a Hash list <MudUser, State> to be able to talk to multiple Users.
NOTE: This could be used to only talk to one User at a time also.
5. repeat 3 and 4 as needed and remove entry from Contacts list when done.
5a. Also remove and clean up state if User leaves the area. Need to detect this.
First thing to do is find out where ALL messages get received by the
Server and use the new Message Factory protocol there.
Going back to the original investigation of DarkMud, the UnderstandingDarkMud01.html file shows that PDS calls the Server side object with the ClientSessionListener interface uses receiveMessage() to receive messages from the Client. This object is the MudUser class.
The plan will be to send all command messages as TextMessage objects. All of these will have their message element passed on to the parse() method to be processed as before. New message types will be added after these changes are working.
PS #1 is in place now. The next thing is a simple database of Quests.
Quests usually have the following
A unique ID for ease of management
Flags and counters if the quest can be done multiple times
A list of things to do or aquire (need a way to record the action, check item list)
A reward of experience points, item, cash (need a data struct to hold these)
A link to the next quest
The Server will maintain a Hash list of Quests by ID and ManagedReferences.
The Server will have a Hash list for each MudUser object to manage the state of the quests that the Player has active and a list for completed quests.
The Quest active list will have the ID, kill count, and progress state. Everything else comes from the Quest object.
|questID||Unique number for this quest|
|name||Quest name displayed in the GUI Assignments list area|
|description||Description of the quest used when it is given or when selected from the GUI list|
|kills||Hash list of type and number of kills needed|
|collection||Hash list of type and number of items to collect|
|exp||Experience points awarded on completion|
|coin||Cash awarded on completion|
|reward||Item rewarded (could be a selection list)|
QusetNPC will have a list that is build when they are insanciated.
Quest objects are copies to the User's Quest list and deleted when done.
Ok, try to implement Quest objects and list for MudUser..only kills list will be active for starters.
The kills list has a Mob ID and a number of kills needed..hmm..MudObjects have an id already,
but this is a system generated unique number..need a MOB type ID for quests..
Adding mobID to MudCharacter..Each sub-class will set it base on what they are.
Zombies use 1000 to 1999, so a series 1000 is any zombie and 1001 is Fred. 1002 is Bill, etc.
Adding questCheck(MudCharacter.ZOMBIE) to MudUser to call from Zombie.java
Always return true for testing.
If true, remove quest #2. Then you can add it again...in theory..it works.
Update repository and update server this week. Add ASK to help list.
Then on to better combat and inventory stuff.