Benutzer:Amogorkon/PiLife

This is a concept for a long-term software project, a community-driven, scriptable 3D-communication platform, developed and used by people recruited from PPs mainly, but not limitted to, around the world (which is the reason I write this in English).

The Idea

The idea is to combine the normal game-idea designed to immerse people and make them forget the real world with the possibilities of web2.0. The result will be a platform for people around the world to meet and play (RPG-like) while having access to many standalone communication channels to discuss serious issues and organize and work in an Augmented Reality (AR) way. To achieve this, a 3D avatar game platform (like PlaneShift or Second Life) is adapted in such a way that it interfaces with many other online services.

With this it will possible to "play the game" in any way you wish, or not at all - but use the platform in a productive and "serious" political way.

Brainstorming

• The name might need to change. A possible alternative could be "Pirates in Matrix - PiM"

Maybe more like PiLife (play on words pi ~3,141 > 2 as in second life & pi short for pirates)

• Accounts: only by invitation (viral, example gmail), limitted to 23 invitations
• communication via XMPP
• Zones:
  • VR, public - like wild/town in Planeshift
  • VR, private - freely extendable regions and buildings by using instances of maps and action locations, moderation by founder (private regulation like IRC channels)
  • AR, public - overlay of RL interfaces with maps that resemble real areas
  • AR, private - instances of public maps owned privately

• GMs can do everything but all actions are logged publicly
• People apply at the GM team that reviews the application and proposes it to the public after internal discussion. The community votes over every proposed GM and with that grants security levels. GMs can be removed by public vote.
• Voting system is especially important ("stochacracy")
• Content is displayed in a preview that can be visited. People can vote in this mode over content and with this accept or refuse contribution.
• entities can be flagged as
  • client - for users to only connect with the server, without virtual representation of the player
  • agent - any external application that interactively handles a specific task like weather, economy, datamining (see social networking)
  • NPC - AI controlled character
  • PC - player controlled character

Gameplay

• All chars start with a given stat-distribution that can be altered by investing time and braincells. For example: every char starts with 1000 SP (stat/skill points) that can be invested in a skill or left undistributed. The more points are left, the faster a new skill can be learnt. => old skills have to be forgotten before new ones can be mastered. Certain combinations of skills may raise the SP available.

Puppets and Ownership

Items ingame are regarded as owned by real world players, not by characters ingame - items and chars merely are manifestations (or "puppets") of players (except of course AI-controlled stuff). At account registration time the player has to choose a nickname as ID by which they can be reachable by any given means of communications (like email, jabber, etc connected to the account) , even go ingame as invisibly floating camera without way of interacting with the world visible to other players. To interact with the world one would need to create a char that has certain constraints. If items are created, they are regarded also as manifestation of the player and can be dropped anywhere.

I imagine a concept in which the player is regarded as "magical being" (similar to Magic the Gathering) with a certain amount of mana that can be used to summon chars, things and creatures under the control of the player (the methods of this "summoning" could range from crafting/casting of the char(s) over gathering ressources to using communications means in a certain way). The (IRC-)concept of "karma" to determine the standing with the rest of the community could affect the amount of mana available and thus determine how much the player can mess around in the world. The amount of mana would be a natural limit of chars, items etc a player could control. Requiring a constant draw of mana during certain actions might work as natural moderation of crazyness.

Dynamic Assignment

Any account, which can be player, the FSM (for world-objects like houses and landscapes) or AI (for bots and NPCs of any kind) starts with no objects owned. Entities like objects or characters are created by assigning an address and registering to the owning account. Entities have specific attributes that can be accessed depending on the category. Categories of entities can be changed, requiring a conversion of attributes depending on compatibility. So for example an object "mug" can be used ingame as mug, with the corresponding animations. If the owner registers a mobile device and connects it with the ingame object, the mug may become "magical" and inherent attributes and functionality provided by the mobile. Objects and characters are owned by accounts, and thus linked to the accounts directly, while the inventory of chars act as location: the char possesses the object. Chars, as do objects, can change owning accounts. The objects possessed by the char need to be handled and reassigned, if needed, seperatedly. As the nickname of the responsible player is static, this mech provides security against impersonation while providing a maximum of freedom in gameplay.

