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.


Using Gaming Software for Archaeology


Say you have a large archaeological site with many features and much to show. Say you want your site to be accessible to everyone who has an interest in it, regardless of their knowledge of the period or of archaeology in general. How would you go about showing what you have found in the most appealing and simple way to the general public?

Of course there is not one single answer to this question, and many methods of public engagement are available to you. However I’d like to suggest a newer and more visually stimulating way of presentation, by combining archaeology with gaming software.

I personally enjoy playing around with Game Maker from time to time, a program specifically designed to create games in a simple fashion, and that can easily be adapted to create any type of program. But beware, Game Maker is not an easy program. Behind a simple-looking interface hides a complex script writing process that means you have to know at least a bit of programing to do anything good.

Given the nature of the program the possibilities are endless, and the final result depends solely on the imagination and time available. One of the projects I was working on was to create an interactive plan of sites, which allowed the user to select different time periods and then click on the features to receive information about them. Having already created a 3D version of the plans in Sketchup for a different project I decided to use these again in order to save time and improve the visuals.


I then proceeded to create a mechanism by which clicking on the features would direct you to another “room” where the information was. This was done by creating invisible boxes on the 2d surface and then telling it what to do when a specific box was selected. I then created buttons to go through the different time periods using a similar principle. Finally I wrote the code and made sure it appeared within a box next to an image of the selected feature.


I cannot give you the exact way in which I achieved this unfortunately for a number of reasons, first of which it would be pages and pages of text and code, but the basic idea is that I played around with the software until I achieved what I wanted: a series of snapshots of the site in 3D that allow navigation through time and that show exactly what we have found with images and text.


Another project I’m currently working on in instead a program for kids that allows them to interact with a roman soldier and help him carry out tasks. The aim of this is of course educational, and it displays the archaeological finds in a fun and interesting way that kids will enjoy. This one is made using a series of rooms that change every time you click on a certain portion of the map, depending on what the task is, i.e. if the soldier asks you to find the enclosure, then clicking on the enclosure changes the text.


And these are only some of the ideas that can be made into reality. As odd as it may sound to use gaming software to create archaeology, the potential is great. Games like Assassin Creed or Skyrim have massive cities within them, with which the player can interact, so how much harder can it be to reconstruct entire sites and allow players to walk through them in order to learn more about them?