Switching Hemispheres - Update

It has been about 6 months since my plane landed back home in Sweden after 2 years of game design studies in Australia. This is where I have to use my skills and knowledge to find work in the industry, and continue working on personal projects.

So what have I been up to?

Untitled FPS Game

Almost a week after I came home, SAE’s Make-a-thing jam started. I wasn’t sure if my brain would have recovered enough to participate, but I wanted to do something to keep my momentum going. This was something my lecturers advised me not to, considering how close to burn-out me and the rest of the team of Dragon Drop Games was during the last trimester.

But since I felt fine at the time, I decided to work on something for the Jam, even if it didn’t become anything. I started making a cartoony first person shooter game, where you shoot pumpkin monsters. I quickly realized I wouldn’t have time to finish the game for the jam, because as per usual it grew too big, but I kept working on it anyways.

I had a faint goal of making it into a higher quality game, and only used the low-poly assets as placeholders. I got fairly far on it, and got to work on a bunch of things I don’t usually do like rigging. In the end, I never really had a clear goal for the game, so I stopped working on it, but I still enjoy looking at the things I did for it, as I believe it will become a good point of reference in the future.


Mead Maker

after maybe one month of working on this, I took a little break. I still had the game development spirit burning in me, so I decided to try and make something smaller, with full documentation. I went back to my old Viking themed games, and decided to make something like it. I settled on a game where you bounce ingredients into barrels.

From the start I was very uncertain on how to make certain things, like the barrels deciding an ingredient and checking if the ingredient hitting it matches. However, after working on it for a while, it all became very clear on how it should work, and I managed to fix it.

I actually got very close to finish before other things happened that forced me to stop working on it. All I really had left was to decide a win and lose state, and add some polish and sound effects. However as I mentioned, something came up.


East Sweden Game

Pretty much as soon as I landed back here in Sweden, I had kept hearing about this “East Sweden Game”, that supposedly was a community for game developers, and that was fairly new. Having just left Australia, and therefore the indie dev group “Squiggly River Games Collective”, I really felt like getting back into a community that supported all kinds of games and where you could get feedback on your work. Still, I was a bit shy, as I wasn’t sure my level of game making was as high as everyone elses. But I decided to go to one of their meetups anyways.

My presumptions was right, most games here had had a development cycle of at least a couple of months and most of our projects in Australia (not counting the graduation project) was 4 weeks at maximum. But I began talking to some people none the less. After all, I had two years of experience with Australia to talk about. But I began visiting more often, and it is thanks to the creator of East Sweden Game (ESG) that I landed my first job (more on that later).

ESG has been a perfect change in my life that will help me keep momentum on ANY project I make. Everyone here is incredibly nice, talented and knowledgable. I’ve always been taught to surround myself with those that are engaged in the same things as I, and there is no better place than ESG for that.


The Accelerator & Dragon Drop Games…?

While a member of ESG, I decided to sign me and Graewolv up for an Accelerator course. This is a business coaching course that will teach us the ins and outs of the business side of running your own company. Teamwork, marketing, and much more will be included, as well as guest visits from other companies.

While I love my job, I still want to keep all my other skills up to par and work on my own projects. This course will be excellent both to improve myself and my teamwork skills within the Graewolv team, and to give me the skills to perhaps revive another group of people making games together. Dragon Drop Games.

The Accelerator Group

The Accelerator Group



I got my first job as a game designer! I am now the AI designer and programmer for a startup company here in the town where I live. I can’t mention anything about the game, but it is a very exciting step in my life. I look forward to where my career will go from here.

Currently the project is set in Unreal Engine 4, mainly using Blueprints. I however, mostly work in the Behavour trees, making sure the AI does what it is supposed to.



My time in Australia was one of the highlights in my life. I met so many amazing people that I try to keep track of and in contact with to this day. I hope to return at some point in the future. Things have gone well here in Sweden I’d say, and I hope that within a year or so, things will be even better.

I’ll try to keep updates here on further projects I make, even thought MONTHS pass between each post.

Thanks for reading


Scrapbot Dev Diary #1 - Level Design and Early Choices

