The campaign editor offers pretty exciting options for creating your own campaign, giving you a lot of options and even allowing you to add new assets, short of new terrain or character sprites. I have spent hundreds of hours using it to craft a campaign and gotten pretty comfortable using it. In this guide I will give an overview of pretty much the entire editor and run through some examples of things you can do.

If you prefer video guides, I do recommend watching the developer's official video on using the creator if you haven't already seen it, where he walks you through creating a simple campaign. This guide will overlap with some of the contents of the video.


For the sake of this guide, I assume you have never used the editor before. Having experience in computer coding and scripting or modding games will likely be useful in understanding how to use the campaign editor to the fullest, but it is not necessary.

My hope is that after going through this guide and following the demos, you will have enough understanding of the basics that you can start to figure out more advanced uses, or have enough of an understanding that you can look at existing campaigns and better understand what you are looking at. I wrote this guide with the intention that you read through each section in order, though some sections may have useful information to refer back to later. If you have poked around in the editor before though, you may be able to skip around to sections that feel most relevant to you. This guide is long, but written in a way that should hopefully be easy to follow. I advise you to pace yourself as you go through this guide, as it will probably take multiple sittings to read and absorb the information here.


Both "Dialogues" and "Scripts" are used in the campaign editor to accomplish certain behaviors. In some places in this guide, I will be referring to them interchangeably as small-s "scripts" since 1) what they accomplish is similar to scripts in other editors, and 2) there is a lot of overlap in what they do. When I do want to make a distinction, I will use the capitalized Dialogues and Scripts as appropriate.

The editor refers to cut scenes and battle maps collectively as "scenes". I will be doing the same in some places.

The Guide is a handy in-editor reference tool. Small-g "guide" will be used to refer to this steam guide. I will also be capitalizing the names of sections that are found in the Guide, such as Actions.


The editor offers some interesting options for procedurally generating a variety of things, including battle maps, units, and items. However, my experience with these is pretty limited; I have only dabbled with the battle map generation. I encourage you to play around with such options if you are interested, but I will not be discussing unit and item procedural generation.

This section includes notes on updates made to the guide over time, barring small wording changes or re-arrangements.

4/22/25 - Added brief discussion of equipment masteries to the end of the first part of the polishing a battle demo.

3/29/25 & 3/30/25 - Made a number of corrections and updates thanks to the developer's feedback: corrected "backslashes" to "forward slashes", added information on default behavior of portrait X position and the AddSpeakerPortrait Action, added information on default behavior of rosters, corrected "stat masteries" to "stat proficiencies", updated description of the "multiplayer" toggle for battles, added some clarification on Tag usage, and added a couple useful tools related to working with .xml files. Some unrelated wording was tweaked or moved around to make room for this new info.

3/28/25 - Initial release of the guide.

Starting from the beginning. When you open up the campaign editor and create a new campaign, you will have a chance to set a name and brief description for the campaign. Both of these can be changed later, don't worry!


When you click the campaign name in this menu, you will be able to edit them both.


Once you confirm, you will get a few tutorial pop-ups. If you want a reminder of what it wants you to do next, you can click on the ? button in the upper right. In this guide we will be doing a few things in a different order. However, for now I recommend following their suggestions and trying out the character creator and taking a look at the Introduction cutscene.

Before going further, I will recommend finding the folder on your computer where your campaign is contained. This will be important for some of the uses of the editor covered late in the guide. When you hover your cursor over "New Campaign", you are told where the folder will be found. Let's take a look at it.


I'll go into more detail on each of these later, but to describe what we are generally looking at: most of our folders are for containing custom assets that we can choose to add to the campaign. The files beneath them (which have Microsoft Edge icons here, they probably won't for you) are .xml files that contains information related to the campaign. Finally, at the bottom we have "Thumbnail". This is the image that players will see when they look at your campaign in the workshop or in-game browser.


Read on in the guide to learn more about the editor! Outside of this steam guide however, in most screens in the campaign editor there is a Guide button (represented by a book) in the upper right; you will be using this a lot. It's a very handy in-game reference for how to set up various effects.

Any time you want to figure out how another campaign pulled something off, I highly encourage you to open it up within the campaign editor and try to figure it out. If you feel lost when you try to do this, hopefully it will make more sense by the time you get to the end of this guide.


When you are ready for the world to see your campaign, click the wrench icon at the top of the screen. If this is the first time you have clicked the icon, it will publish the campaign. If the campaign has already been published, it will update the campaign with any changes you have made since the last time you clicked the button.

What happens if you update a campaign when a player is partway through it? In my experience, any scenes they were in the middle of will remain in their pre-update state, but will change if they restart the scene. If you are pushing an update to a campaign you have already released, do not remove or change the name of any scenes the player had access to. Doing so will give them a very bugged campaign if they attempt to load a save made during that scene. There may be console commands that can get them back to a normal place, but it's better to not have to deal with this situation in the first place.

This is mainly a guide about wrangling the technical hurdles of making a campaign, but before going into more detail I wanted to use a little space talking about my workflow as I work on my own campaign. I've seen quite a few people start working on campaigns that (as of this writing) have not been published. So I'll talk a bit about how I managed to keep working on my own campaign and make updates (albeit with some long breaks).

Good enough

The temptation to keep working on and iterating dialogue, the balancing of a battle, etc. until they are perfect is real. But worrying too much about getting things just right will bog you down and make it very difficult and time consuming to get to the finish line. I recommend working on your campaign until you feel it is decent, then hitting publish. Plus, it is easier to make things perfect when other can play and give their feedback!

Rough draft, then iterate

Related to the above, don't worry about getting every part of a battle or cutscene just right on your first pass. Jump around as inspiration strikes, use placeholders where needed.

Publish parts of the campaign, before the full campaign

This partly depends on what the full scope of your campaign is; if you are creating a short campaign that is only one or two battles and cutscenes, it may make sense to "finish" the campaign before publishing. However, if you feature creep are ambitious and want to create a longer campaign, breaking it up into parts may be the way to go. This does have some disadvantages if you are trying to make sure the early players can get the same experience the later players get, but the tradeoff is worth it in my opinion.

Just create

Sometimes I am not sure what I want to do for a cut scene or battle. When that happens, I just start working until a clearer idea begins to form. Sometimes starting to write a dialogue between a couple characters helps me flesh out each character and what they would want and what they would choose to say in the scene. Sometimes toying with terrain and elevation leads me to figure out a fun concept for a battle.

Deadlines

Giving yourself deadlines to hit can be helpful to keep you moving forward. Even if you don't quite hit it, it can help motivate you to make a lot of progress.

I won't be talking about creating characters until later since I think the basics of the creator are fairly straightforward; many fields are optional or you can enter in randomized info if you want.

Instead, let's talk about cut scenes. When you created your campaign, you automatically have one cut scene named "Introduction". As of writing, it was allegedly made possible only recently to have a campaign without this cut scene. I say allegedly but I admit I am not sure how to make the change.

I haven't looked into the consequences of this, so I will be assuming here that you keep this cut scene.

As you can see here, I have already made a few characters. Amir Ottersquish and Jordana Mindbucket will be used in the cutscene demo in the next section. If you want to follow along with the demo you can create two Unique characters with those same names, or create two other characters and substitute in their names where appropriate; their class/species/gender/appearance won't really matter, though I will recommend not making these characters golems for reasons I will mention later.


When a player chooses to start playing your campaign, they will automatically be loaded into the Introduction cutscene. Try looking at the Introduction cutscene now if you haven't already. Here you will see some tutorial and placeholder information that you might want to use for a campaign. If we were publishing this campaign, I would update the Introduction cutscene with whatever scripts are needed at the beginning of the campaign as well as any information or choices I wanted the player to see right away. Instead, let's leave the Introduction cutscene alone for now and create a new, totally blank cutscene. "Exit" the Introduction cutscene and click New Cut Scene. Enter whatever name you like; here I will just call it "First Cutscene".



Let's walk through what each of the buttons on the top bar are for:

New Scene - this is another way you can create a new cut scene besides the button we used on the previous menu.
Save Scene - save any changes you have made to the current cut scene. Note that there is no auto-saving of your work on a cut scene, so always remember to manually save your work! I recommend saving periodically as you work just in case.
Load Scene - load a different cut scene.
Scene Settings - this opens up a menu that lets you re-name the cut scene, choose background music for the cutscene, set what will come next in your campaign after this cut scene, toggle whether saves can be generated during this cut scene, and set Conditions for the cut scene (accessed through the blue flag icon in the bottom left).

New Frame - think of your cut scene as a fancy slide show. The player will progress through your slide show until it reaches the end, then move on to whatever scene is next. The New Frame button will add an additional slide to the presentation.
Delete Frame - deletes the current slide you are on.
Move Frame - this allows you to re-order your slides.

Narration - write some text against your background, no dialogue boxes involved.
Background - select an image to serve as the background for the current frame. There are a variety of stock backgrounds in the editor you can use, though you can also import your own (see new assets section).
Dialogue - this may be a little more confusing than you expect. This let's you select what Dialogue will automatically be loaded when the player arrives at the current frame. When you click this button, you will see a list of any Dialogues you have created for this cut scene to select. Leave it as the default [No dialogue] if you don't want a Dialogue to pop up here.

