Galactic Gauntlet is a cross platform LiveCode built game that we designed to test the new high performance graphics architecture of LiveCode 5 and to demonstrate to LiveCoders what the new LiveCode engine is capable of. You can download the code here. I spoke with Steve Thomas, RunRev designer, and David Williams, LiveCode developer, about how the game came about, what challenges the development process posed and how much they enjoyed working on the game.
Mark Taoilinn: Where did you start with the game, what was step 1?
David Williams: Firstly we had to decide what the game would be. We settled on a simple sidescroller where the object of the game is to avoid obstacles as you fly along. Initially it was quite a straightforward concept and it was easy to structure the program in my mind.
Steve Thomas: That’s where I came in to design the game. Working with Dave we agreed the game would be built using 3 layers. The background layer, a middle layer that the ship would interact with and a foreground layer which would be animated quicker to give the impression of depth.
Three layers
MT: You had a concept, what came next?
DW: The first thing I did was code the rocketship and the physics supporting it - which took a lot less time than I thought it would and was generally a lost simpler than expected. This was then integrated with a main game loop (a loop that is used to update the 'state' of the game every x milliseconds) that could be stopped and started to stop and start the game.
ST: Meanwhile, I wire framed the scene. This allowed me to quickly get an idea of how the game would look and discuss with Dave how he was going about building the game. We agreed that he needed to construct the game in such a way that the graphics could be reusable. This would bring down the overall size of the download and help performance. So the mountain area was sliced into 100px wide tiles which were then brought into the game randomly using the games engine.
Sliced, diced and tiled mountains
MT: How did you progress from this basic wire frame and simple physics for the rough objects to a fully moving side scroller?
ST: For the visuals I create a psd containing all of the elements. Once I was happy with that I then took each layer and sliced it in photoshop to create the game assets. All of the assets were png files with transparent backgrounds. So the mountains were sliced, renamed and exported. Each tile was given a name such a slice_1_4 which allowed LiveCode to know which slice to bring in next. For example slice_1_4 could link to slice_4_3 which could link to slice_3_1 and so on. This way the mountain could be constructed dynamically within LiveCode using an algorithm to ensure the pieces matched each other.
Dynamically constructed terrain
DW: This terrain generation was the most challenging part of the project. As Steve said the terrain is made up of a set number of 'layers' which are in turn made up of a set of 'slices'. Dividing the terrain up into layers allowed me to assign different layers different properties, such as how fast it should move (to give the perception of depth), whether it can collide etc. When the game starts, data about the properties of every slice and every layer is stored in a large multidimensional array. The data in this array is examined and updated at each iteration of the game loop.
One thing that I did a lot throughout the game was to indicate data about certain objects based on the filenames of their images. For example, to get this consistent, flowing effect to the terrain, each 'slice' has to meet the next 'slice' at the same height. There are 4 set levels of height that the slices can have on each side - the terrain image files indicate this data about themselves with the format
LAYERNUMBER_LEFTHEIGHT_RIGHTHEIGHT-UNIQUEID.png
for example 1_2_4-54.png. LiveCode’s text processing functionality is perfectly suited to read through a folder full of files and populate the relevant arrays with data by looking at the names of each file.
MT: Does that mean that the game was just like you imagined it at the very start?
DW: As we tested the engine more and more and realised how much we could do, the concept of the game evolved as well. Steve, designing, and I, developing, worked really closely together to evolve the game. The code was able to lead the design - when a new feature was suggested I could use temporary graphics to test and say “oh that works, that doesn’t work, let’s change this bit”. Only then would Steve make the polished graphics which we slotted into place. It was really important on this project that the design to be really fluid - the game changed as we tested different parts of the engine - and LiveCode facilitated that fluidity without compromising on the quality of the end result.
MT: We’ve spoken about backgrounds, tell me about the other assets.
ST: Elements like the explosions and the ship tilting were animated as sprites using a stop animation style. I would create a layer in photoshop with multiple layer. I would then adjust each layer slightly to create the desired effect.
Explosions galore
DW: One of the most interesting aspects of using the assets for me was managing the asteroids. The game has a fixed number of asteroids, that are displayed repeatedly along a loop. I used a pseudo random number generator to work out the height at which an asteroid would appear. If you plot the output on a graph with height on the y and time on the x, you will get smooth increases and decreases in height, but in a random fashion, almost like hills and valleys. Having the obstacles appear in a smooth fashion makes for more comfortable game play.
MT: Any other tips for budding LiveCode game makers out there?
DW: Yes, remember your platform! This game was designed to be cross platform. From the start, the game was coded to not rely on the size of the display. Graphics are initialized in a completely dynamic way - in fact, you could size the window to 100 by 100 or 50000 by 50000 and the game would still run. This is because when running on a mobile device, the size of the 'window' is essentially the size of the screen. Therefore, you have to make sure that you not only are able to deal with different screen sizes, but you are able to make the game run identically on different screen sizes, and different aspect ratios. Don’t rely on x,y coordinates - the coordinate '100,100' is in a completely different place on a very large screen like an iPad than on a very small screen like an old iPhone. You therefore have to refer to coordinates - and indeed the dimensions of objects - as ratios. So if you want to place something in the center of the screen, you place it at ratio 0.5,0.5 and it will get placed in the center of the screen regardless of size. The app has a set of functions for converting traditional coordinates to ratios and vice versa. Coding any app in this way is a very involved topic in and of itself.
ST: When designing your assets always remember to consider the medium, or media, they are being used in. Design for the largest screen size but consider the smallest. Simplest is best, too much detail will get lost on a small phone screen. A tip: once you've designed it, upload it to your screen or shrink the window down to size and see how it really looks - you'll quickly realize that simplicity of design is much better than intricacy.
And get a great sound track! I know you can’t hear it on the video here but Neil in the office made an awesome sound track for Galactic Gauntlet, it really enhances the user experience.
MT: Last question, what’s next for Galactic Gauntlet?
DW: Lasers!!! Version one of the game has already been submitted to the app store, we’re just waiting on approval. I’ve already started to code in some ‘power ups’ - in app purchasing examples for iOS that, yes, will include lasers and shield and worm holes to make the game more interesting and to highlight how you can use in app purchasing to appeal to two types of gamers: those who want a basic free app and those who are willing to pay a little extra for an enhanced experience.
ST: Working on the game has been one of my first projects with RunRev. I can’t wait to bring it even further with more features and assets and to get started on our next sample app or game.
The shape of things to come
The full stack of version one of the game, as well image and audio assets are available to download here. Galactic gauntlet will be available to download shortly from an app store near you!
About the Authors
David Williams is a Software Developer for RunRev Ltd. His hobbies are coding, playing and listening to music, and gaming.
Steve Thomas is Web Developer and Designer for RunRev Ltd. His main passion is listening to music and watching rock bands at music festivals and gigs.
Mark Taoilinn is Sales and Marketing Manager for RunRev Ltd. He is known to the team as Markety but he assures us he does have a life outside work.
