• entries
11
• comment
1
• views
815

This blog is all the dev updates and info about RoKabium's new game "Something Ate My Alien" for PC, Mac and Linux.

We will be posting progress on the development along with other useful bits of info that could be of help to over Devs.

You can find us on lots of different platforms:

## SAMA Dev - Mag Blocks

We've finally finished a new game mechanic, 'Mag Blocks'.

These blocks are magnetized and attract (Blue) or repel (Orange) the Phys-Blocks in the puzzle sections. They can either hinder or assist you, and can make some of the puzzles harder to complete.

Initially blocks can only be pushed 1 tile at a time, but now as the puzzles progress, Mag Blocks will be placed as obstacles and you will need to figure out how to use them to help complete some of the puzzles.

Click the link below, to see a video of them working:

## Dev Blog #03 – Polishing the UI

UI is an important part of game design and is not always easy to get right.

When we started our game “Something Ate My Alien” we just dumped text on the screen to get the info on there without any real care of ‘design’ or aesthetics. Which was fine to start with as we just needed ‘functionality’.

We got to the point where the game was coming along nicely, but it was time to give some TLC to the UI.

We started with Kat doing some UI design in Photoshop to get things looking coherent and get the design right. Then she split up the bits into sprites and I would code it in Unity.

This worked well and saved us time I think because it was easier to get the design right in PS first, rather than spending time in Unity moving things around etc.

We made sure everything was easy to find without having to ‘drill down’ through too many windows, while also not allowing the screen to get too cluttered with lots of info.

We found a font that worked well with our design and we used the Unity Asset ‘TextMeshPro’ to do all text with as this was a great asset that helped us scale and customize the text easily.

Although currently we have only done everything in English, we have also kept in mind that we will want to localize it into other languages further along.

We’ve had problems along the way with Unity, as a couple of the upgrades caused bugs and issues that took some time to find which was quite annoying. Currently we have them all worked around, apart from one that I need to locate. Between version 2017.2 and 2017.3 one of our screens has dropped FPS from 1300 to 300, which is a significant performance drop, which I think is something to do with ScrollRects having a problem. At the moment though 300 FPS doesn’t cause us a direct problem, but it is something I need to look into.

SAMA contains 4 different worlds that you go through, and they are very different color schemes. So we also had to get the design of the UI to match them all. So we came up with the idea of using background images for the UI of the actual game worlds themselves. Kat hand painted them to match the worlds and then we select them depending of which world we are currently in. For smaller windows that pop up, we pick a random part of the background image, and use that for the window background. It seems to work well and make our UI now has a consistent feel about it, no matter where you are.

Another important part of UI, is the size of it, particularly the text size. In the beginning we had used a very small size, since we were using large screens (30′ Dell monitors and 2560×1600 res) and we didn’t notice too much. But it was hard to read on a smaller and more standard 1920×1080 screen. So we increased the font size quite bit, and that made it much more readable and easier to see. We have got a scaling system in place also that I’m hoping we can expose in the settings menu, so the users will be able to change the size depending on their preferences.

While making it look good, we also had to consider functionality, and keyboard navigation is an important part of that. Everything can be controlled with the keyboard or mouse. Some people like clicking, some like keys… or both, and it’s important that a UI has both.

We tried to follow what I would call the ‘windows standard’ of things, and make it work the way windows does, as most people are familiar with that. So tabbing between fields (including reverse tabbing), cursor movement between items in scroll areas, button positions and defaults, standards like Escape key closing any window etc etc.

It’s important to make the text on a button very explanatory. So if you have a window pop up for ‘saving’ the game, don’t just put ‘ok’ and ‘no’ on the buttons. Its much better to put ‘Save’ ‘Cancel’ instead as that is more clear what the buttons do.

As part of the UI we also updated the HUD to match the same design. All the important information you need while down in the worlds is displayed. Again, we will have settings that allow the scale of the HUD to be changed so that the user can tweak it. Also so they can remove it fully (or fade it) for screen shots or if you don’t want it visible during game play.

All in all, its taken alot longer than I had imagined to complete it all, but finally I think we can say that its mostly done now and is in a good shape. Hopefully we have created a great UI and one that our players will enjoy using.

Any comments and feedback is welcome.

## Puzzle me this – Alien Logic

Alongside fighting enemies and collecting loot for the pirate, there is a large puzzle element to our new game ‘Something Ate My Alien’.

