next »

[The Sombrero Kid]

Hi, I've been meaning to syndicate my devlog here for a while, you can also read it at my website:
ratusapparatus.com

or my indieDB Page:


or The Rock Paper Shotgun Forum:
http://www.rockpapershotgun.com/forums/showthread.php?13255-Announcing-Alaska-from-Ratus-Apparatus

I thought I'd do a quick update with all the details I can give right now:

Overview
Alaska is an immersive sim with a dynamic narrative, you have been sent to a remote space station to investigate a murder, you must explore the station and investigate its occupants. Build a case against a suspect, but did you prove his guilt or have you made a terrible mistake?

• Immersive Sim - World is simulated and reacts authentically.
• Dynamic World - You are free to roam the station and observe the participants going about their day.
• Adventure Game - Use the Talk/Use adventure game style to progress.
• Agency Engine - Alaska uses my own Agency Engine, nothing is baked everything is dynamic.

Screenshots






Trailer




IndieDB

[The Sombrero Kid]

To solve the murder, you will have to find out what this machine is.

I plan on posting more regular development updates from now on detailing what i'm working on and where i'm going with it to coincide with my screenshot saturday posts.

This week I've mostly been working on a system where if an NPC is sleeping you can still talk to them by going to their room and pressing the call button, they'll answer the door and let you talk through your dialogue tree with them. I'm also adding a system where you can sleep to fast forward time, the UI for setting how long to fast forward to is an alarm clock on your phone. Finally I've been 'writing' the dialogue for the ending of the first act.

Things i've still to do before the next build are:

• Polish Pass on Act 1
• Make the Encyclopdia work, any datapads with historical background go here, like Mass Effect.
• When you meet a character their profile is added to the Contacts App in the Phone, and stores all the information you have on that person.
• Add Google Analytics
• New More Polished Trailer

Then I am going to begin work on a Greenlight Campaign.

[The Sombrero Kid]

Thought I'd add some of my gifs i've made of the gameplay to the page to give people an idea about how it plays.
Intro


On Screen Keyboards


All Lights are Dynamic & Shadowed

[The Sombrero Kid]

I've not had a chance to post development updates the last couple of weeks because i've been busy, I have a small list of things to work through before I put out a Demo, Trailer and Greenlight campaign.


Primarily I have been working on getting the UI up to date with the new style and removing all the programmer art, it's an ongoing process and there's still lots to do. Part of that is connecting up the functionality for the Mass Effect style encyclopaedia that reveals background details about the setting as the player explores and the Contact screen which holds all the details you know about the NPC's you meet as you find out about them.


I've also been writing and implementing dialogue for some of the NPC's, I hate writing the dialogue because I know how important it is and I don't have a clue what I'm doing. I had initially planned to have a relatively small selection of dialogue options and present them all to the player all the time, rather than having them tunnel through a tree, but this approach means you need to be quite careful about constraining the conversation too much and not getting to flesh out the characters enough. I'm still going to persevere with this approach as I don't think 'exploring' a dialogue tree is very fun, but if it turns out later that I need a lot more dialogue than can comfortably exist in one menu, I might switch.


The other thing I've been working on is Google Analytics implementation in C++ using Microsofts Open Source Cross Platform C++ REST API. I've already uploaded the Google Analytics code to GitHub because I think it might be valuable and it's small and clean. I intend to flesh it out further as time goes by, currently it only supports Events. Analytics is something in mobile we take for granted and is invaluable for measuring all sorts of aspects of where our game is failing the players. Most big studios have their own Analytics solution for their games but Google Analytics is fine for my needs and will help me learn more about how people play my game in the absence of any kind of testers.

[The Sombrero Kid]

There are 4 areas I've been working on this week:

• The flow diagram of the second act
• Dialog with Asher that links the first and second act
• Bug fixing and code cleanup
• finishing the encyclopedia functionality and updating more UI elements to the final UI

 
Story

