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.

Assembly

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.

Construction

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.

Salvage

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.

Processing

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...

May 26, 2014

Progress Update May 2014

The Entity/Component/System refactoring is officially over, and the new codebase is much better than the old one. I won't elaborate on the advantages here as I've already talked about that in previous posts.

The one remaining task I have on the ECS front is to overhaul the rendering system to make use of the new components. Currently the renderer is using a hybrid of the old and new and is pretty messy. I've had a task on my todo list to redesign part of the renderer to allow better control of the shaders, (which I'll need for graphical enhancements I have planned for the future), so it seemed easier to roll the two tasks into one.

The immediate future will feature more testing, and then preparation for Snapshot 10, which is due to kick off on June 1st. Snapshot 10's major new features will be allowing the player to rest/sleep, introduction of some proper crafting, and a bunch of content additions to round out the items a bit. It's exciting because it will finally be some forward progress again after almost a year of stagnation.

As part of my renewed commitment to the project, I'm going to try (once again) to be more forthcoming with updates, and try to coincide them with each snapshot I build. So, I'll be aiming for a once a month posting schedule, and try to include some screenshots of what's going on. We'll see I guess. :)

Apr 28, 2014

Recent developments.

There hasn't really been much to report in the time since my last blog post. I've been doing a long overdue major refactoring of the entire architecture of the game.

I'd originally developed Bulldog from an Object-Oriented approach, but ended up running into the Diamond Problem, where different classes needed common functionality but didn't have a common base type. I worked around the issue for many months and then stumbled onto the solution; the Entity/Component/System (ECS) pattern. I did alot of reading into how it works and realised that it was the perfect solution for all my issues.

I started converting the codebase to make use of ECS around a year ago, but only a short way into the work I had to put Bulldog on hold due to a reshuffling of my business interests (as mentioned in my previous post). At my new role I was put onto a fairly large project with a tight deadline, so finding spare time for Bulldog was difficult. Now that the project has matured, I'm finding I have more free time again, so in the last couple of months I've resumed the ECS conversion in earnest.

By my reckoning I'm about 75% of the way through the conversion, so there's a few weeks to go. The most frustrating thing about this type of work is that the end result is all under the hood, and not visible to anyone. If you were to compare the latest build to the build I did 12 months ago you'd be hard pressed to tell them apart. Such is the nature of architectural changes.

That said, I have some big things planned for the development of Bulldog in the second half of this year. None of which would have been possible without this architectural groundwork being re-established now. So yeah, stick with me on this... :)

Oct 8, 2013

The continuation of the project? Aka: Why so quiet?

It's been quite a few months since my last post. The last 7 months have been pretty busy times from a personal and business perspective. Though I haven't spoken much about my day job in my posts before, I feel it deserves a mention now.

For over three years myself and two other guys ran a software development business specialising in database-driven desktop applications. Running my own business allowed me to take half or whole days off each week to dedicate some quality time to Bulldog.  My take home pay suffered a little as a result, but the bills were getting paid, so it wasn't all that bad.

Not long after my last post in March, through a complicated series of circumstances, our biggest customer suggested we shut down the business and become permanent employees for them. After considering the situation we agreed and set about shutting down the business.

Let me tell you, it's pretty stressful and takes a lot longer than you'd think, especially since we still had to meet our previously agreed development deadlines. We started with them officially on the first of July, and have been pretty busy in our new roles ever since.

A welcome side-effect of the change is a much higher salary and not having to worry about all the busywork you have to do as a small business owner. An unwelcome side-effect of the change is that my work is very full on now and there's no room for work on Bulldog during work hours. Additionally, the work is more draining mentally than before and so when I get home the last thing I feel like doing is firing up Visual Studio again and coding for a few hours.

Despite these setbacks I don't regret my decision at all. My wife and I have another child on the way, so a higher paying job couldn't come at a better time.

So what's happening with Bulldog? Well, the good news is that I've managed some sporadic bursts of coding in the last few months, so the project is not dead. I'm determined to make something of this, so I'm going to continue chipping away where I can.

I've started to write another post which I'll clean up and submit sometime soon hopefully. It details some of the coding I've been doing recently which should take care of one of the most important aspects of the game, terrain generation.