Deepvelopment Monthly #5 {July 2015} – To Die For

This Deepvelopment Monthly post will cover my work on Deep throughout July 2015. Lots to cover this month, I was extra productive!

Weapon Fire Effects -Visual
After honestly too long, weapons now have a powerful looking smoke shockwave effect on firing, the size and shape of which matches the weapon you’re firing. The recoil that comes with firing more powerful weapons is actually a pretty significant part of combat in Deep. This new smoke effect paired with the recoil really gives firing each weapon a uniquely powerful feel to it. Here are just a few examples:
gun1 gun3 gun4 gun2

Progress Report? -Content
After doing some tweaking to the way enemies spawn (especially in the early areas of the game) and which enemies are allowed to spawn in the first couple of levels, I’m happy to say that Deep is essentially completely playable from the start of the game right through to the second major boss! This is a pretty solid chunk of gameplay. It’s definitely not as polished as I want it to be for the final release but the fact that I can open the game, start a save file, and play for that amount of time without any bugs or incomplete feeling areas feels like a pretty huge achievement! More importantly I’m really having a blast playing it. The combat aspects of the game are coming together in ways I’m just super proud of and the random generation nature of the game means I’m constantly encountering new situations where I have to use the robot’s unique abilities in creative ways to progress.

Microchips -Content -Visual
THIS is what’s up. This is a feature I’ve been excited to work on since I started Deep and it’s SO exciting that it’s finally coming to life. Obviously the most important mechanic in Deep is the Microchip Installation System. It’s what makes your robot your own. If you haven’t been following the blog for long, here’s a quick refresher:
1. You play as a robot (it’s quite cute but it can’t do much):
2. You collect Microchips (there’s over 100!):
3. Microchips let your robot do cool things (and change the way it looks):

As of this month though, Microchips you have equipped will actually integrate onto your screen as part of your Heads Up Display. This provides useful information about how and what the chip is doing, and frankly just looks really cool! Let me show you what I mean. In the following screenshot I’ve equipped a Microchip called the Regeneration Cycler. It’s the little white and red med-kit looking attachment behind the robot’s head.
As you might expect it slowly but gradually restores your health. The attachment itself on the robot even emits little heart-shaped particles while it works! Meanwhile, you can see that the Microchip has plugged itself into your health bar and is filling it up as time goes by:
The Regen Cycler has to restart the cycle if your robot gets hurt, and it will only fill up one full heart’s worth of health before stopping. So having things like this bar on screen where you can see this all play out makes it easier to understand the more intricate mechanics of the various Microchips in the game.
Ultra Friction’s game-screen integration is another one I think is especially cool:
Since every player will be provided with a different set of Microchips to use throughout the game (and even two players who earn all the same Microchips probably won’t end up using the same ones), your game screen will become more and more unique as you progress through the game and reflect what kind of robot you’ve developed!

Death Animation! -Visual
Previously when you died in Deep, the game just sort of blacked out and sent you back to your last checkpoint. Now…
…Now the robot tragically and dramatically falls off to one side and lays there for a while before the fade out animation plays. It’s a little depressing honestly! Don’t let the robot die!

Map Generation Issues -Glitches -Programming
This isn’t one huge thing but a lot of smaller things that really add up. Basically I spent some time cleaning up weird corner-case issues where things like sloped terrain and spikes would interact in weird ways if the game wanted to generate a map that used both of them. Or hazards being generated in ways that were essentially impossible to bypass. It was a few days of work on this aspect of the game and not much else but it really paid off. I’m pretty much ready to call the random terrain generation aspect of the game essentially complete at this point, which is really exciting since it’s a huge chunk of the game I just don’t have to worry about anymore. Progress!

Cracking Animation -Visual
When I first introduced Deep a lot of people were asking me about comparisons to Minecraft, Terraria, and other sandbox-y games, probably because of the blocky tile-based terrain. In Deep though you don’t really do much brick breaking or relocating. There is one type of block you can destroy once you acquire the Drill Microchip though, and now the blocks will actually slowly crack and then shatter as you attack them, rather than just falling apart all at once.

