IRC handle: fusionlove email: fusionlove at gmail dot com
Project Title: A new ruleset for Thousand Parsec
Most of the existing Thousand Parsec rulesets are based on empire-building. You sit back and watch the universe unfold in front of you on your screen; you dispatch fleets, burn planets, harvest resources and look on from afar as your battles play out as dots of light, parsecs away.
But what if you were actually out there? What if you weren't some impersonal imperator, watching the universe from above- but sitting in the cockpit of your own ship as you watch the next planet draw near off your bows? What if you were not a ruler but a soldier, a trader, a pirate; and what you were risking was not you armies and yourwealth, but your own ship and your own life?
I want to bring the close, personal gameplay of games like the classic Escape Velocity on the Mac (and of course Elite) to Thousand Parsec. I would also like to work on creating a believable, interesting, deep universe as well as writing good code.
A similar proposal, EliteSec, was attempted last year by epyon . The difference here is that I wish to emphasis narrative and universe quality (and above all originality and player interest) as well as code quality. I wish more to create my own framework rather than cloning or emulating Elite or other games.
I have always found Elite-style games more fun to play than Reach for the Stars- or strategy-style games. As your character is directly interacting with the universe and other players, rather than via orders and fleets, you feel more immersed and there is more emotional investment with the game. When under attack, it is your character who is in danger rather than Battle Group XII; when you pull off a good trade deal, you can buy yourself a new ship rather than upgrading the shields on a space station light years away.
Moreover, I have found that many people are intimidated by RTS-style space games; they view them as massive endeavours with complex rules rather than something they can dive straight into. They also tend to be longer. I feel that an adventuring game (I shall use this term to distinguish the Elite style from the Reach for the Stars style) would helpTP to be more accessible and attractive to new players.
The project will work around creating a Ruleset class for the C++ server, tpserver-cpp (I am quite experienced in C++ and not very much in Python), as described in Lee Begg's book on creating rulesets.
Another main deliverable will be documentation. I found tpclient-pywx slightly confusing on first run and it would be very useful to have documentation on how to use my ruleset specifically. Also, I intend to write a scene-setting document providing back story for the scenario. I have found that games which present a bit of history and background first are always more fun to play as the player enters the universe with preconceptions, expectations and questions.
Documentation for future developers should also be produced so that there is scope for expanding on my project, perhaps in future Summers of Code.
The universe will focus on the traditional 4 X's, but in a more personal manner than strategy-style universe games.
eXploration: The player explores the universe by means of movement in-system and hyperjumps between systems. Exact mechanics of hyperjumps have yet to be worked out; how many turns they take and how much energy they consume, for example. The universe, unlike the TP demo server's, will be very large; this ensures maximum playability and a sense that the universe is huge and unknown. There is a possibility for dynamic universe creation, like in the original Elite, but this will depend on time.
eXploitation: The player can exploit both planetary resources and other players. The classic trading missions (transporting goods from planet to planet to take advantage of price differences) will be included, as well as more creative missions such as delivering objects of value or transporting refugees. Other players can be exploited mainly by piracy, but also by buying goods from them or taking over their missions.
eXpansion: The main difference between my project's ruleset and, for example, Reach for the Stars is that instead of expanding an empire, a player expands her own personal resources. When new wealth is acquired, such things as
* -Ship upgrades
* -New ships
* -Information about the galaxy
* -Chase ships or escorts
* -Weapon upgrades
can be purchased.
eXtermination: Combat will be a major part of the game, as this is one of the most exciting parts of any sci fi scenario. It can take place either player-to-player or player-to-AI, if there is enough time to implement a simple AI system. Combat between ships and planets (space-to-ground missiles, surface-based orbital artillery) is alsoenvisageable.
To support the 4 X's, the scenario will have the following major components:
1. -Star systems. These will be many and diverse, and as detailed above, possibly randomly generated. An interesting detail of the Mac game Escape Velocity was that unexplored systems were unknown to the player unless he or she purchased a star map in advance; this lent a feeling that the galaxy was vast and mysterious. This could be implemented if there is support in the various clients (or if such support could be easily added). 2. -Ships. These can be either the players', AI ships controlled by the server, or ships controlled by AI clients. At present, of course, no AI client exists for the newruleset, and creating one may not be within the scope of the project ; but a simple rule-based system might be implementable within the time frame. Ships have various statistics controlling movement and combat such as speed and armour information. 3. -Missions. Completing these is (apart from combat) the meat of the game. Their main point will be diversity, as missions in other games can begin to feel samey: endless trading runs or repetitive bounty hunting missions. Here, again, random generation could be possible, along the lines of [verb] [object] in [system]: "Transport ambassador to System X," "Collect asteroid dust in System Y."
Any good game needs a back story, a canvas against which the action can unfold. There are two options here: creating a new universe, or taking an existing one and setting theruleset there. Using an existing universe, like the Star Trek canon (only an example!) would definitely be more popular, and easier to create to boot. The universe of the Culture from the novels of Iain M Banks is particularly attractive to me because of its originality.
However, there are issues with copyright which would need to be worked out, so creating my own backstory is probably the best option. This also allows for more narrative creativity, which is attractive to me as well as to potential players. Theruleset should not be just an exercise in coding but something which people are actually keen to play!
The main philosophy of my back story is originality. Every SF game has multiple races of stereotypical aliens and the standard Frigate-Cruiser-Battleship arrangement of ships. I want to try for something new and believable, with all the dirt and rough edges that a society and culture actually has. Economic recession in a galactic civilisation? An incompetent Confederation Navy which can't keep track of its antimatter warheads? A mission where you are a detective and must solve a murder?
TP's framework is fundamentally turn-based. Elite, Escape Velocity and Eve Online are fundamentally real-time and non-turn-based. This dichotomy and its possible solutions are discussed here.
Does the scenario really need to be non-turn-based?
The easiest way to solve a problem is by sidestepping it; we must therefore ask whether the scenario can somehow be fitted in to a turn-based structure. This would eliminate the need to modify either the protocol or the client's turn-based structure.
The advantages to a real-time system are that:
* Players can instantly see other players' actions
* The game feels more reactive and more fluid
* Combat is more fun and more exciting
The advantages to a turn-based system, however, are that:
* The protocol is far easier to implement. Details of latency and network speed cease to matter
* Players have more time to issue orders to many units
It would in effect be possible to preserve the defining advantages of the Thousand Parsec protocol by using a turn-based system. Engineering a real-time system would require radical changes to both the protocol and the clients, including the tackling of complex problems like latency compensation; the protocol is not designed to cope with such issues. Simulating a real-time system using a turn-based protocol (by using very short turns in order to update information several times a second) would also be difficult, as it would require changing the client so that it did not ask whether to update on each new turn. The time taken to download new turn information, even on a fast connection, would be prohibitive.
I would prefer this project to focus on game content creation rather than, in essence, retargeting the TP protocol to do something for which it was not designed. I therefore decided to work within the turn-based structure. The only disadvantage is loss of fluidity; this is also an advantage for some, though, as it would make the game calmer, less stressful, and less time-consuming. An immersive real-time game is very attention-consuming when it is multiplayer; the player cannot look up for a few moments or do something else at the same time. There is no reason why Elite-style play is fundamentally incompatible with turns, and working within this structure is a new and interesting way of implementing space adventuring.
Designing with turns
The main design point here is that not as much needs to be done each turn, as the player has less under his control- one ship or fleet of ships as opposed to an entire empire. Turns could therefore be made shorter; but content could also be made more immersive to take advantage of the extra time. Actual narrative and dialogue could take place which the player would actually have time to read, and the player would have more time to look at variables such as his finances or the prices of goods in different star systems.
It is obvious that the game must include some kind of dynamically generated content in order for gameplay not to be identical every time. The universe, however, cannot be completely dynamically generated for each instance of a server, as with Elite; if the galaxy is to have a back story that the player can come to know (for instance, regions and civilisations with different behaviours and reputations) we cannot start completely anew every time.
I will therefore restrict dynamic generation to:
* Missions
* Non-player characters such as AI drones
* Random events, such as planetary disasters, famines, civil wars, ship component failures and economic collapse
Variety will also be ensured by player-to-player interaction. The missions available to complete will not just be generated by the computer, but by players as well; it will be possible to, for example, take out a contract on someone's life, or order an item to be fetched or transported from one system to another. Alliances and friendships will thus be mainly player-controlled, and thus different with every play session.
- 1: The beginner
You talk to a few promising-looking ships in the local system. Eventually you find someone who's offering fifty thousand pieces of silicon carbide to take his daughter to the other end of the galaxy. It'll take you weeks, but you accept, and her stasis coffin is loaded aboard. Just as you're about to jump to hyperspace, one of your wing mirrors falls off.
When you reach your destination, you open the stasis coffin, and the girl immediately offers you another fifty thousand pieces ofSiC to take her home again. You know that this will seriously annoy her father, but you like her more than you did him, so you do. When you get back, you buy yourself a slightly faster ship and head off into space before he hears about it and hunts you down.
This scenario illustrates missions and how your reputation (or news of acts you have performed) travels at non-instant speed. It also illustrates a system I would like to implement for random component failure. A ship is made up of different systems like weapons, propulsion, life support, etc; the each have a random (small) chance of failure each turn. This would allow for interesting scenarios like being stranded in a remote system and having to call for help. Also, more expensive components have a much smaller chance of failure; this would make cheap, older ships feel more realistic. Individual components could also be damaged during combat, which is more realistic than having a single integer variable for ship health.
- 2: The warlord
But it's risky as well. It's empty out here on the frontier, but the long arm of the law still reaches out into the Western Spiral Arm of the galaxy. You have to stay one step ahead of the police fleets, paid by central government to take down scourges of society like you; and there are always the police drones, stupid andnonsentient but small and fast and annoying.
This scenario illustrates how ships can be upgraded from tiny to gargantuan, and how escort ships can be bought (or other human players paid to escort you around). It also shows how different factions (here, pirates and police) would come into conflict, and how the game could pay human players to police the galaxy, as well as doing so by means of AI-controlled drones.
- 3: The trader
This scenario illustrates an example of trading. Rather than using exclusively game author-generated missions, players will be able to contract each other out to accomplish tasks such as delivering items or destroying another player's property. Exactly how this will be implemented using theTP protocol has not yet been decided, but the protocol seems complex and powerful enough to support such a system. Also seen here is how theruleset blends into strategy-style SF games when players start getting rich enough to own planets and control multi-system empires; this will be made very difficult and therefore kept to a minimum, though, to emphasize the adventuring aspect. The economy could also be dynamic instead of static: prices could react to such variables as local wars and availability of goods.
AI A potential, simple learning AI could be implemented (either for server-controlled drones or client bots) using a rule-based system using rules like Health less than 50% -> stop attacking Range greater than 1000km -> use torpedoes instead of microwave lasers
Time allowing, a learning AI could be implemented using dynamic learning functions such as a coefficiented variable weight fitness function from actions to integer fitness (evaluating the value of each action). The basic idea here is that the effectiveness of an action is fed back into the coefficients deciding its weight next time.
I am at present taking a course in AI for games and have some experience building rule based systems in Prolog.
Dynamic economy
A dynamic economy could be modelled on the assumption that there is a constant amount of money and resources in the galaxy and than price is dependent on resource availability: what is rarer is more expensive. What is hard to obtain- for example, goods produced on the other side of a war zone- is also more expensive. Prices could be updated every turn or every several hours, to allow players to spot patterns and exploit them.
As I have been without an Internet connection for the past week and a half I have not been able to download and build tpserver-cpp. I knew I wanted to help TP's development as part of GSoC, however, and have been working on my proposal and planning ideas.
There are a few periods before August when I will be unable to work full-time on the project: I have final exams in mid-June and will be away for a few days near the end of June. During July and August, however, I am completely free and will be able to work uninterruptedly on TP.
April 3 - April 20: -Development of more preliminary ideas for the project. Nothing too definite will be committed to, however, as it won't be known whether I'll be able to work on the project as part of Summer of Code until the 20th. -Test build of tpserver-cpp, bug fixing. I will try and fix some bugs anyway even if I'm not accepted :)
April 20 - May 23 (Community bonding period): - Discussion of ideas with the mentors and the TP community. - Detailed study of the TP framework and tpserver-cpp. - Test plays of all the existing rulesets to see what has been done and what is possible. - Detailed study of the TP protocol to see exactly what is possible within the framework.
May 23: coding begins.
End of June: Milestone. Have a working version of the ruleset that can communicate with the client.
July 13: Mid-term evaluations. Have the major objects- ships, planets and missions- in position.
End of July: Milestone. Have all the major features finished. Have a server which is actually playable and open to the public.
August 10: Pencils down date.
-Final testing and debugging -Finalisation of background story and documentation
August 17: Firm pencils down date
If the project is unfinished: Of course, I fully expect to be able to finish this project. I have designed and implemented a system that took four months, start-to-finish, before; this project also required learning other people's code (see experience). However, we must always plan for the worst case. If for some reason I cannot finish the project or become stuck, I will try and tidy up existing code into as clear and complete a form as possible. I will also be sure to document development problems and how the code has been written so far, in case future developers wish to take it over. I usually comment code as I write and think clarity is more important than speed (differences in code length are usually evened out by the optimizer anyway).
In 12 months: SF and space gaming is a subject about which I am quite passionate (SF is my favourite literary genre and I probably have more experience in SF gaming than in any other genre) so I am quite likely to continue working on this project, if not as intensively, afterGSoC . If not, however, I will take care to leave the code in a well-documented state; I will maintain a development blog documenting algorithms, bugs and solved problems. This will ensure that the code can be worked on by other people- and more easily by me when I return to it.
I'm a third year Computer Science student at the University of York in England. I grew up in the UK and was home educated until I was 15, which gave me the opportunity to focus on learning about what really interested me (not just computers, I promise). My main areas of interest were science and fiction. My attraction to SF is therefore natural.
When I was 15 my parents moved to France and I went to college there, choosing the scientific path. I returned to the UK for university.
Languages- I know quite a lot of C++ and have got past most of the major milestones including templating, template metaprogramming, object factories, function pointers, multiple inheritance, references and handling pointers to compile-time-unknown types using typeid. I have taken a semi-advanced course in Haskell including recursion, Haskell's higher-level functions like map and automated program transformation. I am also fairly competent in Scheme and Ada and know a little Prolog. I am fairlly advanced in static web design using HTML + CSS and have built three websites using these.
Projects- my largest project was a neural network system frontend which I implemented as a third year uni project. I wrote several thousand lines of C++ code and had to learn the theory and application behind a complex library developed by the University of York's Advanced Computer Architectures Group. The library concerned a neural network system based on matrix memories called AURA. I am presently applying for a PhD research position in the neural computing / bio inspired computation area at the University of Edinburgh. This project made me comfortable with deciphering other people's code and learning non-standard libraries.
My second largest project was a C++ and OpenGL 3D ballistics game where the player was in control of a turret and had to target and hit various objects. This gave me experience in graphics programming including fractal terrain generation and multiple camera angles in OpenGL.
In terms of team interaction I completed a two-week team design project where we did preliminary and object-oriented design for a presentation program targeted at elderly users. We had daily meetings and collaborated over the Internet in the evenings and I feel very comfortable with working as part of a team.
I feel that when writing a ruleset, competence in programming is not the only important thing. If successful in this project I will be implementing an actual game that users will be playing, and quality code alone will not be enough- the game must be playable, captivating, and interesting. It must have, if not a storyline, a wide and variable universe against which users can play out games.
Although the point of Google Summer of Code is code, not fiction or plot development, I feel that a good canvas and back story in Thousand Parsec is at least as important as good documentation and usability in a more standard project.
I nearly did English at university and am widely read in the field of science fiction; not just the standard Star Trek clones but more classic works such as Arthur C Clarke, Heinlein and Asimov. I have written several SF short stories and am working on a longer story, and I like writing as much as programming. I find writing a program similar to writing a story; you have the beginning (the main function, declaration of variables) the middle (the algorithm) and the end (tidying up the output, presenting it to the user). When programming you have to plan ahead, revise, cut out and change designs just as much as you do when writing a story. And when writing a story you have to be nearly as precise as when programming; although a story can't cause a compiler error, a plot hole or typo can make it just as useless as a major or minor bug can in a program.
I love science fiction- why restrict yourself to one planet and one time when you could have a whole universe to play with- and coming up with ideas for Thousand Parsec would be just as interesting a challenge as the coding itself.
What makes YOUR game fun? What makes it unique?
My main points are:
* Non-repetition. The player needs to have a new experience every time, and most adventuring-style SF games like Escape Velocity are heavily scripted: missions and economy are set out once by the developers. I want to ensure a new experience every time by means of dymanic mission creation, mission creation by players (contracting), random events such as ship component failure or natural disasters which figure heavily in the gameplay, and dynamic economy.
* Story. Most existing adventuring-style games are also very similar: they either seem to be based mainly on trading or combat, and trading (or combat) feels similar in all of them. They also tend to have universe backstories which are not very believable or passionate; for example, many contain unoriginal, stereotypical alien races. There are three in Escape Velocity: Override called the Azdgari, the Zidagar, and the Igadzra. I would like to create a game with a story which is actually captivating and does not follow the standard [ships-aliens-various levels of shielding and blasters] recipe: I would like to address questions such as whether the player should morally be doing an offered mission and include interesting elements such as sentient AI, poverty, and the fringes of society like fraud and trickery that we do not often see in 4X games.
Overall, I do not want my ruleset to make players feel like they are playing Elite, EV, or any other space adventuring game. I will conduct a review of what has been done before in the area, including plays of major previous games (that I have not player already) to ensure my ruleset is not too close to anything existing.
Alternatively consider that I can play Stars! now, with lots of people on pretty much any platform (it runs perfectly under wine)...So why would I play this game? (It's an evil question)
You can't really compare Stars! to my prospective ruleset. While they are both SF 4X games, in Stars you are an emperor controlling fleets of ships; in my ruleset you would be an individual controlling one or a few. So let's rephrase the question:
Why would I play my ruleset instead of Eve Online?
1. TP is open source and free. Eve Online is closed source and expensive. There are two advantages here: the obvious financial one, and the ability to talk to the developer community and possibly work on the game yourself. Eve Online has a massive, hierarchical community in which it takes years to accomplish anything significant, as all the action takes place on one server; TP has a small, open community into which new players and developers can integrate easily. Multiple instances of my ruleset could be run on servers, ranging from hour-long games to persistent, month-long scenarios. 2. Eve Onlne is very time-consuming. You cann't do anything else while playing it, as the action is fluid and takes up the whole screen. Consider the difference between chess and speed chess; the former is fairly calm and relaxed, the latter is intense and stressful. My ruleset would be less energy-intensive and less for the obsessed, hardcore gamer.
If you want to play a strategy game, why not play Reach for the Stars instead of the TP RFTS clone? Why not play Risk instead of the TP Risk ruleset? Why develop Thousand Parsec at all?
The answer is that innovation and creativity are good. We see problems with other frameworks and we want to improve on them, so we create our own. Even if new rulesets draw on ideas set up by old ones, they still create new universes and explore the boundaries of what can be done with the framework.
Is there more details about the game system and the like? How long does the game take? How long does the turn take? How many players?
* The game length will be server-configurable: it is impossible to tell at this stage in design how long a good game should be, and it would be good to have the opportunity to play either short games or long, epic, persistent ones. Perhaps smaller games could be player on subsets of the full universe.
* The turn length is also as of now impossible to set exactly, but it would definitely be shorter than the present MiniSec or RT turns, as the player would have less to do. Perhaps a minute to a couple of minutes (with the client modified to refresh automatically to avoid the player having to do this).
* Players could range from one (if the AI and bots can be made sufficiently clever in time) to hundreds (if I can ever attract that many to a server at once!). A universe large enough to take time to explore would definitely be able to fit a hundred players, and if less people were connected, the number could be made up with AI players. Remember that here each player is essentially a travelling ship, not an empire, so more players are possible.
Do you have more on the ruleset somewhere?
This is all I have so far except ideas :)
I would like to see a script which describes how a player would interact with the game through the current client. Which windows would he use to see what information? Which orders would he expect to see in the orders panel, what would the starmap show.
This example involves tpclient-pywx as I only have access to a Mac for the next few days. Most of the windows would be used fairly traditionally.
* Orders: show the orders generated by the player. These are listed just below.
* Picture: show a picture of the currently selected object. A description would also be included to enhance narrative quality (included as part of the image file). Something actually descriptive and evocative for each object. Graphics could be sourced from clip art, with care taken to ensure they went together; but the verbal description would be the most important part.
* Map: fairly similar to the standard star map. Would show the currently visible (explored) portion of the universe and the ships in the current system. Whether to show ships in other systems is an interesting design decision; if we assume that information does not travel instantly, the question of "Where is this ship I am hunting?" becomes possible, as well as interesting enhancements like tracker bugs that you can plant on ships you are following which home and let you know where they are.
* System: shows, traditionally, the star systems of the universe and (if known) what objects are present. Will be extended to show the different components of one's own ship, i.e. the different subsystems.
* Messages: various messages from the server. This will be a major part of the game's narrative.
* Information: Information about the currently selected object.
I can envisage the following types of orders:
* Move: to another star system or another place in the current system.
* Talk: to another ship. This would allow player-created missions (contracts) to be assigned or messages to be exchanged.
* Attack: another ship or a planet.
* Deliver object: for completing various missions. Other misison-specific orders could also be defined.
* Pick up object: analogue. These two orders are also used for trading.
* Upgrade ship: when talking to a planet or a ship, allows new components to be bought.
More orders will be elicited as the design progresses, for support of such things as repairing your ship after random breakdowns or taking evasive action during combat.
Example script
- Asterisks* indicate orders. Each paragraph is a turn; the orders given during that turn give results during the next one.
There's a mission available to transport some antique computer hardware to New California, so you *take it aboard* and *jump* towards galactic North.
Then you realise you haven't been to New California yet and aren't exactly sure where it is, so you *land* on a planet in the next system and *buy* a local star map. Then you *jump* on again.
You arrive in the New California system, and come under attack by a fleet of tax-collecting pirates! You knew this was going to happen. You *message* a ship you recognise in the system for help, and *open fire*, choosing your weapons carefully to take into account range and opposing ship design.
Luckily you come out on top, so you *land* on the planet and *deliver* your cargo. You are paid by the reciever.
You *buy* a heavier chain gun for your ship and then *jump* back out again.