Haxe programming : step one

This is a series on learning to create something without any prior knowledge of programming whatsoever.

I will (hopefully) be helping you understand how to go from no programming knowledge, to being able to make things on your own.

Assumptions...everywhere.

Many programming tutorials will start with the basics... for a programmer. They start with teaching the first steps - usually for someone transitioning from another programming environment.

What most of these tutorials fail to accomplish (and a difficult task for sure) is teaching somebody to understand what these things mean. You can show somebody a hundred pieces of code snippet and they will never remember much of what it was because they literally have no idea about what any of it means.

The words, lingo, and (obviously) the code is heavily laden with a swathe of terminology, meaning and concept that is assumed knowledge.

For the majority of tutorials this is fine, and works great.

Though, I wanted to try the other approach, the kind where the programmer is non-existant and I have to explain what everything is, means, and it's purpose in plain words before assuming anything past that they can read english, and understand basic logic.

Series information

  • I make video games for a living, I will frame all examples and ideas in this light, unless necessary for explaining otherwise.
  • I want people to be able to express themselves, through creativity, output through programming and exploration.
  • I might take liberties with complex concepts for the sake of clarity.
  • If you already know what something is or what a term means, gloss over it. There are other's that want to learn.
  • I love learning. I love teaching. This is an exercise in both.
  • Feedback, failings, suggestions and ideas are welcomed.

part one

“Programming?”

What the hell does programming mean anyway?

Programming is actually a shortened version of computer programming, it's about the fact that computers run programs. These programs, also known as applications, games, executables or whatever you want to call them - are often made by a person or team of computer programmers.

So, programming is simply the act of creating a program or application or game, so that a computer can run it.

How do you create a program, like a game?

A program is not a whole lot more than a list of instructions for the computer to do. Move the player. Copy a file. Change the brightness of a photo. This list of instructions is called program code or just code for short.

These instructions tell the computer what to do, and very often it is the job of the programmer to tell the computer how to do the instructions as well.

new term : “code”

Code is the list of instructions that a program is made out of, usually stored in files, and often called “source code” because it is the original source of the program itself.

The term also get's used as a verb, “I was just coding a new enemy in my game”. Coder; coding; code - referring to the person, act or resulting files containing instructions for a computer program.

To create a program, you then feed a list of these instructions, your code, into a tool that converts them into something the computer can understand and run.

new term : “compiler”

The tool to convert code instructions into something that the computer can understand and run. Compiling program code is the act of turning source code into a program.

Code is written in a specific language - and fed to a compiler that can understand that language.

”Programming Language”?

Code instructions are often typed out, line by line, by a programmer. The specific instructions, how each line is layed out, and how it is formatted, is specific to the language that the code is written in.

A programming language usually describes a method of giving the computer instructions in a specific format and structure. Just like the english language has rules about the structure of a sentence - a programming language puts forward rules to lay out code, so that the compiler can translate it to a program.

Haxe, the language I will be using in this series, is a programming language. The Haxe compiler understands Haxe code, and can help you turn that code into a program or game.

The exact rules of the language is called the syntax.

new term : ”syntax”

Syntax is the set of rules that explains to you, the programmer, what the compiler is looking for when you type code into a file.

This syntax, can vary wildly between languages - and many languages share quite a few similarities in the way things work.

What does an example of syntax look like?

Well, let's start by choosing a simple instruction. One thing you will do a lot of when coding, is repetition. What I mean is doing something over and over again, like in a loop.

Say you had four birds flying around the sky in your game. You need to tell each of these birds to move. You could say "Bird one, move. Bird two, move. Bird three, move. Bird four, move."

This is kinda tedious, but what if tomorrow you felt like 20 birds would sell the vision you had in your mind?

You would probably want to somehow automate these move instructions - which the programming language will often have syntax to do just that.

Examples of syntax for a simple instruction : loop a number times,

where our number was 4, and we wanted to change it to 20.

To demonstrate different languages and syntaxes, I will list a few variations for the exact same construct (a construct just means a type of instruction, like a loop).

Don't worry that you might not understand what the lines below mean!
It is merely to demonstrate what syntax means and nothing else. This is the syntax of a loop in 4 different languages - and each of these instructions do the exact same thing.

