Table of Contents
For anyone not familiar with both Windows and Linux, running a BigWorld server on a Linux box to test game scripts and/or assets can be intimidating and error prone. Additionally, since designers and artists typically do most of their work on Windows, the process of synchronising files between the Windows and Linux machines can be tedious.
The solution presented here aims to simplify this task by having all assets and game scripts reside on the Windows machine, with a Linux box (which can be shared among multiple users) hosting and running the BigWorld server binaries.
Basically, the solution proposes the following:
-
User exports the root BigWorld directory (i.e., the directory containing
bigworld,fantasydemo, andsrcfolders) as a Windows share. -
Linux box mounts the relevant
directories inside the<res>bigworldfolder on the Linux filesystem.
This makes game development easy for a Windows-based developer/artist, since all editable files reside on the machine they are working on.
Note
The solution intentionally keeps the server binaries on the Linux box.
Running server executables pulled from SAMBA-mounted filesystems causes unexpected problems, and is not recommended.
Running server binaries from NFS-mounted filesystems, however, works correctly.
To share the mf directory on the Windows machine, follow the steps
below:
-
Select the
mfdirectory 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.
To assist the process of mounting the Windows share, BigWorld
provides the script
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 script works on the following assumptions:
-
You are using CVS ‐ if you wish to use this script in a Subversion-based environment, then a search-and-replace should be done.
-
The server binaries are stored in the CVS repository.
-
Your username on the Windows box is the same as your username on the Linux box.
-
You are using Fedora Core 5 or later (this script has not been tested on Debian).
The script displays a list of prerequisites upon startup, which are reproduced here for convenience:
-
You have been entered in the sudoers file (for details, issue the man sudoers command) on the Linux box.
-
You know the appropriate
$CVSROOTfor your environment. -
You know where your home directory will be on the Linux box.
-
You have shared the root BigWorld directory on your Windows box.
Once these requirements have been met and/or the necessary
modifications have been made for your environment, running
setup_win_dev.py will perform the following
actions:
-
Create your home directory on the Linux machine if it does not already exist.
-
Mount your Windows share using Samba and patch /etc/fstab (so it can be easily mounted in the future).
-
Detect the
folder in your Windows share and ask you which ones should be symlinked into the Linux BigWorld folder.<res> -
Request the order in which the
folder should appear in your<res>$BW_RES_PATH. -
Set up your
~/.bwmachined.conffile. -
Fetch the server binaries from CVS.
Once the actions above have been performed, you can use WebConsole from your Windows box to:
-
Start and stop a server.
-
View server output.
-
Connect to the Python Console of a running server process.
-
Perform other administrative functions.
At present, setup_win_dev.py does not insert your
Windows password into the /etc/fstab entry. This is
because the file is world-readable by default, which would expose the
passwords.
The downside to this approach is that the Linux box will not be able to automatically remount any Windows shares at boot time ‐ the shares have to be manually mounted via the shell, and each user's password must be entered. If the Linux box is rebooted often, then this can be time consuming.
If you consider your internal security robust enough to have your
Windows passwords in /etc/fstab, then you can add the
passwords in the options section of the relevant mounts in
/etc/fstab.
