I've started dabbling with some new editor tools as an extension of a kind of RPG regioning system I'm working on. The region system itself can take a scriptable object which will determine the climate (and associated elements like materials, environment meshes, etc) and can store an array of positions for placing collectibles and environmental elements like trees and rocks.

As an extension of this, I wrote several editor tools. The first is a simple vertex painting tool, it's not super intuitive yet, requiring colours to be set by buttons in the inspector or keyboard hotkeys and then the individual vertexes be clicked on, but it functions just fine. I'd like to get more of a painting tool happening but I'm having some problems getting a custom cursor or any other visual tools that could help drawing into the scene window. I do have gizmos on all vertices though which show the stored vertex colour.

The positions which are being stored for placing environmentals and such are also manipulable in editor and have mesh representations which can be configured which makes setting them quite easy, I opted for this over just having child gameobjects largely for efficiency but I also think it's a lot cleaner and was more interesting to implement.

This last tool was a bit more involved, I've made a basic mesh modification tool which snaps overlapping verts together. The intended application of this is for things like modular sets; to avoid little gaps and edges you'd put this component on both objects and it would modify an instance of the mesh just a little to clean the edges up and make them more seamless. There's still some quirks, and I haven't really tried to use it as intended yet, but I'm pretty impressed with the way its progressed.

I needed to get way deeper into matrices, multi-threading, and slightly wacky editor coding on this than I'd expected at the outset in order to get it to work properly and to get efficiency up to the point where it was a usable tool.

I've made a couple of interesting updates since the last post. The animation system now accounts for characters talking (and they know when the dialogue being displayed is theirs), I've learned a lot more about Articy and figured out how to get it to work the way I want it to, and I've been playing with some fancy new hardware.

I've implemented some interesting re-useable nodes in Articy, largely to make up for their lack of switch statements (their only conditions are boolean) and when my systems have a lot of enumerations dictating the flow of conversation that's really necessary.

The switch blocks for motivations and emotions.

Inside the switch block for character motivations.

And I've been playing with the Tobii Eye eye tracker. The Unity SDK for it comes with a 'Gaze Aware' component which, quite literally, just knows whether or not you're looking at that collider. I've been able to add it to sections of the UI roughly covering the face, body, and feet (the Tobii seems to only be accurate to about the size of a 10c-20c piece on the screen, and loses accuracy towards the edges, so I can't be too specific with it) and implementing a system which times eye placement to figuring out where you're tending to look on the character, essentially, the characters can tell if you're staring and react accordingly. At the moment this is just a change in emotion, but it could potentially trigger different conversation options as well.

Example of the dialogue triggering the talking mouth animation, emotional responses will still affect the eyes if they're talking, and the eyes and mouth if they're not. Also shows the tobii indicator tracking my eyes but the emotional triggers to staring either weren't triggering for some reason or weren't noticeable.

This project started as a smaller part of a bigger game I was planning, but at this stage it appears it's going to be turning into more of a visual novel type game in its own right. I think I'm gonna need to work on my writing skills.

I've been experimenting with the game design software Articy Draft and implementing its exported content into Unity.

Unity implementation is new with the latest version so there's been a lot of fumbling blind and trawling through the very limited documentation.

I'm using Articy for handling branching dialogue and a database of characters and items.

Example of some conditional branching dialogue from my testing.

Example of separate conversation hubs from my testing.

Character definitions, in this case my shopkeeper with his inventory of items. Which are also defined within Articy.

Another character definition, in this case an NPC with all their stats and various options associated with them.

(Character asset by piablood sourced from the asset store, background art by Corentin Chevanne, placeholder assets only).

I modified a provided dialogue system attached to the Articy Unity SDK and implemented my UI driven character. The characters are imported from Articy and their local values can be manipulated by the dialogue, which I'm using to drive a simple emotion system which in turn connects to my animation system. I've also got various procedural elements which are driven by Scriptable Objects that link to the Articy Character reference, generating things like their appearance, personality, and eventually names and stats.

I can trigger dialogues or store interactions from clicking on sprite versions of the characters, in the case of shopkeepers, their store is populated with the items referenced as their inventory in Articy.

I've developed various scriptable objects to make things easier as well.

This object makes up for some limitations in Articy's Unity implementation, allowing me to connect the Articy reference to a local scriptable object and to override display their name, it also serves as a link for Aritcy's Dialogue system to readily find the scriptable objects. I realised this would quickly get crazy so I also made a custom inspector to easily break all the assets into groupings.

