Project Husky Dev Diary 08

This sprint I decided to fire up Blender and replace some of the temporary models with new ones created in Blender. I ran into some issues with rotations and scaling due to the differences between Unity and Blender, but I eventually figured out a workflow that fixed the issue.

New features:

* Added the ability to pick up and drop items
* Replaced a few of the models with new ones created in Blender.

Project Husky Dev Diary 07

Due to the development of the new AI taking longer than expected, I decided to skip last fortnight's video and cover them both this time around.

New features:

* New finite state machine based AI with 3 states (idle, flee and hide)
* Added rustling bush effect when creatures approach plants.
* Switched over to using cinemachine for camera
* Alan and Jerry now have eyes!

Project Husky Dev Diary 06

In sprint 6, I spent quite a lot of time working on story elements for the game, as well as doing a first pass on the layout of the forest region. I started work on a new AI for a new creature, using a finite state machine, but ran out of time.

Until next time!

New Dev Diary for Project Husky

So I just realised that I've been neglecting this blog for a few months now. Development on "Husky" has been progressing quite well, and I have been doing fortnightly dev diaries on my youtube channel, but I haven't been posting any updates here. Starting today I'll be putting together a brief post here to go along with each Dev Diary.

The videos are typically less than 5 minutes long - just a quick summary of what I've been up to in the preceding two weeks, and occasionally a more detailed explanation of a concept.

The latest video is here:

For those that are interested, the other 4 episodes can be found on my youtube channel (Personally I think episode 2 is the most interesting thus far).

Until next time!

Husky Dev Blog 1

So, after a period of research, story writing and tech prototyping, I am pleased to announce that proper development on "Husky" will begin today. I still have a few ideas to polish from a story standpoint, but the basic structure of Act 1 is locked in, which means I have enough to get started.

"Husky" started as a game idea I had back in 2011, where the player experiences a certain game-changing epiphany during gameplay. In my mind I envisioned that an entire game could be built around hiding this until the point where I wanted the "wow!" moment occur. I had no idea how it would start, or where it would go after the epiphany (it was set to occur around the middle of the game). I was already working on something else at the time, so I wrote down the idea with the notion of revisiting it and fleshing it out sometime in the future.

The other game project I was working on eventually petered out and after a period of self-reflection I decided I needed to work on something simpler in scope. In January I brought up my list of ideas and decided to flesh out the "epiphany game". Over the past 6 months I’ve evolved the game world and story and didn't even notice when the "epiphany" concept was slowly slipping out of my overall vision for the game. I kind of knew it needed to be in there somewhere, not sure exactly where, but I was determined to shoehorn it in… because… reasons!

After reviewing my notes this week I had an epiphany of my own. The epiphany moment didn’t fit at all, and furthermore, it was actually pretty lame compared to the rest of the amazing story I’d crafted and honed over the last few months. The fleshed out story has many more interesting (and natural) “wow!” moments than the original concept, which was a silly gameplay gimmick at best.

Even a few weeks ago, if someone had suggested ditching the epiphany moment I would have strongly defended it as absolutely essential to the game. As of today I have officially killed it off and it feels weird. I probably wouldn’t have come up with what I have now if it wasn’t for that original idea, but it has no place in the final design. It was like scaffolding on which I could construct something more interesting, but the key is that scaffolding is ultimately dismantled.

During its development I’ll be attempting 2 week sprints in my free time. Progress will be slow as I still have a full time job. My plan is to show off *something* at the end of every sprint. Here we go...

Introducing "Husky"

So, work on "Bulldog" has stalled again. It's been many months since my last blog post. A lot of (non-games dev) stuff has happened to me during that time, such as changing jobs. I also feel that my friend, Skugga, is partly to blame for my lack of free time when he introduced me to Player Unknown Battlegrounds :D. I've been playing it an unhealthy amount, and its rocketed up to my most played game on Steam.

So, after having done no games dev for months, myself and a few mates at my new work participated in the 2018 Global Game Jam recently and it was awesome fun! It's inspired me to pick it up again. I've decided I need a smaller project that will help me get up to speed with Unity, and so I'm pleased to announce I'm kicking off a new game project.

In keeping with my dog-based theme for naming, until I have a proper name, I shall refer to this project as... (rolls dice)... "Husky".

Husky is based on an idea I've had kicking around for quite a while now. There's a lot of concepts that need to be nailed down before I can go into more detail, but broadly speaking, it is a story driven game in a world of geometric shapes about a village of circles and their bitter rivals, the squares.

More to come...

Progress Update April 2017

Big announcement time! I'm abandoning my self-made game engine and starting again in Unity3D. BAM!