Edit Rosters - you can create up to ten rosters (0-9). These "rosters" can be used for a few different purposes, most notably setting what units are on the player's roster for deployment in battle.
Edit Shops - from here you can set up shops that the player may encounter in the cut scene. You can set the stock of the shop, set price multipliers, how many items are stocked, quality of the items stocked, etc. Shops are honestly kind of annoying to set up and I strongly recommend looking at an existing example to get a sense of how it works. Once you have it set up in this menu, you can then trigger the shop in a Dialogue.
Edit Menus - similar to Edit Shops, we set up menus the player can see in the cut scene that will later be triggered by a Dialogue.
Edit Dialogue - here we actually create Dialogues and Scripts to be used in the cut scene. Once a Dialogue is created, it can be selected from the "Dialogue" menu to determine on which frame it loads. You can zoom in and out (mouse wheel) and pan around (click on the background and drag, or use WASD) in this screen. These movements are useful when you have a lot of Dialogues and Scripts. Imagine this screen is a bulletin board where the Dialogues and Scripts are pieces of paper pinned to it.

Guide - a trusty in-game resource for understanding a variety of behaviors and variables that will be important for scripts. Refer to this a lot!
Test - allows you to start your campaign from whatever scene (either cut scene or battle) you have selected. By default, it will select your current scene as the starting point. Even if you transition through multiple scenes, you will be brought back to screen where you started the Test when you end. You can also set up test rosters and scripts to activate just for this test run.
Exit - back out of the current scene back to the main menu for your campaign.

Let's say you want to create a simple cut scene introducing your characters and the motivation for their battle. Let's start by creating an additional three New Frames to give us four. We will also select a stock background for Frame 1 (I've selected "Blacksmith"), and write a short Narration to set the scene.


Let's advance to Frame 2. Notice that the Narration disappears but the Background we selected is still here; the Background won't change in later frames unless we manually change it.

Now let's show a conversation between our characters. Go to Edit Dialogue and click New Dialogue in the upper left.


Here we have a few empty fields. For the purposes of our cut scene, we only need to fill in Conv. ID, the behind-the-scenes name we are giving to the entire conversation, and the rest can be left blank. Once created, we can start adding Branches. Branches are basically different stages of the conversation that the player will progress through.

Let's start by adding portraits for characters to our Dialogue. How can we do that? Let's open the Guide to try to figure it out.


For now I will draw your attention to two sections of the Branch's menu: Actions and Replies. Notice that both those categories are listed in the Guide. If you click on each of those categories in the Guide, you will see a brief overview of what kinds of information you will find in that section on the right. When you click on Actions, you will notice that the summary mentions "creating, removing, and moving character portraits"; that sounds like what we are looking for!

If we look back to the list of Actions on the left, we can see an Action called AddPortrait at the bottom of the first page. Clicking on it shows a summary of what the action does and parameters this Action wants. Think of parameters as options we can set to determine what our Action does. The commas you see help the game figure out where one parameter ends and the next begins.

Now that we know what Action we need to add some character portraits, let's return to the branch. Click the plus sign underneath Actions, then click the newly-created box. On the left, now enter the name of the Action we want to use: AddPortait. Notice as you type in that name some suggested Action names pop up; you can click on these to fill in the rest if desired.


Here we again get a summary of what the Action and its parameters do in case we need a reminder. Now we just need to fill in the parameters in the box in the bottom left. There are only three things we need to enter: reference name, portrait name, and facing. We can enter in anything we want for reference name; this is just a behind-the-scenes name we can use later to modify this character's portrait. The Portrait Name is just the full name of a character you have created. Here's how it may look when filled out:


How you treat optional parameters is up to you. Here, I chose to leave the default text as is. You could also choose to delete everything after "facing" (left), or delete the words and leave the commas. All of these approaches should give you the same result. I often prefer to leave the default text in case I decide later that I do want to set one of the optional parameters; the default text helps remind me which parameter is which.

Let's finish up this first branch with a little narration. Here we will put the text into italics by surrounding our text with the formatting shown in the Special Character section of the Guide. We will put this in the Text box. We can leave branch name, speaker, and the replies alone.

We only have the beginning of this conversation, but let's go ahead and see our work in action. Exit out of the Edit Dialogue area to our cut scene editor. From Frame 2, select Dialogue and select our conversation from the list. When we do so, we will automatically be shown the first branch of our Dialogue.


So far so good! Let's return to Edit Dialogue and continue work on the conversation. Let's add a branch and introduce our second character. Although we're adding a second character on a second branch, there is no reason why we could not have just added everyone immediately. Note that by default the player can simply click to advance through each branch of the dialogue in sequence; if we want to modify this we can change the Replies, but we won't get into that yet.

We'll use another AddPortrait action for our second character and start writing actual dialogue. This time we will fill in the Speaker field with the name of our second character. When we do this, not only will that character's name appear in the dialogue box when that part is spoken, but there will also be visual indicators that that is the character speaking if this were taking place on a battle map. Also the "speaking noises" you hear will be adjusted according to the gender of the supplied speaker (these noises can be manually adjusted if you want however; more on that at a later point). If you misspell the character's name in the Speaker field, the game won't know which character to reference for "speaking noises" and you will just hear silence.

Let's back out, test our cut scene, and see what our conversation looks like now. We can use the Ctrl + T keyboard shortcut when done with our test or just keep clicking until we get to the end of out cut scene:


Uh-oh, we have an issue. Although it is hard to see, Amir is still on screen, behind Jordana. The portraits remain in the conversation until they are removed or moved "off-camera", which is what we want here; the problem is Jordana covering him up.

How can we resolve this?

Going back to the AddPortrait Actions, let's look at the X and Y position parameters. These values determine where on the screen the portrait appears. For most two person conversations, it's a good idea to have one character on the left (X position: 0; this is the default) and one character on the right (X position: 20). Leaving Y position as default (0) is usually fine. Note: set facing to left and X blank and the portrait will default to X pos 20.

But wait, it would be weird for our second character to just pop in (even as a ghost). One way we can handle this is add her portrait "off-camera" and move her "on-camera". If she's moving into the shot from the right, I recommend starting her at X pos 30; if she were coming in from the left, I would choose X pos -10. So, let's change her X pos parameter, replacing all of the text for that parameter with 30. We can continue to leave the other optional parameters as they were.


Now we can use another Action to move her into the shot. If we return to the Action section of the Guide, we find an action called MovePortrait; this is exactly what we need. Let's add a second Action for our current branch and fill this box with the MovePortrait Action. For reference name, enter whatever reference name you used in your AddPortrait Action. Remember we want her to stop at the right-hand side of the scene, so X Destination 20, Y Destination 0. Speed is up to you, but as the help text says think of 100 as "average" speed. For this scene, I think Jordana is moving with some urgency, so give her 200 speed. Finally, the glide parameter; for most characters it makes sense to leave this as default (false), but since Jordana is a ghost is would make sense for her to glide.


While we're at it, let's add a touch of ambiance to the scene. Let's add one more Action to this branch. Since we're at a blacksmith, maybe we should have some banging or hammering sounds. A relevant Action here would be PlaySound, which let's us play a sound effect. When we select this action, we get a special menu that lets us see all available sound effects. Clicking the arrow next to the name of the sound lets you hear it.


StatUpChime isn't a bad fit, so let's use that. You can type in the name of the sound effect or simply click it in the sound effect menu. We will leave the pitch at default.


We now have 3 Actions in this branch. The editor supports up to 6 Actions in a single branch, though you can do more than 6 by putting some of your Actions in a Script and then using an Action within the Dialogue to run that Script. Note that the actions are executed in order, so the order of the Actions is important; for example, our MovePortrait Action would not work if it came first, since there is no portrait referenced as "ghost" before we use AddPortrait (however, it would still work if we used "smith" instead, since we added that portrait in our previous branch). We can click the blue arrows to change their order.

If we go back to test our Dialogue again, we'll now see things are working like we wanted: Jordana floats in from the right and we have a clanging sound effect play as she comes in.

Next, how about we continue the conversation while giving the player some input? Now that Jordana is in the scene, Amir should turn around to talk to her. One option would be to remove his portrait and add it again, this time facing right. The simpler option, however, is using the FlipPortrait Action. You only need the reference name for this Action and it will change the facing of the portrait. Let's add another branch with the FlipPortrait Action.

Now let's give the player a couple options for how Amir responds to Jordana. Let's add a second Reply. When we click on a Reply, we have a few fields to use. First, we're going to change the top field, where "Continue" was written for the first reply. This is the text the player will see when Replies are displayed to them. Let's write a couple responses to Jordana's news.

But what do we want to happen when the player selects these responses? We can look at the Reply section of the Guide to see our options. In this case, let's use the NamedBranch Reply: this will let us go to a specific branch depending on what response the player chooses. In the image below, the Reply type is followed by a forward slash and its parameter(s). Here, I've written one response where Amir is upset by Jordana's news ("shock") and one where he is keeping cool ("calm").


Now we need a couple new branches: one named "shock" and one named "calm", so we're finally creating branches where "branch name" is filled out.

The emotional state of Amir is pretty different between these two responses; we should change his facial expression. Luckily, we have the ChangeExpression Action. Here, we supply a reference name and the name of a specific facial expression we want our character to adopt. You will see a list of possible expressions when you select the Action, but you can also see a listing and brief description of each in the Expression section of the Guide. Shocked sounds like a good fit for the "shock" response. Blank would be a good fit for the "calm" response, but by default each portrait is added with this expression, so we don't need to change it. Note: golems don't get expressions.

As you might have noticed though, the AddPortrait Action does let you specify what expression the portrait starts with. Given the situation, maybe Jordana could have started with a more nervous expression. Indeed, let's go back to branch 1, where her potrait was added, and change her expression to Nervous.


Let's wrap up. Let's have our two responses converge into one branch to conclude the Dialogue. If you tested the Dialogue you probably noticed that selecting the "shock" response, then clicking through to the next branch brought us to the "calm" response, since that was the next branch in sequence. To avoid this, let's use a different Reply type: NewBranch.

We should have five branches in our Dialogue at this point: 0 through 4. Add a new branch (branch 5). Going back to our "shock" and "calm" branches, change the reply type to NewBranch. The parameter for both should be 5. You can leave the default "Continue." text in the top box.


There are pros and cons to different reply types. NamedBranch has the advantage of taking you to a very specific branch in the Dialogue, though sometimes it's cumbersome to name every important branch. NewBranch let's you point a reply at a branch just based on it's order number in the Dialogue, but this could get you into trouble if those numbers change. For example, perhaps later you decide to change the order of the branches (using the blue arrows in the Edit Dialogue menu) or you delete/add branches later.

If this is the end of our cut scene, we have to determine what scene we are moving our player to next and how we want to get them there. We will return to this later since there is no where to go yet, but there is one more thing we can do for now. Since this conversation is the last thing that happens before the scene changes (Frame 2), we ended up not needing Frame 3 or Frame 4 of the cut scene. Switch over to Frame 3 and Frame 4 and click Delete Frame to remove them. Be aware that you do not get a confirmation box when doing this. If you accidentally delete Frame 1 or 2, don't panic, just leave the cut scene editor without saving.

The meat of campaigns: the battle maps. While the most obvious use of battles is, well, battles for the player to overcome, they are versatile: if you have played the TTL main campaign, you will recall times when cut scenes play out on a map, or the infiltration of the bandit fortress which largely let you free roam. Battle maps are thus pretty flexible in how you want to use them, but for this guide I will primarily focus on creating an actual battle.

From the main menu for your campaign, you can create a new battle map from the New Map button. You can then specify the name of the battle (this can be changed later) and the dimensions of the map (also can be changed later). For our purposes, I will just call it "First Battle" and leave the dimensions at the default 12 x 8.



When you create a new battle, you are automatically greeted with the Map Settings screen. You can click through it and come back later. But to describe what we're looking at:

Map Name - self explanatory.
Music - set what music will play during the battle.
Victory aura - how much money does the player earn when they win the battle?
Victory morale - how much morale does the player's army gain when they win the battle?
Loss morale - how much morale does the player's army lose when they lose the battle?
Next scene - specify what scene the player goes to when they win the map (can be another battle or a cut scene)
Defeat scene - specify what scene the player goes to when they lose the map (can be another battle or a cut scene)

Saveable toggle - can the player generate saves during the battle?
Procedurally Generated toggle - determines whether the map is procedurally generated; more on this later.
Multiplayer toggle - according to the developer, this has an effect on miscellaneous things such as how the game behaves upon an army reaching its victory condition. For example, if checked, any army that wins will get a victory screen; if single player, the game shows a victory screen if the winning army is a human player and a defeat screen otherwise. In the developer's words: "It's basically a way to make the battle behave a bit more like a one-off Super Smash Bros bout rather than a proper campaign battle."

Objectives - this is where you write your description of the battle objectives that the player will see. Making the actual victory/defeat requirements the game will obey is done elsewhere.
Armies - this is the menu where we set what factions will participate in the battle, including the faction names and color among other things. Six factions max per battle.
Conditions - as the pop-up says, this is where you set a variety of rules for the battle and other settings. Check the Condition section in the Guide for a full list of what settings you can use.



Leaving the map settings screen, let's walk through what each of the buttons on the top bar are for:

New Map - this is another way you can create a new battle map besides the button we used on the main menu for your campaign.
Generate Map - configure the map for procedural generation. There are a lot of options here and I recommend experimenting with the settings if interested in using this. What is the difference between this and the "Procedurally Generated" toggle in map settings? The toggle will use the settings here to generate a new battle every time the battle is loaded. If unchecked, you can use Generate Map to procedurally generate a battle once that will then be the same every time it is loaded.
Save Map - save any changes you have made to the current battle map. Note that there is no auto-saving of your work on a battle map, so always remember to manually save your work! I recommend saving periodically as you work just in case.
Load Map - load a different battle map.
Map Settings - see above section.
Undo - undo a series of changes you have made to the map.

Paint - the main tool for changing the terrain. Clicking Paint will let you select one of the available terrain types which you can then paint over the map.
Fill - fill the entire map with one terrain type.
Eye-dropper - select the terrain type of the square you click on, then switches to paint mode with that terrain type. Honestly doesn't feel very useful, there aren't that many different terrain types to try selecting from.
Elev. + - similar to paint tool, but used to raise the elevation of the squares you paint over. Max elevation: 7.
Elev. - - similar to paint tool, but used to lower the elevation of the squares you paint over. Minimum elevation: 0.

Edit Char. - edit the properties of a character currently on the battle map.
New Char. - place a new character on the battle map. You can choose a specific unit, a procedurally generated unit, or a unit from the player's roster. You can also select what army the unit belongs to and the initial direction the unit faces. Once selected, the new character can be placed on the map similar to the paint tool.
Delete Char. - remove a character currently on the battle map.

Edit Object - edit the properties of an object currently on the battle map.
New Object - place a new object on the battle map. Once selected, the new object can be placed on the map similar to the paint tool.
Delete Object - remove an object currently on the battle map.

New Light - paint light sources onto the battle map. Clicking on a light lets you adjust its settings (if New Light is the last button you have touched).
Delete Light - deletes the light sources you click.

Alter Map Size - this gives you a few options for adjusting the height and width of the battle map: blue options add one column/row, red options remove one column/row. Note that when adding a column/row, the terrain of the column/row you click on will be duplicated and added to the right/below.
Dialogue Editor - this is where you will create the Dialogues and Scripts needed to carry out many of the behaviors you want. You can zoom in and out (mouse wheel) and pan around (click on the background and drag, or use WASD) in this screen. These movements are useful when you have a lot of Dialogues and Scripts. Imagine this screen is a bulletin board where the Dialogues and Scripts are pieces of paper pinned to it.
Guide - a trusty in-game resource for understanding a variety of behaviors and variables that will be important for scripts. Refer to this a lot!
Test - allows you to start your campaign from whatever scene (either cut scene or battle) you have selected. By default, it will select your current scene as the starting point. Even if you transition through multiple scenes, you will be brought back to screen where you started the Test when you end. You can also set up test rosters and scripts to activate just for this test run.
Exit - back out of the current scene back to the main menu for your campaign.

Let's continue the adventures of Amir and Jordana from our cutscene. We will be hand-crafting this battle, as opposed to using procedural generation. There are several things to do, but let's start with figuring out the terrain.

The default 12 x 8 dimensions of the battle map is a bit small, so let's start by expanding the dimensions. Let's use Alter Map Size to increase it to 15 x 15.


You'll notice as your cursor moves around the map that a little window in the upper left will tell you the Y, X coordinates of the square you are currently hovering over, as well as the elevation. Coordinates are used as parameters for some Actions.

Now let's Paint the map. Paint the map however you want, try different terrains and try decorating the map with some objects. For the sake of this demo, however, let's keep a couple things consistent: 1) paint a road straight down the middle, and 2) create a small hill in the upper right section of the map. The objects I used here were the basic Tree and Wildflowers.


