Gather round, children, I’ve got an extraordinary, wonderful, fantastical tale to tell!
Come along... There we are, are you sitting comfortably?


Ahem… Three Moons ago, I was sitting at my desktop writing untold amounts of COMPUTER CODE !!


But then I noticed a terrible problem, children... My computer code WOULDN’T COMPILE !!1!


It turned out I had made a grave and frightful mistake! It was... a SYNTAX ERROR !!!1!!1!


Sorry I can't just write a load of stale techy guff without showing on my part bit of self-awareness. I know some of you like to insist in the comments that it's not dull but I beg to differ!

Right then, let's get on with it. In the last 2 weeks I’ve achieved some things which are pretty cool from my point of view, but they’re mostly conceptual and possibly hard to describe. I feel I’m going to struggle to put it to words, but I’ll try.



Firstly, I’ve devised a way of cutting the world into many smaller pieces for the game automatically by script, which for any seamless free-roaming game is essential.

Designing the outside area requires that I’ve got everything as 1 seamless 3D model at this stage, cutting it manually is far too fiddly and once I’ve cut it up it becomes an absolute chore to alter.

It means I can unload the unnecessary parts out of view, increasing performance considerably. Yay.


I’ve also managed to get a building/floor/room system set up, which means the player can move between rooms and floors, allowing the system to know where you are and which rooms to load and display.

Since implementing this though I’ve been considering if it might not be better to show other rooms instead of isolating the view to the current room inhabited by the player.

There’s no good reason to have it that way except to look more like the original Wasted Youth and to present a room as an entity.As I’m essentially striving for seamlessness I’ve decided for now to try and keep other rooms and the outdoors visible, and instead to lock the camera to the bounds of the room for that sense of ‘roominess’.

I told you this was going to be conceptual didn’t I?


I’ve also designed some very basic building shells which are only viewable from outdoors... but they're just white boxes so to save myself embarrassment I've made the image on the left ridiculously small.


Perhaps the most significant thing I’ve managed to achieve in the last 2 weeks, without intentionally aiming to I’ve created a pretty nifty day and night system.

The way I would have approached this in the past would be just layer a transparent color over the screen, maybe with a filter to simulate night and day, as I did in the original game.

Given the resources to create something a little more complex, I decided to try that instead.

The system I created tries to emulate real life as much as possible. There’s a rotating Sun, an ever present Moon, fog and a basic transparent color layer like from WYP1.


It should be noted that you never have a chance to see the Sun or Moon objects due to the locked downwards perspective, but they are there, trust me.

In the past it would have been very tricky to define all these properties to make a convincing night and day system, most likely I would have defined them purely in code.

And there’s lots to consider - the sun’s speed, its intensity, its colour, screen colour, fog colour, and many more... from sun-rise to sun-set, these values change depending on the time of day.

This is where Unity’s Editor is an absolute blessing. You can program these properties visually, with graphs, colour gradients, sliders and so on. Also I can have the game running and change these properties on-the-fly and see the effects immediately.


This is how I’m designing most of the system, essentially making my own Wasted Youth game editor application within Unity.

Eventually, when it comes to designing cut-scenes, I plan to develop my own little editor to create/edit/preview them, whereby I can plot the positions of characters, where and when they move, their dialogue, their clothes, their facial expression, etc.

This almost seems like an obvious necessity in game development, but when I designed the original Wasted Youth I never considered this approach. For designing cut-scenes I developed a sort of mini scripting language within a language, but in the end it was all just raw code, and very difficult to visualise without compiling the entire game. When I recently looked inside my old project files it was akin to viewing a palace made of lollipop sticks. Impressive, but not the best way of doing it.


I’ve explained this in the wrong order, let’s go back before the concept of night-and-day. Originally I wanted some way to know what period of the day it was, because I had some streetlights which needed to turn off and on at certain times of the day. In the original Wasted Youth there were 4 time periods - morning, noon, evening and midnight. When you start the evening period the light is dim and continues to get dimmer for about 2 minutes, until it’s night-time (incase you didn’t notice).