This is the local Unity scriptable object representation of a character, the main purpose of this object is for handling all of the procedural aspects of a character and communicating with the materials on a sprite or UI image. With how my generation and animation systems work, various other scriptable objects store sets of animations or sprites which can be used in generating a character, allowing for some control over the types of characters it can generate.

Over the past few months I've been working on developing procedural characters. This started as a result of the game I worked on at Global Game Jam 2017, L-Wave. In the time between the jam and the follow up IGDA meeting I developed a system for generating background characters from a pack of sprite pieces and simple HSV shifting.

(character art by Kai Lynk)

Later, I ended up adapting this same process to a more detailed character. I have a game concept I'm working with right now which would utilise comic book style characters so I searched the Unity asset store for the closest approximation I could find in the free assets. Thankfully, I found an anime-style character with about the right level of detail and it came with a really well structured PSD file for me to work with. I cut the character up into more specific layers where necessary (mainly the sections of clothing details) and then re-imported the sprites and applied the modified L-wave system.

(character art by 'piablood' sourced from the Unity Asset Store)

This ended up being pretty problematic though, as Unity doesn't seem to have the ability to save the compiled final sprites post-manipulation as assets and the generation process is really slow. As a result, I ended up shifting to a shader based approach. Due to the necessary complexity of the shader I decided that writing the shader from scratch would have been far too difficult, and I'd been meaning to try out some of the nodal shader assets available on the asset store, so I decided to make the shader with the aid of one of them. I ended up deciding on Amplify Shader over Shader Forge as it seems to be about on par, cheaper, and more frequently updated, so I suspect that it will become the dominant option soon.

