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

No Arms in Space for SGA - Lessons Learned

Last week we made the hard decision to put our SGA entry, I Lost my Arms in Space, on ice. With just over a month left before the deadline and team members needing to dedicate time for studies and applying for jobs it was clear that we wouldn't have enough time to make a competitive game. The game idea needs a great deal of attention to detail and tweaking through testing to really be compelling and that is not something we can do right now. Construct has also become more and more of a headache, which certainly wasn't helping our work either.

There are some good lessons to be learned for my future game projects. This is what I will be doing different in future projects.

  • Construct is a great tool for making quick prototypes, but is far from mature enough for larger projects. There are many bugs and strange behaviours to watch out for, and it's just unforgivable that it's not possible to merge files or even copy-paste between them. Collaborating on the coding and scripting is nearly impossible. This certainly wasn't obvious and I had gotten quite far into my work in Construct before realizing this. Another drawback is that games can only be exported as .exe files. The developers of Construct recently acknowledged these drawbacks in an open letter to the community, and announced a complete re-write, Construct 2. It promises to fix these flaws but will likely not be ready for general use until the end of the year. Until then I will stick to XNA and maybe try Unity or UDK.
  • It's very important to establish one general communication channel within the team and make sure everyone uses it. Since we all lived in the same town and see each other often I thought this could be handled through meetings, Google Docs, phone calls and IM but there is a definite need to have easy-to-access, lasting communication in writing that everyone can see. Something as simple as a Skype conference chat can work. Through this, team members can post little status messages, ask questions, and raise warnings about unexpected snags, ideally making everything run smoother.
  • Under a tight deadline planned work needs to be divided up into single tasks and time requirements estimated. Seems obvious, but with GanttProject this was too much of a hassle, so I only had blocks of tasks. This made it hard to create milestones with clear, tangible goals and follow up on the plan. In restrospect it would probably have been preferable to just use an Excel-list of tasks, such as I'm using for GunFlyer. Ideally though, a plan should be easily available without the need for specialized software. I hope to find a good cloud-based planning tool.
  • Try to always have the player's perspective in mind when designing gameplay and levels. Do the gameplay elements and level design elements really provide a new kind of challenge to the player or are they just a new interesting task for the developers to implement? Again this seems very obvious but it's easy to grow too attached to any original ideas your may have thought up. I realized too late that some of my gameplay ideas probably wouldn't do much to vary the experience for the player and that we would require more level elements than what we had already planned in. Earlier testing would certainly have helped here.
  • Related to the above, I think one problem in working with I Lost my Arms in Space was that, while logistics-puzzle games are interesting to design levels for, I just don't enjoy playing them very much. This did of course affect my motivation and made it harder to judge the mechanics from a player perspective. Of course this doesn't mean that you shouldn't challenge yourself and try new kinds of games, but in this case we should have started testing earlier or gone for a simple gameplay idea that we all really enjoy from the start. Hearing hopefully positive feedback from testing players would have helped us push forward a lot, I'm sure.

I still want to hear feedback on our gameplay ideas, so I'll see if I can finish the two areas that were almost fully planned out and let people who are interested try them. Maybe I'm being overly critical at this stage and the gameplay ideas really have a lot going for them, but at any rate we need to switch to a different development platform before picking this project up again.

So what now? For the coming month I want to focus on GunFlyer, the final project in the XNA course, and learn to make games using the tried-and-tested method of object-oriented programming. I will probably also check back with some of the nice people I met at Nordic Game Jam and see if they want to pursue some of the ideas we made up in an inebriated state there. I need a good reason to check out Unity and UDK! :)

Blog downtime and some gamedev courses I'm taking

There was some trouble with the communication between Squarespace and my bank resulting in this blog being temporarily suspended. It took several days of trying before the payment finally went through, but here I am! Yay!

Apart from working on the SGA game and working part-time at the electronics warehouse I'm also taking two distance courses, one in game development and one in XNA programming using C#. The former, at Luleå Tekniska Universitet, is really interesting and gives lots of good advice regarding the development process, publisher relations, and scheduling and budgeting. I especially like the course book, which feels very accessable and has plenty of developer interviews.

The XNA course, at Blekinge Tekniska Högskola, provides a good opportunity to get to grips with another development environment and above all MAKE MORE GAMES!

For the final project in that course I'm making a twin-stick shooter with visuals inspired by the ZX Spectrum. It's called GunFlyer and it's all about flying around using the recoil from two guns, aiming them individually with the two control sticks. And killing enemies with said guns! The course project will just be singleplayer but I think the basic premise would also work great as a very skill-based deathmatch game.

Many of the updates lately have been in English. From here on posts relating to my various game dev projects will be in English, while more everyday posts will usually be in Swedish as I feel I can write more personally in my native language.

Spreadsheets, oh joy! Also, cool lights.

We're still kicking. :) However, Shaw has not been able to continue with us as school takes it's toll. In general, real life has been stealing far too much time from game development for all three of us. However, our mutual online friend Erik, studying writing in Jönköping, has joined us to help flesh out the story and script stuff in Construct. 

