We Are Alive


We Are Alive

Created: September 2015 - ongoing

Project Description:

After years of anxiously waiting for educational games that are as much games as they are educational to come out - Aleks finally gives up and throws his time and amazing coding skills (I'm kidding, they suck) into turning his old final year project into a game. A story of overcoming challenges, success and love.

Now then, what's different from 'The Amazing Adventures of Chloe Pikselle'?

There will be two playable characters - Chloe and Notchloe (wait-wait-wait, I'm still picking names). New graphics. New mechanics. Different structure of levels. So, really, it's a new game inspired by Chloe's adventures.


31 Aug 2016

Right then, a ‘We Are Alive’ update! This is not going to be a short post, but then again - this has been a lengthy wait. In the past several months I have not only changed jobs and made a new website which you are currently enjoying, but also research different possibilities for implementing audio in ‘We Are Alive’. I could go with the default option that comes with LibGDX, but decided that it would make sense to invest some time in understanding what other options are out there and how applicable what they can offer is to what I need. Well, and also, how can I know exactly what I need if I don’t know what’s possible, right? So these are the main tools I looked at:


FMOD seems to be one of the go-to sounds engines for developers of video games. Here’s some video-games developed with FMOD. It is a pretty powerful tool for playing and mixing sounds on a wide range of platforms. It also helps that it’s free for non-commercial and educational use, it is also free if you’re an indie studio with a budget of less than $100k, working on your first title. If it’s not your first title it’s still laughably cheap ($500).

The main issue for me was that it’s written in C++ and ‘We Are Alive’ is being written in Java. Naturally that’s not the end of the world, there are a few options available that have been around for a while.

There’s NativeFmod by Jouvieje, I think it’s distributed under the LGPL License. I suppose my main issue with NativeFmod was that it was last updated 5 years ago and I wasn’t convinced that I could easily get all the needed support for it if I wanted to.

There’s also fmod-jni, a cross-platform Java JNI wrapper distributed under the Apache 2 License. It is ‘experimental and incomplete’, but it is still getting updated. The project has a pretty good readme and is being developed for a game. I’ve tried setting it up and playing around with it, but in the end I felt that using a project that only has one contributor might not be the best decision.

After a bit more searching around I decided to try something other than FMOD.


PureData is something altogether different. It is a visual programming language made specifically to create interactive computer music. It’s an open-source project released under the BSD license and runs on a wide range of OSs. PureData is what you use if you want to have generative music.

The two main Java implementations of PureData are pdj and libpd. There are lots of written tutorials, youtube tutorials and introductions and interactive tutorials (these come with the download) on PureData. There is also a sizeable amount of examples kicking around of generative music made with it.

It’s definitely something that I would love to dive into as a separate project, but making it a part of ‘We Are Alive’ felt like massive overkill.


OpenAL (Open Audio Library), OpenGLs cousin. It’s an audio API and is really good at working with 3D audio. Years ago it used to be open-source, these days it is not. It supports a wide range of OSs and has been used in a sizable list of games. It is written in C, but when did that ever stop anyone.

JOAL is a Java implementation of OpenAL which I attempted to use. It comes with a handy set of tutorials, originally from OpenAL, rewritten to work with JOAL. OpenAL also comes with a pretty good and also massive Programmer’s Guide. It is a powerful tool, even though the method names for it are a nightmare to understand without a manual, but I guess it’s to be expected for a piece of software that allows you to represent fancy stuff like the Doppler Effect relatively painlessly.

After spending some time going through the tutorials and the manual I was convinced that this is going to be the option I am going to settle on until something caught my eye… So I was reading about OpenAL one day and came across the phrase that went something like: ‘LWJGL uses OpenAL’. LWJGL, by the way, stands for ‘Lightweight Java Game Library’ and is an open-source Java game development tool. Notably, apparently Minecraft has been written using LWJGL. But that’s not the point.

The point is - I’m using LibGDX to develop my game. LibGDX is cool, because it provides a bunch of neat extensions (an AI framework, a physics library, etc), and also because it can compile written code to run on Android, on iOS, on a HTML5 page or on the desktop. For the desktop it implements LWJGL. At some point in development I have decided that I’ll be making ‘We Are Alive’ only for the desktop. So by creating my own representations of the few bits and pieces of JOAL that I will actually need I’m literally reinventing the bike that already kinda came in the package.


And that is how I came back to LibGDX. By that time I knew what sort of functionality I wanted and, turns out, LibGDX could offer it to me. Here is how the audio in ‘We Are Alive’ works:


Sounds split into two categories: environment sounds and character sounds.

Unimaginatively environment sounds live in the environment. These are the sounds enemies, elevators, travellators and other stuff make. I decided to work with the assumption that the player is hearing everything the main character is hearing, from the position of the main character. So the sounds coming from the environment should be played relative to the player. Environment sounds can have pan and volume. They also have a hearing distance. As the source of sound gets closer to the character the sound simultaneously gets both louder and more centered.

Here’s how it’s done. The sounds for each non-player character live in the respective character class, originally. When a level gets created - all the NPCs pass their sounds to the EnvironmentSoundController. On each run of the game loop the player character passes its position to the controller and the controller decides which sounds it wants to play and what volume, pitch and pan values to use.

Perhaps it’s not immediately obvious that the volume is calculated as the length of a vector from the character to the source of sound measured as a percentage against the overall hearing distance. That way the loudness distributes equally in any direction from the source. Pan, however, is only calculated as a percentage of the horizontal distance to the source against the overall pan distance, because with the current setup a sound can only be panned to the left, right or center, but not top or bottom.

Character sounds are the sounds a character makes (what did you expect?). They programmatically live inside the character class. Those include: opening doors, collecting items, jumping, walking, falling. These sounds always happen in close proximity to the character, so they will always be centered, and, currently with a single exception, they will always be played at a 100% volume. The exception being - sounds of collision with the ground. It felt more natural that the less distance the character needs to fall - the quieter should the sound be. It seems to work well.



‘We Are Alive’ has three types of music. Threshold agnostic music; music with transitions and music without transitions.

Threshold agnostic is a fancy way of saying that it will keep playing with the same volume regardless of what the player is doing, as long as they are in the same room. When the player leaves the room the music stops. I honestly tried coming up with a better name for it, but had some red wine in me and the name kind of stuck.

Music without transitions is different. A room can have several musics defined. When the player reaches a certain threshold - music designated to that specific bit of the room stops and a track assigned to the bit of the room beyond the threshold starts. Immediately.

Music with transitions is a variation of the above. The only main difference is that the previous track does not end abrubtly, but instead slowly fades out with the new track slowly fading in.

Note that all the sounds and tracks you’re hearing in the video are temporary placeholders.

That about sums it up. That’s the audio side of the preparations done. Next step - code manipulation!

12 Jun 2016

Admittedly it has been a while (nearly 3 months). Most of the time that’s passed I’ve spent on personal stuff, like arranging a move to a new job. It’s all done and dusted now - I can finally get back to We Are Alive.

What’s new:

  • After the [nearly] 3 month break I have looked at my code and decided that it can be cleaner. So I have been gradually refactoring it, it’s getting there.
  • Through the magic of gitlab I now have builds triggering after every code check-in. Automation is great.
  • Did a bit of a research on third-party sound libraries and compiled a list of ones I should give a try.

What to look forward to in the next few weeks:

  • Cleaner code (I’m adopting a clean-as-you-go policy)
  • Unit tests (shockingly there are currently 0)
  • A sound library decision with a simple demo of it working.
  • An updated We Are Alive project page, let’s be honest the page you’re currently reading can be better.

21 Mar 2016

No video today, as I’ve made some changes to the code that make it quite impossible to run and see what the game looks like, you will have to take my word for it. Plus, more visual excitement with the next video, right?

New things:

  • I’ve removed my own AI logic and got the LibGDX AI libraries to work with my enemies. It was a lot easier than I anticipated, so I’d say enemy behavior creation is sorted and I can move on to other things up until work on visuals and specific levels start. Currently there are two enemies: a balloon that floats between specified points in the level (up to four, currently); a bird that hovers in one place, but starts chasing after the player if they get close enough, goes back to its initial position if the player gets too far away again.
  • I want WAA to provide means of creation of levels for the users, be that teachers who want to teach their students programming; parents wanting to teach their kids; or… you know… anyone, for fun. So I started writing up docs on level creation.
  • I wasn’t happy with the out-of-the-box implementation of parallax scrolling (see Demo #2). I’ve finally found the courage to address that. Hence why nothing is currently working.

What to wait for in the next few updates:

  • Shiny new parallax scrolling;
  • Documented level creation process;
  • Testing fmod integration, wouldn’t it be cool to have dynamically changing music/sound effects?
  • Console implementation.

Note that as I get closer to implementing the above stuff - there will be less and less stuff for me to demo, as my main focus after that would be on actual level and graphics creation. This is a long-winded way of saying that gaps between updates will inevitably increase.

07 Mar 2016

It’s that time again! Admittedly a day late, since I’ve been away yesterday.

So in the past two weeks I have done a simple implementation of an enemy based on the things I’ve read in the ‘Artificial Intelligence for Games’ book. I have then discovered that LibGDX has its own implementation of AI algorithms that the book talks about, so there is probably very little point in me writing them from scratch. The other change is cosmetic - there are now three looping background layers - each a silhouette of a city, generously provided by Beth Styles and shamelessly traced by my shaking hands in Photoshop. It feels like three layers provide more depth. I am contemplating adding a fourth one.

So what’s new:

  • An enemy + a decision to take a new approach with enemy creation;
  • 3 looping layers instead of 2 + a non-repeatable layer.

21 Feb 2016

Four weeks have passed since I started looking into AI for games. I know a little bit more about it now and, I think, got the general idea of where to start, as well as came up with a few concepts for enemies. For the past two weeks I was still reading through the ‘Artificial Intelligence for Games’ book, you can see my wall slowly getting out of control below.

​What’s new:

  • More sheets of paper on my wall.

What’s next:

It’s has also been four weeks since I wrote any code for ‘We Are Alive’, I’d like to change that a little bit for the next two weeks.

07 Feb 2016

Admittedly I know close to zero things about game AI coding. So the past two weeks have been spent reading through the second edition of ‘Artificial Intelligence for Games’ by Ian Millington and John Funge. I have a feeling it will take at least a few more weeks before I’ll be ready to jump back into coding.

What’s new:

  • Following a few requests to explain the connection between the code you write and the game that comes out - I made a video that should in theory give a high level understanding of hows and whys.
  • ‘We Are Alive’ related? Nothing really, but I can show you these photos of my notes:

What’s next:

  1. More research (I’ll keep you posted).

24 Jan 2016

After looking skeptically at my previous version of the overall map I’ve decided to put some time in making clickable areas on maps representing worlds and levels pretty. Surprisingly it took more time than I anticipated…

What’s new:

  • There is now a whole new bit of functionality aimed at just that. Clickable areas can be static or animated, can have as many or as few frames of animation, can be huge or tiny.
  • There is also now a separate class that makes the job of navigating between levels/worlds easier for me code-wise.
  • Finally, there are now collectible items. Currently they’re simple rectangles that the player can collect (think Super Mario Bros. coins), but they’ll be extended to also consist of items that will expand the list of commands available in the console and trapped rescueable people. Piece of cake.

What’s next:

  1. Do some research on what cool enemies I can have in WAA.
  2. It has been brought to my attention that for some the connection between code and a video-game isn’t as obvious as I assumed, so I’m planning to spend some time on a video to explain what the freak I’m actually doing.

10 Jan 2016

A few more new things in this demo. First let me explain the level hierarchy in ‘We Are Alive’. The first point of navigation is the overall map that is split into Worlds. The player can select the worlds that are accessible to them. Clicking on a world takes the player to the world map. Stop me if I’m being too technical. The world map is where the player can select specific levels. The levels themselves consist of rooms.

This odd room business is there to:

1) Have easily contained puzzles; 2) Simpler progress saving; 3) You know how you sit down to play a game and go ‘I’m just going to finish this one level to save progress and then go to sleep’ and then you’re stuck and before you know it - it’s the middle of the night, because the level took hours to figure out. Rooms are smaller.

