We are often asked how certain Computer Science concepts map to GameSalad features.
Throughout our tutorials we help explain these concepts, but as an instructor you may not have time to go through all of the tutorials. Or, you may not be using the tutorial that explains a particular concept as part of your class.
This document is meant to help familiarize you with how Computer Science concepts map to features in GameSalad.
Summary sections assume a greater familiarity with the computer science concept in question and are meant to help you quickly map Computer Science concepts to their implementation in GameSalad.
Detail sections provide more computer science background information for those less familiar with the concepts or are just curious what is going on behind the scenes in GameSalad.
We are constantly refining this document, so if any of our explanations are unclear, feel free to reach out and ask us about it!
Summary: In GameSalad, Variables are called Attributes
Detail: Variables are a label in code representing a spot in the computer’s memory holding data. They can represent the data itself or hold a pointer to another spot in memory that holds the actual data. Variables are called such because the data they represent can be changed but keep the same label.
Often items in a program are organized into objects (as in object-oriented programming). When variables are attached to an object they can be called a number of things: members, properties, or attributes. Since all things in the GameSalad system are “objects” (including the game itself), we decided to call all variables “attributes”.
Summary: GameSalad supports a number of types, some common to other programming languages, some unique to GameSalad. Text Variables are Strings. Real Variables are floating point numbers. Angle and Index values can usually be ignored unless the programmer wants to use them to help future programmers understand the purpose of the variable.
Detail: You usually need two things to define a variable in computing, a name (the label) and a type (does the variable point to a number, text, etc). Type information is important because the computer stores everything in binary as 1s and 0s, so we need some extra information to tell us whether those 1s and 0s represent an integer, a floating point number, or a character.
Attribute types in GameSalad include:
boolean: a value that can be either true or false.
text: a value that represents text. In many programming languages, this is called a “string”
integer: a value that represents an integer, a positive or negative whole number with no decimal places.
real: a value that represents a real number, a number with decimal places. In other programming languages this is also called a float (for floating point number).
The following types are unique to GameSalad and are mostly there to help indicate to the programmer the purpose of the attribute. In older versions of the software we even used them to help indicate to the tool display different specialized editors for these types.
angle: this is unique to GameSalad and represents a real number between 0 and 360 degrees. GameSalad will accept any real number value as an angle and this type is mostly used to communicate to the programmer and future programmers that this number is intended to be an angle.
index: this is an integer greater than 0. GameSalad will currently accept any integer in this field, and it’s mostly used to indicate to the programmer or future programmers that the value is meant to be an index into another value. In lua, the language that underlies GameSalad’s engine, array indexes are 1 bases (i.e. they start at 1 instead of 0). So index values should only be positive integers.
Summary: Variable Assignment is accomplished via the Change Attribute Action or the Constrain Attribute Behavior
Detail: As we noted earlier, variables can be changed. Sometimes variables can be changed via system events, like the game.time attribute which is updated automatically to match the current game time in seconds or an actor’s x and y position values while it’s moving. Sometimes it’s updated by code by using the Change Attribute Action or Constrain Attribute Behavior.
Change Attribute changes the value of the target attribute once per context. If it’s at the root of an actor’s behavior list, then it executes after the actor is created. If it’s inside a rule, it executes every time the rule’s conditions become true.
Constrain Attribute runs all the time when it’s active. It’s used to “constrain” one attribute to the same value as another attribute. Every time the target value updates, the constrained attribute will update too. This is useful for things like having an actor mirror values between actors.
Summary: Game Attributes are like global variables. Actor Attributes are like local variables.
Detail: In early programs, every part of the program had access to every variable. This would often lead to confusion as different parts of the program might change variable values unexpectedly. To reduce this problem, programming languages introduce the concept of scoped variables, limiting how they can be accessed. GameSalad doesn’t have variable scopes, but the way attributes work provide an analogue for scoping. Game level attributes could be considered “global” variables, as they are accessible by any actor in the game. Actor attributes would be considered “local” variables, as they are only available from logic inside the same actor instance.
GameSalad lets you organize data in two ways.
First as part of an actor using actor level attributes. They can be thought of as structs or objects.
Second as part of a table. Tables are much like database tables, they have rows of columns. Each column can be of a single type. We provide functions to retrieve data from tables. You can think of a single column table as an Array and a multiple column table as a multidimensional array or an array of objects.
While you and your students will naturally discover how to organize attributes in GameSalad, tables are a more powerful feature we’ll go into in more detail.
A fundamental concept of computer science is that of Data Structures. Data structures are common ways of organizing collections of data to make them easy to reason about both in the process of programming and with mathematical rigor. The study of data structures is often linked to the study of algorithms as most algorithms are dedicated to searching, sorting, and manipulating data in different structures.
GameSalad tables are a 2 dimensional data structure that is made up of columns of value and you can have multiple rows. They’re similar to database tables where each column of a table consists of values of a single type.
You can use tables to represent many different data structures in computer science:
Arrays are often considered the most basic data structure of computer science. An array is simply a list of items stored contiguously (right next to each other) in the computer’s memory.
So a single column in GameSalad can be treated (and under the hood is implemented) as an array.
Data in an array is accessed by “index”, an integer representing the nth item in the array. In most languages the 0th item in the array is first (though in GameSalad, because it’s using the programming language under the hood), the first item in the array is 1.
The value of an array is in its simplicity. Because every item in an array is the same “type” the CPU can quickly access any value in an array by multiplying the size of the item by the index and adding it to the memory address of the start of the array.
Maps, Dictionary, or Associative Arrays are names for a type of data structure where data is mapped from one value (a key) to another (a value). We’re gonna call them Dictionaries for now. The name Dictionary is the most illustrative description of this data structure. The words in a dictionary are the “keys” and the “definitions” are the “values”. They’re also called map cause you can think of them as providing a mapping from one set of values to another! While they’re usually implemented very differently under the hood you can think of an Array as a Dictionary whose keys are integers!
As we noted above, arrays can access data very quickly because they only require simple arithmetic to calculate where in memory to look. A Dictionary requires us to search through the keys (think about flipping through the pages of a dictionary) and the keys are often themselves stored in other specialized data structures for faster searching! But for most introductory lessons all you need to know is that dictionaries let you look up one value using another value in a relatively fast and memory efficient manner.
GameSalad Tables can simulate a dictionary by using the “label” columns and row. Every table has a special column and row called that “label” column. These label fields can be used as the “key” to the dictionary, and the data column can be the “value” that the key points to!
Data Structures in your Data Structures!
You can even combine these concepts to create compound data structures!
A multi column table can be:
- An array of arrays.
- An array of dictionaries
- A dictionary of keys pointing to arrays
- A dictionary of dictionaries (row labels pointing to columns with each column having labels pointing to values).
Summary: GameSalad Rule Behaviors can be thought of as IF / THEN / ELSE or WHEN / DO / OTHERWISE conditional statements.
Detail: Most programming languages have if/then or when/do (or do/when) statements. These are conditionals that let you control the flow of your program.
You usually introduce them to your students using IF / THEN / ELSE statements. While we phrase GameSalad Rules as IF/THEN/ELSE statements for familiarity, they are probably better thought of as WHEN/DO/OTHERWISE statements when debugging. WHEN the conditions evaluate to true, DO some things. OTHERWISE do something else.
Because they are always “running”, rule statement work as follows:
When any attribute referenced in the conditions change, the conditions are re-evaluated. If this changes the value of the conditions in aggregate to true, then the actions in the block will be run once and all the behaviors will be activated. If they change to false, all the behaviors will be deactivated. If the condition becomes true again, all actions will run again and all behavior will activate.
Summary: Conditions evaluate to true or false. When using ‘Any’ for a group of conditions, it’s like using OR between all the conditions. When using ‘All’ for a group of conditions, it’s like using AND between all the conditions.
Detail: In most programming languages you can do complex boolean logic between your conditions. GameSalad, for the sake of simplicity, only has two ways to evaluate a set of conditions: All and Any.
When set to All, the code in the then block only activates when all of the conditions are true. This is like putting an ‘AND’ or a ‘&&’ between conditions in most programming languages.
When set to Any, the code in the then block activates if any of the conditions are true. This is like putting an ‘OR’ or a ‘||’ between conditions in most programming languages.
Summary: The Loop Over Table behavior is an Iterator / for-each loop. It loops over every element in a table row or column. Loop behavior is a while loop. It runs the actions in the loop while a given conditional statement is true. Loop behavior should only contain Actions and not Behaviors. GameSalad does not currently support nested loops explicitly, but a clever programmer can figure out how to implement something similar.
Loops are one of the most important control structures in programming since they help you do what the computer does best, repeat the same task over and over.
There are two loop behaviors in GameSalad: Loop over Table and Loop.
The Loop Behavior is a conditional loop, one that will run the contained code until a set of conditions is met.
Usually you want to have an attribute that is changed over the course of the loop. Often this is a value that increases for every loop iteration and ends the loop when the value becomes greater than a test value. Imagine if you want to run a loop 10 times. You set an attribute to a value of 0 and every loop iteration you add one to the attribute. Once the attribute’s value is 10 you stop the loop. Or vice versa where you start at 10 and subtract one from the attribute every iteration until it’s value is 0!
In theory a loop can run forever (or at least until the program is closed). Sometimes this is desirable (like in an operating system or game engine event loop). Sometimes this can be dangerous (a loop that runs too many times and ends up accessing data it shouldn’t).
Loop Over Table is often called an iterator in other programming languages or a “for each” loop. The Loop Over Table is guaranteed to run the instructions contained in the loop once for every value in a table. This is helpful when you 1) don’t know the size of a table ahead of time and 2) you want to be unambiguously sure the loop will only run once per table row.
The reason many programming languages implement an “iterator” construct is to ensure the program will safely access data. Remember how we said earlier that arrays are accessed as an offset from the beginning of an array? If the program is accessing each value of an array in a loop but runs one time too many, it may access undefined data after the end of the array!
GameSalad Loops and Max loops / frame
One thing to note that is not common to most programming languages is the Max loops / frame settings. This is because all the loops in GameSalad are themselves running inside a loop.
GameSalad, as a game engine, is always running in a loop as fast as 60 times per second GameSalad:
- Updates attributes linked to the system or to hardware input.
- Updates actor positions based on the physics engine Box2D
- Evaluates Rule conditions.
- Runs code for all newly active actions.
- Runs code for all active behaviors.
- Updates what is displayed on the screen.
The thing about game engines is, if the code in the loop takes longer than 1/60 of a second, then it delays the next iteration of the loop. If the delay happens too often, the game will appear to stutter. We allow the tweak of loop iterations per frame to allow the programmer to adjust for delays potentially caused by their loop logic. If there are very few instructions in a loop, then you can set the value higher so that it runs more iterations of the loop before rendering the frame. If you have a lot of instructions inside a loop, you may only want to run the loop fewer times per game frame, to ensure the execution fits inside the ideal 1/60 of a second and to avoid causing the game to stutter.
Summary: GameSalad does not support creating new functions. But by using actors in a Function Object or Command Object pattern, a GameSalad coder can simulate a function.
Functions are a core computer science concept and are used in programming to encapsulate programming instructions into smaller chunks. A well written function has several benefits:
- Breaks code into smaller chunks, making them easier to think about.
- Allows common sets of instructions to be easily reused.
- Avoids unintended side-effects by working only with the data it needs.
GameSalad does not have the ability to create functions as most programming languages do. Students will learn to use existing functions inside of expression in a manner akin to traditional text based programming.
There is one way students can simulate functions using a programming pattern called a “Function Object” or “Command Object”. The idea is to create an Actor that contains only Actions or Loops. The actor then does the following:
- If the function has arguments, use Change Attribute to copy the values of arguments from the input game level attribute to similar actor level attributes. This frees the arguments to be used again by other instances of the actor.
- Perform desired logic using Actions or Loops.
- Set the result of the function into an output game attribute or table row.
- Destroy itself.
This allows students to encapsulate their logic (encapsulation) and allow them to reason about what they want their code to do in a smaller context. When they want to “call” the function, they just need to create the actor. The actor will do its work, saving the result, and destroy itself.
Because actions are executed in the order they appear in the behaviors list, this also lets them break up logic into multiple Change Attribute Actions, making each change to a given attribute easier to think about.
Object Oriented Programming
Summary: GameSalad Game, Scenes, and Actors are objects. Attributes are properties / member / fields. Actors are the only programmable objects and effectively have one method containing behaviors. GameSalad has a version of prototypical inheritance, actors are prototypes and when they are dragged into a game, they become instances, inheriting the prototype’s behaviors unless overridden by the user via (unlock). GameSalad has no equivalent to ‘super’ or ‘base’, i.e. no way to call the parent functionality when the behaviors are overridden.
Detail: Object Oriented (OO) Programming is the practice of organizing code into classes of objects that combine data (i.e. members, properties, or attributes) and related functions (methods).
Objects can be analogues of “real” objects represented in the game, groups of related functions, or even a way to encapsulate a single large function.
GameSalad has 4 types of “classes” to works with:
The Actor Instances.
When thinking about things in OO you can have classes: the definition of something in code and instances, the actual instance of the object that is in memory at runtime.
There is another name for class in some languages: prototype. There is actually an under the hood difference between a class in a classically OO language and a prototype in a prototype oriented language. But, for now, think of a GameSalad prototype as synonymous with class. Actors that are defined in the Actors tab are usually called prototypes.
When a programmer creates an actor in the Actor in the GameSalad library, they are defining a prototype. When an actor is dragged into a scene, an instance of that actor is created. When the game starts, the instance will start with the same functionality and data as the prototype.
Except when a user breaks the link with the prototype by unlocking the behaviors or attributes. When an instance is unlocked a copy of the prototype’s behavior is made. Any subsequent edits to the instance’s behaviors will override the prototype’s behavior effectively making the instance different.
If you see a student complaining that they are changing an actor, but the change isn’t being reflected, then check to see if the misbehaving instance isn’t unlocked.