With the terrain in an okay place, let's move on to other matters. Next, let's set up the armies that will be participating in our battle. Let's open up Map Settings, then Armies.

By default, the first army will be the player's army and be the color blue. In the pop-up turn box the player's team will be called "Army 1". The number for the army will be 0, and they are assigned the roster -1. This effectively means there is not a specific roster associated with this army. This is fine for AI armies, but we may want to assign a roster for the player. We will come back to these settings.

The second army is AI controlled. Under the color selector, you will also see "Arena". This is AI behavior that that army will follow. I recommend switching to Balanced in many situations, but you can look at the description of each option.

Let's add a third, neutral army: click one of the Add Army buttons. We will leave the AI as Arena, but let's change their color to orange.

Before leaving this screen though, we have an issue to resolve. By default, each battle is a Free For All; if we want two armies to be non-hostile to each other, we need to fill in the Allies fields. Thus, our neutral third army should be listed as an ally to the other armies and vice versa. Note that we can use Actions to change allied statuses mid-battle if desired.


Now that we have our armies set up, this would be a good point to place down our units. We will place down our AI units first. When you select New Character you will be given an option for what army the unit belongs to (Army 0, Army 1, etc.). Note that this is referring to the army number in the Armies screen we were just looking at, not the army name even though by default they are named Army 1, Army 2, etc.. Thus, assuming you did not change anything, Army 0 will be player units (Blue) and Army 1 will be our hostile AI units (Red). If you accidentally place a unit belonging to the wrong army, you can delete the unit and place a new copy down with the correct army, or you can edit the character and update its army allegiance. Actions can also change army allegiance, but that's an unnecessary amount of work here.

Here I have placed down our enemy boss, Goreslaughter the Destroyer, on top of our hill. I have placed a neutral golem along the side of the road. By the way, if you want to modify what direction the unit is facing, you have multiple options. When placing down a new copy of a character you can specify what direction they look. You can edit a character on the map and change their facing. You can even use Actions to change what direction a character is facing. The simplest option, however, is right-clicking the unit until it faces the direction you want.


For deploying our player's units, we have a couple options: we could place them directly on the map as we did with our AI units, or we could add some deployment slots to the map and let the player decide who and where to place their units.

Let's go ahead and paint a few spots for the player to place units from their roster.


Now that we have some units for each army on the map, how about we test the map and see what happens?


Oh no. As you just saw, the battle ended in defeat just a few seconds after loading in. What is happening?

In short, the game took a look at the map, saw that one army had achieved their victory conditions, and declared everyone else the loser. By default, an army wins the battle if there are no units remaining that are hostile to them. While you probably weren't able to see it, the player army had no units, while the red army has Goreslaughter the Destroyer sitting on top of the hill. Since the golem belongs to the orange army, which is not hostile to the red army, it does not interfere with their victory conditions. (Technically, I believe this would be a joint win for the red army and orange army; not that that makes any difference to us since they're both AI.)