With the deadline only two months away things are a bit hairy, so it's important to work in a structured way. Sadly Ganttproject, the software I was using to plan and keep track of the project, is not proving very reliable so instead we currently work from spreadsheet lists of tasks in Google Docs. In one of the lists, tiles and graphical assets are listed, and they are included in the file for reference as they are completed. Here's a short part of the list:


In the second spreadsheet all implementation tasks are tracked. With the help of these we are sure we can get a good demo ready for SGA, with as much time as possible for testing. Optimally, we would like about a month of testing and tweaking, which means the basic tasks should be done by early/mid April. That's our goal anyway! 


(Yes, it's not very good to not have entered the due dates yet. I'm working on that right now, but there are a lot of birthdays and events to take into consideration)


Oh, and here's a neat thing I've been working on: Dynamic lighting! This really helps in creating a more atmospheric setting, and adds a lot of depth to the otherwise flat graphics. Moving lights also create moving shadows. :)


Nordic Game Jam 2011 recap

Another post in English in case fellow jammers want to read this :) But first a qiuck update:

This post is far overdue but the application for the masters in Interaction Design is kicking my ass. The exam process in the human-computer interaction course, which is a prerequisite for Interaction Design, has turned into something utterly bizarre and I've had to spend far too much time stuck in bureaucratic processes. But that is just about over now, for better or worse.

I also got a go-ahead of our current team structure for the Swedish Game Awards entry, which means that project can finally gain some momentum again. I've also had the pleasure to welcome Shaw to the team as 2D pixel artist!

Copenhagen IT University. Games being created everywhere!

Last time I wrote I was on my way to Nordic Game Jam in Copenhagen, and it was absolutely the most fun thing I've done in this game making business so far. I got into a great team of fellow game afficiandos and together we managed to bring about a fully playable game. Not just that; we made it to the finals, meaning we were in the top 10 of the ~60 games at the event! Presenting in front of 300 people while simultaneously playing the game, avoiding the worst bugs, was an interesting experience!

I also got to Swedish indie game devs Nifflas and Cactus. Nifflas presentation on the novel techniques he uses to make his games was one of the most interesting things at the Jam.

So, how did we make our game?

From the left: Martin, Elvis, Nicolaj, Thorbjörn (top), Malthe, Jonas, David

The CornPushers team

Gameplay: Jacob, Thorbjørn, David

3D Art: Jonas, Martin, Thorbjørn

Audio: Nicolaj

Programming: Malthe, Elvis, Nicolaj

Project management: Jacob, David

Tools we used

Unity, 3DS Max, Photoshop

What I'm most proud of is that we really managed to hit the ground running. Me, Thorbjørn and David worked really well together when it came to brainstorming game concepts, and within the hour we had eight concepts around the theme of Extinction. We pitched these to the rest of the group, who in the meantime had set up their tools and gotten to know each other better. In the end we chose an idea I had originally proposed, and we hammered out the details together. Us gameplay designers ran out of energy pretty early in the night, but early next morning we had a working 2D prototype and shortly after that we had gone full throttle for the idea and soon had a working 3D prototype.

Thorbjörn pitches one of our ideas to the team

The colored Post-it notes I brought along came in handy as I tried to keep track of our progress. It actually went pretty well though I wish I would've had more experience in Unity so I chould have gotten my hands dirty and helped out more with it.

The planning board

Our design approach was iterative so we could be sure to have at least something to shove out the door if we got stuck.

The first iteration featured a rolling player character chased by small minions in a 3D-environment. The player would grow when near the minions, who would shink and die if the player was near them for too long. Rolling them over would also kill them. The player could move to a glowing aura to deposit the "love" sucked out from the minions for points, which would reset player and minion size but make them go faster.


The second iteration, which we started work on at Saturday afternoon, tweaked the behavior of the following minions to make the less likely to clump together, but also introduced the score bar. The collected love from the minions would gradually fill up a bar at the bottom of the screen, showing how much of the total love from all minions that had been collected. This could either be cashed in at the glowing aura, or by pressing a button used to either freeze all minions in place for a while or spawn an extra minion, depending on how full the bar was.

The score bar took longer than expected to implement and the programmers worked through the night. We didn't have time for the third iteration, which would have introduced traps and level obstacles. We hardly had time for any gameplay tweaking either, so the game as it stands now isn't too exciting or challenging. However, for a 48 hour game I think we did really well. You can download the game on the GGJ entry page. Here's a video of an earlier version in action!

We're thinking of turning it into an iPhone/Android game, which is easy with Unity. The rolling ball concept would probably work great with accelerometer steering.

Thanks to everyone in Team CornPushers for being AWESOME and the planners and volunteers at NGJ for helping to create such a great event. I'll come back next year, that's for sure!

Here's a bunch of videos from the other amazing Nordic Game Jam Games.

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.

Page 1 ... 3 4 5 6 7 ... 8 Next 5 Entries »