It was a very tough decision to make. I've grown quite attached to my codebase in 7 years of tinkering in my spare time. As a learning journey, it is how I learnt C# and simultaneously contains the best and the worst C# code I've ever written. As an idea, abandoning that is bittersweet to say the least.

I actually explored the idea of switching to Unity quite a few years ago, but I found the learning curve to be too much and went running back to my comfort zone with my tail between my legs within a month. In hindsight I probably should have perservered with it, but at the time I was evaluating alternative approaches, so switching back was an acceptable outcome. Unity evaluated? Unsuitable? Great, back to work.

This time around, I don't have that luxury. I've painted myself into a corner and I can't see any other way out. I fear that unless I switch to Unity, I will end up abandoning this project due to lack of motivation. The catalyst for this terribly pessimistic thinking is my experiences trying to implement skinned animation in my game engine. I've followed many tutorials, rewritten the skinning a few times, and I actually got as far as having the skinned model rendering correctly... until I tried to animate it and then it all fell apart. *cue sad music*

Basically there's too many quirks in my setup that means no tutorials are directly transferable to my situation. eg: Different matrix representations of DirectX vs OpenGL. Different coordinate axes for animations vs meshes. YUp vs ZUp representations. Each of these would be easy enough to trial and error my way through, but combined, they have been kicking my butt for a couple of months.

Another factor is SlimDX. Back when I started this project, SlimDX was already starting to wane in popularity.  Then there's the fact I'm developing against DirectX 9. Back in 2010, that was a bit silly, since it was already 6 years old, but now in 2017, that just seems ludicrous! I'd already resigned myself to the fact that I'd eventually have to add DirectX 11 support, but realistically, when was I going to find time to do that?

So I've decided that I should cut my losses and embrace Unity.

The Good

So what am I gaining? A fully featured, mature game engine that is graphically superior to anything I could create. Access to a huge number of useful assets on the Unity asset store. Many useful tutorials on a variety of game development topics that are relevant to my exact situation, and don't require messy transpositions. I'm using Unity, they are using Unity. Profit!

The Bad

What am I losing? Pretty much all of the 90,000 or so lines of C# code I've written over the last 7 years. Actually, that's not entirely true, as Unity scripting can be done in C#, so a proportion of the back end code might be able to be re-used.

The Ugly

Ok, so what am I keeping? All the concepts, all the ideas, all the game mechanics and systems that I tested and tweaked should be able to brought across. Everything that makes it a game, rather than a game-engine.  There's much, much, more of this that's still in my game design workbooks than in code, so that's an advantage I suppose. If I waited another year before switching I'd be losing more work down the line.

Conclusion

I think I've made peace with the fact that I have to let the codebase go, and starting from scratch is actually not such a bad idea. Over the last few years I've slowly been refactoring my game engine to be more Unity-like in its approach anyway, eg: Using components and a similar User Input system.

One way of looking at it is that what I've created thus far was a prototype. A fairly elaborate prototype that I spent way too much time polishing, but a prototype nonetheless. Now that I have access to better tools I can hopefully make this crazy idea a reality. :|

Development Snapshot 17

Once again, most of the work was graphics related. It's refreshing to be making forward progress on tangible things, rather than back-end stuff nobody sees but me.

The animation system was the first thing I tackled. I was looking forward to making great strides on this item. It took more time than I expected so I had to put off the final parts (eg: BVH importer) until the next snapshot. In theory, the player character is animating properly, I just don't have any way of loading animation files yet.

Debugging Frame Timings

After that I spent a bit of time upgrading some of the debugging information the game spits out about frame timings etc. I was expecting to make a few small changes and call it day, but I went a bit crazy and replaced my old profiler with a much more flexible system that does most of the setup automatically. I celebrated this success by upgrading the frame time visualisation to add some colours to represent different parts of the frame. This should aid in optimisation down the track.

Top secret performance benchmark

The first thing I noticed with the improved frame timing information was that my text renderer is slow, taking up almost 30% of the entire General render pass when there is very little text on the screen. Fortunately, the text renderer is due for an overhaul a few snapshots from now to add support for scrollable content windows. The side effect should be improved performance, which is great.

Waypoint Tweaks

I also improved on the look of the waypoint path from last snapshot, adding a dark border. This doesn't sound like a big deal, but the way I originally wrote the waypoint path creation, this was pretty tricky.

Not too bad. But we can do better...

The border helps the waypoint stand out a bit better from the terrain, and tidies it up a bit in my opinion. I also did away with the triangular shaped notch at the start of each run, and I've had a few ideas for improving it further, but they will have to wait until next snapshot.

