Apr 14, 2015

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.

Nov 23, 2014

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.

Oct 2, 2014

Progress Update October 2014

The last couple of months haven't been the best for the project, but I'm still moving forward, albeit at a slow pace.

I won't go into excessive detail, but I'll just mention that I was sick for about 4 weeks with the flu, which meant I was barely keeping it together enough to head into work on the good days before coming home exhausted and collapsing into bed. The bad days were... unpleasant. This means I didn't have many contact hours with the project in the past few months.

That said, what have I been working on recently? I decided to finally implement the virtual file system I've had as a TODO item for months.

Virtual File System

The virtual file system is there to allow you to reference files or resources using a virtual path, eg: "/textures/UI/border.png", and then resolve that to a concrete asset when needed. That file could be part of the standard path of the game's data folder, or it could be part of a packed resource file that contains many different files. By removing the reliance on hardcoded paths, patching (and maintaining the patches) for the game will be considerably easier.

To issue a patch, I'll provide a packed resource file that contains a file manifest, and that will automatically be included (and supersede) the already installed files. So the request to "/textures/UI/border.png" will be re-routed to the patch file instead of the original files.

This should also make developing and maintaining mods for the game relatively easy. I've converted approximately 50% of the file-loading code in the project to use the new virtual file system, and it appears to work quite well.


Another thing I looked into was incorporating a scripting language into the project. I'd previously investigated this about 2 years ago, when I had a crack at introducing IronPython support. It took a while to get working and I converted some of my GUI creation code into python. But it seemed like I was struggling to find code that would make sense to convert, and it seemed easier for the interactions with the rest of the code if it was all in C#. So I eventually backed out the changes and went back to pure C#.

Jump forward a few years, and I now have an Entity Component System that runs the whole show, and adding a new "EntityScriptComponent" was pretty much trivial, and would allow entities to run custom code where needed. I decided to revisit my original thought on using Python, and looked around for some good .net compatible Lua implementations. NLua pretty much fit the bill and I had it up and running it 10 minutes or so.

So Bulldog now support scripting to a limited extent. For now, I've created hooks for OnSpawn(), OnDespawn() and OnGameTick() for entities themselves, but as I develop the game content further I'll expand on those as appropriate.

Parting Thoughts

I'd really like to get this Snapshot 10 finished, as I've been promising it for months now. I'm slowing reducing the list of bugs introduced by the refactoring brought about by the push for crafting, and am slowly bringing the project back to a more stable state. Soon.

Jul 24, 2014

Progress Update July 2014

I began work on Snapshot 10 at the start of June, and initially made some good progress. Once again I've come back to the issue of crafting. Crafting in some form or another has been in Bulldog for over a year now, but it has never really gotten past the proof-of-concept stage. One of June's tasks was to address the crafting situation once and for all.

I've made some pretty good progress and answered some of the lingering questions I wasn't sure about previously. As with most of my game design, I looked at other RPG user interfaces to see what they did, and try to come up with something that is intuitive, but suits my specific needs.

One of the inspirations for Bulldog is Minecraft, so the Minecraft crafting system was high on the list of candidates to examine. While I think the shape-based crafting is a really clever idea, it doesn't suit the style of play I have planned in Bulldog. Instead, I've opted for a 5-slot shapeless system. The choice of slot count is actually a fairly tricky one. If you have too few, then crafting recipes become a bit boring. If you have too many, then crafting becomes cumbersome, since you need to have access to all the different items at once, which takes up inventory space. Five is a happy medium between the two extremes I feel, but I'll see how it goes when I get to playtesting.

"Crafting" is actually made up of 4 sub-types. Assembly, Construction, Salvage and Processing. The line between the various types is actually blurred considerably in practice, so the player need not pay attention to the individual types when playing, but from the code point of view, they represent very different things.


This is your typical crafting most players would be familiar with. You take a number of ingredients and create a single output. Eg, you might take a tree branch, a stone and some duct tape, and craft a stone axe with it.


This is similar to assembly, but it is for crafting larger items that are built directly in the world. For example, you might take a bunch of wooden logs, and a lot of stone, nails etc, and construct a small cabin. This also has the distinction that you would initially prepare the building site, as well as having the opportunity for others to contribute labour as well.


Since Bulldog is a modern, semi-realistic post apocalyptic world, the player won't be mining ore, smelting it in a home made furnace and making iron ingots. However, the ruins of civilisation are everywhere, so Salvage is going to be a VERY important skill. This is the process of taking something and breaking it down it useful raw materials. Eg, taking a wooden pallet and breaking it apart with an axe (or sledgehammer) to produce some useful wooden planks (as well as some scrap). Later down the track this will also include careful disassembly of electronics and other technology.


Finally, we come to processing, which is basically anything that a machine, device or similar entity does to convert something into something else. For example, cooking a raw piece of meat on a campfire or stove, and producing a cooked piece of meat. These are generally passive tasks that the player can set and forget, whereas the other 3 are all active tasks, that require a direct investment of time and labour from the player.

As is usually the case with any expansions I need to make to the game engine, there was an unexpected hiccough. I planned to add a new type of slot control, which only allows references to entities in other slots. This sounds complicated, but is actually quite common in other games. Wherever you have a "HotBar" or "ActionBar" onto which you can drag items. The actual item is somewhere else, maybe the players inventory, or a spellbook etc, and the slot only stores a reference to the real entity.

A short time into attempting to implement that control I realised that half the drag and drop functionality that is specific to the existing slot control is hardcoded into my WindowManager class! This is *terrible* design. I don't know what I was thinking when I did that. It will be next to impossible to implement the new control without making things even worse. So, I had to take a step back and tidy up the existing implementation first.

The end result of this unexpected work (and a sudden loss of free time for several weeks) is that Snapshot 10 has gone way over time.  As of this writing, it isn't complete, and will require some serious effort to bring it in before the end of August, which is kind of piss poor, but I soldier on...

In non-coding news, I've been doing alot of design work on random parts of the game, and coming up with some interesting ideas for the backstory of the gameworld, which I hope to share as time goes by.

Now, if you'll excuse me I have to get back to coding...