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" way.

Brainstorming

• 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
• 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 - applications that handle specific tasks like weather, economy interactively within the environment
  • NPC - AI controlled character
  • PC - player controlled character
  • service - external applications like interfaces to other communications networks, datamining for social networking etc. that need to be visible in a list for users to access them.
• Entities are owned by accounts that can be flagged as:
  • pirate (player) - any natural person
  • FSM (flying spaghetti monster) - control of houses, landscape and global stuff
  • AI (artificial intelligence) - servers dedicated to NPCs, bots and such.
• Content from Peragro Tempus and Trinity Reign can be used for a headstart, very helpful people
• Economy
• Magic
• Time
• small idea for testing the IP/ingame object binding concept
• Chat
• Skills

Controls

I imagine an extremely simplistic GUI initially, which can be extended easily. Direct access buttons may be Options, Communication, Contacts, Property, Tools, Help. The player-property-inventory is important as it contains all items in the player's sphere, including those possessed by his avatar(s). Minimap, compass and other GUI-extensions can be items in the player's inventory that can be activated and placed at will and also combined through crafting.

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.

Dynamic Assignment

Any account 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.

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

All entities need to be addressable ingame, but as many entities are realised as seperate threads (like NPC-AI) or even external processes (like a control-daemon for a freezer) a high-level approach is needed. A possible idea to realise this is to use a database schematic like entityID, name, owner, description, connection, protocol

The interesting thing about this schematic are the two entries at the end, which are not entered into the database but dynamically bound at runtime. The protocol determines which class of entity is spoken to, the connection determines where the entity is located at, which can be public/private IPv4 or IPv6. A message to the entity is sent from server to client via XMPP, the client unpacks the message body and uses the needed interface to the entity determined by the specified protocol. This way any kind of entity, may it be NPC-AI, freezer, userinterface, item, mobile phone and so forth can be addressed and handled appropriately.

Maps and such

Layers

What you see ingame is build in layers:

1. the topological map - a rough 3D layout which ensures compatibility with the bordering areas and determines the coordinates of tiles. The topological map is fixed mostly and cannot be changed on the fly, however modified copies can be uploaded interactively.
2. ready-made pieces of ground modifying the topology, (material and textures etc) called tiles, are placed on top of the topological map - the configuration of the tiles can be changed on the fly.
3. world-entities (entities owned by the FSM) like buildings, one also can interact with
4. regular entities

Hexgrid

There's a hexgrid projected as abstraction layer onto the topological map and the tilemap. The hexgrid consists of regular hexagonal fields that have edgelength 0.7 m and minimum radius 0.6 m. For 3D application the fields can be projected up to 3m height. These dimensions should be fine-grained enough for most applications like pathfinding and collision detection. For proximity detection and to save memory all fields that contain entities can be listed and grouped via a multi-tree, to only query the relevant ones in large areas. The hexgrid can not only be used in range applications, but also to play with angles, for instance when realising field of view.

This approach can be used for:

• using proximity as trigger - attach a trigger to a field and check when an entity is moved onto it
• range-based communication - calculate which fields are in the defined radius and query which entities are contained in each. It is possible to flag fields so that they are excempt from this query (due to spells etc.)
• fast cross-world distance estimation with little error
• pathfinding - find the shortest and least expensive way
• reactive landscapes
• auto-generated mapping of the world
• anti-cheat mech - it's easy to make fields not accessible without needing expensive collision detection or extra meshes, also the time needed to switch between fields can be tracked and determined if the move is legit
• simplified movement system with extra use - if there's no entity around to watch (which would need more detailed messages on movement) the system only needs to keep track of field switches. If needed, movement can be tracked and visualised, thinking of a smell-tracking spell there.

Instances

Instances of maps can be used as quick and dirty way to add new areas to the world. This is important for instance for interior maps as each player gets their home and also can make their own region to play privately. To simplify the management and make it possible to apply the hexgrid properly, instances need to be explicitely called as copy from an existing map, which then becomes a unique map on its own. On creation time of an instance the owner, bordering maps and permissions to access the map are determined. It also could be useful to only copy the topological map or also the tiles and world-entities. One might also want to explicitely hardlink coordinates of entities within different instances of the same map.

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.

Authentication and Passwords

Due to all messages being encrypted and only can be decyphered by the sender and receiver, a password-loss will be fatal, so password-recovery and authentication will be complex. Because most people probably just want to take a quick peek when checking things out for the first time and don't want to be bothered with technical details, a "quick and dirty", insecure method should be available (while encouraging the secure method). With the insecure approach, all messages could be encrypted with the public key of the server, alongside with the sender's and receiver's. So when one lost the key, the messages could be recovered or the password is saved encrypted by the admin-key on the server.