If we want our player to deploy their units like we intend, we need to assign them to a roster, and then assign that roster to their army. Let's do the easy part first and return to the Armies screen and assign the player army Roster 0. Any number 0-9 will work, but 0 is typically used for the player's regular army.

(Note: technically you could leave the player with roster -1 here. When left as -1, the player's army will draw from the "current" roster, which by default is Roster 0. If there are situations where you want your player to use a different roster, you could specify the roster numbers in this screen. Alternatively, you can use the SwitchRoster Action to change the current roster.)

From here on out, we will be jumping around to different portions of the campaign creator as the need arises.

As I mentioned, we need to create a roster that will hold our player's units. Technically there was a way we could have done this within the battle, but we need to return to our cut scene anyway.

Within our cut scene, click the Edit Rosters button. Here you can select a numbered roster with many blank rectangles. Switch to Roster 0/9 if you aren't already there, click on a rectangle, and select our player's two characters.


Now that the roster is set, let's come back to linking our cut scene up with our battle. There are a couple ways we can do this, but when there is only one scene all players will see next, the most straight-forward option is setting it in the Scene Settings.


Now, when the player reaches the end of First Cutscene, they will automatically be loaded into First Battle. Let's make sure that happens by starting a Test from our cut scene.


Looks like a partial success. We loaded right into the battle, and the player has the two units they should have right on the battle! But why didn't we get a deployment phase? Why were the units already placed on the map when we loaded in?

Believe it or not, the deployment phase is a map Condition we need to opt into. When we do not have the deployment phase turned on, the game will choose units from the player roster on its own to fill out the "From Roster" spots. Let's quit out of this test and return to the editor for First Battle.

Now let's open up the Conditions menu from within Map Settings. It is here we can enable the deployment phase. Here, I will encourage you to try to figure out what we need to do to enable it. There are some hints on this screen. You can also back out of the Map Settings and consult the Guide, browsing the section for Condition. Once you're ready to check your answer, scroll down and reveal the spoiler text.




Answer Check!

For readability I have deleted the optional parameters. If you got it right, congratulations! If not, let's examine the answer. As was hopefully easy to pick up on, Deployment is the name of the condition we want. There are two mandatory parameters: army number, roster number. Recall that our player's army is set as army 0, and that we assigned roster number 0 to their army.

Now, let's try testing our battle and seeing our deployment phase in action:


No, I didn't trick you: we did set up the Deployment condition correctly. Even though it says Army 1 at the top, recall that that is the actual name of the player's army, even though internally they are army number 0. We will change that name later to something more interesting, but for now, I'll explain why we don't have any units to deploy.

Rosters get loaded and passed from scene to scene in ways I admit I myself do not fully understand yet. My understanding is that, when we start our testing from this battle, the game has not seen "roster 0" yet. So, when it tries to load roster 0 for deployment here, it doesn't find any units. On the other hand, if we had loaded a cut scene first where we had set up roster 0, the battle deployment would work as normal. If you try starting the test from First Cutscene, you will see that our units show up for deployment in First Battle. Since campaigns usually start at cut scenes, this is a situation players aren't likely to encounter as long as all of our rosters and Deployment conditions are set correctly, but it can be an annoyance when we drop into a battle directly to test it. To avoid this, we can set a test roster.

This time when you click Test from First Battle, look over to the Test Rosters on the left. Cycle to roster 0/9 and add our two units. Remember: this is not a replacement for normal rosters, which will be necessary for a player going through the campaign normally. This is just a way for us to set what units we want available to that roster for whatever scene we are currently testing.


Finally! We can deploy our units and the battle will start normally. If you wanted to, you could play this out as a 2v1 battle against Goreslaughter.

At this point you know enough about creating cut scenes and battles that you can put together a simple campaign. In the following sections, we'll cover a few more areas of the campaign creator we haven't already touched on, and then return to this battle for further polishing in a demo.

Briefly: I think the item editor is pretty straightforward. I recommend opening up/copying existing items. Looking at how the different options are used for base game items should give you a good understanding of how it works. If it is unclear and you want more information on something related to item creation, let me know.

Similar to creating items, I think you can learn a lot from viewing and copying existing skills, though skills are a bit more complicated than items. We will run through creating a new skill in a demo, but here I will briefly talk about one of the most complicated parts of skill creation: Sounds and Effects.


Mostly I agree with this tool tip: when creating a new skill, copy the effects of an existing skill and at least use it as a starting point. Clicking the note button will let you choose an existing skill to copy the FX of.

However, let's examine the FX of the humble Sword skill and try to understand it:


The Sword skill has two FX associated with it: one sound effect, one visual effect. The name of the sound effect is Swoosh Sword (this is one of the sound effects you can access through the PlaySound action). The number after the colon tells us how much of a delay there is before the effect begins. Because it is 0, we know the Swoosh Sword sound plays immediately when the skill is used.

The visual effect is called Slash (this can be accessed through the SpawnVisualEffect action, though you will not get a menu of existing VFXs). The spawn type is "OnTargets": this means the Slash VFX will be centered on the sprite of the target of the skill. The first number after the colon tells us the delay for this effect. In this case, the Slash VFX starts 0.36 seconds after the skill is used. The final three numbers are the trickiest to understand, and I honestly am trying to get better with them. In short though, they modify how much offset from the "center" the VFX should be: Back-Front | Left-Right | Down-Up. Here, the Slash VFX is not modified for Back-Front or Left-Right, but is nudged upwards by 0.6.

You can group multiple SFX and VFX together in one skill; just separate them with commas. If interested in creating custom skills, I recommend starting from an existing skills and try modifying different parts of it: the damage, status effects, visual and sound effects to get a feel for how everything works.

The character creator does a pretty good job explaining the different things you can do with units and what each option does. Now that we are at the stage of creating our battle and potentially thinking about balance, however, I want to pay special attention to a few parts of the character creator.


Unless I have a specific concept in mind for a unit, I will often randomize their skills and skill progression and be satisfied with the result. However, make sure the unit has all of the skills you intend for them to have. For example, take a look at the level 5 generic swordsman below. See if you can determine the issue before reading on.


The issue here is that our poor thug can't actually swing his sword and attack, only Shove and Feint. We can fix this by clicking the Show Skills button and selecting "Sword", the basic sword attack, or typing it in directly on the skill line.


Note that this particular issue won't be a problem if our unit has a sword equipped, since this will grant the unit the "Sword" skill. However, I recommend giving inventory items to generic units only sparingly. Why?


By default, an enemy unit will drop everything in its inventory upon death. Putting items in the inventory of special enemies may be fine, but think if you really want items dropping from every instance of a generic enemy that the player will be killing a lot. Thus, I recommend always making sure generic units have access to a basic attack in their skill list instead of giving them a weapon.


Adjusting the level of the unit within the creator will have two important effects (that I aware of):

1. The higher the level of the unit, the more XP a player unit will receive when attacking/killing them. Note that for XP purposes, a level 1 version of a promoted class is (I think) equivalent to a unit level 20 in a base class.
   
2. The level of the unit will determine the starting skills the unit receives when randomized. Each class in the game has a set of skills that it commonly learns as part of its skill progression, and it tends to learn the same skills around the same levels. For example, swordsmen often learn the skills Shove and Feint at low levels. In our above example of our generic swordsman, since he was set to level 5 the skill randomization gave him those skills as already available to him. If he were level 8, he would likely have Pull, and at level 11 he would likely have Sprint.

Adjusting level within the character creator will not have any direct effects on the stats of the unit.


Let's talk about how unit stats increase on level up, looking again at our Sword Thug.


When a unit levels up, they will gain stats in X different stats, where X is that unit's "Stat Gain". As far as I know, all units in the main campaign have a Stat Gain of 2. If you ever saw a unit gain 3 stats upon leveling up, it likely coincided with a level where the unit gained a stat proficiency. For example, according to the skill progression for our Sword Thug, he would level up his strength at level 17 and his dodge at level 19. These skill proficiencies can overlap with randomly-rolled level ups, giving a double level up for that stat.

The randomly-determined stat-ups are weighted according to the Growths set for the unit. Once a stat is selected for increase, it will not be selected again for that level up. For example, our Sword Thug could never roll two Health level ups at once. The stat must have a Growth value of at least 1 or it will never increase from level ups. There is no minimum or maximum number of Growth points you can distribute, though Growth points for each stat ranges 0-20.

Put together then, how would our Sword Thug level up from 5 to 6 in battle? If the unit hits something in it's skill progression, it will learn the new skill or stat proficiency. The Sword Thug has nothing in his progression for level 6, so he doesn't gain anything there. He has a Stat Gain of 2, so he will randomly roll 2 stats to increase. Across the 12 growth points he has distributed, Health has the highest chance of being picked (5 out of 12). Let's say that gets picked for his first stat. Health is then eliminated from the second roll, leaving: Energy, Strength, Reflexes, or Counter Limit. This time we roll one of our low chances and get Reflexes (1 out of 7). So, Health and Reflexes are increased for our level 6 level up, and the chances for each stat are reset for the next level up.


It's up to you how you want to handle unit stats, but I will mention a couple broad approaches you could take. If you know you want your unit to have certain values in certain stats for a battle, you can adjust their starting stats to match what you are looking for. This approach gives you precise control over how the unit will perform in the battle you plan to use them in, but they could scale strangely if you increase their level in battles (more on this later). The other approach you could take is make at most minor adjustments to the starting stats and growths of the unit and level the unit accordingly for battles. The unit will probably scale better with level increases, but you could also get more variability in stats from unit to unit than you want. I have tried bits of each approach and do not have a strong preference; do whatever suits you.

You now know the basics of the creating cut scenes and battles. From here though, we will start getting fancier and make use of a few more areas of the campaign editor.

Since Amir is a blacksmith, what if we gave him a special sword that grants a special skill? Let's start with making the skill. Back out of the battle editor and create a New Skill. I'm choosing to name the skill "Blackpowder Slice". The skill type does not matter yet, choose any valid option. Once you are looking at the skill screen, click Copy Skill and choose Sword.


We're going to make a special sword attack that costs some energy, does more damage, and is very flashy. I've set energy Cost to 5 and Strength Multiplier to 1.5. In the Sound and Effects box, Ctrl + C to copy the default FX for Sword. We're now going to copy over the FX of another skill. Click the note button and cycle towards the end, where we will find the skill Explode (page 7). Choose this, then paste the FX for the original Sword skill back into the box. Finally, let's choose a new image for our skill. Click the button for image browsing and select Explode again (page 3). Your skill screen should now look something like this.


Let's clean up our FX slightly. Let's try keeping all of the FX of Sword and all of the FX of Explode; we just need to make sure each effect is separated by commas.


This will do for now. We will come back to tweak parts of this skill, but let's move on for now. Enter in a tooltip description, save the skill, and let's back out to create our New Item.

Let's name this sword something like "Amir's Scimitar". Enter in "Weapon Hand" as the type. In the item screen, choose Copy Item and select the Steel Sword. Choose whatever fancy image you like for our new sword. In the Grants Skills box, click the button to browse for our new skill (page 8) and choose it. Save all of the changes you have made.


Before we're done with the sword, let's do one more thing: assign a global script to the skill. Global scripts are Dialogues and Scripts that can be accessed from any scene. They're useful for adding effects to custom skills among other things. Back out of the item editor and click on Global Dialogue / Scripts. Note: this is the one section of the editor that autosaves; you can freely enter and leave this section and changes will remain.

We'll keep it simple and just create a new Script and give it one Action: PlaySound. We will make this Action play MysteryFlourish whenever we use our custom skill.


Since we're just playing a sound, we could have just added it as a SFX for the skill. I'm keeping it simple for demonstration purposes, but there is obviously a lot more you could do with a Script tied to a custom skill: do behind the scenes calculations, create effects that would not be possible in the skill editor, etc.. Return to our custom skill and add the name of our global script into one of the Runs Scripts fields.

We have a fancy new sword with a fancy new skill. Now let's put the sword in Amir's inventory so that he can make use of it. Open up Amir in the character creator, back up to his inventory section, and place the sword in his inventory. It should be at the end of the list of items. Don't forget to save your changes.

If you created an "Amir" that is not a swordsman, add "Sword" to their equipment masteries on the previous page of the creator. Without this, "Amir" will not be able to equip our new sword. Alternatively, return to the item editor and leave the Mastery Requirement field blank, which will allow anyone to equip it.

Now let's give our new sword and skill a try! Start a test run of First Battle, and have him use his new skill on a target.

Try using the skill a couple times and see how you feel. The timings of the FX could maybe benefits from tweaks, but I will leave it to your discretion if you want to give that a try. There is another noticeable issue, however: Amir does not animate when he uses the skill. Let's return to the skill editor. Our skill should be near the end of the list of skills.

Again I will allow you a moment to look around the editor and try to figure out a solution.

Once you have looked around the skill editor to determine the cause of Amir's animation issue, you can reveal the spoiler text below.

The key to the problem is the Character Animation Name field. This is where we tell the game what animation to play for the user of the skill. Since this is a sword skill, we could write "Sword" directly in this field or, as the tooltip suggests, write "Sword" over in the Depends Upon Skill box. If you make and save either change, you will now see Amir swing his sword when he uses the skill.


If you're wondering why I am sprinkling these kinds of questions into the guide, it is to ease you into finding some of these answers on your own. A lot of this guide is a product of trial and error, or referencing existing skills, items, scripts, cut scenes, battles, etc. until I was able to figure out how they work. If you don't know how to solve a problem you're having, you can probably figure it out with some thought and digging around. Though don't be afraid to ask someone else a question!

Okay, getting off my soap box, I'll give one more bit of skill animation advice. You may have concepts for skills where the unit doesn't have any animation that is a great fit: maybe you want a Psy class to use a "sword" skill. Or, your "Amir" is not a swordsman. In these situations, Shove and Cast are decent catchall animations to put in the Character Animation Name field. This animation is usually the character holding a hand out in front of themselves. Many melee classes will have a Shove animation, Psy classes will have a Cast animation. I find it a decent substitute when there isn't a more targeted animation to use; just enter Shove/Cast into the field.

With the skill animation resolved, this feels like a good point to make our battle grander in scale. Let's create a couple new generic units, one that will be allied with Goreslaughter and one that will be allied with the player. Even though you never see generic units on the player's side in the main campaign, there is nothing that prevents the player from using generic units; they simply will not persist from battle to battle unless they are part of their roster and will never gain XP from battle. Create whatever generic units you want, but leave them at a low level. Once you're done, let's return to the battle and place them on the map.


Try testing the battle, see how you feel about the balance between the player and AI army. If you aren't satisfied, you can of course place more units down for one side or go back to the character editor and adjust the stats of the units. But instead, let's try using some scripts to level up the units. If we look at our available Actions, you will find one called LevelUpArmy. Let's create a Script and add the LevelUpArmy action to it.


This Action is a little weird. After the army number parameter are two parameters that determine how many levels we give to the army: Levels To Gain and Level To. Despite "Level To" being marked as an optional parameter, it would be more accurate to say one of these two parameters needs to be filled in and the other left blank.

For example, see two ways we could correctly fill in the parameters below. In the left image, we tell the game to add 4 levels to each unit in army number 1. In the right image, we tell the game to level units in army number 1 until they reach level 7.


Choose one of these approaches for your Script. With the levels of the AI adjusted, we probably want to adjust the levels of our player units too. Go ahead and click the + button next to your LevelUpArmy action. This + button will clone that branch of the Script or Dialogue. This is handy when we have multiple branches where we are doing something very similar. In this case, we can just adjust our army number to 0, and maybe change the levels we are giving to the player units in this second Action. Now that we have level adjustments set up for both the player and hostile AI, let's test the battle again.

...Unfortunately, nothing happens: all of the units are still at the level they were before. Don't worry, this is one of the last times I trick you.

So, why didn't the Script work? Assuming you filled out the parameters in one of the ways I showed above, the Actions are configured correctly. The problem is, the Script itself was never activated. How can we fix that? One approach is to activate the Script within a Dialogue.

Let's create our first Dialogue in a battle map. Unlike the Dialogue we created in the cut scene editor, we do need to fill out the Trigger and parameter fields, so that the game knows when to activate that Dialogue. You can browse the Trigger section of the Guide to see the list of ways we can activate a Dialogue. Here, we are going to use the "OnLoaded" Trigger. This Dialogue will activate immediately upon the battle being loaded. This is one of the few Triggers that does not need any parameters, so we will leave that field blank.

In our first branch, we just need to add one new Action: Run. This will let us specify a Script to be activated when that branch of the Dialogue is reached.


Now if we try testing the battle again, we see we were (partially) successful. You will notice that the level has been adjusted for most of the player and AI units, but not for our characters in the player's roster. You probably also noticed a couple odd visual issues at the beginning, before we finished deploying.


Let's talk about the visual issues first. These were caused by our Dialogue. We told the game to open that Dialogue once the battle loaded and do any Actions in the first branch. The game did this, but the Dialogue was not closed. Thus, in the first image we see the Dialogue box is still open behind the deployment screen. Once you clicked, the Dialogue was advanced to the next branch (since we left it with the default NextBranch reply). Since there were no more branches, the Dialogue had come to an end and closed. However, ending Dialogues like this at weird times, like, say, while we are in the middle of deployment, can cause weird issues, like the ? skill bar appearing at the bottom of the second image.

While in this situation it only caused some brief visual weirdness, in other situations improperly configured scripts can softlock you when you test your campaign and cause a variety of weird visual issues. I've never encountered any "permanent" damage when this happens, but you will likely want to restart the whole game before trying to fix the issue. I won't be trying to create that issue in our demo, but I normally encounter this more serious issue when a script is not properly terminated.

Back to our current Dialogue though. When we are setting up a Dialogue triggered OnLoaded, we should add an Action at the end: EndConvImmediately. This will let us run any Actions we need our Dialogue to do, then close itself automatically when they are done. Remember that the order of our Actions matter: if EndConvImmediately is the first action, that will be run first, and the Dialogue will be closed before any of the other Actions have been performed.

In case you're wondering, no, we don't need to fill out a name for a speaker or any conversation text. You could choose to put some text that let's you know when one of these scripting Dialogues is not functioning correctly by closing on its own.


As you can see, Dialogues are versatile. We can just use them to set up a conversation, as we did for our cut scene, but we can also use them to control when and how our various scripts function. We just have to make sure they end appropriately.

You may be wondering at this point, why did we bother setting up a Script at all? If we need Dialogues to activate them in the first place, why didn't we just put our LevelUpArmy actions directly into our Dialogue instead of telling it to run the Script? In this situation, yes, we could have put all of the Actions in the Dialogue. However, as I mentioned earlier in this guide, we are limited to 6 Actions per branch in a Dialogue, and moving some of those Actions into a Script that we can trigger at once with a Run Action is one way we can do more than 6 Actions at once. Depending on what we are trying to do, it may make it easier to read and understand what we want to accomplish by moving some of our Actions into a script that our Dialogues occasionally Run. Maybe you have a sequence of Actions that you want to use in more than one Dialogue (e.g., a series of math operations, or creating multiple variables at once); offloading those Actions into a Script may save you some time. Finally, you can set up a global Script to be triggered by a custom skill, no Dialogue needed.

Returning to our battle, you will see that the visual issue is sorted if you run another test. But what about the level of our roster characters? The problem we encountered here is that our LevelUpArmy Action was only increasing the level of units that were on the battle map at the time the Script was activated. The easiest solution here would be to update the last parameter of LevelUpArmy, which specifies if the leveling up should affect reinforcements. For the purposes of this Action triggered at the start of the map, our deployed characters count as reinforcements. So, let's set the last parameter to True.


Since we only care here about the player's "reinforcements", I've only set the parameter to True for the player's army (army number 0). We test the battle again, and finally they are also receiving the level ups!

While everything we just did let us level up an entire army at a time, if you just want to level up one character, the LevelUp Action is an option.

We've just done a bunch of scripting and dealing with bugs, so let's now do a few fun things. Going to Map Settings -> Armies, let's finally set some names for our teams. As you have seen so far, army number is what matters for most of our internal scripting; you can change the army names on whim to whatever you like, the names will just change what the player sees. Go with whatever names you like.

Let's also set a music track, which we can do from the base Map Settings menu. This is the music that will automatically play when the player runs the map. Similar to the PlaySound action, you can browse a menu of the different tracks included in the editor, playing each track to find the one you want. If you go to Conditions, you can also set a different music track to play during deployment; it's one of the optional parameters. You can also do this for cut scenes. You can also change tracks, stop music, and modify the volume of music using various Actions you can look up in the Guide. I haven't brought up music before this point because, depending on your choice of track, you may find it distracting while you work. But we're getting closer to the end of the demos, promise!

While we're in the Map Settings, let's also go ahead and write out our objectives. As mentioned earlier in the guide, the objective text is purely for the player's benefit; anything we write here will not change what the game considers victory objectives. For this demo, let's keep it simple: we just need to kill all of the enemies. Unless you disable Kill-All Victory under the Conditions section, this win condition is on by default.


Let's do one more piece of prettying-up; this one will require an Action however. By default, anything beyond the boundaries of our battle map is a void; however, we can choose to set a background image that will "sit behind" the map, filling in the edges of our view. Let's return to the cut scene editor and browse the available backgrounds. Once you know the name of a background you would like to try, let's return to our battle. Open up our Dialogue that loads immediately after the battle begins and add the Action: NewBackground. Remember that this action will need to be placed prior to the EndConvImmediately Action, so use the blue arrows to adjust the order. The only mandatory parameter is the name of the background image. In the screenshot below, I went with Forest.


Personally, I don't think there is always a good background for a given map; I would only use this feature when you think the presentation of the map will benefit from it.

Let's return to the mechanics of the battle. Our poor orange golem has been sitting there minding his own business this whole time; how about we let the player recruit him? For this we will need, you guessed it, a new Dialogue.

Let's say the player just needs any unit to walk up and talk to the golem. Here I'll let you spend a moment seeing if you can figure out what Trigger this new Dialogue will need and what parameters.

Not surprisingly, OnTalk will activate the Dialogue when two characters talk. The order of our parameters is arbitrary. One of the parameters will be the name of our neutral unit (for me, it was "Crumbling Golem"), for the other parameter we will enter -ANY- to allow any of our units to talk to the golem. We could put in the name of a specific unit instead if we wanted to restrict it.

This Dialogue will be part scripting, part actual conversation. Add a branch, and add a couple AddPortrait actions. But wait, how are we going to tell the game which portraits to add? If one of the conversation partners can be any of our units, how will the game know which portrait to pick?

Let's talk about Special Characters. These are (mostly) variables that can be called upon in certain circumstances to supply information. If you check the Special Characters section of the Guide, you will also see a few text formatting options. For our current predicament, we have a few potentially helpful Special Characters. One option is -FNAME- and -FNAME2-, which will supply the full name of the character initiating the conversation (the player unit) and their conversation partner (the golem), respectively. Take care with Special Characters that use names, however; if there are multiple units in the battle with the same name, the game can get confused when you plug their name into an Action. (If you want to get specific, if there are multiple units with the same name, the game will think you are talking about the unit with that name that is closest to the upper left corner of the map.)

While for some Actions I would recommend using -UNIQUEID- or -CHAR2UNIQUEID-, which can differentiate among units with the same name, -FNAME- and -FNAME2- will be just fine for this Dialogue, even if our speaker is one of our generic units that we have multiple of. We can also use -FNAME- and -FNAME2- in the speaker field.



In the image above, you may have noticed I set the portrait color for the golem to Orange. By default, all portraits used in a Dialogue are colored as if they belong to the blue army, even if there are no blue-colored armies present. For some units though, like this generic lissit unit, it isn't apparent what army they are supposed to belong to. Note: the AddSpeakerPortrait Action will try to find the appropriate portrait (with correct color) to add to the conversation based on the name put in the speaker field. This is an alternative at least when adding a portrait on the same branch that that unit is the speaker.

I did also specify Blank expression for both portraits even though it is very unnecessary: 1) because the expressions will default to Blank anyway, 2) because generic units, such as our golem and lissit, have no facial expressions, and 3) even unique golems do not get facial expressions. I wrote out Blank here just for readability for the sake of the guide.