The main objective of SAMA is to collect the list of items that the pirate has demanded you locate for him before he will release your ship. A lot of these items can be found by digging through the worlds, but a portion of the items can only be found by completing in-game puzzles.

As well as loot for the pirate, its also possible to find upgrades and boosts for your aliens, to help with the quest and make them stronger and more useful.

Each world will have different types of puzzles and so far we have only designed them for the basic first level.

Most blocks in SAMA are mineable and disappear once you dig them, but we have some special blocks that we call ‘Phys-Blocks’. These blocks can’t be mined, but you can move them around. You can push them left and right, and if you dig below them they will fall, killing anything below them.

In specific areas of the world, they need to be moved around and fitted into the correct ‘receptors’ and when they are all in the correct place a chest is activated and you can grab your loot.

Of course, while you’re doing that, there will be enemies around to hinder your efforts, and I’m sure that a Terrator will make an appearance and try to eat you if he’s feeling hungry.

If you get into an impossible situation with the blocks, then you can press the door button again, and this will reset the puzzle to the original configuration.

Puzzles in other worlds will also revolve around these Phys-Blocks, but different ideas will be used to make it more fun and harder. Phys-Blocks are also dotted around the world to block passages and hinder your exploration and to just make life a little more difficult for your aliens.

Now you’ve finished reading this, you’ll want something else to read I’m sure! How about a little blog about the ‘art’ side of things written by Kat. Click ‘here‘ to read her blog.

Also, hop on over to FB and give us a like on our Game Page or follow us on Twitter, and also if you haven’t already voted for us in the ‘IndieDB 2017 competition’ yet, click here and head over there and click the ‘Vote now’ button on our game.

Thanks for reading, and until the next entry….

## IndieDB 2017 Compatition

We’ve entered into the IndieDB 2017 Competition with SAMA!

Please click the link below and go over to IndieDB and vote for our game, it would mean so much to us.

Thanks for all your support.

Rob & Kat.

## Kat's progress blog about our game SAMA

A 2D digging, adventure puzzle game with some retro feel reminding us of the amazing first digger games such as BoulderDash that we knew when we were younger. That is the type of game me and my partner wanted to create as our very first joint project for our studio “RoKabium Games”. Both being avid gamers we hadn’t seen many games in that genre that focused more on the actual digging being the main element rather than being an action plat former or survival and crafting sandbox with the occasional digging part. So last year we started working and planning for our game “Something Ate My Alien”.

We knew early on that for a 2-person team to pull of creating a whole video game we had to have a planning structure for a game that wasn’t too large or complicated. So early ideas of making a full blown 3D, interactive, huge sandbox with multiplayer alternatives was just not gonna be a good starting point. We scaled down the idea of a huge concept and decided to rely more on our existing skill set in the game industry. We decided to focus on a more manageable core of that we ourselves would like to play and what we believed other people would also enjoy to play. A finite game story of about 6-10 hours game play from start to finish, something fun and charming with just the right amount of action/digging/puzzles ratio.

We also knew that our game would show quality and engaging graphics being hand painted by myself and it would all be done in a style that would ooze retro, hand painted, uniform and a beautiful game with easy to navigate and clear game mechanics and graphics. We wanted it to be a lighthearted but a addictive little gem suitable for a both younger and a more adult audience. Our game would be exactly how we envisioned it since it would be the labor of our own vision, not working for anybody else.

As a digital artist with several years experience in working for game studios and painting game assets, backgrounds, icons, characters etc and being part a team of other game developers, I did have some much needed experience in understanding just how much art is needed for a complete game. Even the smallest game contains more art pieces than you might think. For example, for every animation you do in 2D graphics you have to paint a new image and each animation can have anything from a very basic 5 frames up to 30-40 frames. So for each enemy you draw for example you need to also draw that enemy having an idle position, a walking cycle, a running cycle, an attack cycle, a dying cycle, a jumping cycle etc. So for one single enemy in a game you might have to produce up to around 100 images. Add to that, our game would have at least 10 different enemies for each level and we have designed our game to have a total of 4 levels.

