I've got a lot of polishing and smaller interactivity done these last couple of days; mostly to do with interaction between actors.
Items are now in and i have a design for the simple GUI I'm going to use.
What I've been doing in-between all of that work is fighting with unity and some path finding implementations.
My main dislike of unity is that it does not support JIT debugging from visual studio; that being said everything else is pretty good.

Path finding has been my main blocker for the past 3 days, I'm close to a solution now, but it wasn't easy. I considered just throwing together my own A* implementation and i have done in my c++ days but i opted to try and use the community based solutions and hope i get a higher quality product.
There are some good implementations for unity out there but the ones looked at didn't do what i wanted or at least that's what i initially thought, turns out most of them will do what i want it's just that i have to use the source (or libraries) directly and try and fit my goals around the wealth of features i don't need in the libraries.

I was of the impression that because they were all singing all dancing implementations that simple a* path finding would be well...simple; It isn't and the reason it isn't is because they were designed to do path finding in the unity editor with levels and meshes that were preconstructed, which is a common unity workflow. I however am loading all of my levels at runtime and cannot rig a path finding mesh to a level that isn't in the editor.
Again this was mostly problems with my misconception of how they worked, I'm using Aron Granbergs a* implementation and it does in fact allow you to create a grid on the fly and pathfind manually, but it isn't well documented and the examples are informative but require time and understanding of how it's done in the editor so you can cobble together a code based implementation.

I am happy to be proved wrong on this point but it's been difficult to get things working in a purely code based workflow (sans editor).
I think I'm nearly there with the simple path finding and once that's done i can finish the integration with enemy ai and the game as a whole.

Here's quick rundown of my 11 days
Mistakes:
One of the biggest mistakes I've made on this project is to separate the code into an external library, it makes sense from an organisational point of view but it's made debugging things much more difficult.
Stack traces don't extend into external libraries so when something dies you only get the point in the unity solution where it died, having all of the game code in an external library means i made it 10 times more difficult for myself.
Having to put in debug lines for everything is time consuming and clutters up the console no end. What I'm doing currently is moving the code back into the unity solution itself so i can get decent stack traces on issues.
Another mistake i made was to not derive from the MonoBehaviour class; i unity this means you can then attach the script to an object which isn't needed for a lot of my internal classes, it also however means that i cannot make use of variable interrogation in the inspector panel within the unity editor and again I've made things difficult for myself.

The main point is that while i chose unity i was only really using about 30% of the functionality and nearly none of the editor features. This really became apparent once things got a bit more complex and i started to use the rendering and display features.
My intention was to create and external library so i could re-use bits and pieces in other projects but it doesn't really fit in well with the unity workflow. I don't think i was entirely wrong in my intention but i do admit I've gone about it backwards; i need to focus on getting the prototype working and then once I'm done i can strip out the bits i want to make re-usable, that way they are tested to some extent.

Good Bits:
Picking unity was a good decision overall, even though it is lacking JIT it does have many impressive features that make life a lot easier (yes i know you can do JIT from monodevelop but visual studio is superior).
Making lots of mistakes is good, any mistake made is something you've learnt for next time and I've learnt a LOT.
Actually getting things finished is a great motivator and while I'm still overshooting my estimates I'm still motivated to finish which is good.
Having done this prototype I've gained a lot of knowledge in what does and does not work within the confines of my initial design; once I'm done i can go away and update my design with all of the changes i need to make based on what I've learnt.

I'll also have a solid base with which to work on (or scrap depending on how much the design changes)
My initial goal was focused mainly on bettering my workflow, i did want to have a finished prototype but that was a means to learn better ways of working or at least to better understand how i already work. In this respect i succeeded, i now know that i work best when i feel like working. That sounds like an obvious statement, but i genuinely thought i might work better with some sort of structured timeline but alas, that failed miserably.

Future:
I AM going to finish this prototype if it kills me, once the path finding is done there's the system integration and path creation for character movement as well as a minimal gui and then I'm about done(well i suppose there's testing a bugfixing as well).
Once that is done I'll be reviewing my initial design and then I'll start work on the game proper. I'm still leaning to modularisation of the subsystems of the game, not so much for the re-use, more for the fact that i better understand things if they are separate and have clearly defined interactions.
As it stands i think I'm about 3 days away from finishing the prototype, so I'm going to have Sunday coming(8th May) as my new deadline to give me lots of contingency.
Once it's done I'll release an exe (or a web demo) for people to try, should anyone be interested in buggy prototypes with atrocious programmer art.

Writing these entries is helpful but it's a bit much to be doing one every day, so I'm going to be writing one every week (maybe increase it to 2 weeks at a later date) and I'll document the whole process of the creation of my game. I don't see a downside; maybe I'll release it in the documentation as part of a limited edition heh.

Thank you for reading if you have been reading, even more so if you've been enjoying.
I'm open to feedback, questions or suggestions if you feel like it.