Now that we have the portraits set up, let's make our golem actually switch to the player's team. Add a second branch to this Dialogue. To change the golem's allegiance, we will need to update one of their stats. A character's stats include not only what you would normally think of, such as health, strength, fire resistance, etc., but also a few other variables. You can see a listing of these "Special Stats" in their section of the Guide. As you might guess, the Special Stat we want to update here is Army. We can use the SetStat Action to make the change.


You'll notice that even though the golem changed sides on the map, the portrait is still Orange. Again, portrait color is independent of the unit's color. If you wanted, you could RemovePortrait the golem and do another AddPortrait to make it blue on this branch.

Finally, let's give Goreslaughter some attention. Currently, all enemy units will move towards the player to attack from the beginning of the battle. Instead, let's have him and any other hill units wait at his hill until a player unit moves into range. We can achieve this behavior using Tags.

As usual, check the Tags section of the Guide if you want a full list of Tags available. To achieve the effect we want, we will need to combine a few Tags. Use the Edit Character button on Goreslaughter and add these tags to him. Also add these tags to any of his nearby minions.


Here is what our Tags are doing: first, we are adding the Passive Tag to the unit. Passive makes the unit not move or attack until an enemy is in range. Next, we are adding the AggroGroup Tag with the parameter 1. This links together all characters that are in AggroGroup 1. Specifically, if one of the characters in AggroGroup 1 loses their Passive Tag, all characters in the AggroGroup will lose their Passive Tag. Finally, we add the Pursue Tag. If this character attacks or is attacked, it loses the Passive Tag.