Brighter! Higher Contrast! -Visual
You might also have noticed that the game is a fair bit brighter in these demonstration screenshots than it has been previously! This decision came after I tested the game on a few different monitors and found that some (especially those with higher resolution) made the game look excessively grainy and dark because of the unique static aesthetic the game employs. I hope you like it!

I hope you enjoyed today’s update (even if it was a few hours late!). I actually got even more done this last month, but to talk about it would be to delve into spoiler territory… That jungle themed boss I mentioned last update is finalized now for starters! And while I was working on all those Microchip-related features I couldn’t help but add a few new ones in of course. See you next month!


Deepvelopment Monthly #4 {June 2015} – Control Yourself

This Deepvelopment Monthly post will cover my work on Deep throughout June 2015.
I’m really sick right now, so you’ll have to excuse me if I’m a little less thorough than I have been in past months. Sorry!

Thin Platforms -Glitch
First of all, in April’s post, there’s a video where you can see that some of the health that came out of the defeated enemy actually falls through the thin platforms. Whoops it definitely wasn’t meant to do that!! Anyhow I fixed that one this month.

New Customization! -Content
This is a big one! A little while ago the arrow keys on my keyboard broke so I couldn’t test Deep properly. My quick fix was to change the game’s controls to let you use the numpad for movement, and that obviously worked fine, but the real solution to these kinds of problems has been implemented this month:
Yep, that’s a menu for Custom Keybindings!! You can now set the controls of Deep to whatever you feel like. The menu design here isn’t quite finished yet, but it works! The little letter key icons on the HUD will change appropriately too, and even the robot’s in-game dialogue to explain the controls will update itself to use the keyboard key you’ve selected.

Boss #2! -Content
So I promised to never spoil game content in Deepvelopment Monthly, so I can’t talk too much about this, but it deserved a mention since it took up quite a bit of time this month! The second boss is well on the way to being what I consider ‘complete’, and I have a tonne of fun playing against it. The aesthetics and polish aren’t quite at the level of Bandit yet so we’re not all the way there, but it’s fully functional. I will say that this boss is very jungle-themed, but maybe not in the way you expect!

…And back to Boss #1 -Visual
In the last update I mentioned that Bandit would be a very dynamic fight, involving the changing of the arena mid-match! I don’t want to go into too much detail about how this comes into play, but I finished polishing the visual effect for how that looks, and I’m really happy with how it turned out, so here’s a .gif!

Lag Reduction -Programming
One of the best things about coding a game’s engine from the ground up in a language like C++ is that you’re entirely aware of everything your program is doing. There aren’t any mysterious processes running in the background or function calls you use without really understanding them. This means that when your game starts experiencing slowdown, it’s much less of an ordeal to track down what’s causing it and find a faster way of performing whatever task is at fault. In Deep, when I want to perform some kind of action on any entity, the game has to figure out where in the big list of entities it is. Since my entity list is generated dynamically as the game runs, it’s in no particular order, and I can’t just always assume that the Player entity for example is the first item on the list, or that the Boss is the second or anything like that. I use a system called Tagging, wherein every entity has a unique ID Tag number that I can keep track of separately. To find an entity on the list, I just have to write code that performs a scan through the list until it gets to an entity that has the ID Tag I’m looking for! But if I’m having to do this multiple times every single frame, it can be pretty slow. So this month I spent a bit of time streamlining the process. In this new system, there’s a special check value that recognises if the list has been reordered in some way since the last scan. If it hasn’t, the scan just jumps straight to where it last found the Tag for that particular entity! It’s only a minor time saver for each individual scan through the list, but it certainly adds up when there are a lot of enemies, projectiles and other fun stuff going on on the screen.

Deepvelopment Monthly #3 {May 2015} – Bossy

This Deepvelopment Monthly post will cover my work on Deep throughout May 2015.

