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:

1. VR, public - like wild/town in Planeshift
2. VR, private - freely extendable regions and buildings by using instances of maps and action locations, moderation by founder (private regulation like IRC channels)
3. AR, public - overlay of RL interfaces with maps that resemble real areas
4. 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.

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.

Movement and Distances

Areas are covered with a hex-field mesh. 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.
• There should be a way to get links directly to the corresponding results to share via twitter and other means.
• There should be a way to upload contents to work on privately. Public contents require community review.
• Public content could be updated/shared via a P2P approach.

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.

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!