What an amazingly busy couple of days it’s been! PAX Australia has been going fantastically, full write up in a few days when I’m less destroyed. If you’re ready this and it’s still Sunday, come check us out and say hi at Stand 40 in the PAX Rising area!

Also, the Greenlight campaign has gone up! If you’d like to help get us onto Steam, your vote would be super appreciated.

Just a short post to be followed by a more substantial one soon, but we’re going to be a PAX Au! We’ll be in the Indie Rising section, Stall 40, so if you’re there, come and say hi and have an exclusive look at the game!

We’re also launching our Greenlight campaign in the next few days, so be sure to keep an eye out for it!

New Entrance Hall, Butler NPC using CostumeParts, and the new DialogueGraph system.

First things first, the new entrance hall has been implemented. Unfortunately it took a lot longer to do than anticipated (So many stairs and railings to unwrap), but I think I managed to get the look I was going for, which was mostly ‘large and decadent’. One thing which I also didn’t factor in was the time required to get the room generation code to support multiple floors, which took a couple of days. Adding an extra dimension can cause all kinds of code bugs and headaches.

Since I was running so behind, I didn’t get a chance to redo the hallway environments or implement special rooms (Bedrooms, kitchens, bathrooms) as of yet, so they’ve been pushed back to next month.

The priority at the moment is to get the murder mystery part of the game implemented so I can have a full game loop going. A big part of that is implementing NPCs (Non-Playable Characters) so I can populate the mansion with suspects for the murder. However, modelling characters from scratch takes *forever*, and due to several limitations I can’t share animations between multiple characters, so I had to come up with a solution on how I could get multiple characters looking unique while still using the same mesh.

Detective and Butler sharing the same mesh

The solution I came up with was to make a model that can support multiple character types, with ‘CostumeParts’ that can enable/disable certain parts of the mesh and use a different texture for each part. So of the pieces can also be reused for different variations of clothing; as you can see in the image above, the detective only has a short coat, but the coat mesh extends almost down to his knees. The green jacket texture has invisible pixels all over the bottom half of the mesh, while the butler uses the extended part of the coat mesh in order to have longer tails. Same goes for the top of the collar; the Butler uses it to show the bow-tie and extended collar, while the detective doesn’t use it at all.

By default, all meshes on a character are hidden, and when a CostumePart is equipped, it will show the mesh defined by the costume and set the material of the mesh to whatever the CostumePart has defined. With the hat, for example, it defaults to hidden unless a particular CostumePart that uses the hat is equipped. This means that the model that’s actually used in the game actually contains all possible outfits at once, but they’re just hidden and exposed as needed.

This may end up being incredibly expensive in the future, in which case I’ll be changing the system to only instantiate meshes as needed, so there aren’t a tonne of disabled meshes hanging around.

The other major thing that’s been added this month is editable dialogue trees. Previously all dialogue was code-driven, which meant that every time I wanted to change what a character had to say, I had to change the code directly. I made a generic node editor for Unity, so that I can create and delete nodes as well as wire them up and get a visual representation of what the dialogue tree looks like. I also added the ability to have multiple-choice dialogue sections, so you can ask a character something and go down a different branch of the dialogue tree.

Making the node editor was a much larger undertaking than I was expecting, mostly due to being inexperienced with the way Unity deals with serialization (Saving/Loading data from disk). Unity doesn’t support serialization of polymorphic arrays by default, and the default serialization of classes saves them all inline, so if one node links to another, it will actually save/load a copy of that node rather than the actual node itself. While in-game you wouldn’t really notice the difference, if I changed one of the nodes in Unity then saved and reopened the project, I’d have several nodes that would have been duplicated, causing a massive headache if I wanted to go in and edit one of the nodes.

The way around this was to have my IDialogueNode interface inherit off ScriptableObject, then create each node via ScriptableObject.CreateInstance, then add the node to the DialogueGraph by calling AssetDatabase.AddObjectToAsset. This means that the DialogueGraph itself actually contains several objects rather than just one, which has the annoying side-effect of causing the DialogueGraph to be displayed in the project view as multiple objects which can be annoying to work with. Although if you set the hideFlags of each node to HideFlags.HideInHierarchy, then Unity will only show the unhidden ScriptableObjects in the project view, meaning that only the DialogueGraph (The original asset) will be displayed.

So, now NPCs and dialogue have been properly implemented, the next steps are all about getting UI for the players inventory (As well as for the Buy screen on the butler), creating more CostumeParts, randomizing them onto other NPCs in the mansion, then creating the MysteryManager to deal with giving dialogue to the NPCs.

Okay, so work on the new character is done! He may look incredibly similar to the old one, but he’s had his proportions tweaked, a couple of rough edges smoothed out, and also he’s been separated into multiple pieces in order to facilitate changing costumes further down the line.

Also with the new model came a new animation rig, which means I could finally get around to doing attack combo animations. Also new is root animation, which while it’s hard to tell from the gif means that every time he attacks, he steps forwards a little bit. This helps with closing the range on enemies while attacking them, and looks pretty neat.

HA YA RRRAAAH

Also there’s been another big addition; Actual lighting! The previous versions I was working with were going for a flat-shaded style – in line with the Playstation 1 graphical style I was going for – but I always felt like it was lacking in atmosphere. The first few tests I did looked a little weird, with shadows that felt either too dark or too light, or just looked like plastic. To fix this, I’ve placed various ‘bounce lights’ around the scene to fill out the shadows a little more, and I’m quite happy with the results.

