Re: Interface complexity problem in game

Responding to Guild...

Two questions from beginners about constructing an RPG game in one day. Coincidence? Tell your instructor that a computer game is too big a project for a homework problem.

I'm trying to design a game carefully and deliberately, using every abstraction trick that I can to make it extremely maintainable.

The active entities of my game are represented as objects of a common class, subclassed and composed for varying behaviour. I let the objects control their behaviour when I call a method on the object called act(world). I can't define what this method will do, because the point of it is that it will vary wildly from object to object.

This is probably a Bad Idea except in very specific situations. See my response in the "RPG game in UML" thread.


I pass in a 'world' object that gives access to the things that may be needed by the entity to do something interesting. And that is where the problem is: My current strategy is going to result in the class of the world object having perhaps hundreds of methods, everything that any entity in my game might want to do to the world.

This is an Even Worse Idea for exactly the reasons you identify. (One exception below.)

Generally collaborations in OO applications should be on a peer-to-peer basis. One object sends a message directly to another object that needs to respond. To address the message (i.e., get to the right responding object) one navigates relationships from the Class Model. Using relationship navigation is one of the most important aspects of OO development because it is the main tool for managing state variables (i.e., restricting access to attributes). See the category on Relationships in my blog for more on this.


I know that it is a bad thing to have such a huge interface. I don't know exactly what the methods will be at this stage in design, but I want to adjust my design to allow me to add complexities to the 'world' without adding nearly as many complexities to the interface.

I do not have a clear idea of the domain that I am working with and that's an unfortunate but unavoidable reality. However, I can say that the overwhelming majority of methods on world objects will be of the form: world.doSomething(parameter,position), where an action is taken upon a spot in the world nearby to the entity such as slaying a monster, opening a door, cutting down a tree, etc. with a different parameter or parameters for each kind of action.

This paragraph suggests that 'world' represents another, largely undefined subsystem. In that case it is a subsystem interface. Using the GoF Facade pattern is a common way to implement subsystem interfaces. While that Facade is a single class with a large number of interface methods, it does not implement the functionality. It is simply a buffer class that re-dispatches the messages to the objects that implement the subsystem. So in that case a large number of methods is acceptable. In fact, it is highly desirable because it hides the implementation of the subsystem.

What you do NOT want to do is provide a mega-class /within/ a subsystem. Within a subsystem objects have carnal knowledge on one another and talk to one another directly. As you noticed, such god classes are big and complex. Consequently their cohesion is abysmal and they are a pain to maintain. Whenever your classes that implement a subsystem become so large that cohesion is sacrificed, it is time to delegate responsibilities to other classes.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • software install
    ... everytime I try to install a game from a cd I get an error form a 16 bit ... subsystem the system file is not suitable for running ms-dos and microsoft ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Handling error/status messages by interface to C++ programs
    ... You can then use a mode attribute somewhere to determine which subsystem to access based on the environment. ... A more elegant approach is to put the code for both UI modes in the same subsystem with one subsystem interface. ... They can also run either in the console or Windows mode, and send appropriate error and status messages. ... It also requires unique design at the OOD level. ...
    (comp.object)
  • Re: Text terminal rendering design
    ... problems in my design and so it sometimes seems you are pushing back ... The first issue is a fundamental principle of my subsystem interface ... The idea is that I have the client coordinate the conversion ...
    (comp.object)
  • Re: Encapsulation vs separation of concerns
    ... Once that subsystem is rewritten one can be ... The use of a particular RDB access technology like SQL should be ... The messageID has semantics like "I'm done with Customer data" and the ... persistence access subsystem interface then dispatches to whoever within ...
    (comp.object)