Are you a developer who wishes to get started helping with Thousand Parsec? Perhaps you are a computer science student looking for a project that will help you improve your practical programming and teamwork skills? In any case, you have come to the right place.
Below are some of the ideas and suggestions for people who would like to join in the fun of creating video games. The list is not definitive and everyone is encouraged to come up with their own idea to work on. Initiative and imagination rate highly when working on any project.
For additional ideas you can also take a look at Thousand Parsec TODO list.
You will notice that in some ideas "a 3 month timeframe" is mentioned. This is only relevant if you participate in Google Summer of Code (where you have about 3 months to finish a project). If you are interested in working on Thousand Parsec outside of GSoC you can ignore this.
You can find information about applying for the Google Summer of Code on this page.
For Google Summer of Code 2010, the following types of projects are regarded, in general, as high priority:
- Improvements to existing rulesets, such as MTSec.
- Additions or improvements to the daneel-ai AI client.
- Improvements to the single player framework.
- New rulesets.
- New persistence modules for tpserver-cpp.
|
Thousand Parsec's greatest strength is it's protocol for describing games. This allows any client to play any number of games. The different rules which make up a game still have to be added to a server, these are called rulesets. The more (complete) rulesets (and hence playable games) the better. Why not help out by building one?
You can choose to implement the rulesets in either the Python Server or in the C++ Server. Both servers currently implement a limited number of rulesets, but have been designed to support a wide variety of other rulesets. Rulesets which required advanced features will require you to also help improve the the core of the server you are using.
Rulesets can be one of the most rewarding parts to work on (as you are actually creating a playable game). One of the successful students from Google Summer of Code 2007 produced the Reach for the Stars ruleset and liked it so much he has continued to improve it.
Developing rulesets can be assisted by using the Ruleset Development Environment (another Google Summer of Code project) but will still require good C++ (if developing for the C++ Server) or Python (if developing for the Python Server) skills. Scheme skills are not required but would be a strong advantage.
Thousand Parsec is the ideal framework to clone your favourite 4X game!
Please look at the Clone Ruleset page for some ideas of possible rulesets.
- C++ skills or Python skills.
- Knowledge of the Ruleset you wish to clone.
Design a simple ruleset in which a whole game can be finished in an hour. This would be a perfect ruleset for beginners and those who don't have time for longer advanced games.
- Konquest - an example short 4X game
- C++ skills or Python skills.
Thousand Parsec is designed to allow many different clients to connect to the same server and still fully participate. Currently the main client is written in Python. There are also clients for KDE in C++ and EFL in C.
You can help us by writing a new client for Thousand Parsec. This client will service people who are not in a situation to use tpclient-pywx.
These tasks are a reasonable amount of work, depending on which language you choose you may need to improve (or implement from scratch) a protocol library. You will need to be a reasonable coder before you start any of these projects if you hope to succeed.
A web based client was developed in GSoC 2009.
More info on the 3d client and project ideas can be found on Tpclient-pyogre.
A 3D client was developed in GSoC 2008, right now it is in need of the following features:
- Support for creating designs
- Allow users to create and edit ship designs (for reference check out Spore)
- Media.gz support
- Client should download models and other media off the media server
- Single player mode
- Players can play a game locally against AI competition (similar work has been done on the wxWidgets client already, for more info see Single Player)
- Remove python-ogre dependency
- Port ogre-based portions of the 3d client from python to cpp
In addition, there are some other features which may not fit the scope of a Summer of Code program or are not as important:
- Game lobby system
- Ability to communicate with other players and host games, perhaps by launching tpserver-cpp or tpserver-py in the background
- Procedural planet generation
- Generate planet and stars according to their attributes
- Addition of more special effects and eye candy
- Locate areas in the client which could be improved for a better player experience
Thanks to a successful Google Summer of Code last year, Thousand Parsec now have 2 AI clients - daneel-ai and gencon-rfts-ai.
An AI client in Thousand Parsec games connects to the game as a normal client and has exactly the same information as a normal player would have. There are many improvements that could be made to these AI.
The AI will NOT be able to do any of the following
- Integrate with the server, it must be a stand alone program.
- Cheat or have some other handicap, it must play by the same rules as everyone else.
- Existing Python Simple AI.
- Client with inbuilt AI, written in C.
- RFTS Clone - Wiki page about our RFTS clone, getting yourself a copy of RFTS will also be highly advantageous.
- MTSec - Page describing the MTSec dynamics.
- A good resource is Wesnoth for Kernel Hackers talk at Linux.conf.au, Rusty Russell talks about his solution to some of the complex AI battle problems.
- Good programming skills
- Some knowledge of 4X games is recommended
- Some knowledge of AI programming is recommended
tpserver-cpp is one of the main servers in Thousand Parsec. These project ideas deal with improving it in various ways.
You will need some C++ skills before you start any of these projects (but not as much as if you where implementing a ruleset for this server). Lee (llnz) is happy to mentor anyone working in these areas.
New rulesets can be written for tpserver-cpp and existing ones can be improved, see Rulesets section above.
Tpserver-cpp has an abstract persistence interface that allows different methods of saving the game data. Currently, only a basic MySQL module has been written.
The interface it fairly straight forward, but there is likely to be changes to the interface as the new game features are created and the internal architecture changes.
Possible databases include:
- PostgresSQL
- SQLite
- Generic SQL using odbc or similar
It has been mooted to move the Persistence interface an asynchronous model where, if the database supported it, it could process save, update, remove and retrieve without blocking the rest of the server. New modules should document if this is possible, and what would need to be changed.
To make it clear, any Summer of Code proposals for this require detail about how you will approach adding the new persistence method(s), and should probably cover more than one new method, unless there is a good reason not to.
- SQL (preferably MySQL and the target database) experience
Boost.Asio is a library for doing asynchronous IO. Change the low level networking code from the non-blocking select and connections to ASIO and event handler. Also, need to update the timers as these are other events that need to be triggered.
- Understanding of event-driven programming
- Boost.asio experience a plus
This project is very invasive in tpserver-cpp and probably too large for SoC.
It has been mooted to move the Persistence interface an asynchronous model where, if the database supported it, it could process save, update, remove and retrieve without blocking the rest of the server. This would allow it to process another user's frames or other tasks in parallel with database accesses, thereby increasing overall performance and scalability.
These tasks would need to be done:
- Design approach
- Convert one of the less common Managers (say, ResourceManager) to provide new API
- Convert users of old API to new API, including creating "Command Pattern" classes, etc
- Show that the new API works
- Convert other Managers (ObjectManager, OrderManager, etc) one at a time, and convert users
- Create async persistence interface
- Create async persistence interface wrapper for existing (synchronous) persistence modules
- Create fully asynchronous persistence module
BattleXML is an xml format for describing battles that take place in Thousand Parsec, and the files can be viewed by the stand-alone battleviewer. The task is to add calls to the BattleXML API to document the battles in MTSec, RFTS, Risk, and TaE rulesets.
There are some smaller projects which could be a good introduction to tpserver-cpp. For Summer of Code, a number of these could be combined into a suitable proposal.
tpserver-cpp supports plug-able methods for triggering the end of turn processing. The current TurnTimer supports threshold finished changing of the timer, which is set in seconds.
A new timer, called CalendarTimer (subclassing TurnTimer) could be developed that starts the EOT processing at the same calendar time (IE, everyday at 12:03am or similar). Boost.Date_Time might be a good starting point. Also see Tpserver-cpp/Turn Timers.
tpserver-cpp module system works ok, but could be better. It could be just a matter of adding a layer of indirection in.
Some things that would be nice to have:
- Modules dependencies
- New types of modules (advertising methods, universe builders, etc)
- Load all modules, list their names on the console (on command), use some modules, unload rest.
Fail frames as of TP04 have a list of General Purpose References. Most of the createFailFrame calls currently do not set the list of references. They need to be added. Some things don't yet have reference types yet, they will also need to be added to the protocol.
We currently have a reasonable PRNG, which Boost.Random also supplies, but only a limited set of random variables. This could be changed by replacing the custom implementation with Boost.Random.
Create a statistics command that prints out the number of Objects, orderqueues, players, connections, etc. Look at the status command for an example to be similar to, and the various fooManager classes for stats to give.
These projects are about improving or creating standalone tools for Thousand Parsec. They are mostly self contained projectss, however it is still expected that you are involved with the rest of the project.
Some of these projects might require you to extend the Thousand Parsec protocol or specify out new features. These will need to be publicly discussed on the mailing lists or forums.
Scheme is quite a hard language to write. tpcl; the language which is used for communicating between server and client the details about designs, components and properties; is based on Scheme.
For SoC 2007, DystopicFro wrote a Ruleset Development Environment called tpruledev. It is written in python, and works well for designs, components and properties. But since then, there have been changes to tpserver-cpp that require reflecting in tpruledev, and some new features in TP04 are close to being useful and so could now be done inside tpruledev (namely object descriptions). So there are few improvements that could be made, and more will be needed soon.
Make is possible that when tpserver-cpp started with no config file, ask the users a number of questions to set up the server and the game. tpserver-cpp uses tpadmin-cpp for the console, and it supports changing command sets.
Questions to ask include:
- Server name, admin email address, game info, etc
- ruleset to use and parameters
- persistence to use and parameters
- turn timer parameters
- whether to turn on metaserver updates
- logging options (file, syslog, console; log level, colour, filename; etc)
The metaserver was originally written in about 5 hours, it was then improved as part of Google Summer of Code 2007. It is in a pretty good shape but needs some polish before we can deploy it as our main server. Once a release has been made, more features can then be added.
You job will be to,
- clean up and release the metaserver,
- add more functionality to the metaserver.
- Make it portable across databases
- Add a "match making" support
- Intergrate with the forums and mailing lists.
- Add request via standalone UDP or TCP ports.
- Metaserver Code Repository (the currently running code), rewrite branch (which was used during last Summer of Code).
- Metaserver protocol definition
- 1652209 - Clean up Metaserver code.
- Some PHP skills.
These projects are about improving a core part of Thousand Parsec. They may require a smaller amount of code then other projects, but the code will have to be of a much higher quality.
Any changes to the core protocol will need to be vetted by other Thousand Parsec members and approved. This means that these projects may be slower to progress and more frustrating. They will generally be more rewarding as you will know that you have helped with a fundamental part of Thousand Parsec and every one else is doing work based on yours.
Currently protocol libraries have no way of testing their compliance with the protocol specification. Your job would be to write a suite which runs a protocol library through a bunch of tests and reports on it's compliance.
- Some experience with testing is a must
It would be useful to have a tool that measures how fast various operations occur in the server to help profile bottlenecks and overall throughput. For an example of the sort of thing that would be useful, have a look at apachebench (AKA ab) or http_load.
It would be helpful to start with one of the protocol libraries.
It would be helpful to have a module for wireshark (previously ethereal) to decode TP frames. This would help debugging in some cases.
Thousand Parsec uses a lot of python. These projects are generally to do with improve some python part of Thousand Parsec.
Schemepy is a Python ctypes library that Mithro started to allow Python to call out to various supported C Scheme implimentations (such as Guile). This makes processing scheme 10 to 100 times faster then the current pyscheme.
Schemepy is currently used by all the Python parts, including the [Python] and the [Python]. It also has wider application in the Python community and it is recommended that you also work closely with the Python Software Foundation.
You job is to do (some) of the following,
- Add support for various other C scheme libraries such as mzscheme, chicken, Gauche, Sizzle or TinyScheme. The more popular scheme libraries should be preferred.
- Add support for SISC, Gleam or other Java scheme implimentations when run under Jython.
- Add support for python scheme implimentation as fallbacks, both pyscheme and PyPy Scheme (code found here).
- Create a strong scheme and tpcl test suite including benchmarking.
- Port tpserver-py to use the schemepy interface.
- Port libtpclient-py to use the schemepy interface.
Some Python skills are a must. Having used either scheme or python-ctypes is a strong plus but not required. Experiance building compliance and/or testing suits is also a bonus.
tpsai-py is a simple AI written in Python using the Client and Protocol libraries. It has only had a couple of days worth of work and is still very simple. It currently does an okay job at playing MiniSec.
Your job is to clean up and extend it to support either TP RFTS ruleset or MTSec ruleset. You can see the AI Clients section for more information on what you would need to do.
The python server currently uses it's own async core loop. Your job is to port it to the twisted framework, this will be a multiple stage process.
- Step 1 - Port the core to Twisted's reactor, see libtpproto-py twist.py for a start of this.
- Step 2 - Change the SQL queries to using the async thread worker pool. See this documentation about how this could be done.
- Step 3 - Change any print statements to be logging statements.
- Step 4 - Make tpserver-py daemonize.
- Step 5 - Add support for an inbuilt http server - including authentication (to allow download of media and battle data etc)
- Step 6 - Add support for multicast DNS/Zeroconf to Twisted.
- Step 7 - Add a ssh/telnet port that lets programs remotely manage the server (such as add/remove games, etc).
- Step 8 - Party
Strong Python skills are required, experience with twisted is also strongly advised.
See the Rulesets section for more information.
The python library currently has no testing. It's your job to write enough tests that at least 60% of the code has proper testing.
More Information:
- libtpproto-py
- Some experience with unit testing and Python is a must.
libtpproto2-py is the second generation protocol library designed to automatically generate packet descriptions from xml. It is pretty close to being finished and just needs a little love. It also needs a large amount of testing.
You should then port libtpclient-py to the library.
- libtpproto-py - The original Python protocol library.
- libtpproto2-py - The "second generation" protocol library.
- Some experience with Python is a must.
tpclient-pywx is currently the primary client for playing Thousand Parsec games. There are many things which can be done to improve it.
You should take some of these suggestions and build them into a consistent proposal suitable for 3 months. You MUST download and use the client before trying to write an application. You also need to talk to mithro@mithis.com as you will be working closely with him if you take on this idea.
These tasks are in no particular order and some are more difficult than others.
The client should restore all the windows to the same position/size/location. See the wxAUI demo for the window saving perspective code.
The info panel is the primary display for information about the currently selected object. Currently it is really crappy looking. Make it look nicer.
Add a window which replaces the starmap and shows the distance from the currently selected object to every other object in the Universe. Should be able to filter and sort on various criteria. This would be useful for blind players to fully access the game.
Add a window which lists all your various assets.
TP04 will support technology trees. Add support for viewing these to tpclient-pywx.
FreeOrion has quite a cool looking tech-browser, see http://www.optisch-edel.de/fo/screenshots/research.jpg
Add full, proper message board support to tpclient-pywx.
Features should include;
- Ability to see all message boards on the server.
- The ability to post new messages.
- To easily filter various system messages in intelligent ways.
- Good searching facility.
Add the ability to undo any action. This probably comes in multiple parts,
- Adding a change tracker to libtpclient-py
- Adding the ability to revert specific things using the the change tracker
It would be pretty easy to embedded an OpenGL window where the starmap is currently. Why not make a cool 3D starmap while still having access to all the GUI elements.
Look into using something like pyglet or python-ogre.
The next version of tpclient-pywx, the primary Thousand Parsec client, is heavily dependent on pyAUI. There are a bunch of improvements which could be added to make pyAUI even better. Some examples are,
- Minimise button support
- Add better way to align the windows initially
- Add better support for using floating MDI children under Windows
- Add support for "fly out" windows (IE Windows which only show themselves when moused over)
- Tab-based MDI classes (see C++ AUI)
- Vertical Title bars
- PyAUI
- tpclient-pywx Development Branch
- Good Python skills is a must
Thousand Parsec now has support for single player mode, and there are a number of things that could be done to extend and improve it.
Make it possible to save and load scenarios -- sets of ruleset, server, and AI client details and parameters. These should be stored in a self-contained file format that is easy to share between players (e.g. online). A logical extension would be to support campaigns, which chain several scenarios together.
Another use of scenarios would be in saving and loading single-player games. Provided the server and AI clients provide some way to store their state, a scenario could be used to not only load them and set parameters, but also to have them load specific saved states.
Although single player mode is currently only implemented in libtpclient-py and used by tpclient-pywx, it is important to design this feature in such a way that other clients and client libraries can use it in the future.
Another important factor is making sure that the player has the necessary server, ruleset, and AI client(s) installed to play the scenario, and providing the easiest way possible to install them (download links, instructions, etc.) if they don't.
- Single Player wiki page
Parsek is a game client that is written in C++ and uses Qt 4 and KDE 4 libraries to implement a cross-platform graphical user interface.
Currently Parsek is only about half-finished. It does get the objects and messages from the server but displays them in an ugly way. Also it doesn't get any orders yet and you can't issue orders. Your job would be to finish Parsek at least up to the point so that it is usefull for playing basic games. This includes implementation of:
- displaying StarMap
- getting and displaying orders
- creating new orders
- nice looking display of objects tree and messages
- integrate a battleviewer
- integrate a starship design editor
- automatic discovery of game servers
- accounts manager
- C++
- Qt 4
- KDE 4
Finish the galaxie GUI to use Elementary. Ideally this design should be useful to run on devices with a smaller screen or touchscreens. There are a number of devices currently available which can use elementary UI. Additionally completion of the order interface would be desirable.
This will involve ripping out the curren EWL/ETK widgets, and use elementary instead.
Additionally the galaxie client should be updated to work happily with the current tp04 status in the servers (galaxie supports some tp04, and is entirely asynchronous inside already).
- C
- Elementary / EFL (or just learn it)
Convert the existing wiki+website into something like ikiwiki
Cavets - this requires writing a bunch of scripts to do data conversion and reworking the website HTML/JavaScript and converting the current PHP