Intro to Coding Fundamentals

Coding as a language

When you first look at code it can be quite a confronting experience. It’s full of arcane symbols, it’s almost like english but different enough to enter a sort of language uncanny value, your eyes sometimes seem to glide over it without being able to focus on any one thing in particular…

In many ways, learning to code is both learning a new language and a new mode of thinking. So I’m writing this Fundamentals of Code series (of which this is the first entry) in order to try to make that transition a little easier and more pleasant.

We’ll start with the very basics for Fundamentals of Code I, and slowly work our way up the complexity chain. Learning to code is an active task. You need to learn the theory, engage in actively writing it and go through repeated exposure in order to properly absorb it, so consider this series a companion guide to your own experiments.

The more code you write, test and read, the quicker you’ll learn, so I encourage you to branch off with your own experiments as you learn concepts.

Learning to code is exciting, frustrating, englightening and maddening, so don’t worry if you find it difficult. Everyone does! It’s a lifelong rewarding journey where there’s always new peaks to scale.

With all that being said, let’s begin!

Values

Code, at the very core of it, is all converted into binary values, either a 0 or a 1. But in higher level languages, like GML, we get to pretend that it’s a bit more flexible. So instead of everything being binary, we have a few different “types” of data we can represent:

Strings > “Hello”, “gun”, etc Real numbers > 100, 52.5, etc Booleans > true / false Arrays > Essentially lists Structs > Little data packets

And so on. So if we are setting the position of something, we’d want to use a real value, not "100", but 100. If we wanted to represent a name, we’d use a string, not Paul, but "Paul".

Variables

Once we have types of data, we need to store them somewhere. That’s where variables come into the picture.

A variable is simply a storage container that holds some data that can vary over the course of the execution of the program (vary > variable). This is is contrast to a constant, which is a similar concept, except the value cannot change, it’s fixed to a single value for the execution of the program.

In order to use a variable, we must first “declare” it. In GML, this is as simple as assigning it a value with the equals sign:

my_hp = 100;

There we have created a variable called my_hp and assigned it the real number 100. We’ve declared the variable, in other words. In GM, some variables come “pre-declared” by GM itself.

Variables like x and y are automatically declared by GM, so we don’t need to declare them ourselves. But, like in the case of the my_hp variable, there’s plenty of times when we’ll want to create our own little packet of data that GM hasn’t automatically setup, and so we simply declare them ourselves.

Code flow

Code executes in order from top to bottom. Essentially, it’s an ordered list of instructions. This is often known as the “flow of the code” or “code flow”.

One line executes, then the next line executes, and so on.

x = 100;
y = 100;

In that set of instructions, first x is set to 100 and then y is set to 100. The two don’t happen in parallel, they happen sequentially.

This might seem a little obvious, but all too often I see beginners make coding mistakes where they have incorrect ordering of instructions according to the flow of the code.

hp = 100;
hp = hp + 50;

In order to be able add 50 to hp, we first have to have declared it and assigned it a value. So the code has to flow in this particular way in order to be correct: declaration first, modification afterwards.

One final note for this lesson: You might have noticed a lot of semicolons ; at the end of each line. This is essentially code “punctuation”.

A semicolon ; ends a statement, and a statement is basically one complete instruction. So

x = 100

Is the statement (a complete instruction), and to let the computer know “Hey, we’ve finished with this instruction, the next text will be a part of the next instruction”, we cap it off with a semicolon.

x = 100;

It’s almost exactly the same as how we use a full stop to denote the end of a complete sentence, so that readers know the next text is going to be a part of the next sentence.

GM will usually let you get away with not using semicolons, but it’s far better code design to include them (and there are certain situations where not including them will cause bugs, so better to get into the correct habit from the start).