Bumper Bar -Content -Balancing
This wasn’t actually on my todo list for the month, but while I was playing through the game to test out [future content I can’t talk about yet!], I realised that the Bumper Bar was actually entirely useless against actual enemies! Its main purpose is to push boulders around so that you can use those as weapons, and it’s not really meant to be a super useful offensive tool on its own, but during my testing I was finding myself instinctively trying to use myself as a last resort to protect myself against close range attackers when I was low on ammo. But I designed it too small compared to the robot! I even tried making it stick out a little further at full charge but I just ended up getting hit by enemies more often than I could hit them. So I redesigned it entirely and I think it looks really cool now! Here’s a before/after comparison because those are fun.
(I also like doing these so that you can see how the visual style and animation has evolved!)
It’s much less choppy, the bar comes out faster, it’s larger and it has a cool dust effect!

Attached Projectiles -Programming
Some of what I worked on also had to do with projectiles! (again, sorry!) This time it was all about creating projectiles that could be easily attached or separated from other entities. It’s a little hard to explain in words, so I’ll demonstrate by showing off a new enemy type!

Snell -Content
Check out this guy! He’s actually not an enemy you normally find in the early game Caves. The reason the attachable projectiles were required to have him function is because of how he attacks.
You’ll see it’s the actual spikes and shell that you have to worry about, not the head. But they don’t stay attached to him!
As I demonstrate here, this isn’t really a problem you can tackle from close up, which is why you won’t be encountering them until a little later on in the game. Even if you use your bumper bar to shove a boulder at them, the spikes will often destroy the boulder before it can hit the Snell itself!

Bandit! -Content
This is going to be a long one!
If you follow me on Twitter (why wouldn’t you?) then you’re aware that 90% of the work I’ve done this month has been on Boss Battles! You’ve probably seen this guy before:
banditI’ve shown little bits and pieces of him before (the second ever post on this blog featured a very early depiction of him!) but you could consider this his official introduction. His name is Bandit, and despite his size, he’s technically an insect. He’s an evolutionary mistake though, and the only one of his kind, which is part of why he’s so gigantic. Here’s a little size comparison:
size(The robot is 1.7m tall, so this is a big bug)
Boss battles were one of the first things I implemented when I was coding Deep, so this fight has kind of existed for a while, but in a beta state. After this month’s work I’m happy to say that I’ve finished the work on the fight entirely! There are 3 increasingly difficult phases, which will test your puzzle-solving skills and reflexes. I’m REALLY excited about the boss battles in Deep, maybe more than any other part of the game. I’m trying to make them as dynamic, creative and unique as possible. I don’t want to spoil too much of course, but I will say that Bandit is the first boss in Deep. The exact location you find a Boss in will of course differ from save file to save file, but you’ll always encounter him in an Ice themed area early on in the game, and I can guarantee that you won’t have anything to battle him with other than the Bumper Bar you start out with! Even at full charge, that won’t be enough to affect Bandit, so you’ll need to get kind of creative… Things will get pretty crazy as you deal more damage to him, and through his sheer size and power he’ll be able to damage the arena you fight him in beyond recognition. That will, of course, play a key part in the fight’s progression. I’m getting carried away! But please please be excited for Deep’s bosses!!

Bandit Glitches -Glitches -Programming
The downside of trying to do unique and complicated cool things for each boss fight is that it means they’re really complicated to get working properly. Hence spending almost all month on just finishing up Bandit’s fight (and the second boss! He’s a secret though…). Boss battles generally do a lot of things in the game that the game engine doesn’t already support so you have to do a lot of hard-coding, which isn’t a term that refers to the difficulty level of the programming! When you hard-code something it kind of means you are programming it to work without the help of what the game engine already does. So for example, if I added a new enemy type that could walk up walls, I don’t have to hard code that, since the engine already supports it. I just have to flick a switch that says ‘yes this enemy type can walk up walls’. But if I wanted to make that enemy mess up your vision, there’s nothing in the game that does that, and my engine doesn’t really have any way of easily adding that feature, so I would have to write very specific coding statements that change the screen’s rendering under the circumstances of that enemy attacking you. As a general rule, you should avoid hard-coding things where possible, since it adds to the complexity of editing or changing your code later down the road if you need to, as well as the total size of your compiled code. Unfortunately with bosses though there’s not always a way around it, since the whole point is that they do things that are unique from anything else in the gameplay. What I’m getting at is that glitches are frequent when you’re working on bosses, and that for a while Bandit would do nothing but this:
…and that I couldn’t fix it for several days. It was tough.