The way I've been working on the plot for Alaska is firstly I had a general outline of what I wanted to happen, mainly based very heavily on games, films, tv shows and books I like. Those influences are primarily Blade Runner, Pathologic, Twin Peaks and Philip K Dicks books with Faustian themes, like Galactic Pot Healer and The Three Stigmatas of Palmer Eldritch.

I then broke the game into 3 acts, despite my belief that the 3 act structure is wholly unsuitable for interactive narrative, it's actually really difficult to break down a story any other way when you are a complete amateur, so I'm trying not to bite off more than I can chew with the writing.


    Flow Diagram of the Tutorial, Act 1 & 2, Blurred to avoid spoilers.

So dealing with each act 1 at a time I will draw a flow diagram of all the Key/Gate verbs in the Act and then go about implementing each one and marking it off on the chart as I go, as part of the flow diagram I will often write a chunk of supporting narrative that may or may not end up exposed in the game but is justification for peoples actions and when I come to writing dialogue in any of the steps on the flow diagram I will usually do the same and write backgrounds for the characters and justifications for what they say and try and give them more than just one dimension, again even if it's never exposed to the player.

So I've been doing that this week and it always makes me feel hugely out of my depth because unlike with the Art, which was more lack of interest than ability, I've never had an aptitude for writing and I don't think I ever could. So after working on story stuff it's always good to go back to the easy, comfort zone stuff. That being coding and UI grunt work.

 
Bug fixes

The code isn't very clean at all, one of the reasons it's not open source right now is I need to go over it and clean it up before I'm willing to let people see it. One of the most important rules I have that I just can't get myself to adhere to is no code in the header file. No matter how important I feel it is I just have a bad habit of not creating the cpp file when I make the class, so all the code goes in the header and compile times plummet. So with a mind to speeding up compile times after reading and implementing the recommendations in this blog post by Bruce Dawson, I decided to set about moving all the code that shouldn't be in the headers into cpp files and it makes me feel a lot better about the code cleanliness.

Second on the agenda was fixing some of the known bugs. There was a boring issue where there are 2 ways to pick up an object, one is by holding it in front of you and moving it around and the other is by putting it in your inventory and I had to make sure both these methods were supported for using objects on other objects. My favourite bug so far was where you could put NPC's in your pocket, carry them around and then drop them off elsewhere which was a trivial fix. and there was a fairly harmless buffer overflow when reading files from an ifstream that meant some of the text in the game ended in garbage strings in release mode. Buffer overflows are fairly common in code and are usually harmless, especially in a game. They can cause things like the heartbleed exploit everyone's banging on about these days but for my purposes it's good to get rid of it because it can mangle the heap if you're unlucky.

Finally keeping visual studio in check requires a lot more work than it used to, I link statically to the c runtime which means I need to build all the libraries to link statically to it too which means they need to be static libraries because dynamic libraries don't always link well to the static runtime, also since switching to visual studio 2012, I've had issues with conflicting versions of direct x in this new windows sdk it's started getting bundled with which effectively stopped gpu debugging tools from working so I've had to fix that by being very specific about the order they get included and linked and where they get included and linked from. Lastly Visual Leak Detector has been reporting false positives since I upgraded to 2012 and it's made keeping on top of leaks difficult, updating to the new version of vld rectified that though which means I can be certain there are no leaks again. All of this is very boring, very time consuming stuff, thanks Microsoft.

 
Encyclopaedia

most of the work on the encyclopaedia, as with all the menus is in lua, but there was one thing missing from the menu system that I hadn't gotten round to implementing - scrollable button lists. There is already scrollable text boxes and it was quite simple code it affects the inventory too which, before, had a maximum size. The other side to the Encyclopaedia is building the UI elements needed.

 

So that's everything for this week, No screenshots again this week because as you can see everything I've been working on has been pretty bland, I'm  certain there will be new screenshots over the next couple of weeks though, as I work on new stuff. I will finish up by linking to all my coverage I've had so far though because I've been meaning to get them all in one place for a while now.

