Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (113)
games submitted by our members
Games in WIP (562)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  MUD 'action' objects  (Read 1009 times)
0 Members and 1 Guest are viewing this topic.
Offline abirmingham

Junior Newbie





« Posted 2009-03-23 20:25:17 »

Currently I'm working on a MUD as a hobby. Every 'action' in the game is implemented via abstract class Action and concrete sub-classes, like "Put", "Attack", "ChangeStance", etc.

I'm looking for suggestions on the design. It currently works, and is relatively open for expansion, but it just seems... messy. The architecture is especially messy in regards to sub-classes of Action which deal with Inventory functions.

These Action sub-classes contain three primary components:

- static ActionResult instantiateAction(String input) : This is called using reflection(so it has to be static)on the server, when a client enters a command that corresponds to this Action. The string is entered into another object which returns a Targetable object. If a Targetable object cannot be found, or if the object is not of enum TargetType.ITEM, then an ActionResult is returned with an error, the error is sent to the client(IE: "You can't pick that up, it's a monster!"), and the Action object is not created.

- Constructor(): createNarratives(), a private method, is called here in order to produce descriptions of the actions, which are in turn sent to clients. The action itself is also placed on the player's actionStack to be performed.

- initMechanics(): This is called when the action is actually performed from a mob's actionStack. As part of these particular sub-classes, an inventory function is called like Stow(Targetable), which can assume that what its getting is an item and isnt null, but not things like whether or not the item is in hand for stowing. Therefore this too returns an ActionResult which is checked for errors. If it has errors, then createNarratives() is called again, and its original (successful) narratives are replaced with an error. (IE: That item is on the ground. Pick it up first.)

Like I said, not the worst architecture in the world, and it works, but we ARE talking about a lot of eggs in one basket: recognition and response to client's text entry, narrative creation and error messaging, and actual nuts and bolts mechanics. (Although the latter is fairly well encapsulated into the Inventory object, this is not the case with most other Action sub-classes. Most of them contain about 25-30 lines of mechanics code. This provides for a TON of customizability in action specifics, but only because the developer is forced to work really low-level at all times.)

Thanks for any suggestions/feedback!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (15 views)
2014-09-12 09:08:26

Norakomi (45 views)
2014-09-10 13:57:51

TehJavaDev (57 views)
2014-09-10 06:39:09

Tekkerue (26 views)
2014-09-09 02:24:56

mitcheeb (49 views)
2014-09-08 06:06:29

BurntPizza (33 views)
2014-09-07 01:13:42

Longarmx (19 views)
2014-09-07 01:12:14

Longarmx (21 views)
2014-09-07 01:11:22

Longarmx (20 views)
2014-09-07 01:10:19

mitcheeb (30 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!