Interface complexity problem in game

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.

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.

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.

The encapsulated insides of 'world' will be unavoidably very
complicated. Does this mean that the interface must have undesirably
many methods, or is there a way to avoid that? Is it something I can
prepare for even without knowing what the exact complexities of
'world' will be?
.

Relevant Pages

  • Re: Code is organised incorrectly
    ... try to avoid inner classes unless you're sure they are the ... simple game) is likely going to need more than one class. ... existing code into that design. ... A class to coordinate the game and the interface (using Swing; ...
    (comp.lang.java.help)
  • Re: Abstract public member variales?
    ... client (the problem solution) is indifferent to the details. ... at the level of abstraction where you define how the game works. ... I describe the workings of the game at many levels of abstraction, depending on who I am talking to. ... At the other is the level of abstraction that I use when summarizing my design in a paragraph for usenet. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... design; it can only be achieved in maintenance and a sufficiently ... To build game software one needs an unambiguous ... I have no problem with designing how the creatures will move, ...
    (comp.object)
  • Re: Subscription Fees - When did they all start?
    ... MMO's, IMO, don't have more ISSUES than single player games, BTW. ... glaring design flaw that I have NEVER seen in ANY shipping game. ... better than nerfing the overpowered powers. ...
    (comp.sys.ibm.pc.games.rpg)
  • Re: When is a function not a function?
    ... a DOM element and Array or a value with falseness. ... betrays very poor code design. ... subject of the test is expected to be any of a javascript function ... There is nothing to say that an object implementing the Node interface should not be a function object. ...
    (comp.lang.javascript)