The most fun part was writing some geometry code to ensure the width of the border is constant even when approaching the sharp point of the arrow tip. The problem looked like it didn't have an easy solution until I hit upon the idea of using similar triangles, and had great fun optimising the equation until I ended up with something downright elegant (in my opinion):

v = normal1 + normal2
l = (2 * distance) / v.LengthSquared()
result = v * l

There wasn't much on the survival side this time around, but I did alter the poisoning debuff to lower maximum health instead of just eating away at your current health for a period of time.

I also fixed a handful of miscellaneous bugs, most of which have crept in during the last few months.

Next Snapshot

For the next snapshot I have a few fun things planned. First of all, the BVH importer, which should allow me to finally put the animation to bed. Also on the agenda is starting to work on the first biome that the game will support.

My original plan for the start of the game involved the player washing up on a beach after the cruise ship they were on was destroyed. With this in mind I created assets such as Palm Trees, Wooden Barrels, Life preservers etc and set up my test level as a literal sand box.

Now that I've developed the story more, the initial setup has changed drastically.  At the start of the game the player will  be dropped in a Temperate Forest, which couldn't be more different than the acres of sand and a few scattered palm trees I have now. So, in snapshot 18 I'm going to start the ball rolling on the biome generator. It will be somewhat of an experimental feature, but hopefully there will be something interesting to show.

I've also decided on the visual style of the game, which is quite exciting. I'll pretty much have to throw away most of my game assets and start again, but I have so few I'm not that worried.

Development Snapshot 16

The main issue I ran into this snapshot was inflexibility of old code. I ended up having to revisit alot of code that is over 3 years old. That code was unable to be extended without introducing a horrific mess, so I took the high road and invested some time refactoring those ugly parts. This cost me some time, but the end result was worth it.

The majority of work this time was in the graphics area. I overhauled the look of the UI somewhat, replacing the WindowsXP-like windows with something a little bit more modern (in my opinion). I also rewrote a large section of my render loop in an effort to reduce frequent state changes. Instead of just blasting out draw calls, switching shaders and such on the fly, I now enqueue render jobs that are sorted to minimise changes where possible.

Skinning System

This was the major piece of work this snapshot. The first task was creating a rigged model in Blender.  I took my existing quick and dirty model and threw together a simple bone structure (after I watched a few blender tutorials). This fell together quicker than I anticipated, which perfectly set me up for bitter disappointment when I failed at the next few hurdles....

Next was modifying my collada importer to support bones. My previous implementation was done strangely to say the least. Looking at the code again after several years, I drastically rewrote it to be more flexible, and added the bone/joint data parsing as well. I lost a bit of time debugging why all the transform matrices had no translation component before I finally realised that collada matrices are Column-Major and I was assuming Row-Major. Once I got that fixed, the matrices looked right.

Then I had to rewrite my model class to handle the fact that there will be joints pushing and pulling the vertices all over the place, instead of being static. My previous incarnation of my model class was a hastily slapped together mess that came out of an attempt to get the code working again after one of my aggressive refactoring efforts over the years. I treated it as such and gutted it, also making it work nicely with my new render job system.