So a day and night system requires a time controller - sorry, a clock (I think the game-dev side of my brain is infecting the part of my brain that allows me to talk like a normal human-being).

This brought focus to the question: how exactly will the game clock work?

I could set 4 periods of the day like the original, or I could have a realtime clock that ticks about 60 faster times than real time, ie - 1 real second = 1 game minute (a bit like in GTA for example).

After designing a day-and-night system with this in mind, I decided to allow for either scenario, so now I’ve got a toggle button that decides whether the clock is periodic or realtime. Currently I’ve got it set to realtime, but depending on where I’m at later on in development, I could design the game around either system. For now it’s not terribly important so I’ve added it to a list of unanswered questions.

The Ascent Of Man is a great documentary series I'm watching.
In case you're interested...

(I have an increasingly growing file in my main project directory called ‘DECISIONS.txt’)


Another issue I’ve got to consider is once again, camera related, but not the aesthetic of the perspective, more it’s inherent limitations.

Camera problems often plagued older 3D games, but for the last decade or so they’ve mostly disappeared. This is largely thanks to some tried and tested formulas work best… and therefore a very limited set of choices.

As I’ve decided against using a normal usual third-person over the shoulder view or first-person, I’ve got some rather fundamental problems which I’ve not quite solved yet.




The first problem ofcourse, is obscuring. But as I’ve learnt by trying to fix it, it’s not just the player that’s obscured, it’s everything near the player. Ideally I want to see through walls so I can see everything, but I’ve not come across a visual effect that looks suitable yet.

The other problem which I’ve only recently realised is with tall objects like buildings, where does the camera go? If it follows you it goes inside the building when you go behind it.

This problem made me realise why this camera angle is so rarely used in modern 3D games. In fact, apart from Pokemon and Zelda games on the 3DS, I can’t think of any other examples of this kind of third-person perspective being used in a 3D game.

There is a simple and obvious solution - hide the building from view entirely, but for consistency I’d like to maintain the same effect used for walls (I know, I'm awkward). The problem with any other method is that in order for the camera to not go inside the building, it has to zoom out, and unless it thereby decreases the field of view (making it seem more isometric), there’s no way of doing this without making the player becoming very tiny and far from view.

Another fix would be to use an isometric camera, but there are still problems with this as well.

Ofcourse, I might just be a little too nooby to realise an elegant solution, but having posed the question already in some of my haunts, I've been made aware of my stupidity yet.

This problem now also resides on the increasingly growing heap that is DECISIONS.txt.


Finally… there’s been an issue which has plagued me since the very beginning, and it’s to do with how Unity handles assets at a fundamental level.

In Flash, I could structure any object in a hierarchical way - for instance, let’s imagine the protagonist of Wasted Youth.

We start with the body. The body is the parent object of the legs, arms and head.

The head contains the eyes and mouth, the legs contain the feet, and so on...

I could then save this as one repeatable object for duplication, without losing links to the parts contained. So if I changed a detail on the character’s hand, it would update all instances of the character.


Unity unfortunately does not work this way. If I changed a detail on the hand the change does not propagate to every other instance of the character.

Frankly, it still boggles my mind and I can’t understand how anyone manages to create a complex scene with this limitation in mind.

So recently I’ve been developing a way to fix this once and for all. And now my mind is completely fried.

Seriously. The solution to this involves a decent understanding of recursive procedures, and my mind just isn’t built for it. I actually wear myself out thinking about it too long.


Want to hear something really sad? When I lay in bed this stuff occupies my mind, almost by default. Little coding or logic problems fill my head like insects buzzing around me.

There’s something so frustrating and disturbing about some problems that they become mentally exhausting. It’s not a stretch to describe this as a kind of insanity just how much my mind focuses on them sometimes.

After a few hours working on it and a couple more writing and preparing this blog post, I feel well and truly spent. For today anyway.



So let’s leave it there shall we?


Thanks for the suggestions for the camera perspective. I think I’m going to agree with most of you and keep it as it is, option 3.