If you love it then you should’ve shone a light on in.

I also managed to show the game off at the monthly International Games Developers Association Melbourne (IGDAM) meet-up. Got a lot of great feedback from people regarding the new lighting style and animations, which was great because people definitely seemed to respond positively to it (And hogged my laptop for quite a time while playing it).

Next up; environments. The current environments all look incredibly samey and boxy, so I’m going through and doing a pass of having more varied, unique rooms. This should make navigation much easier for newer players, as well as giving them more reward for exploration. I’m hoping to be able to do one new room a week, so hopefully by the next IGDAM I’ll be able to show off a total of 4 new rooms, including a new double-story entrance room. With stairs and everything!

Look, bookcases! And a vase! Also another rat, man someone needs to figure out where they’re coming from.

So one of the things I’ve learned about indie development is: finding the time to do blog posts is hard.

While I haven’t been updating the site, work has been progressing rather nicely. The project that I’m working on is codenamed ‘Mystery’ at the moment, and it’s going to be a randomly generated murder mystery. Every time you die or fail to solve the mystery, the world is going to be regenerated from scratch and the elements of the mystery itself will also change. For me, the main aim of this project is to have a game that you can play for a year or more and still have new and interesting things to find.

However, one of the difficulties in making a game with the scope of ‘can be different every time’ is making an absolutely gigantic pool of assets that can be randomly added to the maps. Since I’m a one-man studio I don’t have an army of artists to constantly make new assets, and I can’t spend forever making this game. As a result, I’ve decided to go lo-fi with low polygon counts, chunky pixels and bright colors. I’m still working on refining the look, but I think it reads well and feels unique, as well as having a much faster turnaround than doing current-gen high resolution assets. The difference in time spent is huge; going from a few days to a week to complete a simple asset to mere hours. And since I’m running off my own savings at the moment and need to be able to finish this project before I run out, every hour counts!

So, what’s been done so far? Well, the game is playable if not a little bare, with a simple implementation of room randomization implemented and well as being able to control the frequency and placement of items that appear in rooms. Keys and doors have been implemented, although at the moment it’s still a first-pass implementation that will be improved later to make sure that the level is always ‘solvable’, as at the moment the key that you need can be placed behind a locked door.

Basic versions of health, weapons, enemies, pickups, dialog trees and smashable objects have also been implemented.

Currently I’ve been rebuilding the main character to fix some proportion and animation issues, as well as add the ability to change outfits. After that, work will begin on making the rooms feel more interesting and unique, as in playtesting I’ve found that the current square room design just leads a lot of players to lose their bearings and get lost, even with a map!

Okay, I think that brings everyone up to speed. Next blog post will be soon, I swear!

So who are you, and what are you doing here?

I’m Nick, guy that likes games and pretty much everything to do with making ’em. Over the years I’ve been an artist, a programmer and dabbled in design and music, and now I’m going to take those things, mix them together, and make a whole product.

I’ve generally gravitated towards programming as a job because it allows me to get all deep and personal with a game; find out how it works, play with what makes it tick and finding creative solutions to difficult problems. However my real passion lies in gameplay mechanics, figuring out how a player interacts with a game and ways those systems can work together in concert to provide an interesting and memorable experience that people will want to play again and again.

I’ve been interested in pretty much all the disciplines that go into making a game, from architecture and lighting, to physics and music theory. I’ve played around in just about every part of a game that it’s possible to do, both professionally and in my spare time.

Also I’m here because this is my website, what a rude question.

What have you done before this?

Over the years I’ve been an artist, an animator, UI guy and sound guy, but most of my career has been working as a programmer for Atari, Krome and Firemonkeys. I’ve worked on various titles for both console and mobile, including Spyro: The Eternal Night, Star Wars: Force Unleashed, Mass Effect: Infiltrator, Need For Speed: Most Wanted and several others.

So why go independent?

Working under a large company comes with a lot of overheads. Ideas need to go through multiple levels of approval, resources need to be allocated, and people need to be paid. As a result, new and interesting ideas that may pose some level of risk tend to be shunned for blander, safer ideas to make sure that the investors keep the money coming in and people can keep their jobs.

Indies don’t have nearly the same overheads that a large company does and they don’t have a long line of managers, executives and investors to appease. This means they can take more risks, try more novel ideas, and play around with concepts that you just couldn’t hope to do in a corporate environment.

Games are still an incredibly young medium – only a scant 30 years old in the popular mind – and there are still vast landscapes of concepts that have yet to be explored. Exploring always has a high element of risk; you could go down the wrong path entirely and end up at a dead end or worse, but there’s also the chance you could also find fertile new lands to sow. When this happens, it reduces the risk for anyone that follows, allowing them to build on the knowledge of those before them, diversifying the landscape and improving life for everyone.

I may be a pioneer and have a town named after me, or I could be a warning and have a cliff named after me. Either way, without taking the risk, we’ll never know what we may have missed.

Also I can work in my pajamas.

What are you going to do?

Make games, of course! I have a game that I’ve been working on for a month or so (And been stewing in my mind for far longer) that will slowly be revealed as I work on it more, and I plan on updating this blog every week both as a form of motivation and to let people see how games are developed.