Development Roadmap
For anyone looking to contribute to the development of Xpilot-AI, here is a summary of the current state of development, to give an idea of the areas where help is needed.
Xpilot-AI
Issues
Some issues and bugs need to be fixed.
- The xpilot client disables key repeat during use. If the client ever crashes due to improper use of Xpilot-AI, key repeat is never reset. This is very annoying.
- There is no function that closes the client. To close the xpilot client you must press the "Quit" button on the window, or close the window.
- Starting multiple clients from one program will bring the whole thing crashing down (xpilot-AI is not threadsafe)
Code Quality
The code could be in better shape. As of right now it can be difficult to follow.
- The functions that do any real work are unneccessarily long and convulted.
AI_wallbetween, for example, is 388 lines long, and full of nested loops, monstrous conditionals, and other needless complexity. - A few proper data structures would make the code much more clear and predictable.
- Initialization code is spread over several functions whose interactions aren't immediately clear. Initialization should all occur in one place.
- No cleanup is done when the client closes.
API
The C API is pretty sane, and pretty nice to use. There are some inconsistencies and old functions that can be removed, however. AIshot_imaginary, for example, does not have any obvious use and can be calculated by the programmer with some simple math. Also, the functions that return strings return pointers into memory used internally by Xpilot-AI, that the user should not be messing around with.
Some way to close the client needs to be added. Passing in some state information as arguments to the AImain function may be a good idea as well, such as the number of frames since opening a connection, and whether the agent is alive or not. It could reduce some of the need for the abundant accessor functions.
There should also be some accessor functions that take in a player name as an argument, for example, to get the score of a certain player regardless of where they are on the map, and other meta-information.
I'm not sure if there should be any dichotomy between the screen and radar: Since the ships on screen are a correctly-ordered subset of the ships on radar, why not just have one set of functions to get positional info that uses the radar?
Xp-proto: experimental xpilot protocol library
xp-proto is an implementation of the xpilot client protocol in C. Or rather, it will be. Rather than emulating keyboard input to an X11 window, xp-proto cuts out the middleman and provides functions for communicating directly with the xpilot server via the xpilot-protocol. There will be no display or user-input code, keeping the library very simple. It is being written carefully to be thread-safe, with minimal global state and strong associations between individual connections and their game states. It is being developed to achieve stability through simplicity, and to make it easier to add new features to the Xpilot-AI API. To see the current state of xp-proto, and/or contribute, clone the git repository:
git clone git://xpilot-ai.org/xp-proto.git