A Simple Guide to Cortex RP

By: Starcraft II player name: Kazuo

Character code: 286

AboutMost of the people in the Cortex community are not too friendly towards new players.

This could be due to a number of reasons, although I suspect that the main reason for this is that cortex is considered a complicated game by many due to the number of technical things and terminologies involved, and people just don’t understand how to break all the information down in a quick, simple, and easy-to-understand manner for new players.

Most often, I see people help new players by just shoving command syntax down their throats after telling them that the game operates based off of commands, and as such, it is never quite simple for a new person to learn and comprehend the game. Others try to help new players by telling them to read the commands guide located in the toolbar at the far left side of the screen, and upon doing so, the new players are sometimes completely lost due to not understanding the syntax as is given in the commands guide. Many new players have never gotten the chance to become experienced cortex players due to having received poor instructions leading them to give up on trying to learn new things about the game, or some have even simply outright stopped playing cortex after not being able to understand the game based on the first few times they’ve played it.

This guide was made in order to somewhat remedy this issue, by providing a structured method of learning the game so that people who read it actually understand what is going on rather than just being shoved command syntax down their throats. This guide is by no means, a way of completely mastering Cortex as the game is indeed too complex to be entirely covered within a simple guide such as this, and in addition, the author of this guide (myself) is not a complete master of Cortex either, but merely someone with a bit more experience and deeper understanding of the game compared to the average player.

If there are any parts of this guide that is read and not understood, and/or you have questions regarding the material covered by the guide or about the guide itself, feel free to add me in-game. My character name is Kazuo and my character code is 286 as shown in the title.

Section 1: Introduction

Hello, and welcome to the start of this guide. For those of you who are curious as to why this guide was made and how to contact me for questions, see the “About” section. Furthermore, it is important to note that it is not necessary for one to read the entirety of this guide before being able to enjoy playing cortex. The guide is structured so that even for someone completely new to the game, only this first introduction section must be read (approximately two-and-a-half pages long) and he/she can immediately jump into a game and start playing cortex with a good sense of how it should be played, along with the fundamentals needed to play Cortex correctly. For those who wish to truly understand more and be able to mess around with the functions of Cortex more however, further reading of the guide will be needed. The amount of reading you do will translate to the amount of information you will learn; as such, one who seeks to become fairly skilled at the game should definitely read the entirety of the guide. With that said, let us jump straight in!

The question we must start off with is what exactly Cortex RP is. To answer this, Cortex RP, or Cortex Roleplay, is a game engine in the game Starcraft II, that gives players map editor-like powers and abilities in the form of commands so that they may use them to ROLEPLAY. The word “roleplay” is capitalized as that is the main purpose of this game. Intricate knowledge of commands and technicalities are nice to have, improve roleplay experience, and are covered by this guide, but are in no way, necessary for one to play Cortex the way it is supposed to be played: through roleplay.

By now, it should be known that cortex is a game engine that functions with commands. For those that do not already know, these commands are typed in-game as regular messages would be, but there are specific symbols and structures that are used when typing commands (known as command syntax). As the final part of this introductory section, we will cover 3 basic commands that are vital to just about any roleplay that is done in Cortex: @spawn, @renameall, and @say.

The first command out of the three listed is @spawn. The @spawn command does exactly as what it sounds like, it spawns things, with those “things” being units, structures, some doodads, and more. The command syntax for @spawn is: @spawn (what you would like to spawn) (amount). If this is not clear yet, do not worry, as an example is provided below as well as what the example does when copied exactly as typed (except for the “example:” part).

Example: @spawn marine 24

