Understanding Kode for those who have never coded

By Invisible Doogey
Created: 8 Apr 2014
Copied from Wayback Machine

You know how Team Dakota and even people like me say getting the hang of brains and kode in Project Spark is easy? Well if you’ve never played around with a coding language, we’re lying to you.

Don’t get me wrong, out of every variation of coding languages out there, Kode is the easiest to grasp. But for a non-coder that’s a bit like saying Dutch is the easiest foreign language you can learn. It still requires a few volumes of Rosetta Stone.

This blog post will try to tackle this exact problem. How to give someone who hasn’t played around with programming languages before some intro knowledge to grasp Kode’s concept. So if you already understand Kode well and are just having issues with one or two tiles, move along, this blog post won’t be for you.

For those of you still here, let’s get started (*closes classroom door and laughs maniacally*).


Before we get into the major kode concepts, make sure you’ve played the tutorial level on Project Spark. I am never a fan of tutorials, but the one in Project Spark is actually very good and necessary to help you learn the controls and the components of the game. It’s not good at teaching you concepts, but it will make you familiar enough with brains and kode to understand what I’m covering here.


The whole concept of WHEN/DO is something that coders like me know well. It spans all program languages. Ever since the evolution of coding languages in the 1950’s, the concept of “when” and “do” became integral concepts of code. They’ve been called and combined with other words like “if,” “while,” “until,” “else” and “for,” to name a few.

All of this extraneous info is just to illustrate that these are the buzzwords code was built on. Project Spark is trying to simplify all of these different buzzwords that coders are used to into just two. WHEN this happens, DO that thing.

These commands in code are used to tell a computer system what to do, how to do it and when to do it. Code is a computer’s instruction manual. And code is a wondrous thing that lets us (in a way) bring machines to life.

Similar to that Skynet metaphor, Kode is what brings all of the characters in Project Spark to life. Besides the effects props, if you place an object in the world with nothing in its brain, it will forever do nothing. You are creating life when you add kode. Let’s use this oversimplified kode as an example below. Note: don’t actually use this kode in your game, because it’s bad and just for the sake of illustration.

At this point there was some kode. I dont know what it was but I am going to assume it was something like this:
WHEN [detect][player] DO [attack][it]

That one line there suddenly gives your object a purpose. You have given it instructions and now it knows that it is not supposed to like your player.

But let’s break this down even further, splitting up the two side. First the WHEN side:

WHEN [detect][player] DO

By itself, this one line of kode is constantly checking if that object detects the player. It doesn’t do anything when it detects the player, but it keeps checking regardless. This is because you have told the object, “Hey, keep an eye out for the player and let me know when you detect them.”


“Don’t worry about it, I’ll tell you later.”

“No, seriously, why?”

If you don’t tell it why, it’ll keep asking why, just in a mute voice that you won’t ever have to pay attention to. And the why here, is the DO side of Kode:

