Liberi Developer Guide: Workflow

From EQUIS Lab Wiki

Jump to: navigation, search

This page will familiarize you with the organization of the Liberi project, and walk you through the steps for testing, building and publishing game builds. This page assumes you are already familiar with the world architecture and the network architecture, since the project structure somewhat reflects these architectures. It is also assumed that you already checked out the Liberi repository, as per the Setup article.

Contents

Project Structure

Overview

Here's a brief overview of the folders and files you'll find under the Liberi root directory, and what they do:

  • Builds:
This folder contains all the binary builds for Liberi. This includes development builds, debug builds, and release builds. More on these below.
  • Dependencies:
This folder contains third-party libraries used by the LiberiNet, LiberiWorldServer, and LiberiServerPool projects.
  • Documentation:
This folder contains Doxygen docs generated from the XML documentation in all of Liberi's code.
  • Liberi / Liberi2:
The folder contains the Unity project for Liberi. This will be used to build the game client and server, and is where you'll be spending most of your time. Liberi2 is just a symbolic link to the Liberi folder. See the Setup article for more details.
  • LiberiNet:
This folder contains the project for the network protocol project.
  • LiberiWorldServer:
This folder contains the project for the world server.
  • LiberiServerPool:
This folder contains the project for the server pool.
  • LiberiWorld.sln:
This is the solution which includes the LiberiNet, LiberiWorldServer, and LiberiServerPool projects.
  • publish-_____.bat:
These are scripts used to "publish" builds. More on this below.

Liberi

This is the Unity project folder. In it, you will find three folders. There is not much to say about the ProjectSettings' folder beyond that it stores the Unity project settings, such as graphics, input, physics, and script execution orders. The Config folder contains game client configuration files used when testing the game from the editor. This is usually generated by the game at run-time. However, in order for testing conditions to be consistent between different development machines, we keep this folder versioned with SVN. The most important folder is the Assets folder. Here is a summary of its contents:

  • Content:
This folder contains all the "content" of the game. This includes all textures, materials, animations, and sounds. It is organized by the content's semantic category ("Avatars", "Mobs", etc.), and not by the asset type. Note that any prefabs that are spawnable at run-time should go under "Resources" subfolders, to make them accessible to the Sync framework. The two types of assets you won't find in this folder are scripts and string resources.
  • Editor:
This folder contains editor extension scripts, as well as script templates used by the wizard editor extension scripts.
  • Gizmos:
This folder contains various gizmos that you are free to use on your object prefabs to make things easier to see when editing (also because it looks cool).
  • Plugins:
This folder contains various pre-compiled libraries used by the project. This also includes the Liberi network protocol library, which is automatically copied to this folder when building the LiberiNet project.
  • Prefabs:
This folder contains reusable, non-content prefabs, such as the cameraman, or the cutscene manager.
  • Resources:
As of the time of writing this, this folder contains only localization data. See the Localization article for more details.
  • Scenes:
This folder contains all the scenes used by the game. Some of these are core scenes, such as "client", "server" and "launch". The rest are scenes for either specific zones or minigames.
  • Scripts:
This folder contains all the scripts of the game, organized by category.

Testing and Building

Types of Builds

There are three types of builds in Liberi: development, debug, and release. Development builds are for developer testing only, and represent the most unstable type of build. Debug builds are relatively stable builds that are meant to be tested by other lab members. Release builds are the final builds used in field trials or studies. When you build the world server, server pool, server, or client, they will always produce development builds. You can then select development builds to become debug or release builds via "publishing". See the "Publishing" section below.

If you look in the Builds folder, you will see some folders with the "_Dev" suffix; these are development builds. Similarly, debug builds are suffixed with "_Debug". You may have noticed that there are no build folders for the server. This is because server builds are placed inside the corresponding server pool builds, since it is the server pool that spawns servers. You may also have noticed that configuration files are versioned for the development builds. As with the Unity project, this is to keep testing conditions consistent between all developer computers.

Testing

Most of the time, you will be testing the game between two instances of the Unity project. In order to establish a full game network, four things must be run: the world server, at least one server pool, at least one zone server, and at least one client. Liberi's Unity project comes with an editor extension which makes testing and building the game easy. From the Unity menu, go to Window -> Liberi Test. This will open up the Liberi Test window. Feel free to dock this anywhere, and save the editor layout. From this window, you will be able to build and run game builds.

The first thing you will want to do is open and build the LiberiWorld solution in the root folder of the repository. This only needs to be done if you've just checked out the repository, or if you've made any changes in to the LiberiWorld solution.

Next, you will want to hit Build Server from the Liberi Test window. This will make sure that any servers spawned by the development server pool will be up to date. Do this if you ever need to have an up-to-date standalone server running for testing. If you are running a server from one of your Unity instances, this is unnecessary, since the Unity projects are always up to date. Now that the world server, server pool, and the server are built, you can click Run World. This will automatically launch the development world server build, plus one instance of the development server pool build. In turn, the server pool is configured to automatically launch one development server with the main zone loaded.

In all, you should now have the world server, server pool, and a zone server running. These can be left running for as long as you are working - you do not need to restart them every time you test, unless you require a change to the zone server. However, if you plan to make changes to the zone server, you can always close the spawned zone server, and simply run one from an editor instead.

question_icon.png

Issues with running scenes and servers?
Check this troubleshooting guide on configuring and building servers for more information.

Running

You can test any combination of zones / servers you want, either as standalone players, or from the editors. To run a client from an editor, simply press play while in the "client" scene. To run a server from an editor, press play while in the "server" scene, and you will be greeted with a UI interface from which you can select the zone or minigame to load. To run a standalone development client, hit Run Client from the test window in the editor. The text field beside the button specifies the player ID you want the client to login with. To run a standalone development server, hit Run Minigame or Run Zone from the test window. You may specify the minigame or zone to load with the corresponding text fields.

clipboard_icon.png

Note:
If you plan to run development standalone clients or servers, make sure they are up to date, using the Build Client and Build Server buttons. You only need to do this if not doing so would cause inconsistencies. Use your own judgment.


To run a client without the editor, run the Liberi executable from the build folder. Make sure the config files are set up correctly for the server you want to connect to.

To run a server without the editor, make sure the server connection settings are configured correctly in LiberiServerPool.ini (WorldID needs to be localhost if testing locally, or a public IP address if you want external connections) and in LiberiWorldServer.ini (add the same public IP address to the whitelist). Please see World IDs for more information on identifying servers. To start up the server initially, run the LiberiWorldServer.exe first in the LiberiWorldServer_Dev folder before running the LiberiServerPool.exe in the LiberiServerPool_Dev folder. Don't do this the other way around because it won't work. The server is now set up and ready to accept clients.

Publishing

Once you are happy with the development builds, you can propagate them to the debug or release build folders. You can do this using the publishing scripts in the root directory of the repository. For example, if you are happy with your changes to a new minigame, and you want your labmates to test it rigorously for the next while, you would run publish-client-debug.bat and publish-server-pool-debug.bat. This will propagate your current development build into the debug build folders. Now all you have to do is commit your changes. The test servers at the lab and all the test clients on all your labmates' computers should automatically update themselves from the debug build folders of the repository the next time they run. The publishing process for release builds are exactly the same. All clients and servers used for field trials and studies automatically update themselves from the release build folders of the repository.