The Abyss

A game about a young man going down an endless well with gun-boots

So, this was probably an inevitable thing, given the nature of life these days, but I'm putting Abyss on hold for the time being. I want to pick it up a bit further down the track, maybe re-evaluate what I think it's going to be.

It's one of those things where I spend so little time actually being interested in doing work on it due to various factors that it's worth just taking a break from.

Some examples of the texture stamping technique I'm starting to go for. This basically just ups the number of usable tiles I've got by a fuckload without having do more work! I think I'll definitely revisit the background textures, though. There are a couple of problems I've got with those.

I haven't been keeping this blog as updated as I would've liked over the last few weeks. It's reached that period where not a whole lot of new stuff is going into the game - more of a refinement of what's there and iterating on various things to try and get things working right. So, what have I actually been working on?

Issue Tracking

I've been lacking a lot of focus on this project over the past little while - I feel like I have periods of time where things come really easy; that's where lots of new things go into the game, or the engine gets some cool stuff or things like that. Then there are other times where I just endlessly obsess over the tiniest of rough edges and iterate on it basically to the point of exhaustion. This is obviously not the best way to do things #captainobvious

So, I slugged down some cash to get a decent issue tracker. I use JIRA every day in my day job, so I thought I might as well use it in my... night job? I don't know, some people use to-do lists or run their own issue trackers or whatever. I'm using a pretty basic Kanban workflow (hi, Agile) and it works pretty well for me - at least this way I can keep track of where things are and how much more stuff I need to do to get something completed. Time tracking isn't really something I want to do, but the issues themselves are pretty important. I didn't want to come across as too much of a shill here, but it is what it is.

Pre-Alpha Blues

I made a little build of the game and gave it to a few friends with some mixed results. Just watching people play something you spent a shitload of time on and see what they do is an incredibly humbling and terrifying experience.

Every bug, every rough edge, every crash is put in the starkest of lights and at times it feels like everything you've done has amounted to a big steaming pile of garbage - but it's something you absolutely have to do as a developer. You can't just be in a bubble and expect things to come out amazing the first time; this game certainly isn't that, but I did learn some pretty key things - I won't go into too much detail.

Time as a Resource