Limiter! -Unrelated
Again, you’ll already know about this if you follow me on Twitter! But it’s pretty exciting news so I thought I’d include it here. I’ve actually started work on an entirely new side project. It’s a puzzle game I’ve decided to call ‘Limiter!’ (including the !), I’ve had a fair few people playtest it now and received pretty overwhelmingly positive feedback so far. It’s by far and away a #2 priority to Deep, which will be completed before Limiter!, but I have to say it’s nice to have a smaller scale project to work on from time to time when I’m feeling really burnt out on Deep. I’m not at the stage yet where I’m ready to publicly talk about the mechanics of the game, but here’s a cool .gif to demonstrate the aesthetic style I’m using!
aaand the logo!
This is definitely something you can look forward to checking out when Deep is finally all said and done.

That’s all for this month and I hope you’ve enjoyed today’s post!

Deepvelopment Monthly #2 – {April 2015} The Area of Effects

This Deepvelopment Monthly post will cover my work on Deep throughout April 2015.

The first thing I did this month and certainly the most immediately obvious change was add a very silly amount of sprited graphical effects. Things like dust flying out of either side when a character lands after a jump, little impact-circles when a projectile crashes into something, static looking sparks when you use a fully charged bumper attack… I had a lot of similar things in game a long time ago as a sort of test, but they didn’t look very good and I had to remove them anyway when I redid the engine framework last month… But these are all almost definitely intended for the final game. Here’s a video. I hope you enjoy! (It took a real long time to upload so I think that’s a good sign)

(Ignore the fact that I can just spawn an enemy wherever, and that my ammo is at 0. That obviously doesn’t happen when my debug tools are deactivated!)

Projectile Trails -Visual
Also of note in that video is that projectiles now have cute trail effects! A long while ago I mentioned that I was adding these but that the version of them at the time wasn’t final. It definitely is now, I think it looks really cool, especially with some of the… Larger projectiles that certain enemies will be launching at you. Actually! How about instead of implying things vaguely, I just show you, since it links into my next point…

Projectile Rotation/Resizing -Content -Programming
Projectiles launched by enemies can now be adjusted based on the size of the enemy!!

You might notice that even the little impact-circle effect that spawns when the projectile hits a wall is larger for larger projectiles.

Box-type Separation -Programming
So, probably the most impacting change this month was the separation of ‘hitboxes’ from ‘hurtboxes’ for enemies. You’re probably familiar with the idea of a hitbox in a video game, an invisible boxed area that the game engine recognises as being the space that some kind of object is taking up. There’s generally some kind of effect set to take place if two hitboxes overlap, for example, your player character might take damage if their hitbox is overlapping with the hitbox of an enemy’s projectile.
Deep is no different, and all enemies have differently shaped/sized hitboxes that the game uses to figure out “where they are”. If you attack an enemy’s hitbox, they take damage, and if you walk into one, you take damage. Most of the time this was fine, but with more complexly shaped enemies, this wasn’t working out. This enemy is a ‘Decback’, and those canons on its shell do exactly what you’d expect them to.
decbackBut after some playtesting they were proving too tough to beat. Not because of the projectiles they fired, but because even when I was above one, I’d get hit by bumping into the canon. So I tried removing the canon from the hitbox area, but that made them even harder to beat, because I could no longer shoot that part of the Decback to attack it!The solution was ‘hitbox separation’. The idea is that I can label some parts of the enemy as hitboxes, which can deal damage, and some parts as hurtboxes, which won’t deal any damage to me if I pass through them, but can still be hit by my attacks. It sounds like a tiny thing, but it’s really expanded what I can do with the enemies in Deep, and even more so the bosses.
Here’s a zoomed-in picture of another enemy design that benefited a lot from the separation, the Cite:
citeThe yellow box is the area that can deal damage to me, and the blue box is the area that I can attack to damage the Cite.