I then added in the vertex blending code. To aid debugging other parts of the skinning chain, I decided to implement software tranformation of the vertices, rather than use the vertex shader at this stage. (It's much easier to inspect values if they are in the CPU vs the GPU). The only bit of excitement here was initially my bone indices were off by 1, leading to the following image:

That sweet looking cape is actually his mangled torso.

After fixing that I decided that visualising the bones and joints would make it much easier to debug the vertex blending. I got really messed up by this. No matter what I did, the bones wouldn't render right when moved. I got the joints rendering correctly in their bind pose, but anything else and it would stretch at a weird angle. It took me several days of hair pulling, but the problem turned out to be the order of some matrix multiplications.

I knew I needed to multiply the joint's bind-pose Transform Matrix (BPTM) by the desired transform (Y), (in this case, a simple rotation), but whatever order I used, eg:  Y x BPTM or BPTM x Y, the end result was not right. Then it suddenly occurred to me that the bind-pose transform matrix is actually composed of a rotation and translation, and there was a 3rd place I hadn't tried putting the Transform multiply... in between! So I decomposed BPTM into R x T and put Y in the middle : R x Y x T, and holy crap... Success!

At this point I realised the next step of creating an animation system was going to have to wait until the next snapshot, which was disappointing.  On the plus side, the model's vertices are being transformed as per the skinning equation, and is rendering correctly, which I'm pretty pleased with.

Waypoints

To close out the snapshot I also overhauled the look of the player's waypoints. I'm not completely happy with the look yet, but its a great improvement over the temp graphics that I've had in there for several years now. It also forced me break down the paths into runs of straights and turns, which will be required for smooth walking animations later on.

Original style waypoints

New style waypoints

Next Snapshot

For Snapshot 17, the animation system is high on the list. There's quite a few sub-tasks to tackle though, so I'm not sure if I'll get through them all. The toughest stuff should be behind me, but I'll see what happens.

Development Snapshot 15

In this latest snapshot my main focus was on further survival-related mechanics, such as food and water borne illness, as well as typical game functionality such as loading and saving the game. The snapshot took a bit longer than anticipated, as I also did a complete refactor on my user input system, which ended up creating some nasty bugs.

The end result is much cleaner and is not bound to the keyboard or mouse devices directly anymore, meaning I can inject faked keyboard or mouse events really easily, which is great for testing.

Food and Water-borne Illness

The main survival mechanic I implemented this time is Food and Water-borne illnesses. Basically, if you don't cook meat before eating or decide to drink from a random puddle you'll probably become sick. The consequences could be dire as this type of illness lasts several hours and during that time your food and water usage rates are increased.

Not quite sure about the wording at this stage.

I've also introduced the ability for effects to debuff the maximum value of stats. This makes for some interesting consequences. Starvation now reduces your maximum health by 20%, and dehydration reduces it by 40%. These two effects can combine (for a net loss of 60%), making you more likely to be killed by pretty much everything.

I like the nuance of the maximum value reduction because it enforces an immediate penalty eg: loss of health when the current value is clamped to the new maximum. For example, Food Poisoning lowers your maximum food by 50%, meaning you'll get the "hungry" debuff. Since your max food was lowered you cannot eat food to remove the debuff. You'll have to wait for the food poisoning to wear off. In this fashion, debuffs can trigger other debuffs causing an escalation of problems.

Another significant change to game mechanics is that health no longer regenerates passively all the time. Health regen now only occurs while you are sleep, which gives a further reason for players to not avoid it for too long.

With these changes in mind, I've grown to dislike the energy stat again. I think I've added and removed it 2 or 3 times since I started the project, and I've convinced myself to get rid of it for good. The Energy stat's role in the player character's economy was mainly to force the player to rest or sleep periodically, and ensure they can't work non stop for hours without consequences. Penalising this behaviour can now be achieved in different ways, so its largely unnecessary.

I'm planning to introduce another stat in the future that model's the player's need for shelter in a survival situation. This stat is related to surviving in cold or very hot conditions. More to come on that in the future.

Save/Load

Saving turned out to be pretty easy. I'd already written most of that code previously when I overhauled my serialisation system a little while back. However, it seems I'd only half-finished the loading code as it turned out to be full of bugs and took quite some time to get under control. But now it is possible to save and load the game state. Hurray!

The game currently works in a partial client/server configuration. Eventually the server will be used by the client for all game logic, but at present it's just responsible for generating the world and then going to sleep. The client then takes over and does all the simulation. The save gamestate code should be run against the server, but it doesn't have the latest information as entity updates are not yet flowing back to the server (perhaps in a future snapshot). So for now the save code runs against the client gamestate.

In theory, having access to save/load should also help debugging, as I don't have to start from a blank canvas every time I want to start up the game.

Onwards to Snapshot 16!

Snapshot 16 is going to feature some graphical overhauls to the game. The most significant of which is starting work on a skeletal animation system, so our poor protagonist can finally put his arms down and walk like a human. 

I'm very excited about this, as it's long overdue. I started building the basics of this a few years ago but abandoned it and moved on to more interesting things. In fact, there are several partially implemented bone/animation related classes tucked away in the source code that haven't been used for several years. I suspect I'll end up throwing most of it away to be honest.

Another upgrade is making the waypoint system work a bit nicer. The main problem is that it only ever displays the waypoints after its done a full plot of the path using A*. So if you decide to change direction midway through a tile movement it can be up to a second before it clears the existing waypoint path, plots a new one, and then draws the new path in the world. This lag between clicking on a tile and a marker appearing there is disconcerting to the player, and shouldn't be too hard to tweak to feel punchier.

On the survival front, I'm planning to implement poisonous foods such as mushrooms or berries. If the player character has a sufficiently high survival skill they should have no trouble identifying which is safe to eat and which is deadly. 

Development Snapshot 14

Snapshot 14 (S14) is officially done.

As part of my attempt to get my project back on track I decided to limit the scope of each snapshot. In the past I'd planned for 6-8 week development cyles, which (due to lack of discipline) wound up overrunning and being more like 12+ weeks. This time round I tried to restrict myself to just 2 weeks. I ran into some unexpected hurdles that pushed that time out a bit, but S14 came in at just over 3 weeks. Hurrah!

What did I achieve in Snapshot 14? 

About half the time was spent on refactoring and improving existing code. I've learnt a great deal about writing better code in the last year, and there's plenty of poorly thought out design in my codebase. This is a legacy of the fact that I'm a much better developer now than when I started the project 6 years ago.

I made good on my promise to start building parts of the system which are essential for the game to be releasable. Eg: the ability for the player to die.

(work in progress)

Starvation and Dehydration are now actual threats in the game. The way it works is as follows:  Living creatures have health, food and water stats. Creatures will be able to consume food or drink that will instantly affect their food or water levels, but health can only be regenerated naturally.

The player's health, water and food display

While alive, creatures consume food and water. These rates are dependant on factors such as the activity level of the creature and the ambient temperature. Once the creature runs out of one of the resources, the amount consumed (plus a penalty) is instead taken from the creature's health.

I'm still tuning the rate at which it occurs, but for a player at full health its something like 2 days without water or 5 days without food before death occurs. Obviously if you're already injured and you're out of both food and water it's going to be considerably shorter.

I'm hoping to make the game less about combat and more about other interactions, such as exploration, negotiation, stealth etc. Since you can't instantly regenerate health, the way players approach combat will need to be more tactical. eg: Taking an enemy by surprise and knowing when to retreat. In addition, NPC's will be less likely to resort to deadly violence unless desperate as they value their lives and the lives of their families.

What's in store for Snapshot 15?

Next I'm going to expand the eating and drinking system to include food and water borne illnesses, such as eating uncooked meat or drinking contaminated water. Also on the agenda will be the ability to save and load the game. Most of the code is already in place to serialise and deserialise the gamestate, however its not being persisted to disk yet.

It's not a huge amount of effort, which is probably why I've put it off, but its essential for Release Ready status.  As previously stated my plan is to drag the game up to a point where I can start making test builds publicly available. Its quite a way off, but at least I'm now heading in that direction!

Basic Survival

So, as previously mentioned I've spent the last few weeks refactoring my codebase to remove ugly static references. I also improved the design of a few important modules, and overall I think the results are very positive. There's still a bit of work to do in this area, but the parts involved I've planned to completely rewrite in the future anyway, so I'm comfortable leaving some ugly code in there for the short to medium term. Note to future Chris: hahahahaha suck it!

What's next? Addressing the lack of focus on the important elements of a survival game. For example, being able to die. In the early game there are 3 big threats to survival ; Lack of shelter, lack of water and lack of food.

Shelter

The most critical factor is shelter. Humans can survive several days without water and a week without food, but extremes of temperature can kill you in hours. Staying cool in the heat and warm and dry in the cold will be vitally important if you expect to survive.

The easiest way to shelter from the elements will be to find a natural cave or a ruined building. In some cases you may have to clear out its existing inhabitants first. If such a shelter is not available, the player may have to construct something.

The simplest structures the player can build will be little more than a few strategically arranged tree branches. This will stop light rain and give the player some shade from the sun, but they are fragile and will be easily destroyed by moderate winds. Since they only provide partial protection from the chilling effects of wind, a campfire will be essential for surviving the night.

Once the player gains access to better materials and tools they will be able to build more permanent structures such as huts that will also keep in warmth and provide protection from other threats such as wild animals.

Clothing will also influence your ability to stay warm. Being caught in the rain or falling into water is a nuisance when you live in suburbia and can pop home to change your clothing, but in a survival situation it can be fatal. Better find somewhere to get out of the rain and get a campfire lit before the chilling effects sap your strength.

Water

Lack of water is the next most critical survival factor. Depending on the weather and exertion levels, humans need somewhere between 2 and 5 litres of water a day. Once the player has a shelter sorted out, finding (and maintaining) a source of fresh water will be the player's most pressing daily need.

In the early game the player may be scavenging water from whatever sources they can. If the player is lucky it will be a freely flowing river. If not, it may be a stagnant muddy pool with any number of pathogens lurking within.

Recognising if a source of water is safe to drink will be a vital skill. Contracting a water borne illness will only accelerate your dehydration and leave you vulnerable to other afflictions. The safest option will be to boil your drinking water, but this may not be possible if the player can't find a suitable container or a way to start a fire.

Food

Food is the final factor. There is less urgency to this one, but it cannot be ignored completely. There will be many food sources available to the player depending on their skill level. In the early game it will be edible plants and less palatable options such as insects. This will only get the player so far though. If the player wants to survive long term, fishing, hunting and trapping will provide improved sources of food if the player has the necessary skills and equipment.

As with water, food borne illness will be constant threat, so avoid spoiled food and cook things prior to eating.

Final Thoughts

In reality if you're in trouble you'll probably die from a combination of these factors.

Without food you may lack the energy to build a shelter. Without shelter your hands may become numb with cold and you're unable to start a fire. Without fire you shiver through the cold night and are unable to boil your drinking water before consumption.

Your thirst has been quenched, but you're exhausted from lack of food. You're approaching the beginnings of hypothermia and you've just started having stomch cramps, nausea, vomiting and dizziness.

Sometimes life is cruel.

Spring cleaning

So in my previous post I discussed how I had returned to this project after a 7 month hiatus. To get back on track I decided to do a bit of code spring-cleaning. Its actually spring here in the southern hemisphere, so it seems appropriate.

Before beginning work again on the game proper, one of the aspects I wanted to improve was the testability of the codebase and eliminate the global references that have spread through the codebase like cancer. Note: my codebase is written in C# in which global objects are defined as "static", so where I say "static", it's the same as global.

First step; make the static classes instantiable!

It turns out that I converted my EntityManager class to not be static at some point, so that was a huge advantage. However, it is created once, early in the life-cycle of the application and is stored in a global that is referenced throughout the app... bugger... about 500 times... double bugger.

Also I have a mixture of local server and client code that refers to the same references but use them in different ways, and some references that use [ThreadStatic] as a workaround to correct problems where different threads needs different versions of the same object. Truly the stuff of nightmares!

Because of that I'd written some truly horrific unit tests that had to start up most of the game engine in order to test something simple like the serialisation of a component. Seemed like an excellent place to start my clean up!

Dependencies to the rescue!

I refactored a lot of code to accept an IEntityManager instead of using the global reference, and over time my unit tests cleaned up considerably. I applied the same logic to other manager objects and eventually my unit tests became completely independent of the rest of the codebase, relying on mocked versions of the important managers, injected as dependencies.

I continued this initiative and carried it over to other globals, and I've managed to completely remove some of the  references entirely. The client and server code is now safely segregated and the ThreadStatics have been removed.

The aforementioned EntityManager global still has 200 references to it, but that's a great improvement on the 500+ that were there when I started this effort. Furthermore, the AssetTemplateManager is down from over 100 to just 27 references. There's still some way to go - the target is to remove all global references..

So, lessons to be learnt here? Static/Global references are bad and once introduced to your codebase they tend to spread unchecked. I've been working on this codebase for over 5 years, and I've learnt a great deal about C# and development in general during that time. Anything in the project older than a year makes me cringe, and there's stuff still in use that was bedded down in the first few months of the project. I had no idea about dependency injection or why global references were a bad idea, and now I've seen the error of my ways.

On a side note, I've discovered that Squarepusher is great for refactoring!

Progress Update September 2016

Where to begin? Not long after my last post, development on Bulldog stalled badly. I had a few other game ideas kicking around and after some soul searching I decided to put Bulldog on the backburner for a while and start developing one of the more promising (and less ambitious!) ones. I made some good progress, and even trialled some changes to my development process.

At my day job as a developer we've been transitioning over to a Test Driven Development process. I've embraced a lot of these ideas, such as Dependency Injection and Mocking for my part-time games development. Its really shown me where I went very wrong with Bulldog's development from the outset.

Now, fast forward 6 months or so and I'm about to abandon the new project, (code-named "Collie") and switch back to Bulldog again. What the hell?!

This is for several reasons:

1. My design for Collie isn't really mature enough. 
2. While working on Collie, I never stopped thinking about Bulldog, and kept coming up with cool new ideas for it, which suggests to me that my subconscious really wants to build that game, not Collie. 
3. I've hit a bit of a wall and can't find motivation to continue on Collie at the moment. Perhaps related to #2?

So... you wasted seven months?

Not exactly. Working on a new code base, it really illustrated to me the problems I was living with in Bulldog, and as mentioned earlier, I can really see where I've gone wrong with singletons and statics all over the place.

I'm excited about getting Bulldog back on track again, and have great plans for resuming development and refactoring the codebase to correct my previous mistakes that prevent proper unit testing etc.

I've also learnt a lot about focusing on the value of new features, and developing the most crucial things first, not the coolest or hardest ones.

On this note, I came to the shocking realisation recently that Bulldog is at its core supposed to be a survival game, but after 5 years of development, I haven't coded the ability for the player to die yet! I've got procedurally generated terrain, real time shadows, pathfinding, a custom UI, status effects, loot tables etc. But if the player's health hits 0, the game locks up. What the hell?!

So yeah, I'm coming back to the project with a healthy dose of "What the hell was I thinking?", a fresh perspective, some new development skills and a renewed passion for making this game.

Onwards!

Progress Update February 2016

As is rapidly becoming the norm, I've scope-creeped the hell out of this latest snapshot. I'd intended to wrap it up just before Christmas, but here it is, 2 months later and I've still got over a month of dev to go. I made the mistake of starting work on a feature I didn't have a really solid design for. I thought I could "wing it" and the gaps would naturally fill themselves in, but I hit a few issues that basically blew that out of the water. I've sorted out the design now, but there's more work to be done before I can tick crafting off my todo list.

I changed my mind re: the UI redesign I mentioned in my last post. It is going to be much harder to change in the future, so now is the best time. It ended up taking about 3 weeks, but I've replaced my old, half-assed layout system with a newer, more flexible one that's now using its whole ass. As a bonus I fixed a few lingering layout bugs that have been annoying me, so yay!

I've got a fairly good design & plan for the next month of development. Barring any unexpected hiccoughs, I hope to put crafting to bed and move on to some of the exciting new things I've been dreaming up over the past year.

Progress Update January 2016

Happy new year everyone!

What have I been up to since October? Less than I would have liked. However, I've made some excellent progress on the crafting system again, taking some influence from games I've been playing recently. Unfortunately I find it way too easy to make my game systems crazy complicated.

One of the risks of being a one man dev operation is you have to be your own bullshit filter. I often get so enamoured with an idea I'm working on I don't realise it will be terribly complicated for the player until I'm a decent way in. Eventually (once the shine wears off) the sanity police rock up and I drastically cut functionality and make it sane. I just wish it'd happen sooner, so I don't waste development effort. :)

On a related note, recently I've discovered some annoying issues in my codebase that are not going to be quick fixes and are preventing me from building certain pieces of functionality. They are relatively minor presentation things, so it isn't a big deal at this stage, but at some point I'm going to have to redesign my UI system to be more flexible. Not looking forward to that at all.

On a non coding front, I recently made some major breakthroughs on the backstory front. I've broadly defined the story elements that will occur leading up to the player taking control and even had some ideas for a short intro sequence to relate this to the player. Previously I had a general idea for what I wanted but there was no clear path from normal world to the game world, narratively speaking.

In the development pipeline for the future I have: Finishing off the crafting system, as well as some technical architecture things such as a procedural content system I've been itching to get going on, as well as rendering improvements such as LOD for my terrain meshes.

Until next time!

Progress Update October 2015

A while back I finished Snapshot 12. It turned out to be one of the longest snapshots I've worked on, coming out at about 8 months. Most of the changes were behind the scenes stuff, so to most users nothing has changed since the beginning of the year.

Under the hood, I've made quite a lot of changes. The biggest of which is splitting the codebase into a client and a server thread. Currently the server thread takes care of creating the initial terrain, and nothing more.  However, over the next few snapshots I'll gradually move more of the client's processing into the server, with the eventually goal of supporting multiplayer.

One of the biggest issues I encountered during that time was serialisation of gamestate. Somewhere around 2 years ago I made an error in judgement which made serialisation impossible without an extensive rewrite. I didn't notice at the time because I hadn't written any of the serialisation code yet.

In retrospect I should have implemented the save and load functions early on. This would have forced me to consider game state serialisation immediately.

So, lessons to be learned here:

1) As soon as you start creating game objects, write the code that serialises and deserialises them.
2) Maintain your serialising code. If you modify the game objects, modify the serialisers. Don't rely on coming back to it at a later date. You will forget.
3) Write unit tests to verify your serialisation/deserialisation process works correctly and then maintain them.

