So I'm not talking about this project much. It's been a very long term thing but for a range of reasons I want to get this off the ground. for a range of reasons.

One interesting point is I'm finally working on Psybrus, an engine built by @Neilogd

We used to work together so I'm familiar with his code and I like the way his code works. Psybrus gives me a stable, small and extendable basis from which to build out this project and the future projects. This project will have a few deadlines and milestones, and I'll post progress but the big picture and purpose shall remain behind the curtain on this one.

Currently I'm using 3rd party software to uploaded some security web cam footage. Sadly I have the Belkin cameras which don't play nice with 3rd party software and have some documented software exploits. I've hardened my network and tweaked with the cameras which account for most the problems though now once your on the wifi you can get to the camera feeds but I'm okay with that level of security.

Previously I've used OpenCV for image work but its C libs and dependicies would muck up this pure go project with platform specific dependicies which I don't like. I might still go with OpenCV approach but otherwise I might implement some image functions into a Go lib. This is more an experiment than anything as I do have a 3rd party solution. It did provide some interesting learnings around MJPEG.

So Ducky has been using a Google Drive script to track her daily writing. It's buggy I've had to fix it and honestly it doesn't do all the things I would like. For a few reasons like plugging into external API and tracking non-google drive wirting in the future I started writing a Go Tool which plugged into the Google Drive API and buildinga word count report. It's been interesting to plug GoLang into Google API which is obviously clean and slowly building some report stuff. This is a project I chip away at and I'm mostly happy with it. Also used BoltDB as my first GoLang with DB work. Useful to learn from.

I want to put in a Twitter api hook and multi-user support. Make it a bit more robust so I can pop it onto a Raspberry Pi and forget about it.

Part of the #GBJam I decided to build something for Pebble watch but also to start playing with SDL2 in a real way. This is part of my ongoing move away from Unity and similiar for my home projects. For the range of reasons I covered in my Wizard post. It was a good experience but I spent a lot of time muddling with Android toolchains and getting workflow stuff setup.

I hope to come back and finish this before the year end but what's more I have a stable small SDL project base to work from for Jams and other projects which is really useful for me.

So KBot is an interesting project which I want to take up for both personal and work reasons but honestly it's been pushed to the back burner.

It's been an interesting learning project as we still haven't deployed anything with Go at scale yet. So all these learnings are good and its a good sandbox on which to launch a bunch of other stuff. Also a lot of the code has been lifted into my other Go projects.

Sick and tired of Wordpress updates, limits and such I moved the site over to mostly AngularJS.

That caused issues with indexing and other structured data problems, so I decided to look at Jekyll

I happened to be working with Go at work and thought the template libs so solid that it would be trivial to do in Go.

It had the added advantage of any custom logic being simple to add.

Implemented a Cards against Humanity style game on Web & Mobile using Google App Engine and Javascript frontend.

Didn't productionise it because the game depends heavily on its social element.

Snowman loves Kitty is a small story about a Snowman falling in love with a kitty in a snowy backyard that is INCOMPLETE :( Made for Ludumdare 31.

Tools: Javascript, Photoshop, no libs

The snow sim was working great till I discovered a few limitations which I banged my head against most of Sunday so it's just a TOY. Experiment and play around. I'll try upload a non-compo version later with complete story on a different link.

Also for anyone wondering I just had to save the most down voted themes: There is no floor, Love, Kittens & Snowman as well as entire game on one screen ;)

Whoops

The concept was a text game of the sort playable in SSH but done in the browser.

You were to command an army but entirely using textual reports which are done with natural language and imprescise.

This was based around how difficiult would it be for a real medival general in a tent without a birds eye view.

One of the more fun LudumDare games I've made you dig up Dinosaurs from the earth in a very calming game. The digging aways layers of earth presented an interesting problem in data and mesh generation. After fighting with Unity shader model I reverted back to a 2D version of the gameplay.

After the weekend I discovered the sub mesh method which wasn't working due to texture sampler not being supported in Shader Model 3 was because I was in HLSL 3 and didn't have some console specific stuff I was used to. Post Comp I am looking at both a DX11 and Ray Marching implementation. This is my current tinker project when I get a few hours.

Climb up a burning building to save as many people from the top of the building. I used this as a chance to explore the 2D toolchain and new animation tools. Lost most of the weekend to building the 2D character and art fiddling more than I should of. Also the building generation is just a noise algorithm it really should be game defined tiles. Overall I'm happy with the gameplay in the time and it was a good way to learn 2D workflow on Unity.

Three colours and one touch try convey a series of platforming and stealth levels. The jumping was quite floaty in the game which broke the feel of the gameplay. Though it was interesting doing a minimalist mobile game. The stark colour schemes and art style meant no time was lost to content creation. Most the time was spent trying to get Unity physics to work just right.

In an empty flat with no furniture a mobile phone and a Chromebook, can you make a game in a weekend? Turns out yes! It was entirely developed in Chrome then uploaded in bursts through my phone. The game is a management of criminals running jobs. The gameplay failed mostly as the flow wasn't very intuitive.

Working with plain javascript provided a poor framework and my tools provided a greater challenge than expected though if I were to do it again it would be much smoother.

I wanted to explore what it was like working with Javascript without any libraries and develop directly in Chrome. Following the previous experiments in Javascript I wanted a more visual art driven experience. The theme was a bit tricky but I really enjoyed exploring the life cycle of a mosquito with different controls. I wanted to branch out into a more experimental style.