Each game level or planet as it is represented in SAMA is built up with a set of ground tiles that has seamless tiling for a smooth and more realistic look. For each tile-set I’m designing 6 variants so the illusion of random and unique ground that looks like it is not repeating. Each world has 4 unique tile types to add variation for the digging mechanics and giving the player more varied game play. On top of normal ground tiles we have variants of 20 unique decals and edges created to blend different types of ground together better and adding even more realism. Inside the ground tiles you can as a player find all kinds of loot. So far I’ve designed 25 unique minerals, 9 different type of gemstones, 8 different kind of gases (each with animation cycles), 28 types of artefacts, 12 different types of complete fossilized animals which consists of 62 separate type of bones to find. There are teleporters, oxygen stations, health hearts, energy boosts, lamps to light up the dark caves, secret doors with puzzle areas to solve to get rare loot or upgrades. There are icons for every item and enemy you can find. All of these visual elements are hand painted by myself and still this is just the bare base of each planet level.

When designing the UI for the game we both wanted it very neat and tidy look, using our main colour scheme of blue-green-warm yellow that I first came up with during the conceptual art at the beginning of the project. I also wanted some elements to have somewhat of a computer screen/electronic look with glowing outlines to emphasize that you as the player are the actual AI of the ship and the UI you see is the computer interior.

While continuing painting and designing the artwork for SAMA we are getting closer to a first Alpha of the game and we are hoping that with the help of feedback from gamers around us and people interested in our game we can develop a game that is incredibly fun and beautiful to play.

See more over at our web site: http://www.somethingatemyalien.com/

## Dev Blog #02 – Smoothing a path for Terrator

The last week we’ve been implementing a new enemy in “Something Ate My Alien” called “Terrator”.

He’s much larger than the other enemies, and he’s a worm like creature that we wanted to randomly appear, work its way across the screen and ‘Eat’ our alien if he gets in the way.

Kat created the art, and split it up into sprites for each of the ‘worm’ sections, head, body and tail.

We didn’t want to create a random path as it was moving, because we wanted more control over him. So we decide to plan out a batch of paths that he should follow and then just pick one at random during spawn. To mix things up a bit, the path should be offset by a random number of pixels, and his start position relative to the path should also change. We also allowed it to be ‘flipped’ randomly to create more variation.

We planned out a path with about 15 or so points, and then used a smoothing algorithm called “Chaikin’s Algorithm” to create a smooth path.

Chaikin is nice and quick, not 100% accurate though, because of the way it works, the result doesn’t pass through the original points, but its good enough for what we needed it for.

It works by ‘cutting corners’ off each point to create a more smoothed curve, and then repeating 3 or 4 times makes it get smoother and smoother. We found 4 times was good enough to make Terrator animate smoothly in the game.

I found a C# example which helped, here: C# Smoothing Path

Although it was a quick algorithm, the implementation I found actually created quite a bit of C# Garbage, so I looked into re-writing it to remove any Garbage.

Now, rather than creating a new array on every smooth pass, you can pre-create an big array, and then it fills in that one array.

So now it was generating zero Garbage during game play. Yay!!

And as a bonus, with a bit of extra tweaking, I got it to process faster also. For 15 original points and smoothing 4 times, the original routine took about 1.22ms and allocated 3.3kb of Garbage. My new one took 1.05ms and allocated none.

Here is a video clip of it in game:

Here is the barebones C# code I wrote for Unity, to generate the smooth curve if anyone else might find it useful:

// Setup smooth info
int smoothness = 4;
int NumMainPoints = 15;
Vector2[] smoothPoints = new Vector2[(NumMainPoints - 2) * (int)Mathf.Pow(2,smoothness) + 2];

Vector2 startpoint = new Vector2(25,50);
Vector2 centerPoint = new Vector2(50,50);

smoothPoints[0] = startpoint;
smoothPoints[1] = startpoint + new Vector2(8,0);
smoothPoints[2] = startpoint + new Vector2((8 + 2),0);
smoothPoints[3] = centerPoint + new Vector2(-6.0f, 0.5f);
smoothPoints[4] = centerPoint + new Vector2(-2.0f, -1.5f);
smoothPoints[5] = centerPoint + new Vector2(1.5f, 0.5f);
smoothPoints[6] = centerPoint + new Vector2(5.0f, -2.5f);
smoothPoints[7] = centerPoint + new Vector2(2.5f, -5.5f);
smoothPoints[8] = centerPoint + new Vector2(-3.0f, -3.0f);
smoothPoints[9] = centerPoint + new Vector2(-4.5f, -0.5f);
smoothPoints[10] = centerPoint + new Vector2(-2.5f, 2.0f);
smoothPoints[11] = centerPoint + new Vector2(1.5f, 2.5f);
smoothPoints[12] = centerPoint + new Vector2(5.0f, 2.0f);
smoothPoints[13] = centerPoint + new Vector2(9.0f, 2.5f);
smoothPoints[14] = centerPoint + new Vector2(150, -0.5f);