Progress Update July 2015

In the last couple of months I've continued integrating the fruits of my new terrain generator side-project into the main project. Progress has been good, and I should be up and running with the new terrain any day now.

I took a brief detour to explore network connectivity as I've always imagined that Bulldog would eventually support multiplayer functionality. Since I started the project with singleplayer in mind, there's a great deal of work to do to make the game client/server capable. I decided to kick things off by getting the new terrain generator to run on the server thread, and have the client request it via a network call, as it will eventually function that way for multiplayer.

Before I could get going on that I needed to decide on a network stack. I started rolling my own and got a little ways into it with a brief proof of concept that achieved listening and connecting before I decided to look around for pre-built network solutions for .net.  The first one I came across was RakNet, it's been around for quite some time, is used by a lot of people and supports C#.

I grabbed the source and I've spent 4 hours trying to get the examples compiling. I followed the c# tutorial and ran into issues, such as the build failing due to missing folders. So I fixed that by creating the folders. Then there were files missing from the project. I found them and added them to the project. None of the generated files have any standard "using" clauses, so I add the required "using" clauses to the generated code. Now I'm stuck with build errors such as "Cannot implicitly convert type 'RakNet.Row' to 'RakNet.TableRow'" or "Cannot apply indexing with [] to an expression of type 'RakNet.SWIGTYPE_p_DataStructures__ListT_DataStructures__Table__Cell_p_t'"... the list goes on...