Copying that without the “Example:” into a chat message will spawn 24 marines. The “marine” can be replaced with the name of anything you would like to spawn, and the “24” can be replaced with any given number you want of the thing you want to spawn. It is important to note that if you’re only spawning one of anything, you do not need to type out “1”. For example, if you would like to only spawn 1 marine instead of 24, simply type out (again without the “Example #:” part) as shown below:

Example 2: @spawn marine

With that done, now try spawning a few things of your own that does not involve marines so you get a feel for the command of @spawn. It shouldn’t take too long for you to understand this command once you get the hang of it as it is one of the simpler commands. When you have done that, continue reading to move onto learning about @renameall which is next.

@renameall is the next command out of the three listed commands vital for any solid, roleplay done in the cortex engine. @renameall is a command that renames a unit type to the name specified. In short, it is a way to change the name of your units to fit them properly for roleplay. It is important to note that unlike @spawn, you must first select a unit or a group of units before you use @renameall since the @renameall command does have to target something, otherwise nothing will be renamed. To test this command out, spawn something as shown earlier with the @spawn command, then select your spawned units/etc. and copy the example below:

Example 3: @renameall Kazuo

This should rename the thing(s) you have selected to Kazuo. You can change the “Kazuo” part to any name you’d like. Before you go ahead and test this command out, there is one technical issue about this command that you must be aware of, which is that @renameall, as stated earlier, renames a UNIT TYPE. In other words, all units of that same type will be renamed to the name you specify. For example, if you did the @renameall Kazuo on a single marine, all marines that you spawn from here on out will have the name “Kazuo”. If you then do @renameall Bob on that single marine, all marines that you spawn from that point on will have the name “Bob”. The name specified in rename all applies to all units of the same unit type. There is a way around this issue which will be discussed and covered later on in the “Basic Commands” section (The next section after the introduction). With that in mind, you may now commence testing and practicing of the @renameall command before moving onto the @say command, which shall conclude this section.

We are almost done with this section, yay! The final command of the three that are vital to roleplays in Cortex, is the @say command. When you have a thing or things selected, typing @say (message here without parenthesis), will cause the selected thing(s) to say that message. Try spawning a marine, selecting him, and then following the example below:

Example 4: @say Hello, World!

This will cause your marine to say “Hello, World!” in the chat. This command is vital for in-character dialogue during roleplays, and also can be used to denote certain actions done by the

character in the roleplay. If, for example, your character in the roleplay has to grab a cup of water, you could do: @say *He grabs a cup of water*, where the asterisks denote an action. This is now going into the style of roleplay you use, which can differ for each person. Some people like to denote actions regularly with @say, so like: “@say He grabs a cup of water”, and then they denote their dialogue using quotation marks within the @say command, like: @say “Hello, World!”. Now try messing around and experimenting with @say.

With that done, you should now have mastered the three basic commands needed to roleplay. If you’d like, you may stop reading here and start roleplaying. The rest of this guide is going to cover things that aren’t necessary for roleplay, but can improve the roleplay experience immensely, and also make things a lot more fun and enjoyable. The material covered by the rest of this guide will go over more commands to modify your units and spawned things to make your roleplay a lot more immersive, as well as technicalities and implications of the cortex engine. The last sections of the guide will be for those who wish to acquire a more advanced and deeper understanding of the game that is essentially on par with what the author (myself) currently knows as of the time that I am writing this guide.

Section 2: Basic CommandsImportant Note (please read entirely before continuing): In this section, @spawn, @renameall, and @say will not be covered as they have been covered by the previous section. It is also important to note that this section and the next will be the longest two sections in the entire guide since there are so many commands that exist in the Cortex Engine, and these two sections make an attempt to cover most of those commands in a manner that is both comprehensive and understandable. As such, the different portions of this section along with next section will be divided into sub-sections that have names that will be bolded in orange to help readers better navigate through the different commands covered, so that if there are commands you already know, you can skip those sub-sections and go to one that covers a command you are not too familiar with yet.

By now, you should have mastery over the basics needed for a roleplay, but the basics by themselves can get repetitive and boring even for the most imaginative players. You will find that it is necessary to add a certain level of depth and immersion into your roleplays, and the other commands really help that a lot. Instead of having to type our descriptions of your characters and imagining them, some of these commands can make the appearance of your imagined characters and settings actually take place in-game, and much more.

Sub-Section: @scale

One of the most important basic commands is the @scale command. This command allows you to change the size of your units. The syntax for @scale is: @scale X Z Y. The

variables X, Y, and Z represent numbers in a direction. To make this simpler to understand, think back to your low level math class where you deal with graphing and coordinates. X, Y, and Z each represent an axis, or in simpler terms, a direction. Just like how the X axis in math goes from left to right, the in-game X variable for the @scale command changes the width of something you spawn. Likewise, the Y variable number changes how great the height of something is, or basically, how tall it is. The middle Z variable corresponds to how long an object is in terms of forwards and backwards. Try the example command below with a select unit(s):

Example 1: @scale 2 1 3

Copying the above example means that your unit/structure/etc. will scale to be twice as large as it was in width, the same amount as it was in terms of length, and three times its original height. Keep in mind that if you want to scale something by the same value across all the dimensions, so for example, if you want to scale something to be 3 3 3, then you do not need to type out all 3 numbers and may choose to type out just one number as shown in the example below:

Example 2: @scale 3

With that done, try playing around with the scale command. You’ll find that you can make something look entirely different just by playing around with the dimensions sometimes.

Sub-Section: @modelswap and searching

The next command this guide will be going over in this section, is @modelswap. The @modelswap command does as it sounds; it changes the model of your current actor. This may sound a bit confusing at first since most of you who are reading this guide will probably have no idea what an actor is. If you truly wish to learn what an actor is, finish the rest of this section and move onto the “Modeling” section where commands such as @attach and @attach+ are covered. As of right now, simply understand and think of modelswap as a command that changes the model of your unit to something else. The syntax for this command is: @modelswap (model name). Try spawning a marine, selecting him, then copying the example shown below:

Example 3: @modelswap barracks

Assuming you did this correctly, your marine is now still a marine in the sense that it moves, behaves, and fires like a marine, but it has the model of a barracks. You can probably guess that you change the “barracks” portion of the command to whatever you want as shown in the syntax.

Earlier, we discussed @renameall and how it had a technical implication in that it renamed all units of a unit type. It was also mentioned in that same section, that a work-around exists for this technical implication through the use of modelswap. The idea behind the work-around is that let’s say you want to have two marines, one named John, the other named Paul. Assuming you spawned both marines and renamed one, you would get the same name on both marines as according to the technical implication of @renameall. You can get around this by making both units being different types. To understand, let’s say you spawned a marine, and then you spawned a marauder. Next, let’s say you select the marauder and modelswap him to a marine. Even though it looks like you have two marines, you don’t. You actually only have 1 marine and 1 marauder that has been modelswapped to a marine. You can now rename one to John and the other to Paul, with both having different names since they are different unit types. It is true that the marauder that has been modelswapped to a marine will behave like a marauder in some ways, such as having a marauder attack, but the animations of the marine model still apply, so all you really need to do is use commands like @removeweapon and @addweapon to remove the marauder weapon and give him a marine weapon. You have successfully just worked-around the @renameall implication, congratulations!

Go ahead and tinker with the modelswap command. One of the most important commands, one which ties directly with modelswapping, is the search command. The search command allows you to search for the names of models, actors, doodads, and more. To use the search command, type out “search (category) (name)”. An example of this is shown below:

Example 4: search model barracks

Typing out the example will bring up search results for any models that have “barracks” in their name. You can also search for things like units as shown by the example below:

Example 5: search unit marine

Just like with the model search, the above example searches for a unit this time instead of a model, and with “marine” in the unit’s name. Typing “search” by itself will bring up a list of the different categories within which you can search. Additionally, typing out “search (category)” only without specifying a keyword or key phrase will basically provide a list of the names of all objects in that category arranged from top to bottom by date added (I believe, not sure on this one). The whole list of names will obviously be unable to fit, so the search function will only load a few names at a time. To scroll down further to see more names, simply type “search” again without needing to specify category and keyword.

Sub-Section: @tint and parameters

Want your unit(s) to look red, maybe blue, maybe green, maybe white, maybe black? Use the @tint command! It is also about time that we introduce the term “parameter” into the scheme

of things so that we don’t have to write out what a parameter represents every time we discuss on commands that have parameters. A parameter, at least in how it will be used in this guide, means something that represents a variable with a changeable amount. For example, in the @scale command, we looked at how the command is @scale X Z Y, where X, Z, and Y represent numbers. In that case, X, Z, and Y are the parameters for the @scale command. They are variables in which you can specify with a quantity or amount that you choose. It should go without saying then, that the @scale command has 3 parameters.

So how does that giant tangent of a mess relating to parameters fit in with @tint? Well the @tint command is also a command that has parameters. In the case of @tint, there are six different parameter values. Most people are only aware of three to five. Very few people actually know that a sixth parameter exists for this command. The syntax for the @tint command is: @tint (red#) (green#) (blue#) (opacity#) (brightness#) (time#). The first parameter, the “red#”, represents the amount of “redness” you want your unit(s) to have. Likewise, the second parameter represents the amount of “greenness” you want your unit(s) to have, and the third being the “blueness”. The red, green, and blue amounts go from 0 to 255. This means that if you type in anything greater than 255 for those values, it will just result in 255 being used. Any value typed in lower than 0 will just result in 0 being used. The fourth parameter is opacity amount or “transparency”. In simplest terms, it is how “see-through” the unit(s) is/are. The opacity parameter is a bit different in terms of value range from the red, green, and blue parameters. The opacity parameter goes from 0 to 1 only. 0 Represents invisible, and 1 represents solid. This means, you will most likely need to be working with decimal values if you want to mess around with this parameter. Before we move on to the last two parameters, this is good time for you to reread through this giant block of text to make sure you understand the first four parameters, and below will be some examples for you to try to see the effects of tinkering with these first four parameters.

Example 6: @tint 255 1 1

This will make your unit(s) extremely red. It is important to keep in mind that if you don’t specify the other parameters, such as how I didn’t specify the opacity, brightness, and time scale parameters, then the engine will automatically assume they are set at default values (meaning that opacity will just be 1 AKA solid, and brightness is standard, with no timescale factor involved).

Example 7: @tint 1 255 1

This will make your unit(s) extremely green!

Example 8: @tint 1 1 255

This will make your unit(s) extremely blue! Keep in mind that a unit’s default, normal color is 255 for red, green, and blue parameters (so 255 255 255).

Example 9: @tint 255 255 255 .3

Is that a ghost? Spooky! After doing the above example, proceed to mess around with these first four parameters on your own with your own values for the parameters. While you do this, keep in mind of how coloring works in real life with how red and blue can make purple, and red and green can make yellow and so forth. This also is true with your tinting. If you specify large amounts of red and blue while keeping the parameter value for green low, you can get different shades of purple, violet, pink, and etc. Likewise, you can also combine this with the opacity value so that your unit(s) with different shades of color is also transparent and see-through on top of it all.

Now that you are familiar with the first 4 parameters of the @tint command, it is time we move on to the last two parameters: brightness and timescale. The brightness parameter has a value range of 0 to 25, with the default brightness of a unit being one. I stated that the maximum brightness value is 25, but there is a possibility that the brightness value maximum could be even higher. The reason I listed 25 as the maximum is due to how I, the author of this guide, have personally never experienced anything with a brightness parameter value greater than 25, meaning that even if such values exist, they do not look much brighter than 25, which is already at a blinding-level of brightness. The sixth and final parameter value for the @tint command, is the timescale value. The number you specify here will be the time in seconds that it takes for a unit to reach the tint you specified. To get an idea of how this works, let us say you spawned a marine. By default, that marine is at a default tint of 255 255 255 1 1 as all things normally are. If you want that marine to be sort of a bright, blue, ghost marine, you could try tinting it to 1 1 255 .3 5. That would instantly tint the marine to that tint you specified; however, if you instead did 1 1 255 .3 5 3, which has a 6th parameter of 3 seconds, that means it will take the marine 3 seconds to reach that tint of 1 1 255 .3 5. The number you put in will always be in seconds for the sixth parameter of @tint. All commands that exist with time-scaling/time parameters involved use seconds and not minutes or hours or any other unit of measurement for time. It is now time to try out some of the examples which will be shown below:

Example 10: @tint 255 255 255 1 .5

Woah, that looks pretty menacing with how shadowy it is. I’m scared!

Example 11: @tint 255 255 255 1 .5 4

Same tint as previous example, just takes 4 seconds to get there. After this example, trying doing your own tints with your knowledge of all 6 parameters now.

Well done! You have mastered the @tint command fully. The next sub-section will cover multiple commands at once, but do not worry; the commands covered have been grouped together into one sub-section due to their simplicity and ease. You’ve done well making it this far, and there are only 3 more sub-sections to go before this entire section is concluded. It is important to note that not all of the basic commands that exist in the game are covered by this guide, as some of the commands simply aren’t that useful (at least I don’t think they are). If you would like to learn more about such commands, you may either attempt to open up the in-game commands guide and attempt to learn from that, or you may add me in-game and we can go over them.

Sub-Section: Removing Things

If all you could do was only spawn and modify things in this game, you’d end up having a bunch of units that cover the entire map. As such, commands that remove things seem trivial in that they aren’t overly complicated, but they are definitely important to know.

If something you spawn is a unit or a structure, chances are, it can be killed. To kill something, simply select it and type “@kill”. Killing things works alright, but sometimes, killing something will create a stain. A stain is some residual death model, texture, or animation-like thing that is left behind after a unit dies. This is due to how the starcraft 2 engine was made in such a way that when something dies, while the main model of the thing will disappear, it may spawn a death model or something along those lines to take the place of the original, and some of these death models and such cannot be selected. Knowing this, the @kill command, which causes a unit’s or structure’s death, may not be the best thing to use but can still be done on some units and structures spawned. The safest way to remove something is usually by @remove. To use @remove, simply select what you wish to remove and type in “@remove”.

“OMG A STAIN! WHAT DO I DO?!!!” If someone (either you or someone else) has indeed created a stain, there is still a chance it can be removed. The thing about stains is that they are sometimes just objects that are removable but cannot be selected. In situations like these, you need to use the @removearea command. The removearea command will remove everything that is not a doodad from a specified area size. The command syntax for removearea is: @removearea (size of area). An example is shown below:

Example 12: @removearea 15

Following the example above will remove every non-doodad and non-terrain object within a 15x15 map tile area size. The area that is targeted will be the area that is directly under your mouse or spawner. Default, standard map boundaries are 256x256 tile size, and as such, @removearea 256 will remove every non-doodad and non-terrain thing from the map that you have privileges over if you were to do this with your mouse cursor or spawner at the center of the map, as the mouse cursor or spawner denotes the center of the area that is to be removed of non-doodad and non-terrain objects. This means that you have to be especially careful with this command if you are admin or moderator (both of which will be discussed more thoroughly in the “Host Commands” section) as admin and moderators have privileges over normal players’ units even if they aren’t in direct ownership of the units.

Sub-Section: Doodads and Regions

You’ve probably played a standard starcraft 2 map in multiplayer or single player; if not, please do so right now (before we murder you). In a standard map, the trees, vegetation, along with things like walls and objects that are built into the map are all mostly un-selectable, and do not show up on the minimap. At this point, you’ve probably tried your hand at making something like a landscape in cortex, by spawning and modelswapping trees and vegetation and such. Despite those objects being seen as trees and vegetation, they still appear on the minimap and selectable, unlike the map’s preloaded trees and vegetation. This is where the doodad commands come into play.

Doodad commands allow you to make trees/vegetation/etc. that behave as if they were part of the preloaded map (meaning that they won’t be selectable, nor will they be seen on the minimap). Commands that involve doodads will usually differ from the “@” commands in that instead of using an “@” in front of the command name, an underscore “_” will be used. A list of the doodad commands has been provided below:

1. _doodad (model name)2. _removearea (size)3. _scale (X Y Z)4. _select5. _remove6. _destroy (Size)7. _tint (Red# Green# Blue# Opacity# Brightness#)8. _face (degrees)

9. _modelswap (model name)10. _animspeed (amount#)11. _height (amount#)

First on the list is the _doodad command, with an example of how to use the command being provided below:

Example 13: _doodad dynamicgrassendion

Following the above example will cause a highly transparent dynamicgrassendion model to appear under your cursor. This transparent model will follow your cursor, and when you click on a location while the model is following your cursor, you will spawn the dynamicgrassendion model to spawn on the location you clicked, with the model spawning as a doodad., with the model spawning as a doodad. A doodad, which is spawned using this _doodad command, differs from something spawned with the @spawn command in that the @spawn command spawns actors, whereas the _doodad command spawns models as doodads (objects in the map which aren’t selectable normally, and do not appear on minimap).

Sub-Section: Host Commands and ??Omega??

Sometimes, you will find yourself as being the creator of a Cortex in-game lobby, putting you in the position of host. Being the host of a cortex lobby will usually make you the in-game admin. As admin, you get access to special admin commands when in-game, denoted by the “!” at the start of the command(s) unlike the regular “@” commands.

Before we continuing going over the many different admin commands, it is necessary to understand the technical implications of admin, in particular, how one becomes and is qualified to become admin. Some people, especially the newer and/or more inexperienced players, believe that admin is granted simply by being the host of a lobby. This is incorrect. Simply because you are the host of the lobby, does not mean the in-game engine will recognize you as host of the lobby. The person who creates the lobby however, is guaranteed to become admin. This means that if you create a cortex lobby, leave the lobby to make someone else host, then rejoin the lobby, when the game starts, you will retain your status as admin. Likewise, if you create a lobby and promote someone else to lobby host, when that game starts, you will retain your status as admin in-game. Now, if the creator of a lobby leaves the lobby and doesn’t return, when the game starts, the person selected to be admin should be random (at least as far as I am aware, not 100% certain however),

As admin, you get access to admin commands and also to higher permissions. Higher permissions mean that you can control certain things in regards to other players as well. An example would be the @remove command which removes your selected objects. Normally, as a normal player, you are allowed to remove things that you own, but not the objects/things owned by another player. As admin, this is no longer true, and you can apply @remove on everything that you can select regardless of who owns the selected things. Essentially, all unit modifying commands (the @ commands) can be done on other players’ units when you have admin privileges.

As mentioned before, there are many commands which are only useable by admin. The first that we will be going through is !seeall. The !seeall command reveals the entire map, and is done by following the example below:

Example 13: !seeall

Typing this command will reveal the entirety of the map, and re-entering it will hide the map. In most lobbies, people will expect the host the use this command and reveal the entire map the moment loading screen finishes and everyone is in-game.

The !secure command is another command that most people in a lobby will expect a host to do the moment everyone is in-game. Much like with seeall, you simply type “!secure” (without quotations of course) to disable secure. The reasoning for doing this command is that many other commands cannot be used until secure is turned off. Some of the commands which rely on secure, such as gamesetup commands and replacement commands, are very useful to have when setting up for a roleplay; as such, secure is usually expected to be turned off right at the start of the game. Doing !secure again will re-enable secure and once more prevent the commands that rely on secure being off, to be unusable.

The admin commands are fairly straight forward. Some of the other admin commands not yet discussed are as listed below:

1. !remove (color) 2. !disable (color)3. !enable (color)4. !promote (color)5. !demote (color)6. !light (name)7. !sound (name)8. !ban (color)9. !fruit (amount#)

The (color) part in each of the commands in the list refer to the targeted player’s color. This means that you put in the color of the player whom you want the command to apply to. The !remove command will remove all the units belonging to player whose color you specified (no parenthesis obviously). The !disable command will prevent a player from talking (muting) and will also remove that player’s ability to use commands, while the !enable command will do the opposite by letting a player talk and use commands again. The !promote will allow the admin to promote players into moderators which have more privileges than a normal player, but not as much as admin does. A moderator can ban, remove, enable, and disable normal players, and can also apply the @ commands to the units of other players who aren’t moderators or the admin. !demote is the opposite of !promote, and reverts a moderator’s status to a normal player. The !light command will change the lighting of the game to the lighting name that you specify. You can search for lighting through “search light (name)”. !sound plays the soundtrack’s name that is specified. The !ban command will allow a host or moderator to kick a player from the game. The !ban command cannot be used to kick yourself or anyone with moderator privileges unless you are admin (and admin can’t be kicked by anyone). If an admin decides to leave in-game, a random player will be promoted as the new admin unless there are moderators. If the admin promoted someone to moderator and leaves game, the moderator will become the new admin. If there are multiple moderators, one of the moderators are randomly selected to become admin. The final command in the list above is a fun one. The !fruit command will cover the entire map in the amount of fruit that you specify (a number value). To completely remove all fruits, simply do !fruit off.

What the heck is Omega? That is a question a lot of people ask after looking at a list of in-game commands from the commands guide. This command is more or less, unusable at this point, so you can more or less skip this final part of this section and move onto the next unless you’re curious. The omega command is a special command that is coded into the engine to be usable by only a list of people, all of whom (that I am aware of) no longer play cortex, meaning that it is high unlikely you will see this command being used unless you are playing with the creator of a map on his own map. Onto what the command actually does, the user who has access to it and uses the omega command, will become the new admin while demoting the current admin. You can easily see why this command was only given access to a select list of players. Map makers who understand coding can code their own profile IDs into the list of people allowed to use omega, essentially creating a slightly modified version of the engine that is on their map, allowing them to use omega on their map. The specifics of how to do this are ones that I, myself, am not too entirely sure of, and is more considered a part of map-making rather than a part of how to play cortex; hence, it will not be covered in this guide.