ChaikinFast(ref smoothPoints, smoothness, NumMainPoints);

private void ChaikinFast(ref Vector2[] smoothPoints, int smoothness, int NumMainPoints) {
Vector2 lastVector = smoothPoints[NumMainPoints - 1]; // Save last point
int p = NumMainPoints - 2;
int factor = 2;
int lastPoint;
Vector2 offsetRight, offsetLeft;

// Loop through mulitple times to smooth
for (int s=1; s<=smoothness; s++) {
lastPoint = (NumMainPoints - 2) * factor;
offsetRight = (smoothPoints[p+1] - smoothPoints[p]) * 0.25f;

// For each point, replace with 2,
// with each one being 25% more towards the left and right points
for (int n=lastPoint; n>1; n-=2) {
offsetLeft = (smoothPoints[p] - smoothPoints[p-1]) * 0.25f;
smoothPoints[n] = smoothPoints[p] + offsetRight;
smoothPoints[n-1] = smoothPoints[p] - offsetLeft;
offsetRight = offsetLeft;
p--;
}

// Prepare for next loop
p = lastPoint;
smoothPoints[p+1] = lastVector; // Copy the end point to the end
factor *= 2;
}
}

## Bitiax solar system

As the AI of the mining ship Antalasia you are stuck in the Bitiax solar system while a pirate ship has taken control of your ship. To find all the items they demand you have to send down your diligent aliens to search the planets in this system for these items. Lets have a closer look at what the scanner says about the different planets that you can visit.

Tartarus
Underground conditions: Porous rock, lava flows, high temperature
Bedrock: 60% solid, 28% liquid, 12% gas
Civilization: Oris – advanced life form, emigrated into space
Items of significance: Rosium (gas), Wunderbat (gem), Hellium (mineral)
Advisory outfit: High performance, thermal suit and standard laser

Metis
Underground conditions: Metal rich ores, clay and alkaline water
Bedrock: 90% solid, 9% liquid, 1% gas
Civilization: Parpiuns – early development life forms, extinct
Items of significance: Fossils, Misty (gem), Inkium (mineral)
Advisory outfit: Standard suit and standard laser

Lelantos
Underground conditions: Hard rock, gas pockets, corrosive liquids
Bedrock: 54% solid, 2% liquid, 44% gas
Civilization: Mitania – colonization of life forms, abandoned
Items of significance: Rare artifacts, Eggium (gas), Lightium (gas), Whyium (mineral)
Advisory outfit: High pressure performance suit and advanced laser

Aura
Underground conditions: Hard rock, permafrost, super-cool liquids
Bedrock: 94% solid, 6% liquid, 0% gas
Civilization: Junits – advanced life forms, extinct
Items of significance: Rare fossils, Pale (gem), Lemoni (gem), Firmium (mineral)
Advisory outfit: High performance, thermal suit and advanced laser

## Back Story

You are the AI of a very skilled mining ship called Antalasia currently cruising the remote solar system Bitiax looking for mining opportunities. Trading is the cornerstone of the galaxy and some rare items can fetch large sums on the open market.

On board you have a cargo hold full of sluglike Aliens which are quite small, drooly and clumsy but also very efficient creatures that are excellent at burrowing through mines seeking out valuables. For every AI mining ship in this quadrant of the galaxy these charming Aliens are a vital part of the crew.

While peacefully scanning for elements on the nearest planet Metis, Antalasias systems are suddenly taken offline and the ship turns dark for a second before being booted up again with all computer screens flashing “Intrusion detected”.

A big, dark looting ship suddenly appears out of nowhere and a demand of takeover is distributed across all screens on Antalasia. It is an AI pirate ship that has infiltrated your computer system and it is now controlling your ship!

The pirate displays a list of valuable loot that has to be collected and turned over to the hostile ship for it to release Antalasia. The pirate gives you limited control back over your cargo hold, scanners and teleportation terminal so that you can get the items it demands. You have no choice but to send down your diligent Aliens to the various planets in the system to search out the minerals, gems, gases, fossils and artefacts the pirate wants so that you can get your ship back. Your Alien will face all kinds of hardships down there having to endure extreme and hazardous environments, hostile fauna and flora, hidden traps and areas only accessible by figuring out the ancient civilizations puzzles left behind in the tunnels.