However, at the moment it only supports surface shaders (I didn't realise that would be an issue at the time) and there's an issue with surface shaders being used for UI in Unity (see above...). I manged to work around this by setting the canvas to screen space - camera, turning off all its shader channels, and removing all lighting, opting for maxing out the ambient light instead (and setting it to baked, not real-time). This somewhat emulates an unlit effect.

This does mean that I'll be unable to use any normal mapping (which I was considering testing out) but the finished product looks just as good as the generated approach but is easier to manipulate and considerably faster.

I also ended up needing to rely on Multiply blending colours rather than HSV shifting (as I didn't know how to emulate that in shader), which didn't work too well with this asset as it already had some colours but would be fine with assets designed with it in mind.

This gif also gives a bit of an idea of the animation system I've put together which I'll cover in a separate post.

I recently decided to go back to Unreal Engine and update myself, I've used Unreal on and off but my focus has mostly been on Unity. Soon after Unreal 4 came out I familiarised myself with the core features and blueprints using both Unreal's Youtube channel and Digital Tutors (now Pluralsight Creative).

Going back to Pluralsight now I found a bunch of much more advanced Unreal tutorials and chose to work my way through a selection of them (I still have a few more in my playlist to get to but I thought I'd make an update of my progress).

The first one I did was an advanced blueprinting tutorial, this made some pretty basic gameplay but it was really handy as it had a focus on interfaces, which I rarely work with in Unity and hadn't used much in Unreal before and a pretty simple hud interaction to remind me of how Unreal handles UI.

The second was on AI and navigation systems.

I'd never worked with AI in Unreal so this was all new to me but it went over all the key AI assets and how they all interact as well as how navigation meshes are generated and manipulated. This one also had some useful tips and tricks for handling maps/levels.

The third was a space flight simulator, this one was really good because it made entirely new game mode and player pawns from scratch.

The last and arguably most helpful was on 'Data Driven Gameplay'. This was so helpful because it went through how to set up Unreal for coding in C++ in Visual Studio and creating custom blueprint nodes and data structures. We also then went over importing CSV files and parsing them into our data structure so we could use that to influence our blueprints.

I'm not as much of a C++ native as I am a C# native so that part was a little daunting but overall not very difficult even with all the Unreal specific macros that are involved.

Overall this was quite a productive week and a half or so that I spent on these and I suspect I'll end up making a lot more Unreal projects in the near future.

Tutorials used available here:

http://www.digitaltutors.com/tutorial/1861-Creating-Gameplay-Systems-using-Blueprint-Features-in-Unreal-Engine

http://www.digitaltutors.com/tutorial/2205-Introduction-to-AI-and-Navigation-Systems-in-Unreal-Engine

http://www.digitaltutors.com/tutorial/2117-Creating-a-Space-Flight-Simulator-in-Unreal-Engine

http://www.digitaltutors.com/tutorial/2035-Using-DataTables-to-Create-Data-Driven-Gameplay-in-Unreal-Engine-4

Looking to expand upon my experimentation with tools and editor extensions I added control handles to position the path nodes in my space rail shooter from my previous posts. I then decided to additionally add bezier curve support as I'd never actually done any bezier spline work before and was curious about the maths involved.

With a little bit of google research and some consultation with my workmate Finn Morgan I was able to get the math side of things handled and get into implementation. This project did present a few different issues. The first was due to the nature of how the custom inspectors pass values back and forth and the way I needed to handle values within my equation I had some trouble with whether I should represent the control points using structs (value types) or classes (reference types). I ended up settling on structs as it required less refactoring and made the methods for my equations more straight forward but it did mean my custom inspector code was a little more convoluted than I perhaps would have liked.

I then implemented custom handles which can control the position of the control nodes and the gizmos to draw the path.

Really all this does is take the short main nodes list from the designer, give each of those one or two control nodes (depending on where they are in the path, start and end only need one), then project a number of additional nodes in-between each based on the position of the control nodes, and use that as the actual route for the AI/Player/Object/Ect within the game.

I also had a problem at one point with my misunderstanding of the equation which resulted in some crazy results, essentially I had the nodes in the wrong sequence in the equation, this didn't stump me for long but made for some crazy results.

The end result working with my game AI:

This project evolved out of the previous camera project, I decided to adapt it to a flying, on rails, context after playing a lot of the space battles in Old Republic (Bioware), which is actually quite similar to the old Star Fox 64/Lylat Wars as I remember it on the N64.

I've been doing a lot of playing with editor tools and gizmos so from the start I was able to make things a lot easier for myself by being able to previsualise the routes for cameras and AI and visualise things like detection ranges.

The pathing for this went pretty seemlessly, the route system isn't too complicated, but I had some trouble getting the player to stay in the screen while pathing around. I tried using camera (its transform) relative points but that suprisingly didn't work, but my workmate Finn Morgan sugested I instead use screen relative points, so I adjusted the approach to position the ship based on a screen position which got the desired result.

The aspect I'm most proud of with this project so far is that I implimented a modified boids (flocking) algorithm on the enemy spaceships, they stay in groups, follow their path, dodge around hazards, and have a really nice smooth movement, they do freak out a little if I push it to its limits but when its kept sane it works nicely. I also have a nice little death effect working (lacking visuals at this point, I only have ship models by repurposing Escape Vector assets).

Moving on with this project I've also begun to implement more advanced concepts that, whilst I understand them, I haven't had much practical experience with to date; my boid system relies on coroutines, the combat mechanics utilise an interface, and my hazard system will rely on inheritence.

Source Code: https://www.dropbox.com/s/1lc5l9bu6v1y5fq/CameraProject.7z?dl=0

I put the AI project on the backburner as I felt like there was some problems with it requiring a great deal of refactoring and instead started on a project focusing on another thing I haven't spent nearly enough time with, cameras.

Initially I started with a third person camera, the first thing I did was reimplement an improved following camera similar to that in my third person game I posted about previously, then I went on to developing a more interesting orbiting camera, adapting the locked camera to a toggleable lock (like that seen in games like Zelda, only currently focused on the player not a target) this video was a large part of the inspiration for this:

How Cameras in Side-Scrollers Work, Itay Keren, GDC

(https://www.youtube.com/watch?v=pdvCO97jOQk)

I still have some big problems with the way I've handled the orbit, rotating by a value derived by mouse movement, then panning back a set distance, then looking at the player. The camera ends up spiraling around when you yaw instead of just orbitting, the idea is to replace this with a proper matrix approach but this will require some further research. Despite that flaw, I am extremely happy with the 'whisker' element of this camera, I got the inspiration and basic concept from this video:

50 Game Camera Mistakes, John Nesky, GDC

(https://www.youtube.com/watch?v=C7307qRmlMI)

I developed this further though by borrowing a concept from my study in procedural geometry to determine the camera's behaviour based on which raycasts hit, in this way I avoid any contradictory calls.

Gifs:

Orbit camera, there's a timer on manual control so the system doesn't overide the player immediately.

Whisker system, the raycasts force the camera to pan around when you're about to be obscured.

Locked camera, when you leave a boundry range on an axis the camera begins panning until you reach the centre again, the speed is a product of the distance until the outer boundry when it locks completely making a nice smooth acceleration without ever being able to escape vision.

This actually shares a project with my rail shooter prototype as they both evolved out of the same experiments and I haven't migrated it to its own project yet.

Source: https://www.dropbox.com/s/1lc5l9bu6v1y5fq/CameraProject.7z?dl=0

One area I haven't spent much time in is AI, this actually occured to me while I was working my way through some GDC and Unite presentations on Youtube, after seeing these two presentations:

AI in the Awesomocalypse: Creating the Enemies of Sunset Overdrive, Adam Noonchester, GDC (https://www.youtube.com/watch?v=O66mmqOjEy0)

and

Unite 2014 - Practical AI in Games, Emil Johansen, Unite 2014

(https://www.youtube.com/watch?v=hhByGZZbcOc)

The later especially, it melted my brain a little but over the next couple of days began to sink in and turn into motivation.

So I set up a simple little prototype, I also needed to learn more about coroutines so this was a good situation to play around with them and see what they can do.

I tried to implement a high level state machine (using an enum) with each state having its own state machine within that, vaguely like a behaviour tree. I've also tried to use a series of checks to sort all priorities in order with the intention of using it to then determine the AI's behaviour, perhaps to lead to more complex actions (like look for the ammo nearest some cover for example). This project still has a lot of bugs and sections unfinished but it shows some promise.

Gifs:

The units spawn, see each other, and decide to start shooting, they then decide to seek cover when their health gets low.

The units seek cover but this is resulting in them losing interest in each other (bug) and then going looking for ammo or health, their next priority.

Source Code:

https://www.dropbox.com/s/xe81pso3jkvm24j/AIProject.7z?dl=0

In the interest of learning some more about procedural generation (the shrub generator got me inspired) and after a conversation with my workmate Finn Morgan I decided to try out generating meshes in Unity. I worked along with this tutorial (http://jayelinda.com/modelling-by-numbers-part-1a/) and after the initial plane creation I extended it myself to see if I really understood what I was doing and how it worked. I doubled up the plane and then tweaked the heights of random vertexes to get a sort a terrain height effect, added a collider, and applied a tileable texture (I needed an excuse to test out one of my new textures anyway).

A few weeks ago I was feeling the need to do some art, it’s something I don’t get much opportunity to do but always love when I have the time. Texture painting is probably my favourite part and I've always had a thing for hand painted/low poly stuff and I have a pretty huge collection of tutorials and reference on pintrest for it.

So I found something simple on my pintrest (https://www.pinterest.com/pin/301037556320070447/).

Process:

I modelled up the plane in 3dsMax, it's really just a plane with an extra vert in the centre which allows a bit of a pyramid shape.

I painted a single leaf and flower on my Galaxy Note, my favourite part of this process was actually that the work was smart rather than labour intensive, rather than painting more I modified that single leaf and flower in photoshop, used layers and adjustments, and easily created a bunch of variation and different copies of the texture.

Intitially I made some shrubs just by placing the planes and it worked fine, but I decided it’d be a bit tedious making a bunch of them.

So instead I wrote a system to generate shrubs based on parameters. I got it working but running on start was annoying and I felt some parameters could be more user-friendly, so I wrote a custom inspector.

There were some unusual bugs (there still are a few) but it’s nice to have produced something from scratch that was so involved in both art and tech fields and even considering its UI/UX in engine, I definitely think I'd like to go about making some more Unity tools in future.

I've started what will possibly become a prototype for my next game, it's mainly a technical exercise as I’ve been looking into cameras a lot lately. I had some interesting bugs because I wasn’t aware of the differing refresh rates with physics based objects and that was giving me some strange stuttering problems, but it’s resolved now. I have a bit of a loose concept to do a Crash-Bandicoot style game that’s a subtle commentary on Australian politics if I ever get the time and resources, but it will also be a great basis for working on my art skills.

The player controls are entirely physics based and the camera works by setting a relative position to the player then using a lerp to move towards that position from its current position (speed is affected by how far it is from that position, in this way it moves subtly when the player moves slowly, but the player can also never get too far away, as it will accelerate as they move away). This relative position can also be changed at run time, at the moment the prototype has three different perspectives which will allow for different gameplay in different stages of the game.