C++ language : for( int index = 0; index < 4; index++ )
C# language : for( int index = 0; index < 4; index++ )
python language : for index in xrange(0, 4)
Haxe language : for(index in 0 ... 4)

Can you tell why I think the Haxe language makes a pretty good option for beginners? Once you learn what the instruction is for, and the syntax for it - it can be pretty easy to read out loud and understand. “For a value called index in the range of 0 to 4, loop for me”.

It may seem strange that it's 0 and not 1, but don't worry about that till much later. The loops will be covered later in much simpler detail - but if you were curious what the birds example would look like to automate the birds moving, below shows some lines of code, written in the Haxe language syntax - to move our fictional birds.

This time we stored the birds in a list, so we don't need to know how many there are. “For each bird in the list of birds, tell the bird to move”.

Again, you don't need to fully understand this at all, it's for curiousity sake. Just take a look, and keep reading.

for( bird in bird_list ) {  
   bird.move();
}

How do you give these instructions to a compiler?

So let's recap. To make a program (like a game), you type these kinds of instructions while following the rules of syntax, into a text file. You save that text file on your computer (this file is the source code of your program) and now you want to give it to the compiler, which will convert your instructions into a program.

How you do this, also varies by language. Many languages have interfaces for you to work in, where you can type the code, and push a button that compiles the code. In the background, the compiler is often just a simple program that takes a list of things you want it to do.

Remember - this is information for you to learn and understand, not something you have to do or grasp immediately.

To narrow down the focus, we will only look at Haxe in this explanation, because that is the language we will be learning. As mentioned, the compiler is a program itself, and it wants you to give it some instructions in the form of program arguments.

new term : “argument”

An argument is a value that is handed around, from one place to another.

This term will come up again later, so I figured it worth mentioning. Take for example, you wanted to buy some items from a vendor, like a hot dog or lemonade stand. When you approach the vendor, they will expect some form of information to give you what you want.

They are expecting it - and might ask for it directly : “What can I get for you?”
This is, for our demonstration, an argument the vendor is requesting in order to process your instructions. Your reply, the information, is the expected information.

A compiler expects arguments

Now, let's put that back into context of the compiler, a program, that is expecting arguments from you, to tell it what you want.

  • You have a file containing source code.
  • You want a program from it.

The compiler expects you to tell it which file you want to compile, and how you want to compile it.

Just information again This is not needed to try for yourself (yet!), but simply to explain.

This is how it might look if your file was called Game and how was if you want Haxe to make a neko program from your code. You will find out more about neko later, but it basically just runs your program for you.

In this example the program is run directly, from a ”command line” or ”terminal“.

new term : “command line”

A command line is a program that will run other programs, by name. It waits for you to type a program's name, and it will run that program.

This is often done by explicitly typing the name of a program, and hitting the enter key. This is also often depicted in movies where any hacker or programmer is presented to the audience because it can look more complex than it really is : typing the names of things by hand.

Commonly also called “command prompt”, “terminal”, “console”.

So recap, we want to run the program called haxe and we want to give it arguments so it knows which source code to compile (ours was called Game) so it can convert it into a new program. Our program!

haxe -main Game -neko game.n

Let's imagine this as instructions, that we read aloud.
“Hey command line, please run a program called haxe and give it my arguments, specifically that my -main file is called Game, and that I want a -neko version of the game called game.n, so I can run it”.

You will notice there seems to be some structure, and pattern here.
program -instruction value -instruction value

This is a common pattern for command line programs, to take arguments in a specific format so that they can do what you want. Many command line programs will explain these patterns and structures they are expecting if you just run the program without any arguments.

On the command line, if you run haxe and hit enter, it will give you some suggestions for arguments it expects, and tell you a bit about itself.

Section Conclusion

That is all there is to a compiler, and how it gets it's hands on your code to create a program. A compiler is just a program, that converts code into other programs!

Much of this is automated for you by files, or interfaces that describe this automatically and handle the commands for you, and then automatically run the program when it is done. Now we can start looking at the anatomy of a program as a whole, and make our first program to say hello.

To wrap up this section: unless you want to learn to program, or are still curious about more specific details, you don't need to continue reading the onward, where we make a basic program run.