This mech gives ingame theft a new meaning as objects or chars can be manipulated by ingame means, while the owning player can always opt-out. So for example one could roleplay and order ones character to pick up a foreign object. The object would be relocated into the pocket of the char, but ownership would remain to the former player. There could be public methods for such objects that can be used by anyone (like using a mug for drinking coffee) and private methods (like using the same mug to request a GPS signal). If the owner doesn't mind the theft, the ownership can be transfered explicitely to the thief while removing (or not) the special attributes. On the other side the owner can also recall the item and force the item back into possession of the former char.

Using this approach it is also possible for multiple accounts to share ownership of objects and chars. As all operations on these entities (chat, actions etc) are logged on the server by account, it is possible for people to review and read up on what happened. This requires a dedicated message management, to filter and graphically present messages in different ways.

The distinction between ownership and possession also allows new ways of ingame trade and functionality as items and chars can freely change possession while the owner can opt-out and has the final say over an object.

Death

One possible implication of this approach is a self-regulating free-for-all player vs. player fighting system with ultimate death (a dead char can't be revived, items can't be restored). So players could create ("summon") disposable chars and enjoy some fighting while other of their chars focus on other tasks. Karma can be assigned accordingly whether the fight was fair or not.

Communications

• Jabber tranport to Twitter and other IM protocols. IRC can be incorporated as well.
• Private communication is encrypted and signed by default.
• OTR (off-the-record) can be enabled if desired.

Chat

On registration, a secure password is generated that is also used for creation of a GPG-keypair. The private key is stored locally (with a special warning for safety), the server acts as PK-authority. All private communication is encrypted with the public key of the sender and receiver before the messages are sent. The server logs all communications (except when marked OTR) in a database in such a manner that sender, receiver, timestamp, communications-medium and encrypted message is recorded.

Player-nicknames are used to automatically create a jabber and email address on the network so players can be reached without login. It is possible to enter auxiliary email addresses for message forwarding.

Database Sharing

Sharing views on the databases with applications or servers can be done by exporting the SQL to XML and sending this embedded in the XMPP. For encryption and/or compression of the message, standard libraries can be used.

Addressing

As the platform also can act as AR where RL objects correspond with ingame objects a new way of addressing needs to be conceived. One possible approach is to use IPv6 and assign an IP address to every object ingame. These addresses could also work as unique identifiers without need of using a new scheme. So one could communicate with RL objects (like mobile devices) via ingame means by transparent translation. To protect the address from abuse (hacking of DB or targets directly) but still be able to use them for identification during play, the server could apply symmetric encryption (key is kept temporarily only on the server) to the addresses ad-hoc before sending them to users. The clients identify objects by using the encrypted addresses. When an object is manipulated, the same encrypted address is used and the server can reverse lookup after decryption. On the other side, P2P or DCC (direct communication) applications are possible by explicit allowance from client side. The keys could be randomly generated for specific timeslots (thus be kept in a dict with pointer to smallest item to look up for delayed messages) and applied in XOR-manner without increase of minimal message-length and without significant increase of CPU usage.

Possible Use

As today many everyday items such as game consoles, mobiles, freezers and many more in the real world are networkable, it can be made possible to connect these for fun or serious application with virtual contexts. This could mean the next generation of geocaching, shared sports, next generation of flashmobs or just controlling the music or light next room without getting up or using a seperate app. As control over these devices can be shared, the range of use is extremely wide.

As this is also just an open possibility, people who just want to play or chat are not affected or forced to use this feature. However, it can open up a whole new dimension - given the process of registration is simple enough.

Inner Voice

As one of the main functions of the platform is to merge a great number of different communication channels for different purposes, a good filtering mechanism is required. As it also should be barrier-free and not solely based or navigateable via graphical clues, a new concept is needed. The idea is to use an agent system which assists the player in filtering the flood of information which learns which sort of messages are important in which situations. Also blind navigation ingame can be made possible by text-clues which are processed by the same common text2speech module. The Inner Voice could give clues by colour-highlighting of keywords in messages, visible or audible notification, notification text messages or more functions of various other human interfaces.