Damage Flash -Visual
This wasn’t really originally on my to-do list for the month, but since I was working with graphical effects a lot anyway, I felt like it was time to redo the damage flash, since it’s been exactly the same since I first coded enemies way back in March 2013, and honestly it’s always looked kind of bad. The damage flash is basically the visual effect on a foe or the player when they get hit by an attack. Check it out;
This animation is only in 33 FPS, whereas the game runs natively at 60, so it’s not quite as smooth and crisp as it actually appears in the game, but you get the idea!

Enemy Balancing/Playtesting -Content -Balancing
I can’t go into too much detail here unfortunately since I want these posts to be spoiler free, and I’m limiting how much of the content I show here… But given that I had to essentially redo all the enemy code last month due to the framework changes (check out the March 2015 post for more details), I figured while I was going back through each enemy this month I’d play around with a specially generated map that only spawned several of one specific type of enemy at a time, and do some playtesting/balancing! For obvious reasons this is the most fun part of development, and I really feel like it made a pretty big difference as well. I tweaked a lot of the enemies to be a lot more fun and fair to deal with, and had way more versatility regarding how I could program their behaviour due to the hitbox separation stuff as well. I’ve added a new section to the about the game’s difficulty, so check that out for more about the game’s balance.

Thin Platform Glitch -Glitch
This isn’t of huge importance but it took an entire day to fix so I felt like I should share my pain with you all a little. Mysteriously out of nowhere, a glitch appeared that allowed you to perform the down+jump input (this is the button combination pressed to fall through those thin platforms) even when you weren’t standing on a thin platform! You didn’t actually fall through the platform, but the robot animated as if you had, and if you held down the button the game thought you were constantly in a falling state and you could just sort of slide around the terrain. AND THEN when I fixed it, it created a new problem where the ‘landing dust’ effect was constantly emitted from your character every single frame that you were on the ground for! So I lost an entire day’s work to that. Incredible stuff.

Play Crypt of the Necrodancer -Unrelated
A very incredible indie game has finally come out of its alpha pre-release build and been released as a full game. It is called Crypt of the Necrodancer, and it’s one of the most original games I have EVER played, as well as being brutally difficult and infinitely replayable. If you haven’t already, go check it out on Steam!

That’s all for April (or at least, all I can show you!) and I’ll see you again this time next month!

Deepvelopment Monthly #1 – March 2015!

Welcome to the first Deepvelopment Monthly blog post, this time covering March 2015:

Ultra Friction: -Content
Remember way back in that first video of Deep, one of the first Microchips I showed off was called Ultra Friction? It’s still a pretty important one in the game, it allows your robot to climb up walls by pushing up against them. Falling off edges though was hard, because sometimes you’d want to just fall normally and sometimes you want to attach yourself to the side of the cliff and walk down the wall. You can now choose! Fall normally just by walking off, or hold the down key as you walk off the side to attach yourself. You can even do it on thin platforms, check it out:thin
You can also jump while on walls now! Obviously you detach yourself and don’t get to keep climbing the wall but I coded in some specific physics and momentum stuff for if you jump while attached so it feels really clean and smooth. Jumping while on the underside of a thin platform lets you do a little hop back up on top, which I think is pretty intuitive.
It’s worth mentioning that while I was trying to get all of this to work, the sloped terrain detection subsequently broke and fixed itself about 30 thousand times.