DO [attack][it[

By itself, this line of kode wouldn’t work, mainly because the [it] isn’t defined (“it” refers to whatever object you have on the WHEN side of the Kode). But let’s just pretend that instead of [attack][it] we had [attack][player]. Without anything set on the WHEN side, the object has no idea when they’re meant to do something, so they just always do it. That means no matter where you or this objet are, it will immediately start attacking you (even if it’s halfway across the map).

So a DO can function without the WHEN side of the kode, it will just always function. A WHEN side can also technically function without a DO side of the kode, you just wouldn’t be able to tell the difference. But together they make something function with context. And without context, you can’t give your characters instructions to create your game.


Let me beat WHEN/DO further into your head with one additional example.

Say in your game you want to have a sneaky little goblin who becomes invisible once you get nearby. The goblin then sneaks up on your character and launches into a surprise attack. In order to figure out how to create this sneaky goblin and make them follow their sneaky ways in Project Spark, you need to be able to translate all of those things to Kode. This means you need to figure out how all of this is broken down on the WHEN and the DO side of Kode.

Here is how the general thought process might go:

  • That first statement needs the goblin to turn invisible. Becoming invisible would be something it DOES.
  • It only becomes invisible if the player gets close, or WHEN the player gets close.
  • WHEN the player is also close, the goblin would move towards the player (that’s another DO).
  • WHEN the goblin gets right up to the player they need to not be invisible anymore.
  • WHEN the goblin is still super close, they would then DO an attack.

Okay, now break that into words that are closer to Kode:

  • WHEN the player is close to the goblin, DO it turns invisible
  • WHEN the player is close to the goblin, DO it moves towards the player
  • WHEN the goblin gets very close to the player, DO it becomes visible again
  • WHEN the goblin is still very close to the player, DO it attacks the player

Now all you need is to find the tiles of Kode that correspond with these actions. Of course, finding the right Kode that achieves what we’ve written above is difficult in its own rights. But understanding how to translate actions into WHEN/DO is much more important to understand than the right tiles to do that.

Here is what that final product would be translated to.

Again. There was some kode here, that the Wayback Machine does not recognise (probably Kodeshare). But here is some kode that I think may do the job.
WHEN [distance to][player][less than or equal to][10] DO [visible][equals][false]
…WHEN DO [move][toward][it]
WHEN [distance to]player][less than or equal to][3] DO [visible][equals][true]
WHEN [distance to][player][less than or equal to][2] DO [attack][it]


As alluded to in my example Kode above, something you may have heard when others talked about kode are child lines and parent lines. The basic premise is a child line is an indented line and a parent line is the line that it is indented under.

WHEN [detect][player] DO
…WHEN [it][health][less than][50] DO [move][towards][it]

When working with parent and child lines, the parent line runs as normal, making the object move towards you when it detects you. The best way I can describe the child line is a little 5-year-old asking the question “and this too??”

Line 1 will always run as intended. But if the WHEN of line 2 happens to be true (the objects health is below 50), then that line will run once the object detects the player. This allows you to give a child line more than one set of rules. Here it has two set of rules that check to see if it is detecting the player and if its health is less than 50.

The other nice thing about child lines is they can let you accomplish two DO’s when a WHEN is met. For instance, if you removed the WHEN from line 2, as soon as the object detects the player it would move towards the player and also move super fast.

Understanding and using child and parent lines are very effective in making a number of commands execute at once or only under multiple instructions.


A key function of the brains in Project Spark is its pages system. You could put kode on one page, then use the [Switch Page] tile to switch to the next page and activate that kode.

But wait, why do you even need to switch pages? Why can’t you just put everything on one page?

The best example I can think of is let’s say you want your character to activate a flight mode in the game. When they’re not flying, the left stick on your controller would cause them to move like normal. But when they are flying, the left stick on your controller would cause them to move “With Flying.”

You can try to have these two different lines of Kode together on the same page, but they won’t work together. Since your character is reading everything on the page and trying to execute it all. And if two things conflict with each other, the player will either choose just one or spasm between the two like an indecisive rabbit.

Each new page of a brain is very close to being an entirely new brain itself. When you switch to a new page, your player is scooping out 90% of their current brain and replacing with a brand new one. What is that extra 10% untouched by the switch? That would mainly be any variable (number, object, Boolean, etc.) you’ve already set.

Simply have this line of kode and your Y button would “activate” your flight mode:

WHEN [button:Y][pressed] DO [switch to page][2]

The biggest benefit of Project Spark’s pages system is the fact that it makes it very easy to switch between a variety of different player “states.” Not many of the other game mechanics (except the variables) you set previously carry over here.


The last Kode concept I’m going to tackle here is the “else” tile that you can use only for child lines (found on page 2 of the timing & logic tiles). Else is important because it’s another major language piece of Kode. In my opinion, only secondary to WHEN/DO.

First, let me show you an example of the Else tile and then we can walk through it. Again, this is super basic for explanation purposes.

WHEN [detect][player] DO
…WHEN [it][health][less than][50] DO [move][towards][it][speed][0.15]
…/…WHEN [else] DO [move][west]

We have that same line 1 we had when we were talking about the parent/child concept. But now we have a new child line and it starts with an else. And whatever that heck that else is doing, that would make the object move west in the world.

Else is a tile that looks up at the parent WHEN tile above it and says “Hey, when you’re not doing your thing, I want to do something.” That is how it works. When the object detects the player, it moves towards the player. But when the object is not detecting the player, that else line on line 2 tells it now it needs to walk West.

The “Else” command introduces us to a two-sided coin logic. When you flip the coin, something happens no matter what side it lays on. Either your initial WHEN is true, or your ELSE is true.

That’s it for some basic concepts on Project Spark and its kode to help you wrap your head around things. If you have other general questions about Project Spark’s Kode system, drop them in the comments below. There are no stupid questions!


Comments are closed.

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: