My own first priority for work on B&S is not on game features, but to help with sorting out the technical needs so that there's a clean slate - a "less hacky" Voxlap game first, and then to consider new additions and branches. I think this idea is more-or-less shared by our other devs.
Pyspades is kind of problematic in that respect since many(most?) of its popular scripts are based around protocol hacks. Overhauling it to get the things we want will break a lot of scripts. But the stuff that is still good - all the little bits of tuning and fixes and administrative features - would be a big loss to throw out. So it won't be a simple process of patching here and there; either we'll have "big ugly breaks" where a lot of scripts have to be maintained to keep up, or a new server gets developed in tandem with our existing one.
All that in mind, I have really "core" things on my wishlist, and I hope to work on some or all of them eventually, in some fashion.
- * More flexible concepts of players and teams. 4 or more "real" teams + spectating(Yourself made a cool 4 teams script, but it really deserves a full treatment); eliminate hard caps on numbers of players; customizable team joining UI; allow an "AI-only" team to exist so that NPC characters can be made; allow players to be things other than deuces(Rats invading the trenches? Aliens pouring out of the UFO in Mesa?)
* More flexible entities to allow for new game modes and to remove old hacks. More than one intel in the game, capture points and win conditions that don't involve the tents or intel, airstrikes that aren't grenades thrown by teleporting the player, customizable physics and collision parameters.
* Moving some common /commands into client UI, and investigating a "structured" form of /command that transmits data via JSON or similar, reducing reliance on abusing the chat system. As it was implemented in pyspades, complex commands often implemented some ad-hoc parsing themselves, when what was really called for was something more like a type system that would translate an incoming string into usable data before it reached the command proper.
* Miscellaneous protocol/API additions so that the server can provide the client with some new custom UI elements at connect time. Text and image positioning/updates and button menus are two obvious ones - in Iceball the core display functionality could be done via a Lua script + APIs, however it would be worth considering something custom that's not dependent on Lua(especially since a lot of things can be done just with a bit of text, menus, and an icon or two).
* Some new goodies for server admins. This is something I've mentioned a few times in the past but never got around to. More statistics, and ultimately, some overall "popularity" and "playstyle" metrics that help sum up the type of game experience a server has, which can feed back into the community's decisions and hopefully grow the game further. The metrics shouldn't be intended just as "optimization" but also a tool to broaden the game and maybe discover new gameplay, simply by extrapolating how to hit certain values.