Platform Developers

From Sirikata Wiki
Jump to navigation Jump to search

Platform Developers Starting Page

Sirikata Platform Developers

The core of Sirikata is a platform for building virtual world applications. This means that we don't produce any single virtual world and there is no resulting "product." Sirikata, at its core, is a set of interfaces and protocols for building virtual worlds. We also implement many of these interfaces, some with multiple variations to support the demands of different applications. If you're interested in building an application on top of Sirikata, for example a game, by writing scripts for objects and using Sirikata's infrastructure to handle things like user logins, content distribution, and rendering, then you are an Application Developer. Sirikata is in its early stages and not quite ready for applications to be built on top of it yet.

If you're interested in helping define these interface and protocols as well as building implementations of them, then you're in the right place. This page describes how the project is setup, how to get in touch with the developers, and how to start contributing.

Communication

Developers stay in touch via a number of mechanisms:

  • Mailing List: Developer List, Archives. Use for discussion about the platform architecture, protocols, and implementations. Patch sets can also be sent to this list for review and application if you do not have core commit access. We don't specifically separate mailing list traffic for application and platform developers since the overlap is significant and often useful, but we'd prefer to see general inquiries on the community mailing list or art related topics go to the artist mailing list.
  • IRC: #sirikata on irc.freenode.net (logs). Used for real time discussion with developers - quick questions, detailed questions about code, etc. (Wikipedia article on IRC)
  • Bugs: Nothing yet, send to the developer list for now.

Working with Sirikata

Because Sirikata is a large project, getting involved can be a bit daunting. This section's goal is to guide you through your first steps in getting involved. You most likely want to follow the steps in the order presented here: get familiar with the architecture, get the code building, learn more about the specific piece you want to implement/improve/extend, and then work on actually contributing back. If you're not sure what you want to help out with yet, this process should hopefully give you some ideas, and the coding projects projects page or a discussion with current developers can help you pin down exactly what to work on.

Architecture

Sirikata's architecture is still being actively developed, so be aware that the available information may fall out of date. To get started with the code, you likely only need a small bit of global knowledge to understand how the big pieces fit together, and then more detailed local knowledge on the parts you're actually developing on.

There are currently two major sources of information about the overall architecture of Sirikata:

  • This 25 min. video gives a high level overview over the Sirikata system architecture.
  • The System Architecture wiki page, which we will try to keep up to date with a similar but more detailed description to that in the video. It will also contain some example use cases to justify our architecture.

To get more familiar with any particular piece of the system, follow the links in the System Architecture document. In the event that the documentation is incomplete, try contacting the developers directly (and complain that the documentation is missing as well as asking your question).

Source Code

The Short Version

The Long Version

Our code is hosted on GitHub. Besides hosting and serving our code for us (thanks GitHub!), they provide a bunch of useful addons - tracking of forks, simple merge procedures, and stats tracking to name a few. It's not necessary that you use an account on github to develop Sirikata, but you might want to check it out. Especially if you want to do some experimental development or just work outside the main tree for awhile, its a nice way to easily track the mainline fork. Overall Git is a great a distributed version control system but it takes some getting used to so you may want to check out some tutorials.

To actually get started with the code you'll want to get it from our GitHub repository and then follow the build instructions.

Building Sirikata can be a complicated affair: it's a large piece of complex, platform independent software which leverages a large number of existing packages. Even worse, we currently have a limited number of test systems, generally those that the developers are working on. We would very much appreciate reports of any problems sent to the developer list, or even better would be fixes.

For reference, the current core developers have Linux, Mac and Windows machines. Most heavily favor Linux, especially the Ubuntu distribution.

Developer Preview (Prototype) Code

The current incarnation of Sirikata has its origins in a 6 months old prototype. This is available as a developer preview. Only the curious and brave will want to check this out; building it is more difficult than Sirikata.

Subsystems

Now that you have an understanding of the high level architecture of the system and have the code built and running, you'll want to jump into a specific area and start contributing.

At this stage its helpful to understand the directory layout of the repository:

build/ - CMake build system, will need to be updated with any new projects or source files
cppoh/ - C++ ObjectHost binary, what you'll run to simulate objects (which are "scripted" using C++, eventually we'd like other object hosts too)
externals/ - external projects that are hard linked into our tree
libcore/ - Core library, mostly utility code that will be used all over the system, including in the ObjectHost and Space. 
liboh/ - ObjectHost library, contains interfaces and some code which is shared among all ObjectHost implementations
libproximity/ - Proximity library, shared interfaces and implementations of proximity related services
libspace/ - Space library, contains interfaces and some code which is shared among all Space implementations
proximity/ - Proximity binary, what you'll actually run to run a proximity service, uses libproximity, adds implementations, plugins
space/ - Space binary, what you'll actually run to run a space service, uses libspace, adds implementations, plugins

Based on the above listing you'll want to dig deeper into whichever directory contains the area you're interested in working on.

How Can I Contribute?

There are a number of ways to get involved:

  • The best way to contribute is to figure out what you need that doesn't exist or isn't working in our current implementation and tackle that.
  • If you're not sure what to work on, check out the list of actively developed systems below or our coding projects page for ideas. The coding projects page contains a list of subsystems/plugins/implementations that we know we want to have eventually but nobody has committed to producing.
  • Fix bugs. It's a thankless job, but somebody has to do it. We don't have a bug database yet, so check the developer list for bug reports for the time being.
  • Documentation. Another thankless job. Developers are likely to let documentation fall out of date or may not even write it up in the first place. Currently we're using documentation inline in the code (doxygen style) and the wiki. Updating and improving either one would be valuable. Additional documentation would also be incredibly valuable; for instance, documents describing to non-developers how to get setup and running, features of the system, and maybe even how to start writing scripts, would be a great addition.

Regardless of the particular item you choose, we suggest doing the following:

  • Clearly define the problem you're trying to solve.
  • Start out with a small project or a subset of features that you can complete in a reasonable amount of time.
  • Seriously, make sure you know exactly what you're trying to provide and that its "nugget"-sized.
  • If you plan to modify or touch an existing subsystem in any non-trivial way, get in touch with one of the maintainers of that code before .
  • Send an email to the developer list with an outline of your project: goals, what subsystems need to be modified/touched/added, and an outline or plan of the code changes to be made. Getting some feedback before you start will make your life a lot easier.


The following is a list of subsystems which are currently being developed or for which designs are being discussed. Much work is just getting started and unfortunately this list is incomplete, but this should give a starting point for those who want to get involved in development that is being actively pursued.

  • We have just concluded a discussion on the type system used in messages and network wire formats.
  • The proposed protocol Sirikata will use. We encourage discussion about these built-in commands.
  • We are starting a discussion on how to implement distributed physics on our space servers.