Hello and welcome to the first non-forced blog in quite a while! This one is all about a personal project of mine, that I have been working on to and from for a few weeks now (trying to relax on a break and still work is a bit hard for me still). In this blog I will be discussing the main idea, then talk a bit about some design choices i’ve made, and then finally talk a bunch about the level design, as that has been the main focus these last few weeks.

So let’s start talking about the idea itself. What I wanted to go for when making the game was a Mario 64 or Banjo Kazooie feel. Kind of an open world platformer where you collect items in order to progress. I wanted to make something that didn’t use many difficult programming elements, as I had decided to make the game in Unreal Engine 4, rather than Unity which I am used to working in. My game had two characters. Two different robots that the player could switch between in order to complete puzzles and challenges. The original idea was that the player could collect three different types of currencies that would be used to construct different tools (like launch-pads) to assist the player further. The main goal of the game was to help a third robot (NPC) to go to space in a massive rocket that is located in the middle of the map. As for the map itself, it was split up into four different areas that I would lock off and release over time as I developed this project. This was the original Idea for the game, however below I will talk about some design choices and issues I encountered that changed the game slightly.

First off is my choice to remove character swapping and two characters. In a game world as “open” as mine, it would be tedious to only move one character at a time to move across the map. It is probably countered through the level design itself by moving the characters in small increments, but it didn’t correspond with what I wanted for the game.

First iteration on level. one part of several massive quadrants that would progressively be released after game release by me.

First iteration on level. one part of several massive quadrants that would progressively be released after game release by me.

The second issue was the map size. I liked the thought of having different zones, but I eventually realized that I probably won’t want to work on this for another few months to fill out all areas with unique ideas and content, so I removed the zones and decreased the overall map size. Because of that I also had to decide what activities I wanted to include in the game. I started off with trying to come up with four different activities, one for each quadrant. However I ended up changing it to four jumping puzzles instead, as I wanted to focus on the level design and platforming aspects of the game, rather than amount of mechanics. So the final decision became four jumping puzzles starting in or being located in, the different quadrants.

New iteration on the level design. This iteration features a significantly smaller level with objectives all around.

New iteration on the level design. This iteration features a significantly smaller level with objectives all around.

Upper Left Quadrant of the new level. Here I have mapped out a jumping puzzle and all it's possible paths as well as locations of bolts.

Upper Left Quadrant of the new level. Here I have mapped out a jumping puzzle and all it's possible paths as well as locations of bolts.

Next up was some smaller changes that I had implemented, but then decided to remove completely. One of them being the three currencies. I had nuts, bolts and springs that all were made for the player to collect. However, none of them had any specific purpose at all, so I removed two of them, keeping the bolts. The reason for keeping the bolts was partially because I feel like bolts do more good than nuts, but also because the internet has ruined me and I didn’t want to keep writing nuts in my documentation. The second issue I had was the mechanic to carry items. Originally in a very early idea I wanted the player to be able to have to place boxes on pressure plates to move through puzzles, but since this became a jumping puzzle based game instead, I decided to remove the functionality completely.

Since I have one of the quadrants ready for grey-boxing, I wanted to dive in to unreal engine and start mapping out the area and test the size of the level, as well as get used to exporting from maya to UE4. The first step was to create a cylinder that would cover the size of the level. Since I had made the level smaller from the start, I decided to make the radius of the level 50 metres, rather than 80. This however, was incredibly far, and it could take me as much as 3 minutes to reach the end of the level, which was way too far. I tried changing it over and over again, and eventually ended up at 15 meters. It's around this point that I figured out that since 1 unreal unit is equal to 1 centimeter, that means that 10 unreal units is 1 meter, meaning that my "50" meters actually were around 500 meters. So my 15 meter radius made more sense as a 150 meter radius. This 150 meter radius was a pretty good size since it didn't feel too long nor too short. I played around as well with the size of the crater the map is in, and the size of the rocket in the middle. I wanted the rocket to be a very clear center-point so I needed it to be visible from everywhere.

Level design test, with final size iteration of 150 meter radius

