APlay implements distributed objects. It does it through code generation in a model driven approach. It for examples simplifies the implementation of multi player or online games. But it is not restricted to games at all.
With APlay, developers can implement distributed, cloud and client-server applications as if they were programming a simple local application. The application code does not need to be aware of the distributed nature. The developer implements an object model and the behavior and interaction of the objects in that model. Distribution of data, events and persistence are intrinsic.
- Text based definition of classes, similar to modern object oriented languages
- Distribution of data between clients and servers
- Persistence: Storage of objects in database on server side
- Automatic interest management
- Server cloud
- Generation of specialised clients for mass testing
- Generation of live online debugging of objects in servers
How it works
With APlay the developer specifies distributed classes. APlay generates the code needed to use these classes in the application. Generated classes automatically communicate and get persisted (according to developer's definition).
Because the classes can be specified directly at a functional level, there is no need to write low level network access layers or even mid level network to logic glue code. The net effect is usually measurably less code than a traditional approach, even with a network library.
As a practical example, informing the server of a color change for the player is as simple as writing "player.color = blue". No marshalling or formatting of messages or any other "administrative" code needed.
Because of the distributed object approach, so called "interest management" is practically automatic. Interest management in this context is to be understood as wanting to always have an up to date copy of whatever game entity a process (i.e. game client) is dealing with. To give a specific example again, once a specific player object has been passed to a client, for example a player standing in visible range, the client will automatically receive all events and data changes for the player object until the client disposes of it. There is no need for any type of subscription management or similar. As this logic works recursively due to the nature of having an object model, passing the data for a dungeon can be as simple as a single object assignment: "player.currentDungeon = Dungeons". Such a line of code on the server would transfer a whole tree of objects to that client (and everyone holding that client object) and keep all that data up to date.
The non-invasive nature of generating code rather than a fixed API makes it significantly easier to integrate networking into an existing single player or local multi player game.
The distributed object model applies also to the server side. It is therefore straightforward (and actively supported) to implement a cloud of servers sharing the data for an entire world and serving many clients. The distributed objects make it simple to only share that data between servers that is really needed. Servers can dynmically decide which objects they need and want to keep active and which not.