Hacking NT:TNG

Overview of interesting solutions used in Netrek. This mainly glues information together, as any real info is available in the .jav this only contains glue-stuff. Any real info is added to the specific classes.

Architecture

NT:TNG is built on top of the CSGC package, and thus gets all the advantages from there.

I would recommend getting the Whiteboard edition of TogetherJ and run it on the netrek package. It can give a nice overview of the whole packages.

The netrek package contains four sub-packages

Initializing the game

The main class, which handles argument parsing and starts in either client or server mode, is the Netrek class.

ServerStart

If Netrek is to be started as a server (which it is by default, if no -host argument is given), it creates a NetrekServerDriver and a Server to listen on incoming events. It then prepares the player database and then loads the server config file, normally located in the installations setup directory and named server_setup.py. It's a JPython file which defines all configurable options in the game. Finally, the server runs the setupGalaxy() method which must have been defined in the config file, and finally prints out "... server is up".

At this stage, the server listens for connections. Once the server gets one, it creates a proxy for the connecting client and hands it to the server driver, who in turns adds it to itself and the server side simulation controller. After the next tick has been run, the sim controller goes through all new clients, and for each new client, it traverses all valid objects in the simulation and asks for their init events. All the init events are added to the proxy.

Finally, the proxy is added to the client list and will thus get any further events added to the simulation.

At the next flushOutput(), the client will start to recieve the events. Normally, the number of events will trigger a mode-change to bulk mode transfer to efficiently move all the events over to the client.

ClientStart

To start Netrek as a client, use the -host hostname argument. By default, it will target port 2495 at the given host, unless a -port portnumber is used.

The client will first attempt to find the personal configuration files, using the "user.home" property for the directory and "./nttng_config" as the filename. (hmm... need to change this - too platform dependent...). This file is loaded by the ConfigManager, which handles all kinds of configuration information (this isn't properly implemented yet, needs a lot more work).

The user interface is abstracted through the NetrekUI interface in order to allow both GUI's and non-Graphical UI's, typically for robots. If any -scripted_ui filename.py argument was given, then a PythonUI class is created and no GUI is used. This is used to start simple robots used for testing - some UNIX start scripts for this are availabel in the nttng/scripts directory, as is a dumb_bots.py script.

Assuming that no scripted_ui argument was given, the client creates a NetrekGUI object to handle the ui.

With the ui handled, the client creates a ServerProxy to get information from. There are two kinds of proxies possible here. The ReplayProxy is used for replay (and debugging) purposes. It is used if a -replay eventlog argument is given.

If that wasnt't the case, then a CsgcServerLinkProxy is created.

Finally, a NetrekClientDriver is created and started.

It adds itself as a SimTransitionListener on the simulation engine and waits until the NetrekServerInfo object becomes valid. Once that happens, it does some initializations and then calls the doAuth() method in the ui to start authentificating the player. Further actions are up to the user interface.

Introducing a new player into the game

Authentification, choosing a team, choosing a ship.

Authentification

The client creates an AuthRequest and sends it to the client, where it calls the CsgcClientLinkProxy. It verifies that the name and password isn't illegal (or that it is a guest request), before calling its newAuthHandler(), a TemplateMethod with a default implementation returning a CsgcAuthHandler.

Control is then passed to the PlayerDB.

Ships and positions

A ship consists of two major parts. Anything which has to do with the position of the ship is in the ShipPositionDriver class, while all the rest is in the Ship class.

Phases

The four phases in netrek.

Tractor/Pressors

Extra demands put on the game to handle t/p's. Chains.

Commands and requests

how to send a command from the user to the server. Trace it.

TorpFireEvent

Special case on optimizing torp fire.

Creating new objects

How to build new objects. Explain state encapsulation and the genstate stuff.

Looking for bugs

Describe the various tools for debugging (DBG, DependMapper, plotting), how to verify that players see things correctly.

Performance

Last modified: Sat Nov 14 16:25:20 MET 1998