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 Construct (4)

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! :)

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. :)


Inledande konceptdesign!

Arbetet på spelet rullar vidare, även fast skola och besök från utlandet har snott en massa tid de senaste veckorna. Construct har visat sig vara ganska buggigt att jobba med, men överraskar hela tiden med hur kraftfullt och flexibelt det är. Faktum är att vi nu är ganska övertygade om att vi kan göra det färdiga spelet helt i det programmet, och sparar då in en massa tid och slit! (fast nu måste jag göra om hela planeringen... :P )

Medan jag har suttit med Construct har Sandra Kjellström anslutit sig till teamet. Precis som Leon är hon en fantastisk illustratör, och tillsammans har vi suttit sena kvällar och snackat om spelets visuella design. Nu har vi lite konceptbilder för armlösa utomjordingar och lika lemlösa rymdmän! Stina kom också med den lysande idén att satsa på kitchig 60-tals Star Trek-estetik och klassisk sci-fi som genomgående tema. Me like!

Den största utmaning nu i början är annars att bestämma storleken på objekten i spelet. Alla banor kommer inte vara scrollande, och det är därför viktigt att elementen på banorna är tillräckligt små för att få plats med mycket gameplay. Samtidigt som det inte får bli för plottrigt, och att gå tillbaka och ändra det här senare blir jättejobbigt!

60 pixlar verkar iallafall lagom som minsta storlek för elementen som bygger upp banorna, som kommer vara lite som labyrinter (nog snart dags att förklara gameplayidén, känner jag...). 50x50 pixlar verkar lagom för spelarfiguren och andra karaktärer, för att få en känsla för den storleken testade jag att pixla ett litet aliensmonster. Jag funderar ändå på om det är värt att få lite skönare lågupplöst retro-utseende genom att förstora allt 200% och köra med scrollning.

Jag har även suttit en del med tidsplaneringen för projektet och börjat registrera spelet på Gameawards.se, men mer om det senare!

Testkörning av gameplay med prototyper och mock-ups


Det behöver inte vara snyggt eller buggfritt... men det är en fördel om prototypen faktiskt är spelbar

Det sägs ofta att man aldrig kan vara säker på att en spelidé faktiskt funkar förrän man har spelat den. Både jag och Leon Stekla, vän, illustratör och gamer, har en massa idéer, men vi behöver ett sätt att snabbt kunna omsätta dem till spelbara prototyper. Vi behöver ett spelbyggarprogram!

För ett par veckor sen började jag pilla med Torque 2D, en kommersiell motor som jag blivit rekommenderad att prova. Torque 2D sägs vara baserad på den gamla Tribes 2 motorn, och verkade till en början vara helt OK med bra dokumentation och en hyffsad indie-prislapp. Under trialperioden blev det tyvärr tydligt att all action låg i skripten, och att även så enkla saker som tangentbordskontroll utan konflikter mellan tangenterna tog alldeles för lång tid att implementera. Torque är säkert bra och flexibelt, men passar oss inte just nu. (När jag senare på GameX träffade indiespelskaparen som jag trodde hade rekommenderat Torque visade det sig att jag helt hade lyckats missuppfatta honom. En kille i teamet hade gjort deras prototyp i Torque, men det var rena skämtet. Torque sög enligt honom.)

Jag tittade närmare på Game Maker, som används av bland annat Derek Yu till hans grottkrypare Spelunky och av vår svenska spelkulspruta Jonatan "Cactus" Söderström som kan ta fram ett nytt spel på bara några timmar. Leon har tidigare erfarenhet av Multimedia Fusion, och bara minnena av det underbara Knytt Stories som Nicklas "Nifflas" Nygren skapade med det fick mig nästan att dyka in. Det fanns många häftiga demovideos med spelexempel från båda programmen, men det behöver egentligen inte säga mycket om själva programmet, och trots att det inte fanns så många kända spelexempel ännu föll valet till slut på Contruct.

Spelprototyp i ConstructConstruct är något så ovanligt som ett gratis och open-source-program med schysst och genomtänkt gränssnitt (I kid, I kid!). Det har även inbyggd Direct3D-acceleration från grunden, vilket ger bra prestanda men begränsar spelen till Windows. Det som blev avgörande var dock gränssnittet, som visserligen lånar från Microsofts äckliga Ribbon-design men som jag tycker är väldigt genomtänkt och lättarbetat. Layouterna (scenerna) är lätta att bygga upp och skriptas sedan med förvalda mallar och beteenden (som såklart går att justera) eller direkt med python-skript. Det som jag trivs bäst med är ändå att sättet man bygger upp spelet är i grunden objektorienterat, så vi som kan programmera känner oss direkt hemma, medan de med mindre programmeringsvana kan lära sig koncepten i objektorienterad programmering. Och det är ju aldrig dumt!


Under natten satt jag och Leon och spånade, byggde, och hävde kaffe och energidryck. Hittills har jag lagt grunden till ett pusselspel i rymdtappning, medan Leon nästan är färdig med ett tankspel där man skjuter bort finnar från ett enormt ansikte.

Allting är roligare mitt i natten

Det kan ju bara bli bättre!


Tillägg: Det blev ytterliggare en spelbyggarnatt dagen efter, men då körde vi fast lite väl många gånger. Construct kanske inte är riktigt så intuitivt för oss nybörjare som vi hade hoppats på, och dokumentationen är tyvärr också ganska dålig. Det verkar som att man måste gräva ner sig i forumet för att hitta det man söker.