The above paragraph is actually from a gamedev.net post I wrote in desperation after having no success with RakNet. Luckily, my friend, axefrog, saw my post and put me onto lidgren, which I'd also seen during my searches before I settled on RakNet.

I took his advice and checked it out and the difference was like night and day. It required one tiny tweak to get it working (Bulldog is built on .net 4 and the latest lidgren assumes .net 4.5 or higher). I hit the internet for tutorials to write some test code. Unfortunately most lidgren tutorials are slightly out of date, leading to a weird corruption issue with status messages, but I sorted that out quickly. In an hour or so I was up and running with a decent message-based network system.

This represents a big change. It's very unlike me to rely on 3rd party components. I much prefer to write everything myself as I can fix bugs in my own code or add functionality I need. I felt vindicated by the difficulties I experienced with RakNet and was itching to go back to the roll your own method. The subtext of my gamedev.net post was that if I didn't get some decent suggestions I was going back to my own implementation.

In the end I'm glad I didn't, and I'm indebted to axefrog for putting me on the right path.  Cheers, mate!

Progress Update April 2015

This morning I fired up Mercurial and noted that my last check-in was 6 weeks ago. I'm kind of surprised, I expected it to be much longer. The last couple of months has seen my day job almost completely take over my life. Working on the weekends and out of hours meant there's been little time to even say "hi" to my family, let alone work on this side project. Fortunately, the crunch is now over, and I can go back to a more manageable schedule.

