The Universe Project Website has multiple Framework and Development Components listed that will be added into the game.
They will be listed here as they are written in the article on the official website:
[Networking] Fundamental Client/Server Communications Framework (Atmosphere)Edit
This is essentially complete.
At the moment, we're going to be using the Atmosphere framework for this. This framework handle the basics of starting and ending Websocket and Comet connections, detecting when to use each one, and ensures cross compatibility on various devices and browsers. Unfortunately, the framework is somewhat rudimentary and needs some help for a real time game, so we've built a layer on top of the atmosphere framework to do the rest of the work.
[Networking] Protocol ControllerEdit
This is 95% complete with only about a day of work remaining.
This layer sits on top of the Atmosphere component. It's job is to simplify the handling of Atmosphere and adding necessary features that are required for a game. Some of these features include: packet ordering, large packet splitting and handling, seamless reconnection handling, buffering during reconnects, and state hooks...among other things.
[Networking] Game Elements Networking FrameworkEdit
This is about 40% complete and will take up the majority of the first 2 months of development.
Now this is a major piece of the entire project, and any related projects. This framework resembles the functionality written in the white paper by Valve, regarding their client/server communication for their games (including Half-Life). It resembles it, but it takes a big step forward in generalizing the concepts into a highly reusable and simplified framework. This framework will massively reduce the amount of data needed to communicate inputs between client and server, and even server to server. It also removes much of the thinking required when dealing with client server delay issues.
[Graphics] Html5 Sprite and Isometric Graphics FrameworkEdit
This is about 80% complete and won't need much, if any work, for the first private demo.
This framework handles the visual side of the game as well as providing game loop hooks, resource loading, and many graphic and behavioural functions.
[Graphics] GUI FrameworkEdit
This is about 15% complete, but only a simple implementation is necessary for the first private demo. Likely only a few days work here.
A simple user interface framework for creating various GUI components, like textboxes and buttons, within the html5 canvas graphic display.
[Backend] Server ClusteringEdit
This has not yet been started, but it won't be necessary for the initial private tests.
This isn't really one component because it comprises of a handful of modules that work together in a scalable, clusterable environment. Most notably: database servers, relay servers, and simulation servers.
Part of this module will be a dynamic server allocation and layout rules engine for automatically and dynamically determining the best configuration of physical locations in the game world that each simulation server should be responsible for. This layout engine will not be necessary at first since servers can be laid out manually, based on population. When the automated version is written, there will need to be a tool that simulates population movement and changes to test the effectiveness of the program.
[Backend] Game Elements DesignerEdit
This has had quite a bit of work put into it already, but it is a long way from being complete. Luckily, we won't need it for quite some time.
This will be the tool that designs most of the game. Capable of describing objects and their associated graphics, ranges and math formulas for calculating attributes and probability curves, GUI element descriptors for interfacing with the object and performing various actions, action association...etc. This tool will essentially link game mechanic code with objects and describe: how objects are created, when ideas for inventions come about, how easy it is to try to create objects.. and the list goes on.