coding – 3D Reconstruction in Archaeology

Before reading this post, please look at my previous post. Seriously, it will mean nothing to you otherwise. Yesterday I went through the basic layout of Game Maker, and explained the difference between rooms, sprites and objects, as well as basic commands using events and actions. Today we will expand this last concept and look at how we can display prewritten text on the screen. The main aim of this series of post is to give an overview of how we can use gaming software to create programs that can help archaeology.

As we saw last time we could easily write some text on the screen by using a series of action drop boxes that game maker has prepared for us, and in some cases this is an efficient and easy approach. But I’ve found that when making a more complex program you can go insane with the number of action drop boxes you would have to use. Hence I like to use Game Maker Language to tell the program exactly what want it to do.

The first step is to create a new object. We can ignore sprites (the visual component) this time as the object is not going to be visible on screen. We can then rename the object something like text_ctrl. This object will have a series of commands attached to it that it will follow at a certain point we decide, the event. In this case the event is going to be the “Draw” event, which means the action happens at all times. The “Draw” event is like the Step event I mentioned yesterday, but the former is connected with making things appear on the screen, so anything visual usually ends up in this event. If for example we are deciding how an object moves, then the step event is more appropriate, while creating a rectangle with certain dimensions is in the realm of the Draw event.

Having decided when the action happens (all times) we then go to the “control” panel and choose the “execute script” action. This is where the coding happens, and where it all gets complicated yet interesting. Copy and paste the following:

{

draw_text(50,60,“Archaeology is pretty much the best thing ever.”);

//draws the text at position, creating new line when reached position

}

Save the object and then create a room in which add the object, which will appear as a blue ball with a question mark. Then run the game (green arrow) and hopefully you should get a screen that displays the message.

What you are doing is running a script. You are telling the program to draw a piece of text, using what is called a function (draw_text), and you are giving it some parameters to follow. First of all, you are telling it where the text goes. The rooms are divided up by a grid, each point of which is recognisable by an x and a y. The point in the top left corner has an x of 0 and a y of 0, while all other points on the screen have an x and a y depending on where they are. The further down they are on the page, the more the y is going to increase, and the further across the point is, the higher the value of x. In this case we have told the program that we want the text to be at the point x=50 and y=60.

We then told it what we want to say, using a “string”, which you can recognise because they are within the “ ”. Within the “ “s you can write whatever you want, and use whatever symbols you want, without making any difference to the code itself. Outside them any small change can really create problems with the code.

A few more things to notice. I’ve used the brackets { and } to open and close a part of text I want to be separate from other parts of text. This means it will work as a block, and if many functions are within it they too form a block. At the moment they seem pointless, but they will become more and more important. Also, the ; closes a function, making space for another, while the ( and ) brackets are used to specify the parameters of the function. Finally the // and everything that follows is a comment, a way for me to put a note to myself to know what is going on. The program recognises the //s and ignores anything that follows on the same line.

A last piece of code is a slightly extended version of the one before:

{

draw_text_ext(50,60,”Archaeology is pretty much the best thing ever, except for making origami, because at least origami doesn’t pretend it has an edge that is nowhere near where you expect it, meaning you spend three days looking for something you thought would take you two minutes to find.”,-1,150);

//draws the text at position, creating new line when reached position

}

The function here is draw_text_ext() and it allows a few more things to take place. First of all It sets a limit to the line you are writing, in this case x=150. When the code gets to that point it automatically creates a new line underneath, at a distance specified by the -1 (which for some reason is the standard number to use). This way you can write long pieces of code without running out of the screen.

Advertisements

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.

3D Reconstruction in Archaeology

Tag: coding

Basics of Coding for Archaeology: Scripts and Text

Basics of Coding for Archaeological Programs: Game Maker Overview