Will you succeed?

## Meet The Enemies

This is a description and list of the current enemies in "Something Ate My Alien"

We plan on adding more and this is just a start to get us going.

#### Strank

One of the least aggressive enemies, it scurries around and has a weak bite. It as no ranged attack, and is easy to kill. Damage only comes from direct contact.

#### Oyse

A plant based enemy, which spawns on top of rocks. If it is left unattended, it will spawn more buds around itself. Can’t move, but if the rock below it is removed, it will fall to the next rock.

#### Damidon

With similarities to a ‘land-based’ octopus, Damidon is extremely fast and agile. It can jump much higher than most enemies. Its attack is to cover you in acid jelly that it throws out at you.

#### Ribbet

A bat like creature that flies around the caves. Quite small, but has a nasty bite.

#### Hatter

Sticks to the underside of rocks and does not move. Its tentacles are poisonous, but it also drops poisonous liquid on you if you get underneath it. If the rock above it is destroyed, it will kill it.

#### Arrog

A little creature with a hard shell. Extremely difficult to kill, unless you manage to get it from the underside. It fires out spikes from its shell if you get too close.

#### Ovaline

A putrid plant based lifeform that sits on top of rocks. It can’t move unless the rock below it is removed, and then it falls down. If you get close to it, it will release a cloud of stench so corrosive it will eat through your suit.

#### Growly

One of the smallest enemies, but flies very fast. Hard to spot in the dark caves so keep a lookout. It has a weak bite, but it can hurt over time. Easy to kill, if you can manage to hit it.

#### Eff

One of the biggest creatures around. Slow to move unless you get close to it and it breaks out into a charge. If it manages to catch you, you’ll surely have some bruises. Very hard skin, so it is difficult to kill.

#### Riverine

A small worm like creature that crawls along the rock surface. Watch out for its bite as it’s venomous. Easy to kill and quite slow movement.

#### Draker

Another large enemy. Runs around the caves and will catch you easily if you don’t watch out. It extends its snout if you get close to him, and you would be wise to keep away. Quite a sturdy specimen, and needs a lot of pummeling to defeat.

#### Creeble

One of the few enemies that keeps to the rocks, rather than the edges. They scurry around and if they get close to you they will weave a deadly web that will stick to every part of you. Best way to deal with these guys is to destroy the rock they are on.

#### Terrator

The biggest enemy you’ll have to fight. It lives deep in the rocks and you rarely see it, but he’s always there. If you stay stationary for too long, it will burrow out of the rock and eat you up in one gulp.

## First Dev Post

Thought I would post some info about the dev side of our game.

Its written in Unity3D and C#.

This is our first real project with Unity and C#, although I’ve been playing with Unity for 3 or so years on and off, but this is the first time I’ve really gone for it, so I had lots of learn, and still do.

We decided to split the game into 2 projects, the ‘Editor’ and the ‘Game’.

#### The Editor

The first one is an ‘dev-editor’ for us to design the game in.

This is where Kat builds the levels, and tests out graphics etc.

This project doesn’t need to be fancy and performant, but it gives the greatest flexibility for designing our levels.

The game is made up of tiled levels, currently at 150×80 tiles.

In the editor project, each tile is a GameObject, but this obviously quickly becomes a problem with performance for a game as its just too much to process. But it makes it easy to design with at this stage.

I’ve written editor tools that place tiles and help us build the levels.

Once we have a level how we like in the editor, we then ‘build’ the tiles into a dataset, which is currently just written to a SQLite DB, but I will be removing SQLite at some point and just create my own dataset file so that we don’t need the added problems that could occur with SQLite.

As well as building the dataset, it processes all the tiles and sprites into Atlases. In the game I create Meshes that hold 8×8 tiles, so that we get good performance and less Draw Calls. As Meshes come and go out of visibility they are put to sleep and culled by the cameras, so this helps greatly.

It also creates atlases for all the other sprites, like Enemy animations, Items, and other animations.

It does some rudimentary checks on the data, to make sure we haven’t created problems in the world, like placing blocks in strange positions or on top of each other.

#### The Game

Everything is prefabs and only a small amount is designed within this project.