Movement and Distances

Areas are covered with a hex-field grid. The radius of the fields is fixed at 3m. Each field is represented as a dict (DB) listing all entities inside. This mech works for all applications based on proximity and can be extend 3D. So for instance in a range-based public communication one would check the surrounding fields for entities instead of using proximity-lists that calculates exact distances. Switching the field is trivial as positions have to be calculated for each movement either way. If the entity is within tolerance (0.1m?) of the border the entity is listed in both fields. Proximity triggers can easily be attached to fields.

For (NPC-)path calculations a movement-mesh approach could be used. Another option is to use intelligent way-finding along the hex-fields.

Servers

A multi-server approach is imperative as the infrastructure would require massive funding as the system is scaled up. A viable concept might be to use central entrance-servers (as PK-authority, for user-identification and such) which refers the userclient to the server handling a given region. These entrance-servers could be operated under direct control of the PPs while the region-servers are operated by volunteers. Switching regions requires dynamic reassigning between servers. NPCs can be controlled by superclients that connect to region-servers in a similar manner. Communications inside regions are handled all by the region-servers. For cross-region talk, the message is sent server2server.

Collaboration

• As SVG can be displayed directly, it is possible to use Inkscape whiteboard for presentation and collaboration virtually.
• Collaborative editing similar to gobby is favourable.
• Mumble can be incorporated as well.
• A way to virtually cooperate in music composition should be considered. Maybe even include a midi-interpreter.

Sharing

As every entity gets a unique IP address, it should be no problem to share ingame contents with external applications. The server which hosts the object in question then works as transparent proxy allowing only registered users to access objects ingame, however, exceptions can be made and dynamic contents can be published on the net that way. It is also possible that way to run complex applications (agents, analysing tools ..) as ingame entities, fully incorporated within the world but on an own machine, addressable also from the outside without any load on the central server, for instance to upload private contents and share with other players. Broadcasting of reviewed content to all clients via P2P can work by explicitly allowing IP publishing for this purpose. Entities always should check with the server if an external IP is allowed to access the contents.

An anonymous bittorrent tracker should be incorporated (file upload, no searchable index, only word-of-mouth hash distribution).

Social Networking

Private conversations are logged with sender, receiver, time and channel, just the messages themselves are kept encrypted. As a database is used also for logging, it is feasible to datamine and visualize data like who-knows-who or which channels are used when, and so on. Datamining for social networking features however should be disabled by default but easily switched on if needed, in general or only for specific purposes. As these features are only available via external tools (applications that connect as entity flagged as agent), it is possible to select which use is allowed and which is not.

With features like these, the platform also can be used for example to meet new friends, but also to find people who could help with specific tasks, without forcing anyone into revealing personal data like common social networks do by design.

Financial Consideration

In the beginning private donations of money and servers probably will suffice. However, as the platform grows and more services and users come together, the infrastructure is going to grow, too. As the platform will probably also draw commercial attention, donations from these firms can be taken into consideration as support.

Because most users won't tolerate advertising being forced on them in any way, the platform must be ad-free by default. However, it may be possible for users to enable advertising by their own will and by doing so donate to the project indirectly. This kind of "donation by advertising" might even proof more effective than any "enforced" advertising as people are aware of the advertising and its use. It is crucial however in this approach to publicly and transparently list the income by advertising and how the money is used. Auxiliary uses of the money could be decided by user-voting.

Engine

Considering the agile development paradigm it is imperative to produce usable prototypes as quickly as possible while leaving room for optimization. This can be achieved by using Python as main language while C++ can be used for optimizations. Considering different 3D engine choices OGRE might be a good one as it is featurecomplete and implements rendering good while it works well with custom plugins.

Kerberos possibly could be used to realise the distributed server concept as well as the "entity as application" idea.

Roadmap

My plan of action is as following:

1. Collect ideas and work out concepts for about 2 months until after elections in germany have taken place.
2. Approach interested people and create a team.
3. Set up infrastructure for testing and coding (Mercurial?), homepage, projectmanagement-system & wiki.
4. Define milestones of development.
5. Arrr!