A recurrent issue we have when playing in editor is the game crashing with the exception "Port already in use". We found out that making the SS3D's folder (the whole project's folder) an exception for your firewall and antivirus is solving this issue.

We might add specific instructions here for specific firewalls and antivirus in the future, but it should be pretty straightforward.

Using the .bat file

First, launch a server by following instructions on the page Hosting a server.

Assuming you built the game and have a SS3D.exe file in the Builds folder, you can simply double left click on the Start SS3D Client - GhostOfBeep.bat to launch a client, with GhostOfBeep as a username.

Using the Command Line Args

Open a command prompt in your project's path to the Builds/Config, and run the following command changing the fields appropriately.

This will launch the client, replace clientUsername with your username and replace serverAddress with the desired server address, you can use localhost or 127.0.0.1 for a local server.

Using Application Settings window

You can set the Network Type to Client, the Editor Server Address to the desiredserver IP, or your local IP (127.0.0.1) if hosting from the same machine, and the Ckey to your desired Ckey.

If you're developing, you'll need at some point to build the game so you can test it with multiple clients.

You can follow Unity's instructions about building here if you need help with that.

We currently have two scenes in game, include them both, and you should be fine by leaving everything else default.

Click the Build button, and select the Builds/Game folder, if you don't, the build won't work !

That's it !

Command Line Args

The command line args are various symbols used to define arguments to be used by the SS3D application when it runs. The reason for it existing is to easily add Hub support for it when we eventually have it.

Here's a little example on how they look, you can find all them in the CommandLineArgs.cs file

Using Application Settings window

The application settings window reflects information used on the Command Line Args, it is useful for Editor overrides and internally we use it along the command line args when using built executables.

In the project settings window, you can find the Application Settings group, where you can see all the settings related to what configurations the game will use when running.

This only contains settings related to the application use. Graphics, sound, and user settings will not be defined there.

Always check your code on host and on client

SS3D is a networked game, some of the code is running server side and some client side. Every time you add or remove something, you should check that it works well both on the host and on the clients.

Ideally, you should make tests including one host and multiple clients, at least one, but be careful, some bugs involve two clients and it would appear as working between host and client alone. Hence, try to test with two clients and one host, whenever it's possible and relevant.

Refer to the section to learn how to host and join a server.

Making attributes of class public

In Unity, whenever an attribute is public, it will appear in the gameObject inspector. This allows you to modify attributes during runtime in the gameObject Inspector.

In the below picture, I can modify the Inventory displayed by the inventory UI script, simply by clicking on it, and replacing the reference with the one of my choice.

This could be useful to quickly go through all inventories during the run, without having to code a special tool for it.

Making attributes public is also interesting to observe attribute changes during run time without using an actual debugger or the console. It has the advantage of not disturbing the flow of the game, and not overflowing the debug console.

Making use of the Input.GetKeyDown() function

Sometimes, what you need to debug involves critical timing, and running some logic. A classic debugger is not good enough or at best makes things really tedious.

To control when you want to get some debugging info, or run some code at the right time, what you could use is the Input.GetKeyDown() function.

This function simply returns true whenever the key of your choice is pushed. Put that in the Update loop of a monoBehaviour and you can log anything you want when you push a key, or run some logic.

Here's an exemple, this little snippet of code allows me to modify a given container by one of my choosing, during run time, when I choose to. It's a simple trick but it's easy to forget about it.

What's destroying my game object ?

SS3D is full of calls to the Destroy() method on game objects and as the game grows finding what's destroying a given game object will become increasingly difficult.

A simple search in your code editor, using Ctrl+f and searching through the whole solution for "Destroy(" can be enough, but it's tedious.

Here is an useful trick to find what's destorying your game object. Just add this code on any component on the game object that is destroyed. It will print in the Unity Debug console the stack of methods responsible for the call of OnDisable, and this usually allows to to trace back what's destroying your game object.

