Game design question...

Blake blake at kingdomrpg.com
Mon May 7 05:51:21 UTC 2007


Hey, gang:

	I'm designing a game and have ended up with a structure like this:

1. The UI creates a command object.
2. The UI passes the command object to the game.
3. The game tells the command object to do its thing.
4. The command object invokes the appropriate method in the game.

	I didn't want to invoke the game's commands directly from the UI. I have  
two input systems, one that can build command objects through menus and  
one that can process a command string.

	I need step 2 to allow the game to validate or alter the command.

	Step 3, gives a separate object to handle its commands. Resolves any need  
for case-type statements.

	Step 4 actually calls the code that gets the job done.

I guess what I'm wondering is: Too much? It seems like a lot.

In the game, the code looks like this:

	aCommandObject := aGame process: commandText.
	aGame do: aCommandObject with: player.

In the game object, there's this in "do":

	aCommandObject doWith: player and: self.

and each command object calls back to game, like:

	aGame move: x at y

or:

	aGame strike: x at y with: value

Any thoughts?

	===Blake===



More information about the Squeak-dev mailing list