(Note that the "Add" part of the Tags is deprecated; while what you see in the image will work, removing the Add part will give you the same effect: Passive/AggroGroup,1/Pursue)

Putting this all together, this means that our hill group will sit there until a player unit comes in range or attacks one of them. Once that happens, all of the hill units will lose their Passive status and attack the player normally. After adding these Tags, test it out for yourself.

Side note: the Trigger field you see for units and objects is for what the Guide calls Unit Triggers, not the kinds of Triggers that are used for Dialogues.

To finish this demo, let's add one more Dialogue while learning one more concept: creating variables. To start, let's create a Dialogue that triggers when Goreslaughter attacks the player. The OnCharAttacked Trigger will work for this purpose.


This Dialogue will activate when Goreslaughter the Destroyer (from army number 1) attacks any unit of any class belonging to army number 0 (the player army).

We're just going to give Goreslaughter one line to speak, but he will show off his most terrifying skill: counting. In his line, he is going to mention how many units the player currently has. Obviously we can't write a number in, since the player could lose units (or gain, if they talked to the golem) compared to what they started with. Instead, we'll insert a variable in his line that will in turn be set to the current number of player units.

This will take some creativity, but here's one way we can achieve this: let's create a new Script and add the following Action: UnitsToList. This will create a list of units according to criteria we set. Here we just want a list of all player units. Once we have this list, we can use the Special Character LASTINLIST[]. If we put the name of a list in those brackets, LASTINLIST will tell us the numbered position of the last item in the list. So, combined with the list we just created, we can get the number of units in the player's army.