What has happened in the last 5 months? Early on I decided to completely rewrite my terrain generator to incorporate a long list of improvements, as well as finally get around to producing correct biomes.  The main project is currently using my 2nd generation Terrain generator from a few years ago, and this new one will be version 5. What happened to version 3 & 4? They were experiments that failed but ended up teaching me the techniques I've now honed in version 5. The new terrain generator is faster and produces much more interesting terrain than before, but so far I've failed to achieve the full objective of producing biomes.

An example of the terrain I'm currently creating. 

The rainfall map generated for the same terrain.

Part of the reason is due to the intrusion of my day job into my spare time as outlined at the beginning of the post. The second is that I'm in uncharted territory and there has been a great deal of trial and error. One of the key factors involved in biome assignment is rainfall, which is a fairly complex phenomenon. In the real world, it involves temperature, pressure, moisture, wind and is affected by the topography of the land itself.

However, I'm not trying to simulate a full on climate system, so I've taken a bunch of shortcuts. Like others, I've tried to seed the world with moisture, then introduce winds, and let them move the mositure around generating rainfall. Since this is a gross abstraction of what is really happening, the results are quite unpredictable, and its taken alot of tweaking and fine-tuning of the overall algorithm to achieve useful results. That said, its still not right. Some areas are completely bone dry, and others receive the equivalent of an olympic swimming pool of water every hour.

