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 http://stkaddons.net) 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:
- Be able to see newly uploaded (and not yet approved) addons
- Be able to approve newly uploaded addons (in STK)
- Donator (might be able to pick a special hat in later online races).
- Child account (e.g. we might restrict online options for child accounts, e.g. not to add friends. And a 'parent' account which can then add the friends for their child).
- Contributor (might be able to pick a special hat in later online races).
- Admin (can ban people (not in game), and might pick a special hat).
- Certified Server (once we support online races, certain users might be running 'certified' servers, i.e. binaries we can be sure of are not patched - people might modify STK to cheat and get an advantage; people playing on a certified server would be reasonable certain that this is not the case).
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.
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 http://stkaddons.net/reports/ 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.
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!
You should be able to set up a local instance of stkaddons to test any changes you make. This means you need a fully working Apache-Mysql-PHP stack. More information like where the database structure can be found or what dependencies need to be installed can be found in the readme file in the github repository.
- CSS and HTML
- Familiar with C++ (Only a little bit will have to be done in C++.)
- Glenn De Jonghe (unitraxx)
- Fallback: Stephen Just