So to sum up:

  • There is now a map (it will change visually and will have a bit more fancy selection stuff, but for now it works);
  • There are now doors that help the player move between rooms;
  • Because changing one room screen with the other doesn’t look sexy enough - there are now fade-in/fade-out transitions.

28 Dec 2015

Added a whole bunch of little stuff.

There are now:

  • Moving platforms (kind of a must for a platformer game, n’est-ce pas?): can be created through Tiled, can consist of any number of tiles, move horizontally or vertically, the movement speed can be defined in Tiled too;
  • Travelator platforms: also created through Tiled, can move the player at different speeds, left or right;
  • Mud tiles: slow down the player, decrease jumping height and disable double jumps;
  • Ice tiles: slightly increase player speed, slippery;
  • Bouncy-hover-whatever tiles: push the player into the air. Rectangle object in Tiled defines the area in which the player will be affected by the tile and the distance at which they will projected upwards.

13 Dec 2015

Today’s demo doesn’t have as much stuff as the previous one, parallax scrolling was a bit tougher to implement in a tidy way than I imagined, and someone breaking into my flat in the middle of the week didn’t help either.

So what’s cool about this demo? The levels can now have multiple background and foreground layers (can be more or less than in the demo). The console window can now be brought up and it has code in it (but it doesn’t do anything yet). And I’ve also tried to show how wonderful Tiled is for creating levels.

The ability to easily visually create a level in Tiled and then import it and have generic classes that only need to be written once handle all of the display stuff not just makes the process of level creation easier for me. It potentially opens the door to the possibility of user-created levels. Wouldn’t that be an awesome thing to have in an educational game? But I guess I’ll have to wait and see if that will still be plausible after all the functionality I want in the game is there.

29 Nov 2015

Most of you are like: Wuuut? ‘We Are Alive’? ‘Amazing Adventures of Chloe Pikselle’? It’s fine. It was an educational game I’ve developed as my final year project some time ago (if you’re curious - check out the video description). I was considering turning it into a proper full-blown game, but kind of didn’t because there was a massive amount of educational games that taught coding, most of them in development and looking promising. It’s two years later and I don’t feel like there are enough good educational games focused on coding out there. The stuff’s mostly educational, sure, but not really gamey (if this isn’t a word - I proclaim it one!).

And that’s where ‘We Are Alive’ comes in. I want it to be a fun, entertaining game first, and then have code editing/writing as one of its mechanics. Because people’s expectations, for some crazy reason, seem to motivate me better - I’m planning on doing biweekly demos of where I’m at.

This is the first one.