http://indiestatik.com/2013/10/25/igf-entries/

http://indiegames.com/2014/02/_waldirs_inferno_by_jeni.html

http://www.indiegamemag.com/screenshot-weekly-alaska-iubes-the-last-federation/

Thanks to all those guys for the coverage, it's hugely appreciated.

 

 

[chris is balls]

This reminds me a bit of System Shock 2 and Doom3, what with reading and using PDAs, which hide clues, and the environment. Good luck with the rest, keep going!

[The Sombrero Kid]

As part of my relentless match to a release quality playable demo, I’ve been working hard on some underlying tech issues and feedback that were considered good enough for whiteboxing but definitely not good enough for the public.

The Key parts of this I’ve been working on:

• Audio
• Fonts
• Player Movement/Control
• Navigation & Signaling

   

Audio

Something quite obviously missing from the Engine all this time has been any audio whatsoever. Audio in Alaska has taken a back seat to Graphics, AI and other features because it’s not going to be integral to the experience, good audio is extremely hard to get right as people notice even slight defects in the production process. Which is why it’s not a great idea to focus on it if you know you aren’t going to be able to do an excellent job. Doing an excellent job costs a lot of resource and expertise. Saying that, no audio whatsoever is jarring and people find it difficult to engage with a world without it. So I’ve implemented a basic sound system built on Open AL which currently only supports RAW audio. It suits my needs for the time being but I will likely extend it to be able to support a container format like ogg later.
Fonts

I’ve been using the inbuilt Direct3D font rendering tech to draw text up until now and it’s unsuitable for production for serveral reasons:

• It has no shader pipeline support
• It’s slow
• It requires a draw a draw call to get metrics about a piece of text for formatting

For these reasons I’ve always had a mind to replace it with a better solution, Microsoft would prefer me to use Direct Write but as I’m switch from Direct 3D to Open GL later on I don’t want to couple myself to DirectX any more than I have to, so I’m building a solution with FreeType, which will enable me to use platform agnostic code to prevent me having to port the font code in future. This work is preliminary and I’ll likely be working on it over the next couple of weeks.
Player Movement/Control

For player movement I’ve been using bullets built in Kinematic Character Controller, which is not really considered release quality. I’ve had a couple of issues with it, mainly the player sliding down slopes and not being able to climb steps at low speeds. On the plus side it being open source means I can take it and make it work properly. I’m still working on the slope problem, but the step climbing problem was the more serious one. It meant I had to increase the player speed to levels that didn’t fit the pacing of the game and made it hard to position the player a comfortable distance from the screens in the game, as a result I got a lot of feedback about not being able to use the screens, the screens being too small or fiddly. When I came to make the screens bigger as part of the feedback I realised that actually the screens were a good size the problem was entirely sensetivity. I added a mouse sensetivity option and set the default to half what it was before but to give more sensitivity to the player position I had to slow him down to a sensable speed, losing the ability to climb stairs with the current controller. So I had to fix the stair climbing bug. It took a lot of digging through the bullet source code to find the issue but I tracked it down to the players step code sweep code not detecting collisions with short casts, probably because of floating point errors, so the solution was to change the step code to function with longer casts.
Navigation and Signaling

In my playtest feedback the tutorial, a very short low friction introduction to some of the basic mechanics, is holding players up a lot.

Some of the issues i’ve been seeing include:

• Ignoring the tutorial text
• Succeeding a tutorial without realising
• Misreading the lights cutting out as a bug
• Not reading the “notes” which are designed to provide hints about how to progress

I’m reluctant to force players to stop and read the tutorial text with a fullscreen popup, so currently I’ve simply increased the size of the tutorial window to make it more prominent, if later metrics show it’s still a problem I may force the text. I’m well aware of the weakness of using popups to train the player and I’ve worked hard to make a lot of the training implicit with the tutorial text as a fallback, my feedback seems to show that I’ve been successful at this as a lot of the basic controls were immediately obvious to the players.