The idea was to make a Jam game as a love letter. The first physical game jam I did at Cambridge CB2. The concept was to build an abstract mesh from a message, then break it into pieces to form a puzzle. The player then rebuilt the puzzle revealing the message. It was going to be the first time I said openly expressed my love to my girlfriend.

The Concept was solid but unfamiliarity with Unity, and the physical game jam environment where my downfalls. You get a lot less time due to travelling to the venue and socialising. Also again the choice of an unknown tool introduced too large a hurdle for a 48 hour game jam. This did lead to further exploration of breaking up meshes using Delaunay triangulation which I have on my interesting list of things to explore.

After failing to complete LD14 I returned to PTK and C++ for speed and familiarity. The procedural cave system proved to be quite successful providing fun and interesting layouts. The gameplay was light but I really enjoyed this title.

I used a form of cellular automaton to generate the caves. Starting with noise successive generation breed open rooms and shapes. With every few generations some custom logic to ensure spaces are linked and providing interesting combination of open space and maze by linking or seperating spaces.

An incomplete entry it was a fun exploration of Python with GL. Pyglet is a lite windowing system, which allows easy OpenGl usage. The premise was a neverending platformer as you climbed a tower.

The first LudumDare entry it was the the first time I had made a game in 48 hours and I really enjoyed the format. I've since become a frequent entrant into LudumDare. I find the format invigorating. Developing a game in 48 hours with no prior code or art provides an interesting challenge. Much like a musical game or script workshop you abandon structure to be creative within a tightly constrained deadline.

While doing a game development podcast in University I was tutoring some students. I came up with the idea of building games as part of the podcast and using the source to teach concepts. I started with a simple Coin Flip game.

Then I built a text based Checkers game with them, then showing them how to port it to PTK. Showing how simple graphics and input could be done.

Following Checkers I used LifeLab, Conway Games of Life, to show how emergent gameplay behaviours can emerge from a simple ruleset.

Northumbria University hosted a Capture the Flag AI competition for the games students. Building on a game framework you had to provide AI for a squad in a capture the flag game using a set of parameters.

Simple 3D Boid simulation to explore flocking behaviours, written in OpenGl.

Puzzle game built around three colour magnets. The player controls the ball by switching the magnets colour making it ignore one colour, be attracted to another then repulsed by the third. Visualising the fields was fun, and it provided some interesting puzzles. The complexity of which is made much more difficult by the pace of play.

Not wanting to spend hours in the real-time lab before I understood the language I used Easy68k to familiarize myself with 68k ASM. The project slowly built up. I had to remember the old way to draw sprites and I had some creative whitespace and memory stomping errors. In the end the project was a success. I didn't add sound simply because the Easy68k sound was not old school or anything like the real thing.

The next project was Pong on the real target machine. This project has helped me loads but it is more fun on the real hardware where I can use a pedometer and timer interrupts.

Simple Pet Game where you took care of Frank on a little island. It was part of an exploration of social AI for my dissertation.

Looking at how to model Audience behaviours has always been interesting. Games like Tony Hawk Pro Skater and similar abstract an audience response through a combo system. KISS explored trying to pace a play and stick to a three act structure by delivering well timed lines. The experiment failed due to exploding complexity of content but it was an interesting exploration.

Using the built in accelerometers to make a little game. Think of it as turning your phone into a Wii-mote. Analyse and use Python to develop a simple application. Analyse and use the data captured by a motion device. Define and use the motion device to recognise gestures. Develop a simple application using skills gained.

The choice of platform and device was a well made one. The device is well suited for rapid prototyping and Python is still flexible. The libraries are well structured and light weight enough that minimal effort is required to start. The amount of feedback a mobile platform can provide while doing these motions is limited. This coupled with the limiting processing power means as a motion gaming platform it is limited. The use of motion in other applications however is still a valid.

The motion sensor is a limited device which does not do what sales teams claim. The processing of motion is several degrees more complex than traditional controllers. This is compounded if a neural net is used. The range of motion detection is very limited. This is due to both the low range of the device and lack of absolute positioning.

If a game is made with the limits in mind a successful game mechanic can be achieved. The gaming audience is more likely to notice the limited patterns of this style of motion controller as time passes. This receptiveness could have a strong negative affect on games which could turn unique control systems into simple formulaic inputs.

Second year project for university module. We basically had to write a game on the Gamecube. However as I was working fulltime getting into the labs during office hours was an issue. So I got permission to do a Wii Title instead.

Basically it was put-put. The level was generated from a heightmap, and textured. Simple system kept track of score. Basic graphics, motion controls and sound in place.

To create a data-driven system for use in the games industry that will generate complete social interactions using seeded scenarios which expands based on player interactions.

Coming from a roleplaying background I'm never satisfied with Dialouge Trees and their limitations. So I looked atomising interations and making them in such a way that AI can process and understand them. This massive undertaking was first dreamed up about five years ago. The project was attempted in a loose way and concepts investigated many times. Most times the attempts weren't even named. Two noticable pre-cursors were KISS (A dramatic simulation) and TavernQuest (a tavern generator which made DTs for NPCs).

As my Supervisor points out I'm in great danger of falling the trap of the 80's where they tried to solve the problem of everything. The important difference is every aspect of a game world is known and defined. So we can cheat a little, because we know everything.

This is an ongoing personal project and I see the disseration hand in as a first important solid step.