Posts Tagged ‘marte’

JAM ENTRY: Blomst 🌻

Posted by (twitter: @avaskoog)
Tuesday, April 25th, 2017 11:07 am

Help the little astronaut give life to a barren rock by planting, harvesting, buying and selling seeds and building up an atmosphere! ♥︎

Ava and Marte made an LD jam game for the 9th time in a row! Woah!


Skjermbilde 2017-04-25 kl. 05.03.06-kopi

Crossposting because unsure where people hang out now! Hope that’s OK!

[SPOILERS] Fun with shaders for LD37, part 3!

Posted by (twitter: @avaskoog)
Sunday, December 18th, 2016 5:03 pm

Hey! Posted part 1 and part 2 earlier about some of the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I decided to divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. This is part three, about two shaders that make use of UV scrolling (sort of) and number two is a spoiler, so do play the game first! c;


Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


Animated TV noise

In the small room that the game takes place there is a television set, and at the start of the game you’ll find that the screen is turned on, but showing nothing but static. Moving static, of course, and not just a frozen image!

View post on

So how does this work? We could of course have gone super fancy and generate noise programmatically right there in the shader, but since we were not looking to do anything procedural here, that was completely unnecessary, and we’re only using a static texture with the noise already in it. The movement comes from randomly jumping around (rather than scrolling) the UV coördinates! ᕕ( ᐛ )ᕗ

UV scrolling

What does it mean to “scroll UV’s”, or “move UV coördinates around”? Well, the UV’s are what determine where and how textures will map onto a mesh/model. By moving the x and y positions of the UV’s along the surface onto which a texture is being rendered, the position of the texture will move. There are many neat uses for this, so let’s look at a few before we move on, just to make sure you understand! (◕‿◕✿)

View post on

A waterfall is easy to achieve by scrolling a repeating texture vertically along a simple rectangular plane. In this particular case, there are multiple layers of textures moving at different speeds on top of each other, as well as some particle systems to help sell the effect further.

This next GIF was recorded from this YT video from the channel ClassicGameJunkie and their show How did they do that?, so go check that cool channel out! Its creator is also working on the 3D platformer Clive ‘N’ Wrench!

View post on

The flat, cartoony eyes in The Legend of Zelda: Twilight Princess are best animated by scrolling the UV’s of the texture around the flat geometry rather than trying to actually move any vertices.

The noise texture

I admit! The briefing on UV scrolling was a filler, to some extent, because there isn’t very much to say about it. It’s very easy, at least now that you know how the concept works! c:

When UV’s scroll enough that we’re able to see one repetition of the texture meet another, there are two ways to go about rendering it. It can either be repeated/tiled, or it can be clamped. You may have seen these option before when looking at a texture in Unity’s inspector. To make it clearer what’s going on, let’s look at the noise texture in both modes:


As you can see, clamping means that the last pixel of each side of the texture will be repeated indefinitely in the corresponding direction, while repeating means, well, repeating. This is what we want, since we want to be able to move to random locations on the texture and still get the TV screen filled up nicely with static.

The noise shader

Finally! As you would know, perhaps from the previous part, the basic way of going about shaders is to run the program on each pixel, or fragment, of something to be rendered, and process the final colour and alpha to output for each. To get the colour from the currently processed pixel, we just use the UV coördinate in the texture that we got from the previous part of the shader, the vertex part. Like so:

fixed4 col = tex2D(_MainTex, i.uv);

What we can do now is to add some numbers to the UV’s—an offset—that will move to a different part in the texture. We want this to happen in a way that looks random, and we want erratic jumping, not smoothly sliding over to the next part in the texture.

The thing to do when one does want to move smoothly around a texture would be to move by a constantly increasing value, like the game’s time. This might alternatively be plugged into some function, like cosine or sine, to move around in wavy or circular fashions.

We won’t do exactly that, of course, but we still need the time variable to have the conditions keep changing. What we can do to get the jagged movements we want is to make use of the modulo operator to see if the current time is divisible by some number, and use that as the basis of our stuff. We’ll even use some wave functions!

Since the rounded number will remain divisible by something until it has changed into something else that no longer is divisible by that number, we’ll be seeing each position where the UV’s end up for at least a few frames, which is of course what we want. We want this to change over time, so we’ll modulo the time by the time itself, but multiply each operand by a different number.

float factor = (time * 10) % (time * 22);

Something like that! That determines how much we move. Now to determine how far and where to move! We’ll use cosine and sine for this, again plugging in the time, multiplied perhaps by something else (or even nothing at all—i.e. 1.0—this time). This will make it move around in circles, but of course we won’t be able to see that as we only skip around on those circles.