As for succeeding a tutorial without realising it, I think this is an area where the tutorials are defined to broadly. The tutorials are currently satisfied if, for example, you pick up an object, but i’ve always intended them to provide a kind of breadcrumb structure. I wanted you to pick up a specific object but picking up any object satisfied the tutorial. It meant players veered off the course of the very linear tutorial (the rest of the game is very open but the tutorial is supposed to be linear to give you that elder scrolls moment when you finish it). So as a result I intend to reign the tutorial in even tighter, It really is something I want the player to glide through without any kind of friction in order to get to the world exploring as soon as possible.

The lights cutting out have been misread as a bug by several people and the reason is because it looks random and isn’t grounded in the world very well at all. One of the main reasons for this is the lights flicker in intensity randomly and there are no audio cues. I’ve already added an ‘shockwave’ push to the swing door, to both signal there was an explosion and that the swing door is a swing door unlike the other doors the player has encountered. I’m in the process of changing the lighting from going nuts and cutting out to slowly powering off and then the red dim emergency lights cutting in as well as adding a sound to the event.

The players haven’t been reading the notes in the diary when they are prompted I need to push them harder to look at them as it functions like a hint system for when you are stuck I intend to do this by rendering the last received note on the HUD until the player looks at the notes and adding this as a toggle in the options menu. I’m not a fan of HUDs and I’ve been trying to get by with zero HUD but as time has went by I’ve added a few things to it, like signalling when the player has a phone call or wifi access because I’ve had no sound so far, I couldn’t use audio cues nor do I want to rely on audio cues because I want it to be accessible to hearing impaired players, I will likely add a toggle for audio and visual hud cues to the menu also.

 

As well as continuing to work on these issues I’ll be adding sounds to the engine next and adding radios to the world that play music, I’m hoping to make the radios play a stream from a real radio station but I need to make sure the licensing allows for it and so far I haven’t found anything suitable.

[The Sombrero Kid]

Quick development update because it’s been so long since I’ve posted one, the primary reason for that isn’t that I haven’t been working on Alaska, it’s that working on Alaska, Family stuff and other issues I’ve got going on right now have left me WAY too busy to blog! Not to mention my annual Dota 2 International & Steam Summer Sale distractions that slow development down every summer and give me the R&R I need to go at a breakneck pace the rest of the year.

That stuff is all largely sorted though and I have got things to post about from my plan in the last development update I got almost all of it finished the only part I’m still not happy with is the notification system which is still too easy to ignore and the tutorials, which I’m currently thinking would serve the player better if they were in the world beside the objects they refer to. It’d mean they were easier to ignore when you’re not interacting with that object and harder to ignore when you are, people have a tendency to filter the HUD entirely when they are focusing on a task and I’ve found that had prevented people from reading the tutorials, I’m hoping this system helps point people in the right direction.

I’m also working on the notifications, adding the most recent text to the HUD until you dismiss it, currently by going into the notes section of the UI although I can foresee issues with that approach and might do a timed dismiss or add an easier way to dismiss them.

The final thing I’ll be adding is final map sections for the players ship, there is a bedroom and lab on the ship which haven’t currently been implemented and a basketball court on the station which also hasn’t been implemented, also I haven’t added any toilets at all and being an immersive sim tradition (along with the basketball court) It feels wrong to not include them.

Implementing the font system actually required a lot more work on the renderer than I anticipated, the previous font system was stateless, a major weakness, in that you couldn’t use shaders to manipulate it which has a lot of ramifications, including not using the same object space as all the other geometry, it had to be in a 2D plane on the screen. Rectifying that however introduced a problem, everywhere a font was used in the code with the new system would flip GPU states and cause the renderer to barely function after it was switched on and I went about introducing the fix.

