Blog

Game Design for Space Exploration

February 7, 2013 0 Comments


The longing for the infinite must always be a longing
–Friedrich Shlegel

When the Kickstarter campaign for Elite: Dangerous was announced, it not only inspired me to write these recent posts on exploration in video games, it made me think back to the hours I spent playing its predecessor, Frontier: Elite II.

Frontier was a magnificent achievement. In 1993 there was no game that could offer similar scale or freeform gameplay. The elegant graphics were also something of an accomplishment since the Amiga and Atari ST were not natural 3d machines.

Despite this, I always felt that Frontier never capitalised on the exploration potential of its vast universe.

There was little incentive to leave the inhabited systems and head out into the unknown. You could mine planets, and extract hydrogen from gas giants to fuel your explorations, but these were difficult operations, restricting exploration to very experienced players.

In spite of the rumoured existence of an alien warship hidden in deep space, there simply wasn’t enough mystery out there to entice explorers. The procedural planetary systems of 1993 lacked detail and variety and you could see most of what the game had to offer without going very far at all. None of this really detracted from a game that offered so much, but those of us who longed for the unmarked places on the map were left nursing our imaginations.

So what kind of space exploration game could we make in 2013 with what we now know about procedural world generation? There hasn’t been much information yet on what the procedural worlds of Elite: Dangerous will be like, but we can get an idea of the contemporary state of the art by looking at Space Engine, a procedural universe simulation created by Vladimir Romanyuk.

Space Engine was originally inspired by Noctis, the cult freeform space exploration game that I wrote about in my previous post. At the moment it doesn’t really contain any gameplay besides the ability to move around and take screenshots of its graphically impressive universe, but there are plans to create a full game out of it, hopefully remaining faithful to Noctis’ vision of a “dreamable space simulator”.

As you can see from the Space Engine galleries, it is capable of generating varied and detailed landscapes, with plains, craters, mountains, lakes and oceans. Different atmospheric compositions alter the appearance of each alien world. The planetary orbits are physically realistic, and it appears likely that physics that effects the player such as gravity and atmospheric drag are in the pipeline.

All of this procedural detail combines to create a web of systems that can provide gameplay, if they can be given as being of concern for the player.

And because we don’t know exactly what the procedural generators will create, but we do know *what* they create we can set goals for exploration that provide meaningful feedback while remaining open ended.

We can challenge the player to find the tallest mountain, the deepest ocean, the richest ore field, the largest planet that is the closest to its sun. All these goals are specific enough to be put into achievement systems, and yet they remain open. A taller mountain may be discovered tomorrow. Achievements then become, literally, world records.


It’s gonna be a rough landing! A Space Engine landscape from the EDGE Review

The technical challenge in this is in creating tools that can scan and interpret the procedural world in order to recognise mountains, ore fields etc. This is the price you have to pay for meaningful feedback; the computer must be made to understand what you mean. The challenge for game designers is to make these knowledge extraction tools fun and interesting for the player to use.

If I were Vladimir Romanyuk, or I had access to his source repository, this is the game I would make with Space Engine.

Imagine an advanced race of spacefarers. War and material gain are irrelevant concepts for them, what they care about is knowledge. When they come of age they set out in lonely ships to traverse the universe. (If you wanted to give the game an end condition you could make it so they were allowed to return home once they had gained enough knowledge. [Perhaps you could even throw them Proteus style into the world with very little contextual knowledge, and make players figure that out by themselves?])

Their ships are equipped with different types of scanning equipment and the means to mine and extract chemicals from planets and asteroids etc. This equipment takes skill to use; for example scanning a mountain formation might involve landing probes in the area surrounding it, in a certain configuration.

The gravity of the planet, the atmospheric composition and the layout of the terrain all effect how easy this is to do. Some planets may be extremely difficult to scan or land on. All this creates gameplay and the potential for informal competition and legendry amongst players.

Perhaps the player flies a living ship, a bit like Moya from Farscape. This living ship grows and develops in response to the knowledge the player can attain from the universe. “knowledge” here is given a more mystical and active significance here than the ordinary intelligibility of human life.

The ship can develop its capabilities using material from the universe in conjunction with knowledge, enabling the player to travel further and do more things.

This creates an economy of progression without requiring any shops or civilisations (less work for the indie developer!) and is in keeping with the wholly alien atmosphere we are trying to evoke.

So there you have it. We’ve now created a basic outline of an exploration game with progression and well defined goals which remains open ended and mysterious. I’d really like to know what you think about these ideas and the thinking behind them. If I had a bit more time and money I’d take a shot at developing it. Maybe in the future.

View Comments

The Gameplay of Exploration

January 25, 2013 0 Comments

Palomar II (2002)

One of the things I love most about video games is their potential for exploration. Like immersion, exploration in games is as much about mood and feeling as it is about the logic of game mechanics. It imparts a watchful, meditative air, a constant openness to emerging possibility that serves as a nice contrast to the intensity and solidity of ordinary gameplay.

This kind of peaceful, yet fully engaged play is something I have always looked for, yet it seems to be a hard thing to find. Too often, explorativity (is that a word? It is now) is simply a side effect of a large game world; there is nothing in the game that acknowledges that exploration takes place. There’s no feedback for anything you do, besides your own satisfaction.

Of course, this lack of feedback may be the entire point. One of the greatest space exploration games, Noctis IV, developed by Alessandro Ghignola from 1996 to 2001, simply presents you with its grainy, expressionistic universe and invites you to explore.

Writing for The Escapist, Philip Scuderi describes Noctis as having an essential “air of tragedy” and loneliness, a sense that there are “no messages to receive or send; no voices to contrast with the endless vacuum.”

Like The Sentinel, that primordial deity of computer generated worlds, the procedural universe of Noctis presents a blank and pitiless face. Without the presence of meaning within the world, this universe reveals itself to the player as a kind of grand, inhuman unfolding of geometry; a “worldless” world, as Heidegger might say.

Many of the older open-world games like Mercenary, Hunter and Midwinter II have a similar quality of rigorous bleakness which overwhelms the entire game, almost in spite of the developer’s intentions. Hunter, for example is ostensibly a Schwarzenegger-style action adventure, going by the back story and box artwork, but all that is lost in the angular silence of its fractal world.

It is interesting to compare these games with Proteus, which as of this writing, is still in public beta. Like Noctis, Proteus simply places you inside a computer generated world, a beautifully stylised island in this case, and leaves you to explore. In fact Proteus gives you even less to go on than Noctis. There is no backstory, no explanation as to what you might be able to do. You begin the game knowing how to move and sit down, and nothing else.

As your eyes open upon the world you begin to scan the environment. Trees, birds, life, weather patterns weave unnamed and mysterious systems around you. “How do they work?”, “What is my place within them?”, “Who is here?”. Exploration begins.

Proteus avoids the bleakness of other exploration games by filling the world with sound and with significant systems. Everything hums and jangles as you explore; each tree, each type of terrain lends its song to your experience. Animals hop about the forests and react to your approach, the weather changes, seasons pass. Everything seems to effect everything else and you are right in the middle of it trying to figure it all out.

And it gives so little away that you always retain the possibility of being surprised, of something new appearing that casts the whole world in a different light. It takes me back to the days when my friends and I knew so little about games that the most implausible rumours grew up around them. I wouldn’t be surprised to find Sheng Long living in that lonely house on Proteus Island.

For some time now I’ve thought that the mystification of game mechanics, the introduction of other kinds of intelligibility to the hard-edged logics of ordinary games are essential steps in moving game design forward. Proteus is an important step in that direction.

Next time, I am going to write something about space exploration in generative universes, so stay tuned.

*The image at the top of this post is not Proteus! It’s the cover of Palomar II, the 2002 album from NY indie band Palomar. I just thought it evoked the qualities I’ve been talking about in this post. Oh, and I am desperate for a copy of Palomar’s impossible to find first album, so if you can help, please let me know.

View Comments

AtlasMaker 0.7 – Make Texture Atlases in Photoshop

November 24, 2012 63 Comments

August 2016 Update: AtlasMaker is now on Github: https://github.com/richardjdare/Atlasmaker

In game development it is common to have hundreds if not thousands of texture maps and animation frames in a single project. Keeping track of all these images is taxing for both the developer and the computer, so what we do is arrange the images into texture atlases.

A texture atlas is an image that contains many other images. Usually, all the animation frames for a single sprite, or all the textures for a single object are arranged into a single image. The game code then looks at a smaller portion of this image when it needs to draw a particular sprite or texture.

AtlasMaker is a Photoshop script that lets you create these atlases inside Photoshop. It takes a directory of individual textures and arranges them on a single image. It can be used both for atlases of different sized images, and for tile grids which are commonly used in 2d games. Earlier versions of this script were released in 2009. I know I promised an update long ago, but I have been working on my iPhone game, Toxin. I have been using this script throughout Toxin’s development, but never got round to tidying it up for public release.


AtlasMaker main window. A tile grid for a 2d game is being created

Features

  • Cross platform – tested in Photoshop CS3,CS4,CS5 on Windows and Mac OSX.
  • Open Source
  • Create texture atlases or tile grids for 2d games.
  • Several image sorting algorithms. Find the most efficient one for your textures.
  • Add a margin to each image.
  • Custom data file export.
  • Extendable – It’s easy to add your own rectangle packing algorithms and sorting methods.


Generated with AtlasMaker: Left, a texture atlas with variable sized images. Right, a tile grid. Images used are randomly generated test textures.

Installing AtlasMaker

There are two ways to running AtlasMaker in Photoshop.
Unzip atlasmaker-v0.7.zip to your photoshop scripts folder. On windows this is usually: C:\Program Files\Adobe\yourphotoshopversion \Presets\Scripts
On a Mac this folder is at: Applications/yourphotoshopversion/Presets/Scripts

When you next start Photoshop, AtlasMaker should appear in the File->Scripts menu.

Alternatively, you can run the script without installing by unzipping the atlasmaker folder somewhere, then selecting Scripts->Browse from the file menu and then selecting AtlasMaker.jsx.

Quickstart guide

The first thing to do is select a directory of images by clicking “browse” at the top of the window. Once you have done this, AtlasMaker will scan through the images and collect size information about them.

Next, you want to select your packing method. If your images are texture maps of different sizes then you want to select the “Atlas Maker”. If you are making a traditional 2d game where the sprites are all the same size, then you want to select the “Tile Grid”

You’ll notice that some text will appear underneath “Number of Files”. This is a notification from the Tile Grid Packer telling you how many rows and columns your images will take up given the default document size. Different packing methods provide different notification messages according to their nature.

Then you can optionally select a sorting method. Sorting the images in different ways can improve the efficiency of the texture atlas. Some packing methods do not allow sorting, and will disable this option if they are selected.

You can also add a margin here if you want a gap between your textures. Margins are added on to the width and height of each image just like CSS margins.
Next, click “Document Settings” and you will be able to set the size of the texture atlas you are going to create. You can also set the document name here, and choose if you want to flatten all the layers into one, once the atlas is complete.

Now click “Create Atlas” and you’re done.

Custom data file export

One of AtlasMaker’s most powerful features is the custom data file export. You can export a text file for each texture atlas containing information about each image on the atlas. This might be XML or JSON to be loaded by a game engine, or you could use it to directly generate source code to be pasted into your application.


AtlasMaker custom data file panel. Here an XML fragment will be generated for each texture in the atlas. filenames and texture positions are substituted into the text using tags

Tags are used to substitute information about each image into the text:

  • #i – Image index (0.. number of images in directory)
  • #filename – Filename of source image
  • #width – image width
  • #height – image height
  • #x – X position of top left corner on atlas
  • #y – Y position of top left corner on atlas
  • #p – page number

If you click the “Reorder export file” button, you can rearrange the order in which textures are listed in the export file. Just select filenames from the list and click “up” or “down” to reorder them. You can select multiple filenames by shift-clicking.

The zip file contains a readme.txt which describes every option in detail.

AtlasMaker is designed to be extensible. It is easy to add new packing methods and sorting algorithms. I have written the code to be more or less self explanatory in this regard, but if you want me to write something about it, please let me know.  And let me know if you find any bugs!

Download the latest version of AtlasMaker from Github

Download from Github

View Comments

Toxin – Creating sprites in Processing

November 18, 2012 0 Comments

One of the most powerful graphical tools I am using to make Toxin is Processing, a Java based platform used to create generative art. Processing provides you with a basic IDE, a graphics API and a simplified front end to Java that lets you get things up and running with a minimal amount of work. It’s great for doing experiments or when you need to create art programmatically rather than with a graphics program.


Processing provides a simplified front end to Java, ideal for quick experiments

The green cells in Toxin were all generated using a Processing program. Each cell is a circle made up of a number of connected spline segments. I animate the cell by displacing the spline control points using Perlin noise. The cells are then resized and colourized in Photoshop.


Left, a cell being rendered in Processing. Right, the finished result

As you can see, the finished product does not look exactly like the original Processing output. I had to do a lot of tweaking, re-rendering and reprocessing until I got them looking right. It was very time consuming. There were many moments where I wondered if I was going to get useable results at all.

Many of Toxin’s graphical effects have their origins in experiments I did with Photoshop blend modes. I discovered that certain combinations of layers and modes resulted in nice abstract animations when the layers were dragged around. I wrote photoshop scripts to perform these movements and spit out animation frames. Unfortunately these scripts revealed many bugs and inaccuracies in Photoshop and its scripting system. You only have to look through the source of my AtlasMaker Photoshop script to see how many strange workarounds are required to accomplish straightforward tasks.

To solve these problems I implemented Photoshop’s blending modes in Processing, and use this to create my animations. Below are a few frames from Toxin’s shot animation that demonstrate the technique. The way the colours shift throughout the animation is down to the movement of multiple layers blended into a simple white shot sprite. You can get a better idea of how this looks in the game by looking at the screenshots I posted a couple of weeks ago.


Many of Toxin’s sprites use animated image processing effects


I also used Processing as a test bed to work out algorithms before implementing them in the game. For example, Toxin has a weapon which freezes the edges of groups of cells. It didn’t take long to prototype this in Processing.


Testing a powerup that uses a flood fill algorithm to find edge cells

Stay tuned for more posts on Toxin, and a new version of my texture atlas Photoshop script which is in final testing…

View Comments