Serious Sam's Bogus Detour - User contributions [en]

Main Page

2017-08-21T14:35:49Z

Scratch:

__NOTOC__
<div style="text-align: center;">
[[File:Logo.png|link=]]
</div>

{{Box|Welcome!|
Welcome to the Serious Sam's Bogus Detour wiki. We are currently actively working on adding articles and information, and you're free to help out!
}}

{|width="100%"
| width="50%" valign="top" |
{{Box|Getting started|
Guides on getting started with Serious Sam's Bogus Detour modding.
* [[Using the editor]]
** [[:Category:Editor layer|Editor Layers]]
** [[Editor Shortcuts]]
* [[Creating a scenario]]
** [[Creating a Campaign level]]
** [[Creating a Survival level]]
** [[Creating a Versus level]]
* [[Sharing your scenario]]
* [[Adding custom sounds and music]]
* [[Scripting]]
** [[Creating a GameMode]]
** [[Creating a WorldScript]]
** [[Creating a Behavior]]
** [[Creating an interface]]
** [[Network code]]
** [[Rewriting Classes]]
}}
| width="50%" valign="top" |
{{Box|About|2=
* [http://store.steampowered.com/app/272620/Serious_Sams_Bogus_Detour/ Serious Sam's Bogus Detour on Steam]
* [https://www.gog.com/game/serious_sams_bogus_detour Serious Sam's Bogus Detour on GOG.com]
* [http://steamcommunity.com/games/272620/announcements/ Announcements and update news]
* [http://steamcommunity.com/app/272620/workshop/ Steam Workshop]
* [http://steamcommunity.com/workshop/discussions/18446744073709551615/?appid=272620 Steam Workshop discussions]
}}
{{Box|Scripting references|
* [http://ssbd.a000ff.com/docs/engine/ Engine API documentation]
* [http://ssbd.a000ff.com/docs/engine/ Script API documentation]
}}
{{Box|References|
* [[Extracting game files]]
* [[:Category:WorldScripts|WorldScripts]]
* [[:Category:File type|File types]]
* [[Console]]
* [[Resources]]
}}
|}

User:Hipshot

2017-08-21T14:22:25Z

Scratch:

This article describes the most basic parts of the editor, from first setup to launching a smaller test level ingame.

=Preparation=
Before you start using the editor, you need to setup a working directory for your level, campaign, or mod. You will also need an <code>[[info.xml]]</code> file.

Navigate to your SSBD directory, then go into the folder <code>scenarios</code>. Inside here, create a new folder called <code>mycampaign</code> or whatever you feel like calling it. Inside <code>mycampaign</code> create yet another folder called <code>levels</code>.

Now you need to set up an <code>[[info.xml]]</code> file. This file contains important information about the scenario. Open your favorite text editor (like Notepad), and paste the following text inside:

<pre class="prettyprint">
<info>
<name>My cool campaign</name>
<tag>This is the best campaign</tag>
<description>The end is near, or perhaps not! In any case, this is a really fun level!</description>

<players min="1" max="4" />

<start>
<level name="The Pride of Memphis" lvl="levels/level1.lvl" />
</start>
</info>
</pre>

Save the file inside of the <code>mycampaign</code> folder as <code>info.xml</code>. (Make sure it's .xml, and not .txt!)

==Starting the editor==
The editor can be found inside the SSBD install directory, called <code>EDITOR.exe</code>, or as a launch option in Steam when you click the ''Play'' button.

==Workspace==
The editor workspace consists of several parts: ''History'', ''Layers'', ''Properties'', ''Toolbar'', ''Menus'', and the ''Status Bar'', the picture below outlines these parts.

[[File:Editor_guide_launch.png|thumb|left|175px|Workspace]]

# '''Menu:''' In the menus you can find most basic functions, like testing the level from the editor and showing and changing the grid.
# '''Tool Bar:''' Quick shortcuts to functions like turn on the grid and simulate physics (it's recommended to turn simulate physics off).
# '''History:''' Saves your current work progrss so you can undo in steps, sometimes this function undoes twice, so be careful, it's better to not use it at all.
# '''Layers:''' Where you choose your work layer. If you have ''Global Selection'' on, you can work in multiple layers at the same time.
# '''Properties:''' Used to change properties of a selected unit or script, like what unit to spawn with a [[SpawnUnit WorldScript]].
# '''Status Bar:''' Shows the number of units selected, zoom grade, on what co-ordinates the mouse cursor is at, and the current level testing options.

==Game mode==
[[File:Basics_gamemode.png|thumb|100px|GameMode settings]]
Before you start constructing a level, you need to decide what game mode it should have. You should always do this, since it contains important settings and information about the level.

For this tutorial, we will choose '''Campaign''' under the tab '''GameMode''' in the '''Layers''' panel. The only thing we will change here is the '''MapName''' and the '''CreatorName'''.

=Constructing=
Now we will start and produce a small playable level. We will place some tilesets, and then move on to building parts and finally some basic scripts to end and start the gameplay with.

==Environment and tilesets==
[[File:Editor basics tiles.png|thumb|100px|Painting a tileset]]
The absolute first thing you want to do is set a default environmental light of the level, so you can actually see what you are doing (else everything will be black).

Switch to the '''Lighting''' tab and look down a bit until you see '''Env:''', open that list and look close to the bottom, find the environment called '''egypt_outside.env'''.

Now enter the '''Tilemap''' tab and scroll down the list until you find a tileset called <code>egypt_tile_inside_16.tileset</code>. Start painting these ''(Add: Left Mouse Button. Remove: Right Mouse Button)'' tiles until you have a good and sturdy ground. There are a few settings in the '''Properties''' panel that you can change, like increase or decrease the size of the paintbrush, this can also be done with the shortcut '''CTRL+MWHEEL'''.

==Walls==
[[File:Editor basics walls1.png|thumb|100px|Almost a room]]
[[File:Editor basics walls2.png|thumb|100px|Two rooms!]]
Before you start placing walls make sure you set the '''grid''' to '''16''' (either from the menu or by pressing '''"5"''' on the numpad), standard walls are 16 units thick and this will make sure they always follow that grid.

Now, open the '''Doodads tab''' and in the '''search field,''' type '''egypt_fancy.''' This will list all units associated with this theme. We are going to use a few different building blocks here, the following is a list of the units we will be using right now:

* <code>fancy_h.unit</code>
* <code>fancy_v.unit</code>
* <code>fancy_crn_ne.unit</code>
* <code>fancy_crn_nw.unit</code>
* <code>fancy_crn_se.unit</code>
* <code>fancy_crn_sw.unit</code>

Start by selecting <code>fancy_h.unit</code> and place it down using the '''right mouse button'''. Place a couple of these to form a long wall. Then move on to the other units and shape a room with a gap, just like the image to the right.

When that is done, continue and expand the level so you get two rooms and place a door in between them. Also, trim the tileset so it won't show outside the walls. Now, let's add some decoration and lamps!

==Artpass and lighting==
The blue area around the walls are called the void, this is outside the level. You can walk there, but enemies and other things might start to act strange and it doesn't look too good either. Think of this as an area you should never see.

The two basic ways to handle this is either to paint over tilesets there, like grass or something else, or as you can see when you play [[e1m1|the first level]] of the game you notice that there's roofing on top of the walls making it feel like you are actually inside a temple, which also covers the void. This is the method we will be using here. To achieve this, search the '''Doodads''' tab for '''color''' and you will find units called '''color_egypt_fancy_*.unit''', where '''*''' are different sizes. Pick the one called '''_512.unit''' and place them around, so they cover all the void around the walls.

When that's done, let's place some decorative props around the two rooms, this is a list of units that I will be placing around (they are all found inside the Doodads tab):

* <code>lamp_torch</code>
* <code>china_*</code> (different vases and things)
* <code>fancy_deco_pillar</code>
* <code>fancy_deco_pillar_blank</code>
* <code>fancy_deco_pillar_large</code>

Creating an interface

2017-07-31T10:34:26Z

Scratch:

Interfaces is what makes the HUD, Netricsa, etc. This means an interface can either be shown passively (without user input) or actively (with user input).

== The gui file ==

Let's start by creating a gui file. Let's call it <code>hello.gui</code> and we'll put it inside of our scenario in a <code>gui</code> folder. We will discuss its contents later.

<pre class="prettyprint">
<gui>
<doc>
<group>
<text anchor="0.5 0.5" font="gui/fonts/font_agency16.fnt" text="Hello, world!" />
</group>
</doc>
</gui>
</pre>

== Drawing our interface ==

To draw our interface, we need to add it to a place that draws stuff. A prime example of this is the <code>RenderWidgets</code> function of a gamemode. But first, we need to instantiate a [[Widget Hoster]] which will do most of the hard work of interfaces for us. Here's how we would load the <code>hello.gui</code> file inside of a gamemode:

<pre class="prettyprint">
IWidgetHoster@ m_interface;

BasicVersus(Scene@ scene)
{
super(scene);

// Create a widget hoster
@m_interface = IWidgetHoster();

// Load hello.gui into it
m_interface.LoadWidget(m_guiBuilder, "gui/hello.gui");
}
</pre>

In our gamemode constructor, we instantiate a basic <code>IWidgetHoster</code>, put it in <code>m_interface</code> and tell it to load our gui file.

Now, to actually draw our interface to the screen, we override the <code>RenderWidgets</code> function:

<pre class="prettyprint">
void RenderWidgets(PlayerRecord@ player, int idt, SpriteBatch& sb) override
{
// Draw our interface
m_interface.Draw(sb, idt);

// Remember to call the base function from the inherited gamemode!
VersusGameMode::RenderWidgets(player, idt, sb);
}
</pre>

And, additionally, to make any sprite animations work, we also update the widget hoster inside of <code>UpdateWidgets</code>:

<pre class="prettyprint">
void UpdateWidgets(int ms, GameInput& gameInput, MenuInput& menuInput) override
{
// Update our interface
m_interface.Update(ms);

// Remember to call the base function from the inherited gamemode!
VersusGameMode::UpdateWidgets(ms, gameInput, menuInput);
}
</pre>

The result should look like this:

[[File:GuiExample1.png]]

== More about the gui file ==

Gui files are formatted as basic XML. Here, the <code>gui</code> tag is our root element, and is required for all interfaces. Inside of this, we have the <code>doc</code> tag, which is also required. Inside of that, we have our first widget, which will be the root widget. In this case, we use the <code>[[GroupWidget]]</code> by using the <code>group</code> tag. A group widget does not draw anything to the screen. Instead, it is simply a container. It has the special property that it will automatically take the width and height of its parent widget, or if there is no parent widget, the entire screen. This makes it perfect as a container for all other widgets.

Inside of that, we have our first real widget, a <code>[[TextWidget]]</code>, which we indicate by using the <code>text</code> tag. This widget is inside of the <code>group</code> tag, which means that this text widget is a child of the group widget, and the group widget is its parent. Also note that we close the <code>text</code> tag immediately instead of opening it, since we don't need to have any child widgets inside of it.

The <code>font</code> and <code>text</code> attributes speak for themselves, however the <code>anchor</code> attribute in the above example is more interesting. This is a vector attribute, meaning it accepts 2 floating point numbers. The first is X, the second is Y. These values defines the scalar position of the widget within its parent's size (based on its own size). For example, if you set the anchor X to 0, the widget will be left-aligned. (0 is the default for both X and Y if you don't define the anchor.) If you se this value to 0.5, it will be aligned in the center of its parent. And if you set it to 1, it will be aligned on the right side. The same counts for Y, but then for the Y axis, where 0 would be the top and 1 would be the bottom. Thus, in our example above, <code>0.5 0.5</code> means to put the widget exactly in the center.

== Sprites ==

Any sprites you want to display in your interface need to go into a <code>sprites</code> tag. You can then display them with the <code>sprite</code> widget. Sprites are defined globally in your .gui file, outside of the <code>doc</code> tag, like this:

<pre class="prettyprint">
<gui>
<sprites>
<sprite name="globe" texture="gui/icons.png">
<frame>26 44 13 13</frame>
</sprite>
</sprites>

<doc>
<group>
<sprite src="globe" anchor="0.5 0.5" offset="0 -16" />
<text anchor="0.5 0.5" font="gui/fonts/font_agency16.fnt" text="Hello, world!" />
</group>
</doc>
</gui>
</pre>

Here, we take the "globe" sprite and put it in a sprite widget just above the text we created in the previous section. The globe sprite's frame is inside of the <code>gui/icons.png</code> texture, where it is located at X 26 and Y 44. It also has a width and height of 13. This example looks like this:

[[File:GuiExample2.png]]

We can also define animating sprites, by adding more frames and an additional time:

<pre class="prettyprint">
<sprite name="block" texture="gui/icons.png">
<frame time="250">0 57 10 10</frame>
<frame time="250">10 57 10 10</frame>
<frame time="250">20 57 10 10</frame>
<frame time="250">30 57 10 10</frame>
<frame time="250">40 57 10 10</frame>
<frame time="250">30 57 10 10</frame>
</sprite>
</pre>

== Adding interaction ==

By default, interface interaction is disabled. You have to do the following to be able to interact with an interface:

1. Place an interactable widget, such as a button.
2. Make sure you are calling <code>Update</code> on the widget hoster and that you have added it to the list of widget roots.
3. Additionally, inherit from <code>IWidgetHoster</code> so you can catch events in <code>OnFunc</code>.

Let's go through this step by step.

=== Placing a button ===

To place a button, the most convenient way is using the <code>scalebutton</code> widget. An example would be this:

<pre class="prettyprint">
<scalebutton spriteset="scalebutton" anchor="0.5 0.5" offset="0 30" width="90" font="gui/fonts/font_msref10_bold.fnt" text="Click me!" />
</pre>

Note the <code>spriteset</code> here is set to <code>scalebutton</code>. This means it will load several sprites prefixed by the string <code>scalebutton</code>. A full list of this is:

* <code>scalebutton-left</code>
* <code>scalebutton-mid</code>
* <code>scalebutton-right</code>
* <code>scalebutton-hover-left</code>
* <code>scalebutton-hover-mid</code>
* <code>scalebutton-hover-right</code>
* <code>scalebutton-down-left</code>
* <code>scalebutton-down-mid</code>
* <code>scalebutton-down-right</code>

Fortunately, you don't have to define these sprites yourself by hand. You can use the default <code>%include</code> to automatically add all of these (including a disabled variation) to your .gui file. To use this, add the following line inside of your <code>sprites</code> tag:

<pre>
%include "gui/main_menu/scalablebutton_sprites.inc"
</pre>

If you save this and start the game now, you should see a nice blue button like this:

[[File:GuiExample3.png]]

=== Widget roots ===

You'll notice that the button can't actually be clicked or hovered over. That's because the widget hoster is not configured to receive any user input, it's only being drawn to the screen. We can solve this by calling the gamemode's <code>AddWidgetRoot</code> function somewhere. For example, directly in our <code>Start</code> function:

<pre class="prettyprint">
void Start(uint8 peer, SValue@ save, StartMode sMode) override
{
// Handle all the main starting logic here
VersusGameMode::Start(peer, save, sMode);

// Add our interface as a widget root
AddWidgetRoot(m_interface);
}
</pre>

If you start your level now, you will be able to hover and click the button, but you will also be shooting your weapon and you can still walk around. To work around this, you can override <code>ShouldFreezeControls</code> and return true when your interface has input focus. You'll have to work with some boolean, and do something like:

<pre class="prettyprint">
bool m_isInterfaceVisible;

bool ShouldFreezeControls() override
{
return m_isInterfaceVisible
|| VersusGameMode::ShouldFreezeControls();
}
</pre>

In the next step we will put this boolean inside of its own class to clean up a bit.

=== Inheriting from IWidgetHoster ===

For the sake of simplicity, this guide started by having you instantiate a <code>IWidgetHoster</code> directly. This is however not best practice in most cases, plus doing that won't let you catch events from user interaction on the interface. It also doesn't encapsulate everything very well, see for example that ugly loose <code>m_isInterfaceVisible</code> boolean inside of our gamemode, which is less than ideal.

The way interfaces are generally built in scripts, is by inheriting <code>IWidgetHoster</code> and putting all interface logic inside of your class. The following example encapsulates our <code>gui/hello.gui</code> logic inside of a new <code>HelloGui</code> class that is in itself a widget hoster. For this example I've also added a few helpful things to this compared to the basic example above:

* Loading the .gui (with filename) directly in the constructor of our class.
* Convenient <code>Show</code> and <code>Hide</code> functions which will help us to easily toggle the visibility and interactability of the interface.
* A visibility boolean that we use to stop rendering and updating of the interface when hidden.

<pre class="prettyprint">
class HelloGui : IWidgetHoster
{
// If visible this is true, otherwise false
bool m_visible;

HelloGui(GUIBuilder@ b)
{
// Load the widget directly from hello.gui
LoadWidget(b, "gui/hello.gui");
}

void Show()
{
// Make visible, and add to widget roots
m_visible = true;
g_gameMode.AddWidgetRoot(this);
}

void Hide()
{
// Make invisible, and remove from widget roots
m_visible = false;
g_gameMode.RemoveWidgetRoot(this);
}

void Update(int dt) override
{
// If not visible, don't bother updating
if (!m_visible)
return;
IWidgetHoster::Update(dt);
}

void Draw(SpriteBatch& sb, int idt) override
{
// If not visible, don't bother drawing
if (!m_visible)
return;
IWidgetHoster::Draw(sb, idt);
}
}
</pre>

=== Catching events ===

Events in interfaces are simple strings sent to the <code>OnFunc</code> function of a widget hoster. To get an event when the user clicks the "Click me" button we made in the example above, we will need to add the <code>func</code> attribute to the widget, like: <code>func="click_me_was_clicked"</code>

<pre class="prettyprint">
<scalebutton spriteset="scalebutton" anchor="0.5 0.5" offset="0 30" width="90" font="gui/fonts/font_msref10_bold.fnt" text="Click me!" func="click_me_was_clicked" />
</pre>

Then, in your class, override <code>OnFunc</code> and look for the event string:

<pre class="prettyprint">
void OnFunc(Widget@ sender, string name) override
{
// If the button was clicked, "close" the interface
if (name == "click_me_was_clicked")
Hide();
}
</pre>

[[Category:Tutorials]]

Creating a Behavior

2017-07-31T10:34:11Z

Scratch:

Behaviors are classes that control a [[Unit]]. For example, health items have the Pickup behavior. This pickup behavior responds to the <code>Collide</code> function, so that it can perform an [[Effect]] when a [[Player]] touches the item.

__TOC__

==Minimal behavior==

The most basic behavior is one that does nothing and simply stores the [[UnitPtr]]:

<pre class="prettyprint">
class MyBehavior
{
UnitPtr m_unit;

MyBehavior(UnitPtr unit, SValue& params)
{
m_unit = unit;
}
}
</pre>

==Parameters==

You can define parameters in your [[Unit file]], and then fetch them in your Behavior script. Take for example the following integer in the Behavior XML:

<pre class="prettyprint">
<behavior class="MyBehavior">
<int name="move-time">1000</int>
</behavior>
</pre>

Then, to get the value of <code>move-time</code> in your script, you can do the following:

<pre class="prettyprint">
int m_moveTime;

MyBehavior(UnitPtr unit, SValue& params)
{
m_unit = unit;
m_moveTime = GetParamInt(unit, params, "move-time");
}
</pre>

To make the value optional instead of required, add the 4th optional argument <code>false</code>, followed by an optional default value. For example, if you would like <code>move-time</code> in the above example to be optional and default to 1000, you would do this:

<pre class="prettyprint">
m_moveTime = GetParamInt(unit, params, "move-time", false, 1000);
</pre>

==Functions==
Further, you can implement any function you'd like from the below list in your class, and they will be called as events.

<pre>
void Update(int dt)
void QueuedPathfind(array<vec2>@ path)
void QueuedFetchActors(array<UnitPtr>@ actors)
void Collide(UnitPtr unit, vec2 pos, vec2 normal)
void Collide(UnitPtr unit, vec2 pos, vec2 normal, Fixture@ fxSelf, Fixture@ fxOther)
void EndCollision(UnitPtr unit)
void EndCollision(UnitPtr unit, Fixture@ fxSelf, Fixture@ fxOther)
void Destroyed()
vec4 GetOverlayColor()
SValue@ Save()
void Load(SValue@ save)
void PostLoad(SValue@ save)
</pre>

[[Category:Tutorials]]

Creating a WorldScript

2017-07-31T10:34:02Z

Scratch:

WorldScripts are units you can place inside of a level that perform some logic. Creating your own world scripts is useful for executing certain scripts in a level.

== The setup ==
This is what the ScriptLink (a default script) looks like:

<pre class="prettyprint">
namespace WorldScript
{
[WorldScript color="176 196 222" icon="system/icons.png;416;128;32;32"]
class ScriptLink
{
SValue@ ServerExecute()
{
return null;
}
}
}
</pre>

This script essentially means: when triggered, do nothing. This is useful for the reason that this script will trigger other scripts that are targeted by this one, without performing any action. In other words, it links scripts together, hence its name.

We store the class in a "WorldScript" namespace, as to not clutter the global namespace too much and to avoid name ambiguities. The name of the class will be the name of the script, as it will be shown in the editor and in the editor view. Use of capital letters is encouraged since in compact script mode, the editor will display the abbreviations of script names instead of their icon. For example, "ScriptLink" will show as "SL".

To indicate that the class is indeed a world script, we add the <code>[WorldScript ...]</code> header, along with a color and an icon. This way the editor will be able to find and display the script. The color is a simple format of <code>r g b</code>, so in the ScriptLink example above, this would be: <span style="width: 1em; height: 1em; background: rgb(176, 196, 222); padding: 2px; border: 1px solid #999;">176 196 222</span>

== Order of execution ==
Script execution can only be initiated by the server. This means that <code>ServerExecute</code> will be called first on the server, and after that <code>ClientExecute</code> is called on the clients.

If the <code>ServerExecute</code> method is not defined, the script can not be triggered, and you also will not be able to target it in the editor.

== Network synchronization ==
The return value of <code>ServerExecute</code> can be passed down to <code>ClientExecute</code>, if necessary. You can build an <code>SValue</code> using <code>[[SValueBuilder]]</code>.

== Functions ==
void Initialize()
void Update(int dt)
SValue@ ServerExecute()
void ClientExecute(SValue@)
void OnEnabledChanged(bool enabled)
void DebugDraw(vec2, SpriteBatch&)
SValue@ Save()
void Load(SValue@ save)

[[Category:Tutorials]]

Creating a GameMode

2017-07-31T10:33:49Z

Scratch:

Gamemodes define rules about what should happen on a level. They are set in a level file. Typically when making a gamemode, you'll want to inherit the class from either <code>BaseGameMode</code>, <code>VersusGameMode</code>, or <code>TeamVersusGameMode</code>. Or, if you're just adding something very simple to an existing gamemode, you can also inherit from <code>Campaign</code>, <code>Survival</code>, <code>Deathmatch</code>, etc.

These scripts are typically saved in your scenario in a <code>scripts/gamemodes</code> folder.

= Base =
There are several ways you can set up the base of a gamemode.

== Minimal gamemode ==
The most minimal gamemode you can make is this:

<pre class="prettyprint">
[GameMode]
class BasicGamemode : BaseGameMode
{
BasicGamemode(Scene@ scene)
{
super(scene);
}
}
</pre>

Note the <code>[GameMode]</code> preprocessor that describes our <code>BasicGamemode</code> class. This tells the engine that this class is a gamemode that should show up in the editor and be a playable gamemode.

If we save this as <code>scripts/gamemodes/BasicGamemode.as</code> in our scenario, we will be able to select it in the editor if we have the currently opened .lvl file saved inside of the scenario folder as well.

The above will simply spawn the player in the map without any weapons or HUD. If we wanted to give the player a few weapons for example, we'd add an override for <code>SpawnPlayer</code> provided by <code>BaseGameMode</code>:

<pre class="prettyprint">
void SpawnPlayer(int i, vec2 pos = vec2(), int unitId = 0, uint team = 0) override
{
BaseGameMode::SpawnPlayer(i, pos, unitId, team);

// Give weapons
g_players[i].AddWeapon("weapons/smg.sval");
g_players[i].AddWeapon("weapons/railgun.sval");

// Give ammo
g_players[i].GiveAmmo("weapons/ammo/bolts.sval", 30);
g_players[i].GiveAmmo("weapons/ammo/bullets.sval", 500);
}
</pre>

== Custom campaign ==
If you want to base your gamemode on the default <code>Campaign</code> gamemode, setting it up is as smple as inheriting from <code>Campaign</code>:

<pre class="prettyprint">
[GameMode]
class MyOwnCampaign : Campaign
{
MyOwnCampaign(Scene@ scene)
{
super(scene);
}
}
</pre>

Your gamemode will then work exactly like the official Campaign gamemode. You can then override methods to modify any of the gamemode behavior.

== Versus ==
We provide a few base gamemodes for versus, in particular <code>VersusGameMode</code> and <code>TeamVersusGameMode</code>. The former is for free-for-all based versus modes (like Deathmatch), and the latter is for team based versus modes (like Team Deathmatch).

A very simple empty versus gamemode kind of resembling Deathmatch would be:

<pre class="prettyprint">
[GameMode]
class BasicVersus : VersusGameMode
{
BasicVersus(Scene@ scene)
{
super(scene);
}
}
</pre>

= Additions =

== Default HUD ==
If you are using BaseGameMode, you probably also want to add a default HUD so you know what's happening. To do this, we have to do a few things:

* Instantiate a <code>HUD</code> object using the GUI builder
* Return the object in the gamemode's <code>GetHUD()</code> method
* Update the HUD in the <code>UpdateWidgets(...)</code> method
* Render the HUD in the <code>RenderWidgets(...)</code> method

This looks roughly like this:

<pre class="prettyprint">
HUD@ m_hud;

BasicGamemode(Scene@ scene)
{
super(scene);
@m_hud = HUD(m_guiBuilder, null);
}

HUD@ GetHUD() override { return m_hud; }

void UpdateWidgets(int ms, GameInput& gameInput, MenuInput& menuInput) override
{
m_hud.Update(ms);
BaseGameMode::UpdateWidgets(ms, gameInput, menuInput);
}

void RenderWidgets(PlayerRecord@ player, int idt, SpriteBatch& sb) override
{
m_hud.Draw(sb, idt);
BaseGameMode::RenderWidgets(player, idt, sb);
}
</pre>

Additionally, you can create a class that inherits from <code>HUD</code> and use that instead, if you want to modify any behavior inside of the default HUD. '''Note''': This is not how you add new HUD elements. If you want to add new HUD elements, see [[Creating an interface]].

== Properties ==
Just like with worldscripts, you can have properties in your gamemode that you can modify per level. These are basically variables in your gamemode class with an <code>Editable</code> attribute. Some examples include:

<pre class="prettyprint">
[Editable]
int TimeLimit;

[Editable]
string AuthorName;

[Editable default=10]
int SomeNumber;
</pre>

[[File:GamemodeProperties.png]]

== Functions ==
Further, you can implement any function you'd like from the below list in your class, and they will be called as events.

<pre>
void Start(uint8, SValue@, StartMode)
SValue@ Save()

void AddPlayer(uint8)
void RemovePlayer(uint8, bool)

void UpdateFrame(int, GameInput&, MenuInput&)
void UpdatePausedFrame(int, GameInput&, MenuInput&)
void PreRenderFrame(int)
void RenderFrame(int, SpriteBatch&)

void ResizeWindow(int, int, float)
void Paused(bool)

vec2 GetCameraPos(int)
vec4 GetVignette(int)

// Advanced methods
void LobbyCreated(bool loadingSave)
void LobbyInviteAccepted()
void LobbyEntered()

void LobbyDataUpdate()
void LobbyMemberDataUpdate(uint8)
void LobbyList(array<uint64>@)

void SetMenuState(MenuState)
bool MenuBack()
void ShowMessage(MenuMessage)

void OnBindingInput(ControllerType, int)
void ChatMessage(uint8, string)
</pre>

[[Category:Tutorials]]

Extracting game files

2017-07-31T10:25:21Z

Scratch:

The packager tool allows you to [[Sharing your scenario|package a scenario]], but it also allows you to unpack or extract scenarios, as well as base the content from the <code>res/assets.bin</code> file. This is useful if you want to use any of our base resources such as units and scripts, in your mod, or use them as reference material.

== On Windows ==
First, navigate to your Bogus Detour installation folder. In this folder, hold down Shift and F10 at the same time to open the advanced shortcut menu. From here, select "Open command prompt here." (On Windows 10 this is Powershell.) You should now see the Windows command prompt in front of you, in the current folder. Then, run the following command, which will extract all files from <code>res/assets.bin</code> into the <code>assets</code> folder.

<pre>
PACKAGER.exe --unpack=res/assets.bin --destination=assets
</pre>

On Powershell, you need to call it like this:

<pre>
.\PACKAGER.exe --unpack=res/assets.bin --destination=assets
</pre>

[[File:Extracted.png]]

== Scenarios ==
The same process works for scenarios, except you pass the .bds file to the /u parameter. For example:

<pre>
PACKAGER.exe --unpack=scenarios/payload.bds --destination=scenarios/payload
</pre>

{{NewBuild|The --sval option currently does not exist, and info.xml is currently not extracted from scenarios.}}

Depending on when the scenario was packaged, you will not get an <code>info.xml</code> file. This is the case for scenarios packaged at or before build 181.

In such cases where you don't have the <code>info.xml</code> file but you do need to know its contents, you can get a read-only approximation of this file by passing <code>--sval</code> while unpacking. This will write a serialized <code>info.sval</code> file into the destination folder. This file is not very useful if you intend to take it and modify it, as it's only an approximation.

Resources

2017-07-31T08:40:55Z

Scratch:

This article is an attempt at listing useful resources that the community has created that can be useful.

== Scenarios ==

* [https://github.com/codecat/ssbd-payload Source code] for the [http://steamcommunity.com/sharedfiles/filedetails/?id=800695063 Payload] multiplayer scenario.
* [https://github.com/codecat/ssbd-prophunt Source code] for an unfinished Prophunt scenario.

== Resource packs ==

* [https://drive.google.com/file/d/0B90aki4w25SCRHZrN0hJekNIdzg Source code] for [http://steamcommunity.com/sharedfiles/filedetails/?id=923700789 Ammo Crate Resource Pack].

== Tools ==

* [https://github.com/Crackshell/NBogus NBogus], a C# library for generating levels.
* [https://github.com/Crackshell/hw2a000ff hw2a000ff], for converting Hammerwatch campaigns to Bogus Detour scenarios.
* [http://ssbd.a000ff.com/files/fmod_framework.zip Fmod Studio skeleton project], a skeleton project for making Fmod Studio soundbanks for scenarios.

Adding custom sounds and music

2017-07-31T08:39:41Z

Scratch:

Adding in custom sounds and music to your scenarios requires the usage of '''.sbnk''' files. While your computer likely doesn't recognize this file type, it is really a glorified text file and can be opened with any simple text editor, such as [https://notepad-plus-plus.org/ Notepad++].

The sound files themselves must be presented in any of the following formats: '''.wav, .ogg, .mp3, .mod, .it, .s3d, .xm'''. Each file format has its own benefits: .ogg files are relatively small, at the cost of some audio quality, while .wav files will take up more space but with good amount of quality. In the end, it is recommended to use .ogg for music, and .wav for sounds. An audio editing program such as [http://www.audacityteam.org/ Audacity] can convert most common audio filetypes into most of these formats.

You can also use Fmod Studio to build your soundbank, that way you're not limited to the features of text-file sbnk files. This also allows you to add dynamic music, and add other kinds of effects to your sounds. See further in this article for more information.

== Exporting sound files to .ogg ==
If your sound file is not already in any of the supported file formats, follow these steps to do so. Using ''Audacity'', drag the sound file of your choice into the gray area. If successful, you will see the audio channel appear. You may now edit the sound file if you wish, otherwise, click the "File" tab and then the "Export" button. Select the file type you wish to use and export it to anywhere in your scenario folder, preferablly a dedicated folder called "sound". Continue to do this for all the sound files you need.

== Creating the .sbnk file ==
With your sound files ready, you must now create an .sbnk file at which you can configure some parameters. Simply open a text editor like Notepad++, then copy the [[SoundBank file|example code on this page]]. You can edit the following parameters:
*''name'': The name that the sound will appear in while using the editor.
*''volume'': The volume of the sound file. 1 is the standard volume, but you can only make it quieter.
*''is3d'': boolean. If set to true, the sound will only play in an area around the PlaySound WorldScript that it is assigned to. If false, it will play across the entire level.
*''looping'': boolean. If set to true, the sound file will keep playing everytime it finishes. If false, it will only play once.
If you wish to add in more sound files, simply copy and paste the <sound> parameters and edit them accordingly. You can use as many as needed.
When done, save the file as .sbnk.

== Using the sound files in the editor ==
Open up a level, and navigate to the WorldScripts tab. Spawn in a PlaySound WorldScript. Select it, then in the "Sound" parameter, type in the name of your .sbnk file, or the name you gave the sound, and it will show up. You can do the same for the PlayMusic WorldScript.

== Alternatively - use Fmod ==
The game uses Fmod internally to do all of its sounds. These kinds of sound effects start with the <code>event:/</code> prefix instead of directly pointing to an .sbnk file. They are therefore found within a .bank file instead. It is possible to create your own Fmod Studio soundbanks for your scenarios.

Download Fmod Studio 1.09.xx from [http://www.fmod.org/download/ this page]. Then, download [http://ssbd.a000ff.com/files/fmod_framework.zip this Fmod skeleton project] to get your started. The reason this skeleton project is needed is because your settings must match ours exactly, which is what this does. Once you export your Fmod soundbank file, you will be able to play each of the sounds or music you've added in Fmod Studio, from within your scenario.

Adding custom sounds and music

2017-07-31T08:36:20Z

Scratch:

Adding in custom sounds and music to your scenarios requires the usage of '''.sbnk''' files. While your computer likely doesn't recognize this file type, it is really a glorified text file and can be opened with any simple text editor, such as [https://notepad-plus-plus.org/ Notepad++].

The sound files themselves must be presented in any of the following formats: '''.wav, .ogg, .mp3, .mod, .it, .s3d, .xm'''. Each file format has its own benefits: .ogg files are relatively small, at the cost of some audio quality, while .wav files will take up more space but with good amount of quality. In the end, it is recommended to use .ogg for music, and .wav for sounds. An audio editing program such as [http://www.audacityteam.org/ Audacity] can convert most common audio filetypes into most of these formats.

== Exporting sound files to .ogg ==
If your sound file is not already in any of the supported file formats, follow these steps to do so. Using ''Audacity'', drag the sound file of your choice into the gray area. If successful, you will see the audio channel appear. You may now edit the sound file if you wish, otherwise, click the "File" tab and then the "Export" button. Select the file type you wish to use and export it to anywhere in your scenario folder, preferablly a dedicated folder called "sound". Continue to do this for all the sound files you need.

== Creating the .sbnk file ==
With your sound files ready, you must now create an .sbnk file at which you can configure some parameters. Simply open a text editor like Notepad++, then copy the [[SoundBank file|example code on this page]]. You can edit the following parameters:
*''name'': The name that the sound will appear in while using the editor.
*''volume'': The volume of the sound file. 1 is the standard volume, but you can only make it quieter.
*''is3d'': boolean. If set to true, the sound will only play in an area around the PlaySound WorldScript that it is assigned to. If false, it will play across the entire level.
*''looping'': boolean. If set to true, the sound file will keep playing everytime it finishes. If false, it will only play once.
If you wish to add in more sound files, simply copy and paste the <sound> parameters and edit them accordingly. You can use as many as needed.
When done, save the file as .sbnk.

== Using the sound files in the editor ==
Open up a level, and navigate to the WorldScripts tab. Spawn in a PlaySound WorldScript. Select it, then in the "Sound" parameter, type in the name of your .sbnk file, or the name you gave the sound, and it will show up. You can do the same for the PlayMusic WorldScript.

== Alternatively - use Fmod ==
The game uses Fmod internally to do all of its sounds. These kinds of sound effects start with the <code>event:/</code> prefix instead of directly pointing to an .sbnk file. They are therefore found within a .bank file instead.

Download Fmod Studio 1.09.xx from [http://www.fmod.org/download/ this page]. Then, download [http://ssbd.a000ff.com/files/fmod_framework.zip this Fmod skeleton project] to get your started. The reason this skeleton project is needed is because your settings must match ours exactly, which is what this does. Once you export your Fmod soundbank file, you will be able to play each of the sounds or music you've added in Fmod Studio, from within your scenario.

Resources

2017-07-27T11:15:09Z

Scratch:

Resources

2017-07-27T11:05:06Z

Scratch:

Info.xml

2017-07-27T09:51:10Z

Scratch: /* Includes */

This XML file describes a scenario. All tags listed below must be within an <code><info></info></code> block.

== Tags ==

=== Metadata ===
* '''Required''' <code>name</code> The name of the scenario that will show up in the scenario list.
* '''Required''' <code>description</code> The full description of the scenario that will show up when selecting the scenario in the scenario list.
* <code>tag</code> A short tagline description of the scenario, which is shown above the description.

=== Options ===
* <code>multiplayer</code> Whether the scenario is multiplayer-only or not. Either <code>true</code> or <code>false</code>. (Default: <code>false</code>)
* <code>saving</code> The save mode to use. Either <code>none</code> where there are no saves at all, <code>current</code> where the current level is saved, or <code>all</code> which is like Hammerwatch, where you can go back to older levels without their progress getting reset. (Default: <code>current</code>)
* <code>players</code> <code>min="X" max="X"</code> The amount of players allowed to play in multiplayer. (Default: unlimited)

=== Modifiers ===
[[File:Modifiers.png|thumb]]

* <code>modifiers</code> A collection of switches for the scenario.
** <code>modifier</code> <code>forced="X" id="X" name="X" tooltip="X" locked-by="X" default-on="X" radio="X" multiplayer="X"</code> A modifier.
*** The <code>id</code> attribute is the modifier ID. When the switch is turned on, in content, a preprocessor define called <code>MOD_ID</code> is defined. For more information, see [[Preprocessor]].
*** The <code>name</code> attribute is the visible display name for the switch. It is displayed in the switches menu.
*** The <code>tooltip</code> attribute defines the text for an additional tooltip that should show when hovering over the switch in the switches menu. (Default: none)
*** The <code>locked-by</code> attribute defines which switches disable this one, separate by commas. (Default: none)
*** The <code>default-on</code> attribute sets this switch to be on by default. This value is either <code>true</code> or <code>false</code>. (Default: <code>false</code>)
*** The <code>radio</code> attribute sets whether this switch is part of a group. Setting this value together with multiple switches turns them into a "radiobox" instead of a checkbox, where only 1 switch of a group can be selected at a time. (Default: none)
*** The <code>forced</code> attribute defines whether this switch is always defined, and isn't listed in the switches menu. This value is either <code>true</code> or <code>false</code>. If you set this to true, the only other attribute you need to set is <code>id</code>. (Default: <code>false</code>)
*** The <code>multiplayer</code> attribute defines whether this switch is only available in multiplayer. This value is either <code>true</code> or <code>false</code>. (Default: <code>false</code>)
** <code>separator</code> <code>multiplayer="X"</code> A separator line for the switch menu. The <code>multiplayer</code> attribute is the same as for the <code>modifier</code> tag.
** <code>header</code> <code>text="X" tooltip="X" multiplayer="X"</code> A header text for the switch menu. The <code>multiplayer</code> attribute is the same as for the <code>modifier</code> tag.

=== Levels ===
* <code>start</code> A collection of levels that the player will be able to start from.
** <code>level</code> <code>name="X" lvl="X"</code> A level that the player will be able to start from. The <code>name</code> attribute is the name displayed in the list of levels, and the <code>lvl</code> attribute is the filename to the level.

=== Scripts ===
* <code>classmaps</code> A collection of script classes to rewrite to other class names. See [[Rewriting Classes]] for detailed information.
** <code>behavior</code> <code>from="X" to="X"</code> Overwrites a unit's behavior class.
** <code>script</code> <code>from="X" to="X"</code> Overwrites a class created in-script with <code>InstantiateClass()</code>.
** <code>gamemode</code> <code>from="X" to="X"</code> Overwrites a level's gamemode class.

=== Includes ===
* <code>includes</code> A collection of scenarios that this scenario includes.
** <code>include</code> <code>name="X" modifiers="X" levels="X" classmaps="X" final="X"</code> An included scenario.
*** The <code>name</code> attribute defines the name of the scenario to include. Required.
*** The <code>modifiers</code> attribute defines whether to include any modifiers from this scenario. (Default: <code>false</code>)
*** The <code>levels</code> attribute defines whether to include any start levels from this scenario. (Default: <code>false</code>)
*** The <code>classmaps</code> attribute defines whether to include any class map rewrites from this scenario. (Default: <code>false</code>)
*** The <code>final</code> attribute defines whether inclusion shouldn't go any deeper than the one you're including. This means that any included scenarios in the scenario you're including will not be included if this is true. (Default: <code>false</code>)
* <code>disable-include</code> Set this to <code>true</code> to disallow this scenario from getting included by other scenarios. (Default: <code>false</code>)

== Example ==
Below is the info.xml file for the Payload gamemode on the Workshop:

<pre>
<info>
<name>Payload</name>
<description>Bring the payload to the other side.</description>
<multiplayer>true</multiplayer>

<players min="2" max="12" />

<start>
<level name="Over the Mountain" lvl="levels/payload01.lvl" />
<level name="That belongs in a Museum" lvl="levels/payload02.lvl" />
</start>

<modifiers>
<modifier forced="true" id="VERSUS" />
<modifier forced="true" id="PICKUP_RESPAWN" />
</modifiers>
</info>
</pre>

PlatformStat WorldScript

2017-07-26T14:03:47Z