The first pass on the fix was to swap all the state change code for state pushing and popping code and use a state stack. State stacks are common in graphics programming because there’s a lot of driver overhead in switching states and a stack can be used to help minimize that. The first pass on the state stack just set a state as it was pushed and set the previous state when one was popped, simple and SLOW! I couldn’t really live with making the engine even less efficient so I wrote some code to manage the states better it involved setting the state based on a comparison between the current state and the one on the top of the stack at draw time, meaning a push and pop without a draw between cost nothing in GPU terms.

After that I noticed I was currently creating the states as I was pushing them, even if an identical state already existed, which is also a source of a lot of slow down. I implemented a system where a state would be created once and reference counted between all duplicate pushes and common states where created once at start up, minimising both the number of states being used at once and the number of times a state was created, the system works well and is a good balance between not having to worry too much about the GPU state in game code and optimising the state switching. I still need to implement a depth peeling system to deal with transparency which will allow me to bucket the states better and reduce switching further, but that will affect the game code quite a bit so is less clear cut for wins/work.

I plan to have something to show in the next update after quite a long series of dry updates, it’d be nice to have  a new animated gif or two so I’ll hopefully get a chance to focus on something visual over the next couple of weeks.

[The Sombrero Kid]

Dare Teaser Trailer





Protoplay

It’s been a month since my last blog post, can’t believe how quickly time is going by and I’ve been working exclusively on polish, meaning the plan to have finished the second Act of the game by the end of the quarter isn’t feasible so I’m moving back the projected release date to the 2nd Quarter 2015, as always though and while there’s no pressure to finish it and less time to work on it the release date will move again if I’m not happy with it. I’ve committed to a playable build of the game at Dare Protoplay on August 9th and 10th which I’m excited about as it will be the first time other people play the game and will inform the direction of future development quite a lot.
Why the delay

I’ve been pretty accurate for the most part with my milestones except when it came to the things outside of the games development, which I have next to no experience with. The time it takes to produce marketing material has ballooned lately and it’s thrown off all my deadlines. Fortunately I’ve got to pressure to hold to them and a when it’s done attitude has always been on the cards. tbh I probably shouldn’t be public with my soft deadlines at all but if it helps other devs plan projects it’s a good thing and it costs me nothing.
Exhibit on a budget



I really can’t spend too much money on Alaska development right now and so I’ve been shopping around at where to exhibit and what to spend when I do. Where to exhibit is a pretty easy choice basically divide the amount you are spending with how many people are going to be there and then again by how many devs are going to be there and you get a very primitive cost per mind share metric, I’ve been looking at a few options between The Scottish Games Expo, Dare Protoplay, Rezzed, EGX and Develop. For me the maths don’t work for any but Dare Protoplay and EGX, The Scottish Games Expo was too new, Rezzed was too small when compared to EGX and Develop had a low public to developer ratio. Protoplay being the clear winner because it was free and being in Dundee will help me practice for any future exhibitions I go to.

So now I’m taking the game on tour what do I need to exhibit it. I settled on an A0 banner and t-shirts for exhibitors as well as my business cards and the game of course. I’ve already had the banners made up and they’re actually very cheap if you are on a shoe string and add a lot of professionalism to your exhibit. The T-Shirts weren’t that cheap as far as t-shirts go but I think it’s a good idea and I got them from Zazzle which means I can add them to a store page and other people can buy them too! The store page is at http://www.zazzle.co.uk/ratusapparatus* and will include other themed products like mugs too. I’ll be adding the store to my site soon.
What to prioritise

When exhibiting it’s important to have a build people can play easily without your input and that means, tutorial, gamepad support, and polished signaling. On top of that I will be filming people playing which I hope isn’t a problem for people, at the very least I will be watching and taking notes because the value of having other people playing your game is incalculable.