Ultra Friction… Bugs: -Glitches
However, I spent a LONG time dealing with this very irritating and inexplicable bug where if you walked off the right side of a cliff, the game would magically snap you back up into the wall and you’d just casually get sucked away into the wall.

So yeah that was cool. It works now though.

Zipping: -Programming -Glitches
There’s a cool physics thing that a lot of platformers, especially older ones on the NES, are known for doing called Zipping. This is where the game will detect if your player character is stuck inside of a wall and automatically push you a set distance away from the wall each frame until you’re no longer stuck. This was also accidentally very helpful for Mega Man speedrunners, who abuse it to rocket Mega Man off towards the end of a level at ridiculous speeds! Obviously being in the wall to begin with should never happen, and I’m fairly certain there’s no way to do it in Deep, but the Ultra Friction glitch I showed above got me thinking that I should code something as a failsafe to catch corner-cases like the above (no pun intended). I’ve found in development it’s always just smart to assume that basically anything you don’t think is possible in your engine probably is and you should code something to subvert it in case it happens. Now, after some very silly testing period bugs where just landing on a platform would make your robot vibrate all over the place because the game was worried you were inside the floor, I have a pretty solid zipping system! If you’re inside of terrain at all, the game checks all corners and sides of the robot to see which is closest to NOT being stuck each frame, and moves the robot a small amount in that distance each frame!

Outlined Objects: -Visual
Remember in old cartoons like Tom & Jerry where you could tell which parts of the set were going to be interactive and move and do stuff, because they had that really distinct brighter colouring and thicker, sharper black outline? I always thought that was really cool and I’ve implemented something kind of similar in Deep’s graphics engine!
I think it looks pretty cool! All objects that can dynamically move around have this effect applied to them, including projectiles and collectable items as well.

Debug Tools: -Programming
This is fairly simple, but very helpful and cool (and something I should have done a long time ago!). The game now has incredibly precise debugging tools for me to use, which let me pause EVERYTHING in the game and advance the engine one frame at a time, and control exactly what keyboard input I’m using on every single frame. This has sped up the process of figuring out what causes glitches by about x1000, since I can see exactly what frame something happens on, and exactly which input on the player’s end causes it to happen. If you’re making a game and haven’t done something like this, do something like this. Man.

Entire Engine Rework: -Programming
Alright… This is going to be a long one! This is a huge project that’s technically been underway since late February, and it’s something that I’ve needed to do since the game began. Early on I didn’t REALLY know what I was doing and the way I programmed a lot of important stuff in the engine, like how the game kept track of multiple enemies and projectiles, meant that lots and lots of unnecessary RAM was going into keeping Deep running, and made it really hard to program additional features for the engine. I’ll try and keep it simple and interesting: Basically, the game had this big (but not infinite) list of enemies, list of projectiles, list of graphical effects, so on so forth. Every time one of those things was spawned, it would take up a slot on the appropriate list. The game automatically keeps track of how much ‘stuff’ was on each list, and every frame it would go through all the lists and perform each required action (like applying gravity to the enemies, checking to see which projectiles were hitting something, etc). This seems like a good idea on the whole, but there are some major issues. The main one being that EVERY SLOT ON THE LIST has the same amount of RAM (or memory) allocated to it, even if it isn’t occupied by anything. Programs need to know how much RAM they might have to use, so any slot on the list that might have, say, an enemy in it, would have to be big enough to hold an enemy’s data. But I’d rarely (honestly never) need to use the entire list of slots, because there would never ever be that many objects in the game at once, so I’m essentially using this big chunk of the computer’s RAM for nothing! It’s also good to never assume that something is entirely impossible in your game’s engine, in case some player finds a way to abuse it. If you don’t code around that, then you’ll get all kinds of crashes or freezes or worse! So even though I don’t think those lists would ever have been 100% fill-able, the game wouldn’t have known what to do at ALL if someone did manage to spawn too many projectiles or something. The lists were a set size and couldn’t have coped with any extra stuff being spawned if they were full.
So! After a few very stressful days of doing basically nothing but code, and an entire week almost of Deep being entirely unplayable because the engine was only half-there, I’ve recoded ALL of how spawning, maintaining and working with objects in the game works! Using some clever tricks, the game now dynamically allocates only the necessary amount of RAM to take care of all the objects that are currently actually in the game (look up ‘container classes’, if you’re a beginner programmer who is interested in seeing how this is accomplished!). But wait, we’re not done yet!
Until now, because all the different kinds of objects in the game (projectiles, enemies, the player) are… well, different objects, I have had to code each of their basic functions (friction, movement, collision, hitbox interaction, etc) separately. This means when I coded in something new, say, sloped terrain, which I did just a few months ago, I had to basically write code for the same thing for each of those types of objects. Since I was rewriting half the game anyway, I took the opportunity to subvert this issue. Now at the core of the game, there is just one very simple type of object, called an ACTOR, which is essentially a single collide-able physical object of any size in the game. What I do now is that everything more complex, like an enemy or projectile, just has an ACTOR inside of it to do all of the physics stuff. Then all I have to do is code that universal physics and collision stuff into the ACTOR object type, and suddenly all the other things in the game have access to those same functions! With me only having to write them all once! Here’s my diagram from when I was working on this setup, to help explain (click to expand):