It reads the dataset created by the editor and Instantiates all the meshes and tiles at run time.

As the player progresses through the levels, mined tiles, positions etc are all just stored back in the dataset when they ‘save’, so that it can be loaded back up again.

After doing extensive testing for performance, I found this the best way to go about trying to create such a large play area and giving the player the ability to mine anywhere.

I keep track of ‘mined’ blocks etc in a 3D array for each tile, based on the X,Y position.

One thing I had to also overcome was colliders. After testing, it looked like a major problem with performance was going to be colliders, because I just needed so many, since they could ‘mine’ a block from anywhere.

I looked into EdgeColliders and decided the best for performance was to create colliders ‘on the fly’. So the player and other important entities like ‘Enemies’ are continuously checking a 1 block square around them using the tile array, and create their own EdgeColliders within the 1 block square.

I found this was more performant, than creating colliders all over the place for each block, or one big collider that would then need splitting and re-creating every time a block was mined.

Probably one of my biggest problems to start with and using Unity and C# was garbage. Having written many business back end systems on huge Linux machines with 4GLs, I had never had to worry about this as it wasn’t a ‘thing’.

After seeing so much written about it, I started off with trying to create ‘zero’ garbage, and that probably took a toll on my coding times, as it was hard for me to see what was creating garbage, even with the profiler. And then it was another thing to try to understand if that was actually going to cause problems or not.

I suppose now, its good, because I’m mostly garbage free with the exception of a few things like colliders and such, that I really cant do anything about because of Unity design. But hopefully the Unity devs will get around to giving us more control soon.

When coding and debugging, I normally test with VSYNC off so I can use the FPS that I display on screen all the time as an easy notification if I have some problems with performance. Currently I’m on about 500-600 fps, and that’s on a fairly old PC (8 year old CoreI7 920 @ 2.67GHz) and running at 2K (2560×1440) resolution. It used to be up at 700 or so, but I’ve since added alot.

I know of a few things I could tweak more, that could save me performance if/when I start getting too low, but currently it does not warrent the time as I have no foreseeable problems.

I do a lot of pooling of GameObjects, so that I don’t have to create and destroy objects, and that has helped a lot with performance. Everything I need gets created on load, and then reused if/when they become redundant.

I’ve not really used any 3rd party assets, in fact the only one currently is the water that I use. But, I’m going to write my own version of that at some point to make it better and more performant. I had a bad performance problem with it to start with, but I hacked it about a bit to get more out of it, and now it behaves quite well.

I generally don’t like 3rd party products, as I normally have more problems with 3rd party code than if I just code it myself.

One area I thought I was going to have problems with was lighting. Initially Unity projects have lights limited to 4 per object, which just was not working for me. I was worried about increasing this, but with all the tiles grouped up into joint meshes, my draw calls were low enough that it didn’t seem to cause any problems with upping the number to 20. Of course, it has an effect, but it was one I could get away with, at least FPS wise.

Since our 2D animations are fairly basic, and I wanted full control of it, I wrote my own class to do our animations. Just a simple flip through the atlases that are created from the editor project. Animations are probably the area I might look into for any performance gains, as they are up on the top of the list in the profiler, but I’m not sure there is much I can do, as all they are doing at the moment is just flipping UVs.

We’re currently on version 5.6.1f1 of Unity, and I will be upgrading to the new 2017.1 soon, as I think there are some improvements to the 2D system that I could make use of. Over the last year I’ve been trying to keep up with regular updates, so that I don’t get into a situation where I need to take a long time out to upgrade. I’ve had little to no problems upgrading so far, so I don’t think it will be much, if any work.

We will initially be releasing on Windows PC. We have quickly looked into Mac & Linux releases since Unity supports this easily. However, we don’t want to promise Mac & Linux to be released initially just in case there are any problems which could delay us. But we currently don’t foresee any problems here.

We’ve been working on this now since Nov 2016, and back then we thought we would be finished by now, but as usual, IT projects just keep going. I think we need another 6 months now, until we will be finished, but we have just release a Dev Trailer video of the game, and a commentary, and you can find them here.

Next week after spending time doing all this video editing and vlogging, I will be spending time on implementing the bigger enemy that you see at the end of the Dev Trailer, as currently its not really in the game. Then its on to more work on the UI and interacting with the pirate.

If you have any questions, ideas or thoughts, then please contact us here as we would love to hear from you.