float2 movement = float2(cos(time), sin(time) * distance;

The distance variable ensures that we move about a fair distance on the texture, so that the difference between each position is clear. And honestly, we might as well plug in something like time % 100 in there as well to make the noise as varied as possible!

And so we modify our initial line of code:

fixed4 col = tex2D(_MainTex, i.uv + movement * factor);

That’s it! Incredibly cheap cheating for some fake randomness that looks good enough for something like this, where the texture is already very random to begin with. I only used a texture that’s big enough to precisely cover the screen, but in retrospect I’d say this works even better with a texture that’s much bigger than the TV screen, to make any repetitions less obvious!




Thus you may want to play the game before you move on! c;




[NO SPOILERS] Fun with shaders for LD37, part 2!

Posted by (twitter: @avaskoog)
Saturday, December 17th, 2016 9:45 am

Hey! Posted earlier about some of the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I decided to divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. This is part two, about one of two shaders that make use of separate cameras and render textures!


Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


Inventory inspection

This one is not a spoiler! c:

When picking something up, or clicking something on the inventory bar that was picked up earlier, the player will see a 3D view of the item in question along with some descriptive text.

View post on

This view is rendered by a separate camera than the main one to get a nice 3D render of the spinning artefact. The main camera that renders the room (still visible behind the UI) cannot see this model, and the camera that renders the inventory view cannot see anything except the inventory item.

Separate camera setup

This is achieved in Unity by setting inventory items to a render layer of their own, and then unchecking that layer from the main camera, while unchecking everything except that layer on the inventory camera.


Then you’re free to render your inventory and your game world in the same place, without them actually interfering with each other, like so:


Render texture

Next, we need to create a texture for the inventory camera to render what it sees onto, since we don’t want it to render into the main game view and replace what the main camera sees. A render texture can be added by right-clicking somewhere in Unity’s file inspector and finding the option in the create menu.

It then needs to be connected to the camera, but we’ll not be using the field in the inspector for this, as it won’t work as intended. Instead we’ll be creating a small script that sets the camera up with the texture as the game starts. Something like this at the top:

[SerializeField] private Camera m_cam;
[SerializeField] private RenderTexture m_tex;

This way we’ll be able to drag and drop the camera and the render texture onto our script. Then as the game starts we’ll call this:

m_cam.targetTexture = m_tex;

Simple as that! Finally we’ll need to draw the texture somewhere so that we can see it. We’ll do this by adding a “raw image” to our UI canvas which will take the render texture as its sprite/texture, and that’s it. Now during runtime the UI will show what the inventory camera sees in that image, and we can edit the UI element as usual to get it to appear where we want it!

Remember we can also adjust the resolution of the render texture by opening it up in the inspector, in case the default 256×256 is too small, or has the wrong proportions.

The shader

You may have noticed we haven’t actually done any shader work yet! ヽ(゚Д゚)ノ

We can see there is a white border around the inventory item’s model, and also a circle behind it. But of course that’s not automatic. Without any shader, the inventory would now look like so:


Not very fanciful, nor stylised. And potentially difficult to see, depending on the background! And of course this game’s UI has a dark overlay, so we want that white border around the model to make it stand out nicely no matter what’s below!

Border shaders can be tricky or not depending on the circumstances. In our case we’ve got a mostly transparent image with some non-transparent pixels in the middle; namely, those that make up the model. This makes it simple: we look for pixels that are transparent but have an adjacent non-transparent pixel at a particular distance from it (which will determine the thickness of the border), in which case we make those pixels as opaque as we wish and then assign the border colour to them! (◕‿◕✿)

Remember that we get the colour of the pixel/fragment at any given position in the texture by sampling a UV coördinate. To get the currently processed pixel, we just use the unmodified x and y that we got from the vertex shader:

fixed4 col = tex2D(_MainTex, i.uv);

To for the alpha value of any pixel around this one, we need to offset the UV coördinate by as much as it takes to move on to the next pixel. We’ll start simple, by only sampling the nearest pixels above, below, to the left and to the right of the current pixel. This gives us a less smooth border, but is easier to keep track of.

UV’s are normalised between 0.0 and 1.0, so to get the size of a pixel at this scale, we will need to divide 1.0 by the width and height of the texture’s resolution (in pixels). If we want our border to be thicker than one pixel, we can multiply the result by some value.

fixed2 one = fixed2(1.0 / width, 1.0 / height) * thickness;

Now we can get the alpha values around the current pixel by sampling the surrounding UV’s and only storing the alpha value and ignoring the RGB components.

fixed left = tex2D(_MainTex, i.uv - fixed2(one, 0.0)).a;
fixed right = tex2D(_MainTex, i.uv + fixed2(one, 0.0)).a;
fixed up = tex2D(_MainTex, i.uv - fixed2(0.0, one)).a;
fixed down = tex2D(_MainTex, i.uv + fixed2(0.0, one)).a;

The case may well be that up actually means positive values rather than negative depending on your coördinate system, but it makes absolutely no difference to the end result of this effect, so we need not worry about it. ᕕ( ᐛ )ᕗ

Now we can accumulate alpha values by adding all of these together, then clamping the result to 1.0 and do some more maths to finish up, which will be explained below the complete line of code.

fixed border = min(1.0, left + right + up + down) - col.a;
col.rgba += border * transparency;

Finally we subtract the alpha value of the original pixel that we are currently processing.

  • If all surrounding pixels as well as the original pixel are transparent, the end result will also be transparent, and we’ll either get no border at all, or a semi-transparent border pixel, which will give a nice and smooth result so long as the original model was also rendered with anti-aliasing.
  • If the original pixel was not transparent, the border value will be reduced (all the way to 0.0 if the original pixel was completely opaque; otherwise a semi-transparent value) and the original colour will overtake the border, since there will be nothing to add when we finally add the border value to all of the channels (RGBA) of the final colour.

We can also multiply the value we add by some factor below 1.0 to only apply a semi-transparent border. Et voilà!


This border actually also samples pixels diagonally from the original pixel to make it even smoother. Note that this doubles the number of texture lookups, which can be slow, so choose carefully whether to add this extra overhead depending on the needs of your own application.

As you can see we still haven’t added that circle, but this post is getting lengthy, and you can get an idea of how to render a circle all in shader from the previous post. It’s one of the easiest things one can do, actually! Or you could just add a circle image to your UI below the UI image with the render texture if you’re not feeling up to it!


That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about some UV scrolling shaders (one of which is a spoiler) before we move on to the second effect in the game that required extra cameras and render textures, which will be a SPOILER, so play the game first! c:

Remain at the edge of your seat! ☆

[NO SPOILERS] Fun with shaders for LD37, part 1!

Posted by (twitter: @avaskoog)
Friday, December 16th, 2016 2:34 pm

Hey! They’re not all too advanced, but I still thought I’d share a little something on the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I’ll divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. We’ll start with the main shader that gives the game its look and feel!


Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


Post effect filter

This one won’t spoil a thing as it is the very first thing to see upon starting the game: the wonky colour effects and checkerboard overlay. There’s also a dark vignette as well as some increased contrast.

View post on

This effect applies to the whole final rendered image rather than individual objects and is therefore done in one step at the end of each frame, simply applying the shader to each pixel, or fragment.

Let’s go! ᕕ( ᐛ )ᕗ

The low-fi colour effect

This is achieved by first multiplying the colour values (which are all normalised between 0.0 and 1.0) by some factor, then rounding the numbers so that any resulting decimals disappear, and then dividing the values back down again by the original factor. This effectively decreases the colour variation. The smaller the factor, the greater the effect.

col.rgb *= factor;
col.rgb = round(col.rgb);
col.rgb /= factor;



The contrast effect is fundamentally not so complicated. It can be done in different ways, but for this particular game what I found worked best was to subtract some of the intensity of the colour if the original colour was below some tolerance value, but multiply it by some factor if it were above it.

col.rgb += (col.rgb < tolerance) ? 0.5 : 1.5;



Alternating dark and bright squares are all over the screen. This isn’t some texture; just a little bit of maths. By checking the position of each pixel on the screen and figuring out whether it’s even using the modulo operator (which gives the remainder of a division), we can figure out whether the number is evenly divisible by two and thereby whether it’s odd or even.

If we multiply the coördinates by some factor to pretend that the screen is smaller or bigger than it really is, we can control how big the squares get. We apply the effect by darkening odd squares and leaving even ones untouched or vice versa.

col.rgb -= ((floor(x * s) % 2.0) - (floor(y * s) % 2.0)) * darkness;



In this case, a vignette is a darkening of the corners of the screen. We’re basically applying darkness to the whole screen except an oval in the middle, leaving the corners dark but the middle unaffected. Circles are easy. We can achieve an oval by pretending that our rectangular canvas is in fact square.

fixed ratio = height / width;
fixed2 middle = fixed2(0.5 * ratio, 0.5);

We can then check the distance from the center to the current fragment, adjusted for the rectangle’s ratio, to get its position inside a circle, which will appear as an oval thanks to the ratio.

fixed2 pos = fixed2(x * ratio, y);
fixed factor = length(pos - middle);
col.rgb -= factor * darkness;


You will probably want to adjust some values by multiplying them by various factors to make your vignette look the way you want.

That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about the first of the two effects in the game that required extra cameras and render textures!

Stay tooned! ☆


Posted by (twitter: @avaskoog)
Tuesday, December 13th, 2016 1:41 pm

Click here to explore the room! (ノ◕ヮ◕)ノ*:・゚✧

View post on

An entry made in 72 hours by Ava and Marte. You find yourself with a severe case of amnesia in a locked room and need to figure out what’s going on. The story isn’t quite what we intended it to be, nor as long, due to time constraints, but hopefully you’ll get something out of it anyway! It’s a concept, after all! And it has wacky shaders and creepy audio, so who can resist? ♥︎

Click this post to read more than the excerpt, for some post mortem information and pictures of the process! ☆


Bedtime update #2 ☆

Posted by (twitter: @avaskoog)
Sunday, December 11th, 2016 9:29 pm

It’s about 03:30 on the second day, nearing the morning of the third. We’re doing the jam, so there’s one day left for us. Nonetheless Ava is already in crunch mode while Marte went to bed hours ago—there’s so much stuff to add to the room! Mechanics are mostly in place but aren’t really used yet since the room needs to be filled first, so enjoy a temporary bit of silliness in the meantime!

View post on

Going to bed! Current progress here!

Posted by (twitter: @avaskoog)
Saturday, December 10th, 2016 7:44 pm

Previous (and first) update can be found here.

Half of our team of two has already gone to bed and the second half is just about to. Spent the last hour or so messing around with a cheap post effects shader to get a somewhat more interesting look to the game than default Unity stuff:

View post on

Some of Marte’s models are finally in, tho not where they’re supposed to be in the end. This is still just a test room.

The contrast provided by this shader allows us to put details into textures rather than relying on stuff like normal mapping with a similar result, which is good enough, and saves a lot of time and effort. Will probably add some bricks to that fireplace, for example.

As you can see, the gameplay hasn’t really changed compared to the previous update. Back to working on that tomorrow. Will need to plan out the story and puzzle elements of this detective story a bit more too.

Good night! ☆

☆★ WIP detective story set in ONE room ★☆

Posted by (twitter: @avaskoog)
Saturday, December 10th, 2016 4:08 pm

⇒ Choo choo goes the LD hype train! ⇒

Ava and Marte are working on a game as always, this time not accompanied by Morten. Started a bit late after a good night’s sleep and most of the time on Ava’s part has gone to core systems, but we’re going strong. After some initial music work, Marte has for the first time done 3D modelling, in Blender, and has been churning out models with increasing speed as she has gotten used to the way it all works. c:

None of the models are featured in the below test room, but you can get an idea for how the game will work. You will be inspecting things and picking stuff up in order to progress and figure out what happened!

View post on

A semi-intelligent system makes it relatively easy to add new stuff to the room and have it working as intended.

Skärmavbild 2016-12-10 kl. 21.54.58

Our previous blog post this time around had Ava considering using p5.js for this LD, but as you can see above, we ended up using Unity instead, as 3D felt like the best way to cram stuff into a single room, and there wasn’t really time to delve into the 3D functionality of p5 this time. Better to focus on a better game using familiar tools!

Good luck to everyone! ♥︎


Posted by (twitter: @avaskoog)
Wednesday, August 31st, 2016 1:34 pm

Post mortem sounds depressing! And wrong—the game just came into being, did it not? c; Here’s something about our two-player explosive hockey game (Pucketeers of Atlantis) post jam, at the very least!

Do begin by having a peek at the game to have an idea of what we’re talking about in the first place!

View post on

Go play here~


What is it?

Let’s begin here and now. The final game we submitted for the jam. Well, you can see above. It’s a two-player game, primarily intended for gamepads, where each controls a team of three characters to battle it out in the rink.

The twist: a periodically exploding puck, and little item boxes that pop up from time to time that can be grabbed in order to be activated when the player is holding the puck (two of these were implemented: one making time go slower for everybody except the current pucketeer, and one making everyone else fall over, both offering a momentarily opportunity to go straight for the goal).

What is it not?

It is perhaps not the best take on the theme, ancient technology. The idea was that the puck and hover boots and items to pick up and some of the characters (robots) were supposed to be ancient relics of long forgotten Atlantis, but that is admittedly a stretch in the first place, and it’s not exactly evident in the game itself, but needs to be spelled out.

What could it have been?

The final game that you now see wasn’t entirely planned as such from the beginning. The original idea was “(J)RPG hockey”, and there were all sorts of wonky ideas floating around, including turn-based elements, strategy, stats and very exaggerated features of all sorts, as well as closeup one on one sequences when dribbling or tackling.

Not much of that stuck around, partially due to time constraints, partially due to reconsiderations of what would be fun to play, but at least the characters still look kind of like those of early Final Fantasy games (no time for proper human modelling, sorry!).

What can it be?

Extended! Brushed up! Packaged. Networked? There are currently some considerations to do a little more work on this game beyond LD, making it more fun, perhaps allowing a third team on the field at the same time, and perhaps even some rudimentary online play.

Who knows? Such projects have a tendency to blow up and not happen, but it’s a fun thought, and there will probably be some experimentation at the very least. We’ll see!




Posted by (twitter: @avaskoog)
Monday, August 29th, 2016 9:55 pm


Click here to play now!

Ava, Marte and Morten have once again magically managed to finish an entry last minute! No LD game ever ends up quite as was initially expected, but nonetheless we seem to be able to tie things up in at least some sort of way by working into the submission hour every time!

Pucketeers of Atlantis ended up being a kind of game that I don’t think any one of us would really play regularly—a sports game—but we figured it might be fun to play with some ridiculous elements. Like a Mario Kart version of sports! And indeed, that does exists in the form of Mario Strikers, and watching some gameplay we realised that that series had already incorporated a lot of the ideas we had individually thought up. Yikes!


Passing a puck! Oh, and collect those boxes to get power-ups to activate!


Ouch! Exploding pucks! Dangerous. Very dangerous.

If you feel like playing a neverending game of explosive hockey with Atlantean robots as well as non-Atlantean human beings on your team while wearing ancient Atlantean hover boots, then this might be for you! Oh, and a friend. Or something like that.

It’s a two player game—no more, no less.

You also need at least one gamepad, but two would be recommended, since that’s a lot more fun. We realise this might lead fewer to play, but perhaps we chose the right LD for such a daring decision.

Second update: JRPG hockey??

Posted by (twitter: @avaskoog)
Saturday, August 27th, 2016 7:09 pm

Hello again!

We posted an update earlier today with some very crude beginnings:

The trio is back! With sportsing!

We’ve now come a bit further, and 2/3 are asleep, and the last one is about to turn in as well. But how about a little update first?

Our first day has had work kind of separated so far.

Morten has been programming without any graphical assets:

View post on

Ava has been working on those assets by animating a character without any character designs, just animating the rig and club:

View post on

Marte has been trooping along despite feeling ill, designing some of these characters, explaining why the animations look a bit weird (getting up really fast after falling; floaty feet): they’ve got hover boots!


Woah! That hair. What’s with that? Well… Our idea is to make them very JRPG because our deal is to try and mix JRPG stereotypes with sport game stereotypes in a wonky way…

Maybe in the next update you’ll actually get to see what we have in mind for that ancient technology...

The trio is back! With sportsing!

Posted by (twitter: @avaskoog)
Saturday, August 27th, 2016 10:46 am


While others have been on and off, the three to usually jam together under this account are Ava, Marte and Morten. And such is once again the case!

Last times

So what have we done before? Among other things, this:


Many more jams have been made under this account (this is Ava’s 12th LD), but above is the collection of games that Marte has also participated, and starting from LD33, Morten as well. An Eva was also part of LD32, and an Ida for LD33.


This time

Ancient technology, eh? Well, we’ve got one for you. It’s a little bit too early into the process to show you the actual piece of tech, but we’ve got an idea and we got started some ten hours ago.

But basically, there will be sportsing. Sportsing with ancient technology. We don’t know much about sports, but let’s give it a shot. Isn’t this sort of what sportsers look like when they’re angry at the referee?

Skärmavbild 2016-08-27 kl. 17.21.31

There will also be slo-mo galore! Plot twist: it only affects certain things/players on the sportsing field sometimes.

View post on


Obligatory lists

Who, what, how, when and where? We’ll answer at least some of those, as usual…

Who does what?

Besides everyone contributing ideas, the workload is divided along these lines this time:


  • Marte: 2D graphics and music
  • Morten: programming and perhaps 3D graphics
  • Ava: programming, 3D graphics and probably sound effects

What tools?

  • Programming/editing: Unity (C#)
  • Synchronisation: git using SourceTree and Bitbucket
  • Music: FL Studio on Android, possibly GarageBand
  • Sound effects: Audacity
  • Graphics: Photoshop, possibly GIMP

What team?!


What team?!


What team?!




Jam entry: SQUIGGLES

Posted by (twitter: @avaskoog)
Tuesday, April 19th, 2016 7:10 am


Click here to go and play the game!

Hello! Ava, Marte and Morten once again teamed up for the jam. This time we ended up following the theme both mechanically (squishy, deformable octopus) and narratively (tadpole growing up into a frog). Help them help each other through this puzzly maze!

The game ended up having to be somewhat experimental in nature; emulating a squishy octopus in a rigid body physics engine was a bit difficult! It’s not entirely bug free when it comes to said cephalopod, but it was fun and worth trying.


Two thirds of us weren’t really feeling well this weekend, but we marched on! This did however mean that some of the details from our previous entries, like dynamic camera, little cutscenes and sound effects all had to go this time around, so it does feel unpolished there, but music alone actually sort of fits the mood of this game, so…

Have a play, will you? c:

Progress and checking if GIF still breaks~

Posted by (twitter: @avaskoog)
Sunday, April 17th, 2016 6:36 pm

Trying a .gifv rather than a .gif this time. Gets an ugly border but hopefully at least it doesn’t stop working after the first two or so views of the post like GIF’s have been doing lately…

Here’s the current progress of the game by Ava, Marte and Morten!

(actually it’s from a few hours ago and some more progress has been made since)

View post on

We’re following the theme both narratively and mechanically.

The octopus is the dynamic shapeshifter of the game, which is a mechanic. The tadpole gradually grows into a frog during the game, which is a narrative. You swap between them and use their respective abilities to solve puzzles and clear the way.

Friends tho they become, they cannot stay here together! :’c An octopus belongs in the salty sea water and the frog must stick to freshwater. Some nasty punk threw the bottle with octopus into this puddle.

Marte and Morten have already gone to sleep. Ava just wanted to do some final work on the frog, but now thinks it’s for the best that she too go to sleep not to fall out of sync with the others for the final day of the jam. Good night and good luck to all jammers!

Ava, Marte & Morten are in!

Posted by (twitter: @avaskoog)
Saturday, April 16th, 2016 10:01 am

I think these posts are much more fun to write when we’ve already gotten started a bit and can give you a hint of what we’ll be making this time, so here goes.

This is Ava’s 11th LD and her 6th together with Marte and 3rd together with Morten. Here are the ones Ava and Marte have done so far, Morten being present for the last two of them:


Who does what?

Our work is usually divided all over the place. This time it looks something like this:

  • Marte: graphics, music and level design
  • Ava: programming and probably sound effects
  • Morten: programming

Ava and Morten have both also done 3D graphics before, but we don’t really need that this time.

What’s up this time?

A game! We shan’t reveal the whole shenanigans for now (hint: certain animals shift their shape in one way or another), but we’re letting the theme inspire us both mechanically and narratively. You’ll see. Ava and Morten are currently busy implementing one mechanic each, while Marte is piecing together a level.

For now, gaze at glorious prototyping graphics that will be refined as we go (in order of who’s working on it: Morten, Ava, Marte):


(click here for animated version)


(click here for animated version)


What tools?

This one is apparently obligatory, or so the tradition says. I think it goes something like this…

  • Programming/editing: Unity (C#)
  • Synchronisation: git using SourceTree and Bitbucket
  • Music: FL Studio on Android, possibly GarageBand
  • Sound effects: Audacity
  • Graphics: Photoshop, possibly GIMP



Posted by (twitter: @avaskoog)
Tuesday, December 15th, 2015 9:09 am

Whew! We’re done, me, Marte and Morten! Last night got way too late and nobody could be bothered posting about the game until after getting some sleep. Good, belated morning! We present…


Play it! Play it NAO!

Didn’t really have the time to make the hair in game look quite as impressive as in the above artwork, but it ended up a fun mechanic to play with anyhow. Throw your hair in all directions to swing from golden plates and activate switches! Why? Your hairy godmother would explain, but there’s no time!

LD34_skjerm_foss LD34_skjerm_stemor

That’s our take on the grow theme, but the two buttons theme was also incorporated through this silly minigame:



[cache: storing page]