Well, almost. Because, according to my understanding, lists in the editor are zero-indexed (if that term means nothing to you, don't worry about it), we will need to add 1 to the number we got. Putting all of this together gives us the following Script:


The SetVal Action create a new variable: pcount. We first set it equal to our last numbered position in the list. Then we add 1 to this value.

Now that we have our count of player units, we just need to Run this script and put the variable in Goreslaughter's speech.


When we want to use the variable, we make use of a Special Character. When it's a Val variable like we are using here, we type it out as -VAL:NameOfVariable-. The Special Characters section of the Guide lists this and other variables you can create and use.


Note that these variables can be used outside of Dialogues, as long as you have created them in a script somewhere ahead of time, and they persist in the background from scene to scene. You can, for example, create a variable in a cut scene and then use it in objective text or even army names in a future battle.

At this point, there are a few simple polish additions I would consider: Edit Character or Edit Object to add some items the player can loot when they die, or a Dialogue at the start of battle but after deployment (Trigger: BeforeTurn, Parameter: 0) where the player characters have a conversation, or adding an epilogue cut scene. But all of these things are well within your capabilities now.

If you have read through everything before this point, congrats! You know how to use pretty much all parts of the editor and know everything you need to make some campaigns. From this section on, I will be talking about a few advanced topics and miscellaneous advice.

The campaign editor lets you add a variety of new assets to your campaign, pretty much anything besides new terrain or character sprites. Do you remember the campaign folder we looked at way back in the Getting Started section? Now is the time to open up that folder again.


There are commonalities in how you add assets. When you have a new asset you are ready to use, drop it into the corresponding folder. Each folder also has a file called CustomAssetInfo.xml. Open up this file in the program of our choice (see some options below) to read file format and dimension requirements. The sections below will be largely repeating the information from the CustomAssetInfo file.


While you could create your own music and sound effects, I do not have the skills for that and cannot recommend useful programs. If you need an existing music or sound file converted to a different file format, you can find free tools for that online.

For image editing, I like to use GIMP, a free program that lets you work with layers.

You will also want to be able to look at the .xml files in this folder. While I have typically used Notepad, the developer recommends Notepad++, a free program that helps with visualizing different structural bits in .xml files. If you find a .xml file you edited is no longer working as intended, you can find online .xml validation sites, such as W3 Schools, that can help with debugging.


Backgrounds are the images used as, well, backgrounds in cut scenes and (optionally) battles.

Backgrounds must be saved as .png files. It's recommended you use images with a 16:9 aspect ratio, with 5000 x 2813 being the default image dimensions.

Once you have a .png file in this folder, you will see it the next time you open up the Background menu in the cut scene editor. The custom images will be at the end of the list.


Item icons must be saved as .png files with 64 x 64 dimensions. You will also notice a file called Blank.png already in the folder. This is the background you see for all of the default item icons in the editor; draw on top of this image if you want the new item icon to look consistent.

Once you have a .png file with the correct dimensions in this folder, you will see it the next time you open up the image browser in the item editor. The custom images will be at the end of the list.

...At least, that's how I think it's supposed to work. When I tested it as of writing, I could not get the icon to show up in the editor. This section will be updated when I learn more.


Music files must be saved as .ogg files. As CustomAssetInfo suggests, search online for a file converter if needed.

Once you have a .ogg file in this folder, you will see it the next time you open up one of the music menus. The custom music will be near the end of the list.


Skill icons must be saved as .png files with 64 x 64 dimensions. You will also notice a file called Blank.png already in the folder. This is the background you see for all of the default skill icons in the editor; draw on top of this image if you want the new skill icon to look consistent.

Once you have a .png file with the correct dimensions in this folder, you will see it the next time you open up the image browser in the skill editor. The custom images will be at the end of the list.


As mentioned in the CustomAssetInfo file, you could not only use new sounds to create new sound effects or loops, you could even use it to added voice acting to your campaign.

Sound files must be saved as .ogg files. As CustomAssetInfo suggests, search online for a file converter if needed.

Once you have a .ogg file in this folder, you will see it the next time you open up one of the sound effect menus (e.g., when setting a PlaySound Action). The custom sound effect will be near the end of the list.


As mentioned when we first looked at this folder, the Thumbnail is the image players will see associated with your campaign in the workshop. The CustomAssetInfo.xml file for this one is in the base folder with the placeholder Thumbnail,jpg.

Your thumbnail must be saved as .jpg file. It is recommended that the image dimensions are 440 x 440. The new Thumbnail.jpg should replace the old Thumbnail.jpg.

Once in place, it should be seen in the workshop once the campaign is published. If the campaign is already published, you may need to push an update for the thumbnail to change.


I've saved objects for last partly because this is the most involved process, and partly because it segues into our next section. The objects you see in game are a mix of 3D models and 2D sprites. While you cannot add 3D models as objects, you can add 2D sprites.

Object images must be saved as .png files with 64 x 96 dimensions. You will also notice a file called Blank.png already in the folder. This file demonstrates the dimensions you are working with for object images.

Once in place, we will need to take an extra step to turn our new image into its own object, which we will talk about in the next section.

We've taken a look at the subfolders of our campaign, now let's look at the .xml files sitting in our base folder. First, an overview of what we can find in each file:

Attacks - this file contains each of the skills available in your campaign. This includes any base game skills as well as any custom skills you have made. If you scroll to the bottom, you will notice the skill we created earlier.


CampaignInfo - this file contains some basic information about the campaign, such as the name, the description we gave it, and a line that can change the first scene the player is booted into when they load into the campaign. At least, that's what I think that line is for; I have tried changing this line to another scene and it did not change the campaign start point for players. I would still plan for Introduction to be the start of your campaign.


Items - this file contains each of the items available in your campaign. This includes any base game items as well as any custom items you have made. If you scroll to the bottom, you will notice the item we created earlier.


PersistentDialogue - this file contains the global Dialogues and Scripts in the campaign. You'll notice the global Script we created earlier here.


PortraitData - this file contains some information on some special portraits for particular main campaign characters. Although we won't be editing this file, there is some interesting information here we will be referring to later.


PremadeUnits - this file contains information on any characters and objects we have created for our campaign. To implement new objects, and do a couple other tricks, we need to manually edit this file.


While not in the base folder, you will also find .xml files for each of the scenes in our campaign in the Maps folder. Here you can see a lot of information for each scene, including any Dialogues, Scripts, map settings, objects, terrain, etc.

As you can see, there is a lot of information in each of these files, and if you're not used to it they probably look overwhelming. That said, you can hopefully recognize bits and pieces of the things we worked with within the editor.

While I have avoided doing so, outside of the manual edits I am about to discuss I believe you could choose to edit each of these files outside of the editor. You may find it more efficient than going through the in-game menus in some cases. However, the consequences of a mistake may be less predictable and harder to fix. I don't recommend doing this unless you are already reasonably confident working with .xml files. Also, avoid making changes to these files from within the editor while you have the .xml files open; this has potential to cause problems. Finally, if you really want to edit them outside of the editor, make sure to save a backup of the files before you make any changes.


Let's say you want to add a custom object, and you have an object sprite placed in the Object Images folder. Now what?

Before making edits to PremadeUnits.xml, save a copy of the file. In case a mistake is made while editing this file, you can save over the original with the copy. Once we have the copy, open the file and look at the line of text towards the top that begins with <u category="object" . Copy this line, and paste the copy just underneath it. Then update the underlined portions of the image with whatever you want.


LoadID is the internal name for our new object; it's the name we use to refer to the object when, for example, we use a script to spawn in the object. spriteSet is the name of the object image we put in the images folder. It will always be preceded with 'Custom/'. name is the object name the player will actually see when they look at it on a battle map.

There is other information we can set for our object here, but in short, since we copied information from the example object: our object can only be bypassed by Flying characters and will generate wooden particle effects on death. The object has 16 Health, has 100% resistance to mental and poison damage, and is pushable. Finally, it is immune to many status effects. We can't use 3D models for custom objects, so is3D should be set to false.

swayStr bears special mention. 2D sprite objects can "sway" in the environment, making them look less static. At 0, the sprite will be perfectly still on maps. The higher the number the more erratic the swaying. If you want to give your object sway, I recommend starting with pretty conservative numbers. For example, I have a banner object in my own campaign with a sway strength of 0.04; much more than that looks pretty bad.

One more note on custom objects: for reasons unclear to me, you cannot right click on a custom object in battle to bring up their stat screen. You can only get the tooltip any object or character gets when you hover your cursor over them.

There are certain portraits and sprite sets created for special main campaign NPCs that are not accessible through the character creator. Sprite sets are collections of sprites that go together for one character: for example, swordsmen have idle sprites, sprites for a sword swinging animation, sprites for shoving, etc. Sprite sets are how you determine what your character 'looks like" on battle maps. I recommend using many of these hidden options for special NPC characters in your campaign, but not fighting units, for a couple reasons. Many of these special sprite sets are intended for civilians and won't have animations appropriate for combat (you can give them combat skills, it will just look goofy when they fight). Many of the portraits are fairly distinctive and don't match up with any normal class sprites.

You can find the names of some of these special portraits in PortraitData.xml, next to 'Base name='. Some of these portraits are for creatures which you could use in a cutscene, but there are no remotely equivalent sprite sets (e.g., "Mantis" or "Chital"). Some of the portraits may not have sprite sets made to fit them (the reverse is also true: some sprite sets don't have a matching working portrait). There are also some portraits listed here that may not work; for example, as of writing "Lissit Child" gives you a blank placeholder portrait if you try to use it.


Okay, so how do we actually make use of these portraits and sprite sets for one of our campaign characters? Like with creating objects, I do recommend creating a back up of PremadeUnits.xml if you haven't already. Next, create a character in the character creator. Appearance, class, unique or generic - none of this will matter for a non-combatant. That said, the next step will be slightly less annoying if you choose generic over unique. Gender will matter for the sake of determining what their voice sounds like during conversations, but the babble voice can be manually adjusted if need be using the Babble Action. Reminder: avoid having a file open while changing it within the creator; at the very least, expect any changes you made while the file was open to not save properly. So, close PremadeUnits.xml before making this placeholder character if you have not already done so. Once created, there are a few pieces of information in the xml file that we need to change for our new character. Exit out of the character creator in game if you haven't already!

Here I have created the character "Not a lizard". Since this is the most recently created/changed character, it will appear at the top of the character section in PremadeUnits.xml:


Apologies for the tiny text, but if you zoom in, you will see I have underlined two areas in the entry for our character: spriteSet and portrait. Replace the text for the first underline (here, Barudit_Male) with the name of the sprite set you want this character to use. Replace the text of the second underline (here, Generic/Barudit_M) with the name of the portrait you want to use. If you compare the portrait info to one of your existing, unique characters, you may see why I recommended making this unit generic. While generic units have a portrait referenced by a short string of text, the portrait entry for unique units is much longer and more convoluted. You can still use unique characters for what we are doing right now, you will just have a longer string of portrait text to clear out and replace.

There is other information here you could consider replacing. For example, charClass determines what class the player sees in tooltips for this character. If you are creating a civilian NPC, consider changing this to "Villager" or "Townsperson". Again, this is ultimately flavor text and is not related to what combat skills the character may or may not have; that is entirely up to you in the section of the character creator where you assign skills and skill progression.

Once done, save your changes, return to the campaign editor, and try placing your new unit on a battle map.


Here I used the sprite set "VillagerDese_Boy" and the portrait "Arena Manager". As you can see, even the species of the original unit doesn't matter, we can replace their sprite set and portrait with whatever we want. Definitely not a secret lizard person.

It is also worth mentioning that even if a portrait has an "intended" matching sprite set, you can mix and match. In the above example, I could have used the portrait "Villager Dese M Child" to better match. I could have also used "Tarion". The mixing and matching is up to you.

Note, if you want a character that will only appear in cut scenes, you can save yourself some effort by invoking the name of the relevant portrait in your AddPortrait Action without attaching it to a character. If you go this route, you may want to use the Babble Action for the babbling sound effects when speaking, since the game otherwise won't have a character to reference when determining the voice pitch.


While we can look at PortraitData.xml for a number of special portraits, we don't have an equivalent resource for sprite sets. Listed below are sprite sets that exist and work as of the time of writing. Again, this is just a listing of sprite sets I am aware of; there may be more that I am not aware of. Below the list, I've included an image of some (not all) of the working sprite sets. Note that I suspect there are slight spoilers for Together in Battle's main campaign in this list:

Emma
Sabrina
Lakshmi
Harriet
Teresa
Matriarch
LissitChild
Pathos
Tarion
RoyalGuard
Slave
SlaveGirl
StaffFighter
Llama
PrinceAjit
PraetorNero
ManbirRaksha
Villager_Male
Villager_MaleAlt
Villager_MaleOld
Villager_Female
Villager_FemaleAlt
Villager_FemaleOld
Villager_Boy
Villager_BoyAlt
Villager_Girl
Villager_GirlAlt
VillagerDese_Male
VillagerDese_Female
VillagerDese_Boy
VillagerDese_Girl

At this point you know how to use pretty much every area of campaign creation, both inside and outside the editor. Here I am going to describe some useful Scripts and Dialogues that I think are handy to use.


Having scripts fire off before anything else happens in a battle can be useful. To do that, you can use a Dialogue with the OnLoaded trigger, like we used in a demo, or a Dialogue with trigger: BeforeTurn, parameter: 0 to still do some Actions before any fighting begins but after any deployment phase.


Sometimes you may want something to happen only after meeting multiple pre-requisites. Setting up multiple conditions is a bit cumbersome, but can be done. In the Guide, you'll see a series of Actions of the form: If___GoTo and If___Run. For multiple conditions I recommend setting up a Dialogue and setting up a series of branches, with at least one GoTo action in each branch. Like I said, cumbersome, but I am not aware of a better way of doing this.


You may want an effect to happen each turn, or check if something has happened. Here's one way you can do that.


Above, I have set up a Dialogue to activate on the start of each of the player's turns. You can see it triggers OnTurn, with the parameter being a number variable. For this to work, make sure you have set up the variable before this Dialogue is supposed to activate, such as a SetVal action in an initial setup Dialogue. Assuming the player is moving first, their first turn will be turn 0. If there are two armies total in the battle (one player army and one AI army) the player turn will be on every even-numbered turn. If you want this to be a re-occurring script, it is very important that you check the Repeatable box!

In the branches of this Dialogue you can set whatever Actions you want to fire but remember a couple things. First, unless this is a Dialogue the player is supposed to see, make sure the last Action that fires is EndConvImmediately. Second, prior to EndConvImmediately, you need a SetVal Action that will update our variable. In this situation, if there are two armies and I want this to trigger on every player turn, I would want the parameters of SetVal to be: PlayerTurn,+:2. This will make the val go from 0 to 2, so the Dialogue triggers again on turn 2, which will update the val from 2 to 4, and so on.

Encountering issues you can't solve? Take a look here first. For some these steps will be obvious but


This is just a collection of tools and techniques that I have found useful when I am testing a map or cutscene.

Ctrl + T

This handy keyboard shortcut will kick you out of whatever scene you are currently in. If you use it, say, while playing a campaign for real, it will boot you back to the game main menu. If you use it while running a Test in the campaign editor, it will kick you back to the screen you were at when you hit Test.

Condition: Delay Maneuvers

When you have a battle where you want to test things out without one of the armies taking turns, add the Delay Maneuvers condition.

Condition: Kill-All Victory

Maybe you are playing out a cutscene on a battle map where everyone belongs to the same army, or you have not placed down opposing armies for the battle yet. In either case disabling Kill-All Victory is handy.

Actions: SpawnFloatingText and AddTextOverlay

These are particularly handy tools when troubleshooting a complicated script or checking that a variable that the player won't see is actually working as intended. Have a script reporting behind-the-scenes information to make sure it's running smoothly.

"Comment out" an action

This isn't exactly "commenting out" code, but the idea is similar. If you want to temporarily disable part of a script without deleting it or changing the parameters, I will sometimes add nonsense to the field where the name of the Action is supplied (e.g., rename AddPortrait to xxAddPortrait). This won't display any annoying errors, just disable the effects.

Console commands

Pressing the ` key (upper left of a QWERTY keyboard) opens the console. This can be a handy way to test something, or help a player resolve a bug, without setting up a formal script. Any Action is a valid console command; simply type the name of the Action, followed by forward slash and then the parameters. For example, the console command below will play the sound Crash, with a pitch of 2.5. You won't get any autofill help or explanations when typing console commands, so you may need to refer to the Guide to get everything right.


Cloning assets

Because I didn't mention it earlier, it is worth pointing out that you can easily create copies of an existing cut scene, battle, or character. In the main menu for the campaign creator, just click on the double-square icon next to it (tooltip says Clone). This has a variety of uses, such as creating a backup before making major changes to the character/scene that you can restore later if needed. Alternatively, maybe you want a new scene or character that uses much of the same information, such as an "epilogue" cutscene to a battle taking place on the map. Cloning will save you the time of re-creating the parts you care about.


You've created your super script that checks that the player has brought the three Mangos of Power before the three different altars on the map, and if it is turn 7, explosions are set off in the middle of the map to herald the arrival of Goreslaughter the Destroyer, and--oh, nothing is happening.

When your big script isn't working, try to break the problem down into smaller problems; make sure each step is working the way you think it is. I will often temporarily add Actions such as SpawnFloatingText and AddTextOverlay to help out, and then remove them after everything is working.

Sometimes you may find you can't get the script to work the way you envisoned; if you can't, see if there are workarounds, such as other Actions, Triggers, Special Characters, etc. that could be used to achieve a similar end result.


1. Double check your work.

Or triple check, quadruple check...just keep checking. Many people (myself included) fall victim to this all the time: you think you have a statement written correctly, but then you eventually notice a typo or other mistake. If you have an example of the same Action/Special Character/whatever working as intended you can refer to, it can really help identify what may be going wrong.

2. Carefully re-read the in-game Guide.

Sometimes I thought I understood how a given Action was supposed to work, but upon re-reading their Guide entry or the descriptions of the parameters, I realized I had gotten something wrong. If it isn't working, make sure your understanding isn't the problem.

3. Play around with "optional" parameters.

Occasionally I find actions that treat "optional" parameters a bit differently: for example, sometimes it's fine to leave all of the default text for that parameter, while for other Actions things work better when it is left blank or I supply an actual parameter there. Try changing things around here and see if it fixes anything.

4. Report the issue.

Sometimes the editor really is broken. I've occasionally found things that don't work or the in-game Guide is misleading or wrong. If you think that may be the case, report the issue, and it should get fixed. I am writing this guide about 3 years after release and just a few days ago reported an issue with a Special Character not working; the issue was promptly hotfixed. The developer is great like that!


The SpawnUnit Actions probably look intimidating, but the important bits are Load ID and coordinates, the rest can be ignored. Load ID is effectively just the name of the unit/object. For most characters this will be straight-forward: use a colon to separate their first name from their last name as they were entered in the character creator. For example, if our character's first name was entered as "Goreslaughter" and their last name was "the Destroyer", their load ID will be: Goreslaughter:the Destroyer. You may have noticed in the main menu for your campaign that your characters have a forward slash separating their first and last name; you're just substituting the forward slash for a colon.

What if the character/object has a one word name? In these cases, usually they just have a "first name" and a blank "last name". We would still do the Firstname:Lastname load ID scheme, but we just wouldn't have anything after the colon. So if Goreslaughter was our character's full name, likely their load ID would be: Goreslaughter:. And yes, the colon is still mandatory; it won't work if you write the first name without the colon.

If the Load ID is fine, double check that the coordinates are fine. As long as you supply valid coordinates, the game should be able to spawn the unit, sometimes spawning the unit on an adjacent square if there is something blocking them on that spot.


The developer has gradually expanded the capabilities of the campaign editor over time. This includes additional options and placeholders accessible in the .xml files. Depending on how long ago you first created your campaign, these options may not be visible. Try creating a brand new campaign and examining the .xml files to see if you find what you're looking for. If you do, you need only use the newer .xml files as a reference; even if your campaign was created before the options were added, your campaign can still make use of them.

Thanks for checking out the guide! I made this guide because I wanted to help other aspiring campaign creators to get their vision out there. If you have any questions related to campaign creation, please don't hesitate to ask! There is a good chance I can answer your question or guide you in finding the solution yourself. Are there any sections you would like to see added to the guide, or more information you want on something in general? Images that should be changed or added? Do you notice any incorrect information? Let me know and I will see what I can do.