Hopefully this post will help you and others better understand what you do all day at work, what makes you spend hours in front a screen, or why someone you know is besotted with typing arbitrary words in lines in order to create a game.



part two

Getting started on some basic programming, using the Haxe language.

Program anatomy, the big picture

The code of a program very often has an entry point. A place where the program will begin. With haxe, this place is the main file, and that main file has an entry point that we can fill in some instructions to do things.

But, out entry point is held together by something called a Class. This term is quite simple to understand, and is the entry point for a Haxe program!

new term : ”class”

A class is a named container, a collection of instructions and information held together under a single name, and very often stored in a single file on it's own.

When you read the command line that the haxe compiler was asking you for your code, what it really wanted to know was which class contains the entry point to your program. The name of your class then, would be Game.

The Haxe language, if you recall, specifies syntax, rules, for how to make a class. The rules for a class, are like this :

Start with the keyword class, followed by the name of the class (Game), followed by a code block. Before we rush ahead and start coding, let's break this down some more.

new term : “keyword”

A keyword is what it sounds like. A word with specific, key meaning that is important to the compiler. It is reserved for use as part of the rules of the syntax, for that language.

This means that keywords between different languages take on all forms and shapes and structures, but we only care about Haxe here. class is a keyword, we cannot use it for anything when coding our program except to declare to the compiler that we are making a class.

new term : “code block”

A block in our terminology, will refer to code in between two curly brackets, like { this is a code block } because it is surrounded by an open { brace and followed by a closed brace }.

To start a block of code, we use {. To end a block of code, we use }. Anything inside that block, is grouped together.

Anatomy of a class

Let's look at the class rules again :

  • We declare a class to the compiler, by having the keyword class first
  • Then, we give the class a name. The name MUST start with a Capital letter. This is a rule!
  • Once we have given the class a name, we have a block , like { one of these } .
class Game {

  //... anything inside this block, belongs to the class called Game.

}

Haxe doesn't care how you layout the block, it could be :

class  
Game  
{
}

or it could be

class Game {}  

Each of the above are still obeying the rules that the compiler put in place for you. Very often it comes down to personal preference, but the first one is my preference. Many people like to put the open bracket for the block on the line after the name, like :

class Game  
{
}

But in reality, it makes no difference. Choose whatever way you feel comfortable reading the code and this is critically important above a lot of other stuff :

Code is for humans first, you included

When you write code, you are taming an unimaginably powerful computer to create vast imaginative worlds (or generate spreadsheets) but program code can get complex very quickly. To understand and continue to code a single program over periods of time, your code being easy to read, easy to understand, and easy to keep working with is of utmost importance.

new term : “comments”

Because code is consumed, maintained, conceived and created by humans - almost every programming language gives you the ability to make notes alongside the code, without it affecting the program at all.

In Haxe, the comments take on two forms. Again, this is a set of rules that the language has given you, the syntax of a comment is as follows :

  • Single line comments start with // and anything after that point on that line, is ignored
  • Multi line comments start with /* and end with */. These may seem like odd choices, but if you look at a numeric keypad on older keyboards, they are right next to each other! This made sense for quick access in the earlier days of programming, because it was a quick two taps to open and close comment blocks.

Numeric Keypad

image from Wikipedia

Example comments

//single line comment

class Game { //this is ok here, because it's ignored

/*
    multi line comment, 
    anything inside the opening/closing 
    braces will be ignored by the compiler.
*/

Let's have a look at the Game class again,

//In this file, we have the main entry point of our haxe application.

//This file was created by Your Name, on 12/34/56 2014.
//If you have problems with it, please email me@example.com

class Game {



} //Game

You will notice that we put some useful information about the file, and the class. I also like to put a helpful reminder that the ending brace - is from the Game class, and not some piece of code inside the game class. In longer files, it can get really hard to know what bracket is connected to a block of code so, this is a preference for me and it makes my code easier for me to read, and maintain.

A class is a named container

So our application starts with the class called Game, and it contains nothing yet. We store this class in a file called Game.hx, the .hx file extension is what makes it easier to know what to do with the file, just like a .jpg or .png extention implies that is it an image file.