Setting Up a Team Development Environment

From Multiverse

Jump to: navigation, search
Asset Management

Overview and Setup  •  Download an Asset Repository  •  Using Asset Importer  •  Using Asset Packager  •  Team Development

Reference

Anatomy of a Repository  •  Asset Definition Files  •  Asset List Files

Contents

[edit]

Overview

Team development requires:

  • Setting up a team Multiverse client/server configuration where each team member can use Multiverse Client to enter the gameworld.
  • Setting up a shared asset repository for Multiverse tools, where team members can upload assets they have created/modified and converted to Multiverse formats.

In such cases, Multiverse strongly recommends that you set up a version control system and repository to manage your media assets, code, and other files. See Version control systems for more information.

If you don't want to use version control, you can set up a "quick and dirty" team development environment in which one team member runs the server and acts as the clearinghouse for assets, essentially performing the same function as a version control system. This may be workable for a small informal team; for larger projects a version control system is recommended as a "best practice."

[edit]

Setting up a shared asset repository

A shared asset repository enables team members to work with and modify a common set of assets. Team members need to be able to access the assets both with tools and "in world" with the Multiverse Client.

[edit]

Team in a LAN environment

If your team is all on the same local area network (LAN), then you can set up an asset repository in a shared directory on a network drive, and everyone can designate that directory as their asset repository for the tools.

In this case, run the client with the --use_default_repository or --development option, so that each client gets assets from the shared network directory. In this case, the client will not actually download any assets, but will use the assets provided in the designated "default" asset repository.

To add an asset to the repository, use the Asset Importer tool, and follow the instructions in Setting Up an Asset Repository. To modify an asset, simply open the asset file with Asset Importer and save it back to the repository.

This process will work as long as people never work on the same assets, otherwise conflicts may occur. A version control system will ensure that there will not be conflicts when people work on the same assets.

[edit]

Distributed team

For a distributed team (not on the same LAN), setting up a shared asset repository is a bit more complicated.

To set up a shared asset repository for the Multiverse Client, follow the instructions in Setting up an asset repository. This requires installing a web server to provide Internet access to the assset repository. Once you have done this, register your world with the Multiverse Network so that remote clients can access the world and use the specified asset repository. See Registering a World with the Multiverse Network for details.

Note: In this case, do not use the Multiverse client --use_default_repository option; this option tells the client to use the local asset repository used by the tools, instead of the asset repository identified in the world settings file.

For the tools, each user uses his own local asset repository. The team member who runs the server maintains the "master" asset repository. When other team members need to add or modify assets, they refine them locally, and then send them (via email) to the repository keeper, who merges them into the master repository. The repository keeper can then "sync up" the team by redistributing the asset repository to the team.

If you use a version control system (see below), then each user can check assets in and out from the central repository. Then you can update the assets in the central asset repository, either manually or with an automated script that runs at specified intervals.

[edit]

Registering your world

For team development where there is one central server accessed by many remote clients, register your world with Multiverse as described in Registering a World with the Multiverse Network. Then, each developer can access your world by using the --world client command-line option. If you have set up a network asset repository, then each client will also download assets at runtime from the specified asset repository location.

Individual developers who run their own server can use the --world localhost option to connect to a server running on the same machine as their client.

[edit]

Version control systems

A version control system will eliminate possible conflicts when people work on the same files and provide a secure way to distribute assets to a distributed team. When using version control, each team member checks out assets locally, and then checks in additions and changes to the repository. You should regularly update the network asset repository (on the update server), either manually or with a "cron job". This ensures that the assets downloaded by clients logging in to the world are always up to date.

Most version control systems are client-server applications; you must setup a central server (that holds the repository) and each developer must install client software on his or her machine.

Some of the most popular open-souce version control tools are:

Retrieved from "http://update.multiverse.net/wiki/index.php/Setting_Up_a_Team_Development_Environment"
Personal tools