So if you’re around Dundee on August 9th & 10th come along and play the game! Give me feedback and maybe I’ll make a decent game! it’s also likely the first and last opportunity for anyone outside a select group to play the game for quite some time. EXCLUSIVE!

[The Sombrero Kid]

I know it's been a long time since I last put up an update, there's a bunch of reasons but mainly it's been because I've thought the greenlight build was right around the corner for so long but things that needed doing just kept popping up.

So what have I been doing on Alaska?

Well the main thing I wanted to do before getting the greenlight demo ready was swap in the final characters to replace the dodgy placeholders I've been using. To do that I had a lot of work to do but I didn't realise it. Basically I wanted to be able to use one skeleton and set of animations to control all the character but the characters come from the software I'm using pre weighted to their own skeleton, I spent a long time trying to set up an animation retargeting solution in blender failing, I still feel like it should be possible but I just don't know how, so I resorted to animating a master skeleton and then for each model moving the master skeletons bind pose to match the models skeleton and then swapping them over, it works fine but it's laborious. Then I had the issue that the skeletons for the new models are 2 orders of magnitude larger than I need them to be and blender has no way to bake the scaling of them without warping the animations which meant I had to extend my model loader to take in the master transform and bake it into the model at load time, this is working now but I've still got a few issues i need to resolve before I can roll it out to all the characters, mainly the walk animation moves the character (rather than letting me move them while the animation plays in place).

After that I've got a couple of content & prop passes on the parts of the map accessible in the demo, to get them to a releasable level of quality & block off the rest of the map, after that I'll release the greenlight build and start working on the trailer for the greenlight campaign which is by all accounts the most important part.

I was targeting this summer for the greenlight campaign but it looks like it's going to slip to the end of the year.

[The Sombrero Kid]

I know it's been a long long time since my last development update, almost a year! The reason is very simply because the things I've been doing have been tediously boring, at least to my mind anyway. Here's a brief summary of what I've been doing on Alaska for the last 10 months. I expect this will be my last development update before I start my greenlight campaign, I currently estimate i'll be ready to go on greenlight in July or August.

Anniversary

Last month was the 5 year development anniversary of Alaska, my original estimate was a 3 year project but I've changed jobs twice, got married and had 2 amazing kids in that time and those things all take priority, as they should. This is what it looked like 5 years ago:


It's come a long way since then. I'm pretty proud of what I've achieved, personally.

So What have I been doing over the last 10 months?

Moving Repo, Moving IDE, C++11 (Aug-Oct)

So the first thing I did after my last blog post was do a lot of long overdue clean-up. Moving to visual studio 2015, updating build flags and dependencies and generally tidying up the build. As part of that I also moved to git which has taken a load of as subversion is a pain to work with. I backed up all my source assets too. With the move to visual studio 2015, I can now support C++11 properly which meant I could clean up some crusty code.

Moving from Windows 7 and Visual Studio 2012 to Windows 10 and Visual Studio 2015 forced me to migrate from the old DirectX SDK to DirectX included in the Windows SDK. I'm still using D3D10 and effects. I'm not moving mid development and this meant reworking some stuff to work better with the new SDK & IDE. It's better in the long run but PIX still doesn't work properly with old effects and that's a nuisance.

This all took a few months but It was important because it made a lot of things that had become a slog less so and it was time away from the mammoth job i'd unwittingly undertaken in my last blog post, the dreaded character import pipeline rework.

Bug Fixes (Nov & Febuary)

Mainly as a consequence of changing lots of stuff related to the build there were a few weird bug fixes that needed addressed, I did some of these in November and some in February.

• BSP Loading was very slow (one small part was 75% of the load time)
• luabind threw exceptions in the destructor and vs2015 rightly didn't like that
• a couple of materials and reusing some render buffers were causing visual issues
• The Game Entities used their address in memory as their guid! Need real guids.

Fixing all these issues meant I had to do the job I'd been avoiding:

The Dreaded Character Import Pipeline Rework (Nov-Mar)



My character import pipeline is a disgrace, It is laughably fragile and I've paid dearly for it. If this was my full time job I would have allotted much more time to making it more stable but I figured I would only have to do it once or twice and so I could just suffer.

My import pipeline currently consists of:

• Build and Rig the characters in Mixamo Fuse
• Load the model in Blender and cut away all the hidden verts (teeth, joins)
• Reduce the poly count as much as possible with decimate
• Import the Rig with all the animations, repose & bind it
• Export the rig and all animations, one by one to collada
• Make DDS versions of all the textures

Alaska is quite rare for a small indie game in that it has 13 unique characters and this process is very manual, laborious and error prone. It took me a long time doing it manually before I decided to try and automate it.

By March I had generated all the Final Models and used a couple in the test map to prove them out. At this point I realised I could use python in blender to automate the export and It made one of the most laborious parts trivial, It really is easy to write scripts for blender and I thoroughly recommend it, this is the script I used to export all the animations:

Code:

 import bpy
import os

for action in bpy.data.actions:
    outname = None
    for object in bpy.data.objects:
        if object.animation_data != None:
            object.animation_data.action = action
        bpy.ops.pose.transforms_clear()
        if object.name != "Armature":
            outname = object.name.lower()
    root = os.path.dirname(bpy.data.filepath)
    if action.name == "Idle":
        file = root + "\\" + outname + ".dae"
    else:
        actionname = action.name
        if actionname.endswith("StrafeWalking"):
            actionname = actionname[:-7]
        if actionname == "Walking":
            actionname = "Walk"
        file = root + "\\" + outname + actionname + ".dae"
    bpy.ops.wm.collada_export(filepath=file)

A few loops around this script and the final models were in the game but something was wrong!

Human Readable Formats (March-April)

I always knew I was going to need to implement binary formats and now was the time, the final characters where massive collada files and they had a lot of redundant garbage in them. This caused loading times to explode to about 2 minutes if I remember correctly so I was forced to address the issue. I ended up making unified binary formats for the following files:

• skeletons
• objects
• atlases
• fonts
• bsps
• shaders

This reduced the load times to ~10 seconds and was pretty satisfying. There were quite a lot of minor bug fixes as a result of this and it took me into April.

Kinematic Character Controllers vs Nav Mesh Based Character Controllers (April - May)

I had been using a kinematic character control for the full length of development and while I was fairly happy with it, there were a couple of issues. Primarily I couldn't achieve the kind of control over it I wanted, getting pushed out of the way, sliding down surfaces, climbing vertical faces and tunneling where all issues i'd been fighting all through development.

Kinematic Character Controllers are good because they give you a strong connection to the physical geometry (walking into a door, knocks it open for example). Nav Mesh Based Character Controllers are good because they give you a strong connection to AI reasoning (If an AI decides he wants to go somewhere, he's not going to get stuck on the way).

Weighing these two options up I decided to take the plunge and try to remove and replace the kinematic controller I wasn't really happy with, with a nav mesh based controller. It turned out to be a lot simpler than I anticipated and now I feel like I have a good character controller which I can tweak much more easily without having to fire off rays and apply forces to.

Animatic (May~ongoing)



I had been looking for someone to do an animatic for me to help with promotion and to cement some of the themes of the game more firmly at the start to help the demo pop better. By April I had decided, as usual to stop waiting for someone to come to me and try and throw something together with my extremely limited artistic capability, it's ongoing and may not pan out but If I can manage to achieve what I'm after it'll really add something to the game I feel it needs.

What Next?

The greenlight submission really is coming soon (although I wont submit it until I am completely happy with it). To get there I need to block off the areas of the map I don't want the player going and finish the animatic, I also need to make an updated in game trailer and then make my greenlight page. Following me on Twitter is the best way to keep up with ongoing development, fingers crossed my next post will be about the greenlight submission!