To add to the complexity, I decided to take into account seasons. In the real world, average wind patterns change with the seasons, leading to vastly varying rainfall. I wanted to achieve something akin to realistic conditions on earth. Eg, some places have about the same rainfall all year, others have a distinct wet season where the rains are torrential, whilst others receive very little rainfall all year round.

I said earlier that I failed at my objective to produce biomes. I decided to have a go at the terrain generation rewrite because I'd made good progress in the previous months re: updates and thought I needed to work on something a bit more experimental for a few weeks. That ballooned into several months, and its not even finished yet, so tangible progress on the main project is non-existent, because the new terrain generator isn't finished enough to make use of.

Time to knuckle down and finish.

Progress Update November 2014

Earlier this month I finally released my first development snapshot in over 14 months. It's kind of depressing that it took so long, and when objectively comparing the difference between the old snapshot and the new one, it almost seems like a step backwards, not forwards. The last 14 months has seen some extensive refatoring going on behind the scenes. I completely ripped out my old inheritance-based creature/item/etc classes and replaced it with an Entity Component System, which has taken a little bit to get used to it, but now it seems like its always been there!

In addition to that, I started switching the entire game project to Unity for a few months before deciding it was not for me. I also found it hard to dedicate any time to the project for many months, and time just slipped away so fast. I've remedied this in recent months and finally decided to polish what I had and show it off to my friends and work colleagues to get some feedback. I managed to get quite a few people involved who'd never seen it before, so the pressure to have progressed from the last snapshot wasn't really there. I got some great feedback that re-energised me and I've made great progress on the new snapshot, which has seen some exciting new features implemented, and some UX/UI improvements.

All in all, the experience was positive, and I'm keen to produce snapshots more often. By next post I hope to have some exciting news to share about the project as a whole. We'll see how that pans out.