Level design test, with final size iteration of 150 meter radius

Previously in my degree one of my weaknesses was to ask “why” questions. Why do I implement X, what purpose does it have? Does it add to the game experience? If the questions were no, then there is no reason to have it in the game. For this project I think I have evolved in that field significantly, and I believe my game will turn out better for that.

Creating the Flybot!

Hey there! 

I do realize it's been a while since I've written anything, but I've been very busy with Uni work these past weeks, and just haven't found the time nor the energy to work on any side projects what so ever. That is, until tonight.

I'm currently writing this blog at 1:35 am, because I was just too worried that I might forget all this new information that I've discovered today if I slept, so I'm going to put it all here both as a reminder to myself and both as an update to what I am currently working on. So let's get right to it.

The Scrapbot

About 2 nights ago (yes nights, I can't work during days apparently) I started working on a robot model. I consider myself to be adequate with Autodesk Maya, but if there is anything I still struggle with, it is skin. The way it stretches along with weight painting is just too difficult for me, and something I will have to tackle another day. Therefore, robots and mechanical parts are way easier because you can use a method where you simply target all the vertices that you want, and tie them to a bone. No stretching involved. Because of all this, combined with a sudden inspiration surge to do some personal projects, I started to work on the robot I was about to call "The Scrapbot". I called it that because it feels like I can get away with not being a fully trained animator/3D artist by making scrappy stuff.

Either way, I immediately got to work, and I did feel like I made heaps of progress on it. In fact, after the second night had past I was completely done with both model, skeleton and animation. I was also fully aware I had completely skipped some of the key guidelines for modeling. One of them for example, is to combine every part of your robot so that they're not separate pieces. Even though I knew all this, I continued working (for some reason) possibly to experiment with what would happen.

I went from this, in Maya: 


To this in Unreal Engine 4:


Needless to say, something went horribly bad in the export. I already knew the skin stuff based on the amount of errors I got when exporting, however I was still very confused about the slow-mo running (more on this later). This had me drained of work energy so I went to sleep. Next day (today) I was determined to keep working on this model, however once I had the free time it just didn't click for me. I didn't want to start over with the rough animation and the rig. I decided that I had to make something even simpler, for the sake of time. Enter "The Flybot".

The Flybot

The flybot was my attempt at making something smaller that barely needed animating or skeleton. The first idea for the flybot was a little head on two legs that was running around. Then I went on to brainstorm a head with a propeller and a grappling arm. It ended up just being a head with a jaw and a propeller on top for simplicity's sake. I did everything all over again, even the things I missed last time like texturing and combining. I was ready to export. The first good sign was the error box, which turned out empty. I had my hopes up. I then hopped into Unreal Engine to start working, and behold there it was in all it's glory. No error messages, fully intact and textured, the flybot.

Now the fun part was about to start. I placed the animation inside the scene to have a look at my masterpiece and.... disappointment. The animation worked, sure, but it ran at 1/30th of it's original speed. Now, some of you might already have realized what is wrong. The key is in the number 30. Apparently (after some online research) Unreal needs Maya to have a playback speed of 30 fps instead of "Default" (which apparently is each frame). This also lead to me having to move keyframes spread out over 600 frames, down to about 90. It was a bit tricky, but hey it worked!


Some other things I learned in the process of Importing from Maya to UE4 was that UE4 requires your Maya scale settings to be set to centimeters instead of meters, unlike Unity which requires the opposite. Now my model was arguably a bit too big still, which I am currently working on solving.

Finally, I learned a helpful little trick that I might be able to use in the future. When making animations, you can make the run, jump and death animation in the same file, and when you import it into UE4 they will give you the option to import different frames separately. Important to note though is that only the first animation has to be imported with the mesh. The other animations are fine if you import the bones only.

That's all for now! The reason I didn't say what the game is yet is because I am still figuring it out and testing. I need it to be really simple because I just want it out there really. This whole modeling project I've been doing is partially just to prove to myself that I can do it, and so far it has worked, but the game is the final piece.

Anyways, thanks for reading! Until next time.