Deepvelopment Monthly Intro

Hi! I’m about to post the first in ‘Deepvelopment Monthly‘, an awfully named series of regular monthly blog posts. The idea is for me to run down all the work that I’ve done in a month, since I know how tough and frustrating total radio silence can be from a project that you’re waiting on.

Some Notes

  • I’ll be keeping it spoiler free! This might end up leading to some very weirdly worded stuff because I want to keep you guys in on the loop while also being vague about the specific content, but we’ll see how we go!
  • Some of you I know are really interested in programming and game development, so I’ll go pretty in-depth with the behind the scenes code stuff where I can, but I know others of you are only interested in learning about the game’s content itself. I’ll mark each ‘point’ with whether it’s about programming or content or both, so you can only read the ones that interest you! Don’t feel obliged to try and read all of it!
  • These posts will be mostly text unlike my earlier updates. The idea is that posting for you guys like this helps you stay up to date without me having to constantly pause development momentum to prepare intricate blog posts, and sometimes it can be really time consuming trying to get the perfect screenshot or perfect video recording. So prepare to do a lot of reading! There will be some videos or pictures if I really need them to convey what I’m trying to say though.
  • I want these to be pretty casual, so I won’t be over-editing or trying to make them sound like big professional PR posts. Since I won’t be doing early access for Deep, I can’t give you guys updated playable demos or anything like that to show you what I’m currently working on, so this is kinda like the next best thing. Think of it more like an in-progress ‘The Making Of’ kind of thing.
  • I’ll probably be doing this right up until the end of Deep’s… Deepvelopment. I don’t like the idea that someone might find this blog, see that I haven’t made a post in a few months, and think that I’ve abandoned the project, so hopefully from now on with this system it won’t ever be more than a month between posts!

I’ll post the March 2015 entry in just a little bit! Get excited!


Just a mini-update today, but I like to do these occasionally to make it clear I’m still alive and working on the game.


There’s something here you’ve not seen before in previous posts… Spike Pits! Deep is a video game, so as you might expect, falling into the Spikes is something you’ll want to avoid.

Spikes actually do a pretty huge amount of damage in Deep, more than most of the creatures do. There are definitely a lot of situations where you’re more worried about an enemy bumping you into the pit than you are about the enemy itself.

I like to think in the above screenshot that the robot is actually just stressing about how he’s going to get the Collectable down there… Well, as is the norm in Deep, there are a number of Microchips that would allow you to perform a feat like that. You’ll have to wait to collect them for yourself.

One more thing…


Not all Spikes are in convenient pits like the ones shown in the first screenshot. Some are just out in the open like this, and you’ll have to jump over them. So be careful!