For authentication, there are three ways:

• Something the user owns (password file, smartcard, ...)
• Something the user knows (password, secret question)
• Something the user is (fingerprint, iris scan, typing characteristics)

Secure authentication can be ensured by using 2 or 3 of these ways, for instance a combination of password and password file can be considered secure. It is important to offer a sufficient number of means for authentication in different combinations as some people might not be comfortable or able to use one or the other.

Collaboration

• As SVG can be displayed directly, it is possible to use Inkscape whiteboard for presentation and collaboration virtually.
• Mumble can be incorporated as well. By using the internal logging facility for private chat (with encrypted contents), spoken recordings can be stored and delivered like normal chat-messages, too.
• A way to virtually cooperate in music composition should be considered. Maybe even include a midi-interpreter.

Collaborative editing is a main feature that should be implemented just after communication as it enables more productive development and boosts the usefulness of PiLife in one go. This can be realised by integrating a "shared folder" concept similar to Dropbox where one folder and its contents is observed and automatically updated with the server and other clients. Versions of files can be marked as "step", which then are archived on the server. During a collaborative work-session all changes can be reviewed and undone by using the logging facility. If a change is done to the file by using an external tool, a new "step" is registered, too. This way work can be done synchronously as well as asynchronously, using external tools, which gives huge liberty in how workflow can be structured and what tools can be used.

Content System

A lightweight database (sqlite for example) is delivered with every client. For this, a schematic is used like filename, hash, version, newest, URL. Whereas filename can be a single name (readme.txt) or a relative path (./help/readme.txt), hash is the current content hash of the file, version is the current versionnumber while newest is a boolean that tells whether the version is the most recent one. URL determines where to look for filename. This schema allows a number of good things:

• basic versioning of any content (user-made or platform)
• simple integration of an auto-updater that makes sure the system and content is up-to-date
• allows good integration of an anonymous bittorrent tracker (with file upload, no searchable index, only word-of-mouth hash distribution)

that can be used for content, but also system-files

• External content easily can be integrated just by linking a name to the URL, so stuff can be uploaded anywhere, thus PiLife infrastructure isn't needed to have stuff available.
• stepwise installation can be realized simply by entering the database entries step by step when they are needed
• content can be checked and loaded at the same time and if faulty or not up-to-date reloaded if necessary. This allows speedy startup without missing to check.
• access of files via URL, thus independent from filesystems, network-transparent.
• hash-check makes it bit harder to modify files and cheat

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.

It might be possible to implement custom social research algorithms with community-approved DB-views using anonymized data so people can examine social networks and make visualizations on their own.

Content

Creation of content is most time intensive. Therefor it is required to use only open file formats and provide means to import/export other formats and encourage it at the same time. For the avatars a unified skeleton should be used, to which all animations apply equally. On the other hand, the dimensions of the skeleton should be adaptable, so players can choose the exact properties of their avatars without need of artistic remodelling. Also an editor for animations should be provided so users can play with it and make their own contributions.

Parental Control

As this is not a game per se, but a unified communications platform, the minimum age will probably be at 13 (like irc.freenode.net), which however will require means for parents to control their children's activities. A possible idea to resolve the tension between the need of parents to know about their children's doings and the need for privacy on the children's side might be the possibility to mark accounts as "parental" to other accounts (which would have to be confirmed by the "children"-account). The parent-account would have access to those logs on the server that are plain text (time, sender/receiver, channel), the message-contents would be encrypted and therefor couldn't be provided (even if a parent requested it). A script could provide a standard summary over the logs, so parents could check quickly if everything's fine.

As parents often only want to make sure their kids go to bed in time and don't hang around on the computer for too long, a menu could be provided on the parent-account from where these settings can be made. A message system for delayed messages could be used to deliver reminders.

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 disposable but 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.

Spideroak might provide some general tools that can be used (Valgrind-Python integration, Transactional Storage system, Python Gimp Captcha generation, StatGrabber, Zipstream).

Users can choose how much space they want to provide for the distributed database. A possible way to realise this distributed, redundant database might be to use some sort of transparent TrueCrypt-drive mounted over network. This would make reading the data directly from harddrive impossible. With the data stored in a binary database, it is also extremely difficult to read it out even while the data theoretically is in plaintext in RAM - and this only counts for the headers of the messages, not the messages themselves, which are never in plaintext except when deciphered by sender or receiver.

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 the social networking feature. However, it can open up a whole new dimension - given the process of registration is simple enough.

Roadmap

My plan of action is as following:

1. Make PiLife.
2. Arrr!

Details about Organisation here.