Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

MUD Action Objects

Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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() 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.)
    Bookmark Topic Watch Topic
  • New Topic