These are edit mode tests that are intended to check basic configuration of objects. These represent actions that a non technical person could check in the editor (given a basic checklist) without needing to look at any code. Examples include making sure no prefabs have missing scripts, making sure all tile prefabs are within a certain size range, all asset data references are not null etc.

Asset audits have been configured as parameterized tests, so it will be immediately clear which object is causing failures.

Note that a business rule is that test failures for prefabs should be resolved before test failures for scenes, because the scenes may be broken because the prefabs in them are broken.

These are edit mode tests that are intended to check the behaviour of public methods within the game systems. They are restricted to editor only functionality, so some code will not function (e.g. IEvent invocation)

The process of hosting a server, where you can play and have players connected to your server is possible via two paths:

Pre-launch instructions

Using the .bat file

Assuming you built the game and have a SS3D.exe file in the Builds folder, you can simply double left click on the Start SS3D Host.bat to launch a server, with john as a username.

Using the Command Line Args

To host a server outside the Unity Editor, first you have to build SS3D in the Builds folder of your SS3D project. You can then open a command prompt, move to the Builds folder and type :

Replace hostUsername by whatever username you want to use. Don't hit enter yet and skip to launch instructions.

Using Application Settings window

You can set the Network Type to Host, the Editor Server Address to your server IP, or your local IP (127.0.0.1) if hosting from the same machine, and the Ckey to your desired Ckey.

Launch Instructions

In the permissions.txt file, inside the Builds/Config folder. The username should have Administrator written on the same line in the permissions.txt file, otherwise it will not able to host the server. This should probably be automated eventually.

You can now hit enter or hit play depending on your case. The server will be launched and you can join with a client now.

Once started, go to server settings and click on start round like in the picture below.

Troubleshooting

When needed, contributors might need to review PRs

To ease out the process, we'll walk through all the points need to be tackled when reviewing.

Check the Target branch, check the source branch

Unity divides tests in two categories, play tests and editor tests. We decided to divide those tests into more subcategories. Here's a summary of the hierarchy, and you can find on the following pages a description of each of those, allowing you to choose the right category when writing a new test.

• Play tests

• Editor tests

  • Asset audit

  • Edit mode

Killing a player by hitting on torso

SETUP : Just have a healthy human spawn, with the AttackBodyPartByClickingIt attached. Check that the damage amount is above 0 (should be 10 to quick test it).

TEST : Press F a bunch of time while aiming with the mouse on the player torso until the player explode.

RESULT : You should see body parts flying, the camera should focus on the detached head, all body parts should disappear after a while and the head should too. After that, you're a ghost that you can control.

Killing a player by hitting on head

SETUP : Just have a healthy human spawn, with the AttackBodyPartByClickingIt attached. Check that the damage amount is above 0 (should be 10 to quick test it).

TEST : Press F a bunch of time while aiming with the mouse on the player's head until the player dies.

RESULT : You should immediately become a ghost.

Bleeding to death

SETUP : Just have a healthy human spawn, with the AttackBodyPartByClickingIt attached. Check that the damage amount is above 0 (should be 10 to quick test it).

TEST : Press F a bunch of time while aiming with the mouse on random body parts on the player.

RESULT : See that blood particles are spawning close to the body part you hit. Check that after a while, the player dies from lack of blood. Should take less than a minute if you hit a lot of time each body part.

Walking when injured

SETUP : Just have a healthy human spawn, with the AttackBodyPartByClickingIt attached. Check that the damage amount is above 0 (should be 10 to quick test it).

TEST : Press F a bunch of time while aiming with the mouse on the feet.

RESULT : See that player movement is slower with injured feet. Try to destroy completely the feet to see that the player cannot move anymore.

Loosing hands

SETUP : Just have a healthy human spawn, with the AttackBodyPartByClickingIt attached. Check that the damage amount is above 0 (should be 10 to quick test it).

TEST : Take an item in hand. Press F a bunch of time while aiming with the mouse on a hand, until you destroy it.

