Table of Contents
As the workflow of creating a game requires a large number of people working on a numerous components simultaneously within a variety of environments it is nescessary to ensure that everybody can work together in as seamless a manner as possible. This chapter aims to outline the key areas in which interaction is required and the recommended methods to avoid conflicts.
Currently there are three areas that have been identified that may cause potential interaction conflict for an unprepared development team:
-
Windows and Linux cross platform development.
-
Using BigWorld with a Version Control System.
-
DBMgr database conflicts.
For anyone not familiar with both Windows and Linux, running a BigWorld server on a Linux box to test game scripts and assets can be intimidating and error prone. Since designers and artists typically do most of their work on Windows, the process of synchronising files between Windows and Linux machines can be tedious.
The solution outlined below aims to simplify this task by having all assets and game scripts reside on a Windows machine, with a Linux machine (which can be shared among multiple users) hosting and running a BigWorld server for each user that requires their own development environment.
Sharing game resources between Windows and Linux
This solution can be summarised as follows:
-
A game developer on a Windows machine creates a network share of the root BigWorld directory (i.e., the directory containing
bigworld,fantasydemo, andsrcfolders). -
On the Linux machine, the Windows share from Step 1 is mapped to a directory and the relevant
<res>
Cross-mounting development resources has been found within the BigWorld offices to be the most effective method for Windows based developers and artists to work, as all editable files reside on the machine they are working on.
Note
This solution intentionally keeps the server binaries on the Linux box.
Running server executables that exist on Samba mounted filesystems can cause unexpected problems, and is not recommended.
Running server binaries from NFS mounted filesystems works correctly and is a recommended alternative.
For the purposes of this example we assume that all the game
resources have been checked out into a directory called C:\BigWorld.
To share the C:\BigWorld
directory on the Windows machine, follow the steps below for your
version of Windows.
-
Browse to the
C:\drive in Explorer. -
Select the
BigWorlddirectory and right-click it. -
In the context menu, select the Sharing and Security... menu item.
-
On the mf Properties dialog box, select the Share This Folder option button.
-
In the Share Name field, type the name to share the folder by (in our example, mf-win).
-
Click the Permissions button.
-
In the Permission For mf dialog box's Group or User Names list box, select the Everyone item.
-
In the Permissions For Everyone list box's Full Control entry, select the Allow check box.
-
Browse to the
C:\drive in Explorer. -
Select the
BigWorlddirectory and right-click it. -
In the context menu, select the Properties menu item.
-
Select the Sharing tab.
-
Click the Advanced Sharing... button.
-
In the Advanced Sharing dialog box, select the Share this folder check box.
-
If necessary, click the Permissions button to enable all users access privileges to this share.
-
Click OK when finished.
To assist the process of mounting the Windows share, BigWorld
provides the script setup_win_dev. The location of
this script may differ depending on your edition.
- Indie Edition
-
For customers using the Indie edition,
setup_win_devwill be installed into/opt/bigworld/current/server/binby the server RPM package. This directory has also been placed into your$PATHso you can runsetup_win_devfrom any directory. - Commercial Edition
-
Customers using the Commercial edition can find the setup_win_dev script located in
bigworld/tools/server/install/setup_win_dev.py.
Please note, however, that it was designed for developers working at BigWorld, and hence it uses default values appropriate for BigWorld as well. Before artists and game programmers use it, a sysadmin or programmer should edit this file to change the defaults to values appropriate for your development environment.
This setup_win_dev script has following
assumptions:
-
The server binaries can be accessed on the Windows share.
-
Your username on the Windows box is the same as your username on the Linux box.
-
You are using CentOS 5 or later.
-
Linux kernel with CIFS module. This should be contained within the default CentOS kernel.
The script will display a list of prerequisites upon startup, which are reproduced here for convenience:
-
The user running the script has been entered into the
/etc/sudoersfile on the Linux machine.For details see the system manual page with the command 'man sudoers'.
-
You know the location of your home directory on the Linux machine.
This can generally be discovered by running the following command:
$ echo $HOME /home/alice
-
You have shared the top level BigWorld directory from your Windows machine.
For details on how to achieve this see Sharing resources from Windows.
-
You may also require the Samba client programs. To install the Samba client, run the following command as the root user:
# yum install samba-client
Once the requirements outlined above have been met, or any
necessary modifications have been made to your environment, running
the setup_win_dev script will guide you through
mounting a Windows share using Samba onto the Linux machine.
Outlined below is a simple run through of the
setup_win_dev program discussing each
step.
When the program is first run, it attempts to establish root user privileges using the sudo command. This enables the program to interact with the system devices nescessary to provide access to your Windows share. This step may not be nescessary if you have recently performed another command using sudo. Enter the password for the account you are currently logged in as.
$ setup_win_dev
NOTE: If you are immediately prompted for a password, enter your *own*
password not that of the root user.
* Validating user has 'sudo' privileges
Password: Next we see that the program is preparing a destination
directory for the Windows share to be placed under. This directory
defaults to $HOME/bigworld_windows_share
* Setting up destination location for Windows resources
The next step involves entering information regarding the location of the Windows machine and the name of the shared resources. If you are uncertain about any of the details attempt to access your Windows machine from another machine in the network to establish the machine name and share name.
* Querying location of remote resources Enter the hostname of your Windows machine: mywindowsmachine Enter the share name of the shared BigWorld directory: BigWorld_indie
You now need to input the username and password required to access the Windows machine. The username will default to the username of your unix account, however if your Windows login is different simply enter that here.
We now need the username and password required to connect to the Windows share Username [alice]: bob Password: Confirm password:
The setup_win_dev program now outputs the
resource name to be used when accessing the Windows share. This
resource name can be used by other Samba tools such as smbclient if
you are having troubles connecting.
Using remote location: '//mywindowsmachine/BigWorld_indie'
Finally you will be asked if you wish to have the Windows share
always available on the Linux machine. This allows you to reboot or
shutdown the Linux machine whenever you need to without having to
remount the Windows share. If you choose 'yes' a new file that is only
readable by your user will be created in
$HOME/.bw_share_credentials
Do you want to automount your Windows share each time this Linux box boots? This will place a file in your home directory containing a clear-text copy of your password that is only readable by your user. [yes]
The setup_win_dev program will now attempt to make the Windows shared resources available for you.
Patched /etc/fstab successfully //mywindowsmachine/BigWorld_indie is mounted at /home/alice/bigworld_windows_share * Windows directory successfully mounted
It is strongly recommended that a version control system such as CVS, SVN or Perforce is used while developing a game using BigWorld. In doing so you allow numerous people within your development team to remain up to date with changes and enable access to all parts of the project resources regardless of the development platform of an individual.
Most recipients of an SVN distribution should place the entire release received from BigWorld into their version control system. This ensures that any changes to the BigWorld source code and resources are propagated to all the game developers at once.
Some files should not be committed into the version control system. Please review the section Files to exclude from version control for further details.
Customers using the Indie edition should only commit their own project directories into version control.
Indie customers should only commit their own project directories into version control.
For example in the case of a new game called
“my_game” it is recommended to commit the directory
C:\BigWorld\my_game into your
version control system.
Some files should not be committed into the version control system. Please review the section Files to exclude from version control for further details.
When setting up a new client machine run the installation procedures outlined in the Client Installation Guide and then checkout your project into the new installation.
When setting up a new server machine run the installation procedures outlined in the Server Installation Guide. You will then need to checkout your project into the home directory of the user running the server, or follow the instructions outlined in Windows and Linux cross platform development to use resources mounted from a Windows machined. After preparing the server and the game resources for use you will also need to ensure that the .bwmachined.conf file has been updated accordingly. Details on the .bwmachined.conf file can be found in the Server Installation Guide.
There are numerous files that are automatically generated while running a the BigWorld Technology Suite which are only relevant to the user currently running a program. These files should be excluded from your version control system to avoid conflicts with other users. Each version control system provides its own mechanism to ignore or exclude files. For example Subversion allows you to set a directory property svn:ignore to a list of file match patterns for that directory.
Below is listed a set of files and directories that should be considered for adding exclusion rules to your version control repository and configuration files.
Application log files such as python.log or
worldeditor.log should not be committed into your
repository.
*.log
When you run the game client or the tools, some resources will be created on-disk as 'processed' or 'compiled' versions of source files. These files are regenerated on demand based on comparing the timestamp of the source with the timestamp of the automatically generated file. These files should not be committed into your repository.
*.dds # Compressed texture map files *.anca # Compressed animation files *.font # Processed font files font/*.dds # Generated font bitmaps
Python scripts used for client and server game logic will generate a compiled byte-code file when they are first run or updated. As these files will be changing frequently during development they should not be included in the repository to help reduce clutter with each changeset.
*.pyc
The art pipeline tools automatically generate user preference files when they are run. As these will differ between artists they should be excluded from the repository.
bigworld/tools/worldeditor/options.xml bigworld/tools/worldeditor/resources/graphics_preferences.xml bigworld/tools/particleeditor/options.xml bigworld/tools/modeleditor/options.xml
The art tools Asset Browser also generates history files as it is being used.
bigworld/tools/modeleditor/resources/ual/history.xml bigworld/tools/modeleditor/resources/ual/favourites.xml bigworld/tools/particleeditor/resources/ual/history.xml bigworld/tools/particleeditor/resources/ual/favourites.xml bigworld/tools/worldeditor/resources/ual/history.xml bigworld/tools/worldeditor/resources/ual/favourites.xml
World Editor will create a
space.localsettings file when creating a new
space.
<your_game>/res/spaces/<your_new_space>/space.localsettings
World Editor will also create two files containing a space map. Both these files must be committed to revision control or neither.
<your_game>/res/spaces/<your_space>/space.thumbnail.dds<your_game>/res/spaces/<your_space>/space.thumbnail.timestamps
The BigWorld game client will also generate a preferences file in the directory it is run from.
# Substitute 'fantasydemo' for your game name fantasydemo/game/preferences.xml
For customers using a MySQL database to store persistent data, shared development environments can present an issue with multiple servers contending for the same database.
The database used by DBMgr is exclusive per server cluster instance so it is nessecary for multiple users running a server on the same machine to use different databases. To do this requires adding or modifying the the <res>/server/bw.xml configuration file entries for dbMgr/host and dbMgr/databaseName. Specifically the databaseName should be unique per user. For more information on these options refer to the Server Operations Guide section DBMgr Configuration Options.