This just turned out to be not that compelling a mechanic. Originally, I had a hard time limit in the game because I figured that it would give the player some incentive to push through - this worked out pretty well at its core; but then I introduced an item that would increase the amount of time remaining - this just threw everything out of whack. If you were halfway decent at the game (which isn't super challenging right now) then you could effectively never lose. That's probably not the worst thing ever, but the less risk there is, the less rewarding and less compelling the experience is - in my experience.

I got rid of it and put in the concept of having a set amount of lives. This is less interesting to me mechanically, but it's a far more consistent system that I feel can actively reward the player for good play.

The time mechanic is still going to stay in the game, but it'll be enforced in a different way that I'm yet to 100% decide upon.

Speedrunning and Spelunky

I watched a ton of AGDQ2014 over the last little while. I think it's one of the greatest and best things the gaming community is doing at the moment. To see so many people come together and play games at such a high level and raise so much money for a good cause is absolutely amazing to me and it inspired me to change a few systems in my game - not specifically so it could be played at that level - but to provide a way to compare how well people play the game. Taking inspiration not only from this, but from Spelunky as well.

The majority of systems in the game are randomized. The way that each of the levels is constructed lends itself to a pretty high level of variability and I want to be able to have a way for people to have a set challenge so they can compare their scores with others. So, I'm on the way to implementing a system whereby the randomization can be reproduced by way of a seed, rather than just whatever happens to be the seed at the time.

This gives me the ability to have game modes like a daily challenge like in Spelunky, which is just awesome; as well as having the concept of a speedrunner mode - something that I was thinking about when watching the Minecraft spot at AGDQ.

Speedrunner mode would be a specific level (based on a particular seed, or maybe even hand-crafted) that would remain static and constant for everyone that plays the game. People could then play that particular level and practice it to see who could get the highest score or finish it the fastest or some other metric I've yet to decide. Whether it picks up or not is not really up to me, but I still think having something like that in a game that is built around randomization could be pretty compelling.

Fix Your Damn Bugs

Half of the issues that I have in my tracker at the moment are fixes for bugs that have cropped up along the way:

Fix unloading and reloading of objects so the game can be run multiple times without having to restart (that was a massive problem)

Player sometimes clips through the environment at regular speeds

Entities cannot collide with the bottom of tiles

Full screen particle effects stop recycling in the game view port after a while

It's not always the best idea to optimize and bugfix when you're deep in development of new features, but the little bits of polish all add up to a much better experience in the end.

Little sketch I did recently for all the phases I've got planned so far for the game. I want to give each one some sort of visual identity, so they're not just defined by words - to make them recognisable at a glance - it's the UX designer in me that gets wound up about all of these things.

There are some ways that these phases fit in to the overall universe, but I want to avoid all of the lorelol stuff for the time being. Suffice to say - there's a reason why these phases exist - but they're there for gameplay first.

Previously on Stare Down the Abyss: the hero of the story attempted to implement a pretty basic deferred lighting system using basic pixel shaders and ended up hitting a wall of solid obsidian. I simply couldn't make it work, no matter what I tried.

I figure that if I spend enough time working on something, I can grasp a concept pretty well. It's usually just a matter of time before I get it - but this was a situation that really broke my expectations. After a solid week of trying to get this stuff working and failing; I was pretty much no closer to understanding how it all worked than I was at the start.

I put it mostly down to a single problem: I could not do any debugging

Waiting... waiting... waiting... (forever)

For some context: I was getting some really weird results with my shaders. Textures cycling all over the place, pixels rendering at random positions with random colours; even situations where parameters just weren't resolving in the shader at all. I'm not one to exaggerate, but I'm pretty sure I hit just about every single possible problem ever, and every single tool I tried to use just didn't work at all. Here is a list of everything I tried:

VS2012 Graphics Debugging Tools - stuck waiting for application to draw a DirectX frame (note that when I was preparing images for this blog, this actually worked - albeit on a completely different machine to the one I develop on - what the fuck mate?)

nVidia Nsight - stuck waiting for application to draw a frame. I had a feeling that this was probably because Mono has to compile shaders to the lowest common denominator - dx9 - where Nsight will only recognise dx10/11 code. That's just a feeling, though; I have no evidence to back any of it up

PIX - Abyss executable crashes on load - every time. This was basically what all forums everywhere said to use to debug dx9 shader code. I know there are some issues with running XNA 4 applications in PIX, but I used the workaround and the crashing continued. It was a very frustrating experience.

FX Composer - another nVidia tool that ended up having some stability issues on my computer. Not really sure what is going on there; might have to spend some time rebuilding my machine and try it again.

nVidia Shader Debugger - Had the same issues as PIX; would just crash on startup. At this point I wanted to throw my desktop through a window; so it's probably better that I just moved on. Although... I could do with a new machine...

The final thing I could think of to actually get any sort of help was to fall back on some oldschool techniques:

alert("this is the worst shit");

For those that don't instantly understand that and feel like vomiting: whenever I had some condition that I wanted to check, or some variable I wanted to see, I would basically return a colour value that represented a hit; like a shade of red or green. Much like filling all of your javascript with alerts so you can figure out why your code doesn't work for the millionth time: this is just an awful, inefficient, gross form of debugging - but it was all I had. No wonder it was so difficult to figure this stuff out. Actually, the more I think about it, the better I feel about it - this stuff is really fucking obtuse.

Typically, though - this wasn't the only problem I faced. I mentioned earlier that shader parameters weren't resolving. That was almost as frustrating as the general debugging issues I had, but at least I could figure out how to workaround it.

I'm going to caveat this with: this may not be factually correct, it's more my general understanding, so don't hate if I don't get it right but basically, in game programming, you have a rendering pipeline, where you do a bunch of passes to get a finished scene. With deferred lighting techniques, you would render your basic scene first to a buffer, do a lighting pass and then render the final result as a combination of the two. This is pretty basic stuff, and can be explained elsewhere much more succinctly than I could (my English Lit teacher noted my lack of brevity on... just about every assessment that I ever did).

Anyway, when you use XNA/Monogame, you use a class called RenderTarget2D to do render passes for a particular scene. You can then apply specific effects using shaders and what-not to these objects and create a nice, complex, effect-rich final scene. It's pretty cool how all this stuff works, but there are issues when you try to pass a RenderTarget2D through to a shader as a Texture2D parameter.

The problem here is that RenderTarget2D objects inherit from Texture2D in XNA/Monogame, but when you try to use one as a shader parameter, it just doesn't resolve - for some reason; so you have to do some gross rubbish and take a huge performance hit to get it to work:

You have to pull out the color data (ie: pixels) from the texture buffer, put it in a struct and then use it to set the data of a different texture. You're basically duplicating a texture here, which is weird because a RenderTarget2D IS A TEXTURE. Why this doesn't work is absolutely beyond me.

The weird thing here is that if you use a SpriteBatch (a basic XNA class that batches and renders sprites - super useful) and apply an effect to that, the texture you batch resolves perfectly fine - I suspect this is a weird bug that just never got fixed at some point; that, or I'm doing it wrong. Both are equally likely.

Long story short: I ended up ditching doing shader-based deferred lighting completely and opted instead for the tried-and-true method of using a semi-transparent light texture and made it additively blend to the scene. The result is actually really nice, and it took me about an hour to do after I finally decided that I'd had enough of feeling stupid.