Basics of Coding for Archaeological Programs: Game Maker Overview


I am not a coder. I am especially not a gaming coder. I am however an archaeologist interested in all aspects of digital archaeology, from 3D modelling to Cad surveys, and I enjoy bending the original use of programs to fit my own needs. The best example I’ve ever seen of this is when some archaeologists used a Kinect to survey a room in 3D.

One of the most interesting programs I’ve ever used is Game Maker. It is not easy, not easy at all, and the main purpose is the creation of small .exe games. However the potential of this program is much more, as it is theoretically possible to do anything using the Game Maker Language, and I’ve seen some people make impressive 3D viewing software. What I am interested in is the ability to create programs to be used in archaeology, and up to now I’ve had success in two projects, one regarding the creation of interactive plans of sites, the other a small game to teach kids the workings of a hill fort.

Given the great potential, I thought it may be worth going through the steps for creating a program for all archaeologists who may be interested in doing so. The first thing to note is that Game Maker is similar to Dreamweaver in that it possesses tools to simplify coding, but allows some coding to be done if needed. The drop boxes used by GM are great to start off, but they get increasingly difficult to use the more complex the program gets. For this reason I use a combination of the two.

GM uses three main elements to create games: rooms, sprites and objects. Rooms are were everything happens. They are were the objects are placed and where they interact with one another. A game can have many rooms or a single room, and we decided what happens in each. Sprites are the images that we see. In the game Tetris, the various shapes can be seen because we have an image file opened as a sprite. What happens to the shapes though is decided by the objects, each of which has the sprite associated to it. The objects are where the coding happens, in which we tell the computer what we want it to do.


So, in Space Invaders we have a single room where the entire game takes place, we have a series of objects with certain commands and represented by image files called sprites. This is the basic working of games, and with programs it is the same. In Word we could say we have a “room” which is everything we see when we open it up, a series of “objects” which are the buttons we can press, each of which is coded to do something, and which are represented by “sprites”, the icons.

The next thing to look at is how to create an object with a sprite in a room. First of all we create a new sprite, and upload the image we want to use. Then we create an object, and in the box that appears we select the sprite we want in the sprite box. Finally we create a room and place the object within the grid that appears. If we then click the green arrow in the toolbar it all opens up, and we have an empty window with the image we selected at the position we told it. Of course nothing happens because we haven’t told the object what to do.


This is the hard part. The commands an object follows are made of two parts: the event and the action. The event tells the object when something happens. It means that if you tell the program that when you click on the object it moves left, it won’t just move left any time, but only when you click it. The action is instead what happens when the event takes place. GM allows you to choose from a large list of events and actions. The main events to remember are the create event, which means that the event happens when the room is opened, and the step event, which means the action happens at any time.


As an example let’s set the event as left key pressed and the action as movement, clicking on the left arrow and the speed as 4 (the speed at which it will move). When we press the green arrow now the room will open up and when we click the left keyboard key the object will move left, without stopping.

I realise this is not strictly archaeological, but I’ll get to that. In the next couple of days I will explain a bit more about this and go into the coding process.


About Rob Barratt

Mphil in Archaeological Research at Cambridge Univerity, BA in archaeology from Cardiff University, field archaeologist, technology enthusiast and computer geek. I like writing codes and making fancy models of old stuff.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: