About Rakethopp

This is my personal site about interaction design in general and game design in particular.

However, it's terribly out of date! Expect a revamp very soon (as of the fall of 2014).

Jacob Michelsen

@Jickelsen on Twitter
Rocketjumpr on Tumblr
Read this stuff! :D

Entries in Game Awards (2)

Using Google Docs for Level Design

I'm writing this in English in case there are readers outside of Sweden who may be interested in knowing about the game and some of the process behind it.

The core gameplay is about the player controlling a limbless astronaut (Lemmy Armstrong!) in a zero-gravity space station. The Lemmy can't move directly, but the player has control over the thrusters of the station, creating artificial gravity in any of the four main directions. However for various reasons it is not possible to change movement direction if the player or any loose objects are still in mid-air. Basically Lemmy will have the same kind of movement as in the classic game Atomix, which can be played for free here. An important difference is all the other objects in the level will be moving in the same direction! In a previous post I posted an early prototype screenshot with placeholder graphics, but I realize now that it's pretty difficult to make things out, especially if using a cheaper laptop monitor. I'll try to clean that up a bit sooner or later.

The path that the player takes through the levels should not be immediately obvious, of course. I'm no expert in game or level design (yet!), but it's apparent that designing a whole bunch of levels through trial and error won't result in a very good game, even if some individual levels may turn out well. The game also needs to provide a sense of progression through the levels, not only by adding complexity but also by driving the story along. There will be some static cutscene images and short dialogue in-game, but the design of the levels and the situations within them should also advance the story.

In short, I didn't feel that sitting in the level editor (Construct) and making levels one at a time would make a good game. It was when I played a remake of Atomix that I got the idea of dividing up the levels into a set of basic elements or structures (y'know, atoms...) depending on the number of entry and exit points of each part, and whether they presented the player with multiple paths through them. I could then build levels using just these classes of parts, worrying about the details later. I chose to use the sketching tool of Google Docs as we already have our documentation there for collaborative work, and the sketch tool is easy to use and quite powerful. The other members of the team can easily add level structures and new level layouts.

First I defined the basic structures

The structures to the left are the basic types, defined by the number of entry and exit points. The next column contains the "closed" versions of the structures, and the next version the "open" versions. This is of course only schematic layouts, they will never be this simple in the game. :)

Here we have the passage, which has two such points, and the appendix (blindtarm ;) ) which only has one. For the passage, there is a closed version, which leaves no open choices to the player but can be suitable for timed traps and such, and the open version which requires more thinking to get through.

For the appendix I have defined three types so far, both with closed and open versons:

  • The dead end, which the player enters to push a button or similar and then leaves again. 
  • The gravity detour is a bit harder to explain, but since the player movement affects all other loose objects on the level it may be necessary to have an area of the map to move around in to affect stuff elsewhere on the map. 
  • The box prison is an area the player will not usually enter. Instead, it is either where a floating box starts or where the player must guide it to get to the goal.

In addition there are two other types, the junction with multiple entry points and the gravity chamber, which has none! I couldn't fit them into the picture above though, and I guess I shouldn't give everything away right away. ;) Also this is not a complete list yet, I'm still brainstorming with the other members of the team.

For each structure I have added a description of what kind of objects and traps the different kinds of structures work with, and an approximate difficulty. The more difficult structures should be saved for later levels. Sorry if the text is hard to read, Google Docs doesn't always scale text very well on-screen.

Using the presentation document type, I have then started creating rough sketches of level layouts. The structures above are just color-coded blocks here, while the objects are icons.

The levels then look something like this, with the details of each structure block filled out when the levels are made in Construct and tweaked through testing. In the end I'm hoping to have 20-30 levels in total for the SGA entry version of the game.

 

This level introduces a concept, namely that the player actually has control over all objects in the level, even if they are in areas the player cannot reach. The main transport passage only has one or two options along the way, but only one of them also leads the box to the button opening the door to the exit. Clever players should realize this right away, but hopefully all players with leave this level with an understanding of this gameplay element.

 

This level introduces dangers and the idea of objects floating around and interfering with the player, but also tries to put these events into a context. A dangerous box (maybe a first-aid box full of syringes? :) ) falls out of storage due to the whole station being moved about, and this must be moved to safety without the player coming into contact with it. I think this level might be quite a step up in difficulty from the last one, if testing shows that this the case it will have to be tweaked or moved to later in the game.

 

This level also tries to move the story along. The first part of the game takes place in the crew area of the station, which is relatively safe. After this comes the security checkpoint which is supposed to protect the crew quarters from invaders from the hanger area. This was shut off in the alien attack. Lucky for our hero, right? Well, in this level the player is forced to pass through to the security room at the top right, which is covered over from the start (I mentioned this mechanic in the last post about the game). Upon entering it's clear to the player that he or she will fly straight into a big red button but can do nothing about it. Of course, this button activates all the security measures in the security area again...

The laser corridor at the end is just for show, as the player is floating around it is possible to just fly straight through without the lasers having time to hit you. Or something like that!

 

Lastly, this is an example of the trap-heavy nature of the security area. The lasers are aligned so nothing gets in to the crew area, but since Lemmy is heading the other way this it's possible to get by with the right timing. This area is less about difficult movement puzzles and more about getting the movement timing just right. Hopefully this shift of focus of the gameplay will make the game more interesting without breaking up the core gameplay too much.

Some levels will all fit within one screen, while others may be bigger and feature scrolling. One advantage of planning levels this way is that the actual scale of the level can be decided later when building and tweaking the level.

Omstruktureringar i teamet för SGA-bidraget. Ojdå!

För ett par veckor sedan lovade jag att visa upp något nytt från spelprojektet. Tyvärr fick vi lite käppar i hjulen.

Jag vet inte om de ändrat reglerna till i år eller om jag helt enkelt missade det, men ett krav för att vara med i Swedish Game Awards är att minst 50% av lagmedlemmarna pluggar på något svenskt utbildningsprogram. Fram till denna vecka var vi noll i teamet som gjorde det! Den senaste veckan har vi behövt ta ställning till om vi ens ska fortsätta. Det verkar dock inte vara så många andra tävlingar som denna, och vi är väldigt sugna på att fortsätta jobba med idén vi har och vara med i en tävling.

Tur i oturen är att vi är i slutet av planeringsfasen och har gjort mycket av grundarbetet, men kan absolut ta in mer folk nu och låta dem komma med feedback och idéer för gameplayet. En polare, Shaw, vill vara med och tackla en del av in-game-grafiken, men vi letar fortfarande någon som kan göra musik. Till sist vore det bra med någon med lite mer programmeringsvana, men den posten är inte helt bestämd ännu. Tyvärr kan inte Stina vara med längre, men med jag, Leon, Sandra, Shaw och två till blir vi totalt sex i teamet, vilket är fler än jag först tänkt men känns fortfarande rimligt. Nu gäller det bara att försöka träffa fler spelintresserade studenter...

 

Tack vare miraklet Twitter och dess öppna konversationer blev jag i söndags uppmärksammad på att Nordic Game Jam går av stapeln i Köpenhamn nu i helgen. Folk som älskar att skapa spel samlas och teamar ihop sig, för att under 48 timmar pressa fram bidrag till finalen på söndagen. Det här är en tävling som äger rum på flera platser runt om i världen på detta datum. Interaktionsdesign på Chalmers kör en egen Jam! Känns mer och mer som jag valt helt rätt att söka dit :D.

Självklart ska jag vara med! Jag åker ner redan på torsdag för att inte missa förfesten, opening party. Bara en sån sak som att en av mina favoritspelskapare på den svenska indiescenen Nifflas ska vara DJ är anledning nog att åka. Förhoppningsvis lyckas jag hitta något schysst vandrarhem i Köpenhamn, jag lär behöva en god natts sömn innan game jam drar igång...

 

Innan dess ska jag iallafall hinna skriva lite mer om spelprojektet. Jag har använt Google Docs ritverktyg för att planera upp gameplayet och banorna, och vill gärna visa lite hur det går till.