GSoC 2014 Server Side


Online Support

To further support upcoming online modes, several new features are needed, mostly on the server side. Some examples are listed here, but feel free to come up with your own (additional) ideas.

Online User Administration

For online multiplayer we've built upon our STKaddons code base (live at to reuse a lot of the account code. This has a nice side effect that the accounts at the site can also be used for online multiplayer. The goal of this project is to have a way to manage what happens in (future) online play. The initial step for this is to add the possibility to assign different properties to users. Examples would be:

An administration panel/portal should be developed that the moderators can use to manage the different users and their properties. It should be nicely integrated with the already present user panel. Keep in mind that it should be relatively easy for us to add new roles in the future - the online system is still pretty rudimentary, and we might need additional roles later.

The above mentioned features will be done server-side using PHP and MySQL. Some functionality would only be required online (e.g. banning people), others might be useful to have them in game (e.g. it might be useful if new addons could be approved directly after testing it, without the need to go to the addons web page). At least you should provide an API that STK can use to query about permissions.

Guest Accounts

Allowing people to use a guest account for online races (once they are supported). It makes it much easier to just test the game, without the need of an account creation (e.g. giving away your email address, ...). Guest accounts might be marked with a special property (as detailed above), but would also need some special coding to give each guest a unique name (guest1, guest2, ...).


Exposing some additional statistics on the pages under would also be nice. For example, we don't have any statistics on monthly addon downloads (the clients.php page only reports on all file downloads each month, which includes news.xml and similar regularly updated files making the numbers less useful), and for online mode being able to see the total number of servers and players could also come in handy. Perhaps most often downloaded addons in the last week or so? Thinking of additional statistics to add is encouraged.

User Feedback

An in-game report option should be added to report cheaters (as well as patched servers). Again some panel should be made for the web client that lists the reports. The proposal should mention where and for what report functionality is added and how the panel will look. (Is it integrated with the other panel?)

Addon Bug Reports

A very simplified bug tracker so that users can report that an addon is buggy or isn't compatible with a certain STK version. We often find that bugs are not updated when we release a new version, and do not work properly, or problems were just not discovered while testing. The maker of the addon should then be notified and have the chance to commit revisions. If the addon is in a buggy state for a long specified time it should be removed from the addons repository. Please detail your vision in the proposal.

Some reasoning should also be done concerning notifications. A mail can't obviously be sent for each report of a cheater or a malfunctioning addon. Some smart algorithms should be used to limit the mail traffic, and it should be combined with a notification system on the site. I.e. if an addon is buggy, it's likely 100 reports will be filed for that addon. In the best case scenario the author should only receive one mail that asks him to have a look at the "bug reports" on the stkaddons site. (API's for mails, database access and accessing the server from inside the game client are already present and should of course be used. (and improved ;) ))


The STKAddons code base is getting a bit messy so code restructuring is heavily encouraged. It would also be nice to have regression testing for the newly added features in the form of unit testing. If time allows this could be expanded to full coverage. We realize that this might be a lot for 3 months, so it's up to the student to come up with a promising but realistic timeline prioritizing features he thinks are most important. If unit-testing is considered more important than statistics, so be it. We do prefer few finished features over a lot half-finished features.

Note : If a student proposes to use a different server-side technology, be sure to discuss this with us first!



Retrieved from ""

User Tools