RESULT : See that a hand slot in the UI has disappeared, and that the player can't pick up items with its missing hand. Try to destroy the other one to check if the player can't take anything anymore. Check that the item held is dropped when the hand is destroyed.

SS3D, now with play mode tests ! Those are heavy tests, that require building the game, and, depending on the goal, they may require starting a server, launching multiple clients ...

Play mode tests architecture

Play mode tests need different setup based on what is tested . For instance, we might want to test picking up an item, for players embarking at the same time as host, or for players embarking after it. We could also test it just for host.

Manual Tests

The pages below describe a bunch of tests related to different systems implemented that a reviewer should do in order to check if everything's alright.

All tests described here should be tests that did pass at some point on the develop branch.

Please add a mention if the test you add is supposed to pass in the future but not yet.

Those tests are under the form :

SetUp : What need to be done before starting the test.

Test : What need to be done to execute the test.

Result : The expected result.

Clothings put in clothes slots show on the character

Should work for backpack, gloves, shoes, jumpsuit, headsets left and right, glasses, mask, PDA.

SETUP : Just spawn a human, make it naked. Spawn a random piece of cloth.

TEST : Take the cloth by left clicking it and put it in the appropriate cloth container by dragging it with left click.

RESULT : You should see the cloth displaying on the player.

Items put in hand slots show in player hands

SETUP : Just spawn a human.

TEST : Pick up a random item by left clicking it.

RESULT : Check the item is well in hand and move accordingly to the player's movements.

Dragging items out of inventory slots dump them out of inventory

SETUP : Just spawn a human. the human should have a few items on it already.

TEST : drag an item with left click and release outside of the container.

RESULT : Check the item is dropped close to the human, and the sprite is no longer showing in inventory.

The process of opening SS3D as server only, where you can play and have players connected to your server is possible via two paths:

Pre-launch instructions

Using the Command Line Args

To open a server outside the Unity Editor, first you have to build SS3D in the Builds folder of your SS3D project. You can then open a command prompt, move to the Builds folder and type :

Using Application Settings window

You can set the Network Type to Server.

You might wonder how to trigger an effect during an animation, how to call functions when an animation ends, even better, have your effect still trigger at the right time even if you change your animation. The answer is state machine behaviours.

To make it simple, SMBs are scripts you're going to put on states in animator controller. It calls some callback methods when entering and leaving a state.

In this page, I'll provide an example on how to set up properly an airlock, using it.

Airlock example

Say you want some lights on your airlock to turn green when opening, red when closing and black when idle.

We have the following state machine for the airlock.

During the opening state, the animator play the "opening" animation.

During the closingstate, the animator play the "closing" animation.

When selecting a state, see the "Add behaviour" option. We're going to use that to write a script to handle the airlock lights.

As said earlier, SMB's have callbacks when entering and leaving a state.

We're going to use two of them here, OnStateExit and OnStateEnter.

public override void OnStateExit(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)

public override void OnStateEnter(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)

The idea is simple : let's put our behaviour on the two states, opening and closing. When leaving a state, we know that the door is idle, so we're just going to make that call (we'll detail the ChangeColors method later).

Since we want to use the same script both when closing and opening the door (notice we could write two different scripts for simpler logic but harder management of files), when entering a state, we need to check in which state we're going.

Pretty simple, the code is self explanatory, we're using the data from the AnimatorStateInfo to retrieve the data we need :

Now, let's see what's going on in the ChangeColors method.

Contrary to a classic monobehaviour, we can't define serialised field on a SMB, so if we need

to access stuff on our game object we need a simple trick. The callback from the SMB are sending back our animator component, so we have an easy reference to the game object the animator is onto. We can use that game object reference to access just any script we need, on our game object.

Here we use that to retrieve mesh renderers and skinned mesh renderers, that we put into lists on the AirlockOpener script.

Once we have them, we can do whatever we want with them, here we just modify some material colors and we modify some blend shape.