Tutorial

This tutorial will present a special type of connection to UT server - ObserverConnection (OC). Purpose of OC is to observe other player/bot on the UT game server (always one at a time). With OC you are able to get all the GameBots messages that come for the observed player/bot and some other that export for example whether player/bot started/stoped shooting.

In this tutorial we will show you:

Note: If you are interested specifically in controlling the game server and obtaining global information, consult the ControlConnection tutorial.

Setting up the ObserverConnection

To set up this example in NetBeans follow up the steps in Opening Pogamut Examples chapter. We will need to open custom control server archetype and modify it a bit. The archetype information is below.

For UT2004 example:

  • Group Id: cz.cuni.amis.pogamut.ut2004.examples

  • Artifact Id: 14-custom-control-server-archetype

  • Version: 3.3.1

  • Repository:http://diana.ms.mff.cuni.cz:8081/artifactory/repo

Observer connection functionality is not yet implemented in UDK.

The easist way how to create your own custom observer connection is to download and modify our observer connection archetype above.

Hooking up the observer to start to observe player/bot

To start observing a player or bot you have to issue Initialize command. In this command either set attribute name or Id to name or Id of the player/bot you want to observer. E.g.:

              getAct().act(new Initialize().setName("SomePlayerName"));
          

If the player with supplied name or Id is on the server you will start receive his synchronous messages right away. If it is not, nothing will happen (and you won't receive any warning message).

Note: All the players are exported in a handshake right after your ObserverConnection connects to the server, so you may decide which player to observe in playerListener (as in the big code example above).

Getting information about the player/bot

When you have started to observe a player or a bot you can get information about him the same way as you would get information when coding a bot. You will hook listeners to messages of interest - e.g. Self message or Player message and store the important pieces of information somewhere.

The observer connection can be configured, so not all of the messages will be exported for the observed bot or player (this can save some resources as exporting of messages is in fact a bottleneck of UT2004). See ConfigurationObserver command for more information.

Note that exporting a lot of messages from the environment is computationaly intensive process. E.g. if you hook 5 observer connections to one bot you will probably get very laggy experience, or the bot maybe won't move at all. Always try to minimize the number of observing connections, good rule of thumb is to not to have more than 8 connections (bot or observer) to the server at the same time. This may differ depending on your hardware.