The TODO list for the client (I will start):
Porting:
- The HUD wall radar
- Recording buffer
New:
- A start screen with the logo, should preferably appear at the same time as some menu, or simplest, the meta interface.
- The GUI part of the meta interface should work in a different thread than the code responsible for pinging and connecting to servers. This will eliminate the annoying freeze when trying to connect to an unreachable server.
- Improved newbie help system
- Two configuration modes: basic and expert. The basic mode would show only the most important options. Options should be shown in GUI by category, e.g. ship control, interface, recording, ...
- A small built-in server with locally-run training maps for newbies. The maps would be objective-driven, e.g. picking an item, navigating through a mine field or through a narrow passage, with or without a ball. Hints would be presented to the player while he tries to complete the objectives.
- Support for in-game map switching, e.g. via teleporters. Note: this will require server support.
- Support for different exchangable keymaps, e.g. legacy, ng, bloodspilot, quake 3 style, ...
- OS-specific version string (or something else) that allows to make server-side statistics of client systems
- Adjust window geometry to the current screen resolution on all OS, allow resizing (this is a problem on Mac OS X)
- In newbie mode: a bar at the top/bottom of the screen, containing the most important key bindings
- The message console: fix the key repeat rate, would be nice if it was the same as in the OS
- A message log (easy to do on Linux, but not the other systems)
DONE:
- Keystrokes from the BloodsPilot X11 client (2012-09-02)
bloodspilot-client-sdl TODO
Re: bloodspilot-client-sdl TODO
* Regarding NEW CONFIGURATION MODES: Basic and expert modes sound sensible.
If you place options in categories (which also sounds sensible at first),
you need to choose the categories and related options very carefully.
Otherwise it may happen that, contrary to your original intention,
configuration is complicated. What I hate about settings interfaces, is
when I know which setting I want to change, but can't remember where to
find it, and have to click through all categories.
Therefore I suggest to have a `filter' text field in the settings dialog.
You could enter part of some option name there and the interface would then
show all matching options.
There should also be a related checkbox widget, which if selected would
match an option if the filter matches the option name or the option's help
text.
An additional feature would be a switch to show options by category or by
name (all in one flat list, sorted alphabetically).
* "A SMALL BUILT-IN SERVER ...": I don't think we should bloat the client
by integrating a server into it for the purpose of newbie training.
Instead the newbie help has to become that comprehensive, that it gets any
willing newbie (who is able to read english) going on _any_ map and server.
* Instead of supporting only exchangable keymaps, go all the way and
support multiple configs (better). The currently used method of selecting
the config file via the `XPILOTRC' environment variable, should be replaced
by a new option `configFileName' or `configFile'.
It should be possible to load another config and to save to another config
from within the setup interface (via a standard file selector dialog).
Reasons for the need for multiple configs are that different maps require
different settings for best playability.
For example on item maps, you need to setup keys for quick access to the
items. On standard bloods music you don't need missiles, mines, etc., but
instead team warning messages are very important. Also colors may be
map-specific. Like for example on New Dark Hell, I want visible sparks,
so that I can see cloaked ships. Or fuel boxes are important on item maps,
while they would only distract on bloods. Etc, etc ...
Also the client can be shipped with several configs for different needs.
The player can then choose whichever config he prefers and depending on
what kind of map he wants to play.
There could be configs for item maps, team ball maps (bloods), mouse or
keyboard steering, for mouse steering with thrust on mouse or thrust on
keyboard and more.
If you place options in categories (which also sounds sensible at first),
you need to choose the categories and related options very carefully.
Otherwise it may happen that, contrary to your original intention,
configuration is complicated. What I hate about settings interfaces, is
when I know which setting I want to change, but can't remember where to
find it, and have to click through all categories.
Therefore I suggest to have a `filter' text field in the settings dialog.
You could enter part of some option name there and the interface would then
show all matching options.
There should also be a related checkbox widget, which if selected would
match an option if the filter matches the option name or the option's help
text.
An additional feature would be a switch to show options by category or by
name (all in one flat list, sorted alphabetically).
* "A SMALL BUILT-IN SERVER ...": I don't think we should bloat the client
by integrating a server into it for the purpose of newbie training.
Instead the newbie help has to become that comprehensive, that it gets any
willing newbie (who is able to read english) going on _any_ map and server.
* Instead of supporting only exchangable keymaps, go all the way and
support multiple configs (better). The currently used method of selecting
the config file via the `XPILOTRC' environment variable, should be replaced
by a new option `configFileName' or `configFile'.
It should be possible to load another config and to save to another config
from within the setup interface (via a standard file selector dialog).
Reasons for the need for multiple configs are that different maps require
different settings for best playability.
For example on item maps, you need to setup keys for quick access to the
items. On standard bloods music you don't need missiles, mines, etc., but
instead team warning messages are very important. Also colors may be
map-specific. Like for example on New Dark Hell, I want visible sparks,
so that I can see cloaked ships. Or fuel boxes are important on item maps,
while they would only distract on bloods. Etc, etc ...
Also the client can be shipped with several configs for different needs.
The player can then choose whichever config he prefers and depending on
what kind of map he wants to play.
There could be configs for item maps, team ball maps (bloods), mouse or
keyboard steering, for mouse steering with thrust on mouse or thrust on
keyboard and more.
Re: bloodspilot-client-sdl TODO
Some more ideas, partially related to the SDL client.
* IMHO it would be better to develop the SDL client in the ng repository.
That way all relevant components (client, server, replay, map editors, ...)
are in one place and are also available as a debian package (from the
official repository). Why again start another project? Are there
unresolvable differences between you (kps/rot) and the other ng devs (who
seem to be retired anyway)?
As I said before, I think the fxi server is unnessesary and the ng server
should be the one to be further maintained. Contrary to what others say
about fxi vs ng, I say: fxi is not xpilot. It's only a small subset of
what xpilot is. And although bloods on ng has some differences to classic
bloods, it is still very playable (if not better). Plus ng offers all the
other features from classic xpilot, which were removed in fxi and has
valuable new features.
I know that it hurts to give up a project into which you have put a lot of
work. While it's nice to see you join me in client development and I agree
that the SDL client should have the most potential, I feel also a bit
frustrated. Because I think the bloodspilot x11 client is almost ready to
revive xpilot if only a real newbie help was was implemented (quite a lot
of work), the key config was finished (little work) and it was included in
the official debian software repository (no idea how to achive this).
I am mainly able to write C code, but have no experience with source code
management tools, like git or GNU autotools. So I don't think I can port
my "countless" improvements/cleanups to the SDL client (easily or in
acceptable time).
The biggest item missing in the SDL client is probably recording. Since
the current recording format/code is X11-based, it will be impossible to
reuse it without considerable adaption.
Finally I think it's good to have portable code, but would not support
non-free operating systems like windows and apple myself.
Instead support free and open source systems, to encourage their use. If
the game is well presented, there will be enough potential players on these
systems.
* IMHO it would be better to develop the SDL client in the ng repository.
That way all relevant components (client, server, replay, map editors, ...)
are in one place and are also available as a debian package (from the
official repository). Why again start another project? Are there
unresolvable differences between you (kps/rot) and the other ng devs (who
seem to be retired anyway)?
As I said before, I think the fxi server is unnessesary and the ng server
should be the one to be further maintained. Contrary to what others say
about fxi vs ng, I say: fxi is not xpilot. It's only a small subset of
what xpilot is. And although bloods on ng has some differences to classic
bloods, it is still very playable (if not better). Plus ng offers all the
other features from classic xpilot, which were removed in fxi and has
valuable new features.
I know that it hurts to give up a project into which you have put a lot of
work. While it's nice to see you join me in client development and I agree
that the SDL client should have the most potential, I feel also a bit
frustrated. Because I think the bloodspilot x11 client is almost ready to
revive xpilot if only a real newbie help was was implemented (quite a lot
of work), the key config was finished (little work) and it was included in
the official debian software repository (no idea how to achive this).
I am mainly able to write C code, but have no experience with source code
management tools, like git or GNU autotools. So I don't think I can port
my "countless" improvements/cleanups to the SDL client (easily or in
acceptable time).
The biggest item missing in the SDL client is probably recording. Since
the current recording format/code is X11-based, it will be impossible to
reuse it without considerable adaption.
Finally I think it's good to have portable code, but would not support
non-free operating systems like windows and apple myself.
Instead support free and open source systems, to encourage their use. If
the game is well presented, there will be enough potential players on these
systems.
Re: bloodspilot-client-sdl TODO
Not replying to everything here, but a few thoughts:
It's good to have a few clear goals. Our current focus on the newbie friendly client is a good one. Rather than having 100 goals none of which we complete, let's take small steps to improve the current situation.
I think we should continue on Angeba's effort to improve the X11 client with the key configuration, newbie help etc., while Rotunda and I support this development effort and add similar functionality to the SDL/OpenGL client.
Regarding NG: MAYBE after we completed the current development effort we could look into how to merge the BP stuff into NG, to reduce the fragmentation. I should still have admin rights in NG. As we seem to be the only active developers, in case we want to do this, I can add Rotunda and Angeba as NG developers.
Another possibility is that we retain bp as our active working repository, but when we have something which is clearly superior to NG, i.e. a client that newbies find more managable, we copy that into NG.
-- kps / Samaseon
It's good to have a few clear goals. Our current focus on the newbie friendly client is a good one. Rather than having 100 goals none of which we complete, let's take small steps to improve the current situation.
I think we should continue on Angeba's effort to improve the X11 client with the key configuration, newbie help etc., while Rotunda and I support this development effort and add similar functionality to the SDL/OpenGL client.
Regarding NG: MAYBE after we completed the current development effort we could look into how to merge the BP stuff into NG, to reduce the fragmentation. I should still have admin rights in NG. As we seem to be the only active developers, in case we want to do this, I can add Rotunda and Angeba as NG developers.
Another possibility is that we retain bp as our active working repository, but when we have something which is clearly superior to NG, i.e. a client that newbies find more managable, we copy that into NG.
-- kps / Samaseon