zomgistania

Main page | About | Articles | Previous Posts | Archives

Thursday, June 15, 2006

Input management

I was playing with an idea about how to manage different kinds of "input" (and also output) in a turn-based game. This stuff could probably be applied to non-turn-based games too.

For example:
-input from the local player through keyboard and mouse
-input from the AI "player"
-input from a remote player through a network connection

Now, the game engine has methods to do things in the game, like moving units around the screen and such. Now the thing is, how to express this information to the different types of "players" in the game.

A local player needs to see things on his screen:
-messages, menus, animation

AI needs to access the "raw" data

A remote player needs to get the data through the network:
-The data from the local machine must be sent through the network
-The game running on the remote host must parse the data and display it to the user


So the idea I'm playing with now is that the engine itself does not know what kind of a player it's sending the data to. The engine would just have a bunch of messages and states like...
-Waiting for input from player
-Waiting for confirmation of action
-Turn begins
-Unit selected
-Unit moving
-Unit reached destination

etc.

The engine would forward these kinds of messages to a IO handler class, which would implement some interface the engine uses. The IO handler class itself would then decide the course of action, depending if it's a "RemotePlayerIO" or "AIIO" or whatever.

For example, a LocalPlayerIO gets a message "Unit destroyed"... it plays an animation of a unit blowing up in the game and plays a sound, as where an ArtificialIntelligenceIO would do something like removing the unit from the DB or something.

The IO handler class would also be have to be able to query things from the engine, like "give me this unit's details" or "is there anyone in this tile?" and things like that.


Basically it would act as a proxy between the engine and the user(s).


Oh well. This is another of my gazillion or so ideas about all kinds of stuff.
There are more important matters than this, like making the GUI code (finally)... but for some reason I keep avoiding it and doing other stuff. Getting the GUI done would allow for some more progress, instead of adding "nice touches" or random things here and there.

It's summer holidays and what have I been doing? Sitting in front of the computer, writing code... nothing better to do I guess.

Labels:

0 Comments:

Post a Comment

<< Home