Mar 28, 2011

As part of this blog I wanted to talk about my failures as well as my successes, so in the spirit of that I'll talk about things which have tripped me up recently and what the solution was, in the hope that someone else with the same problem might be able to learn something.

Full Screen Mode
One of the early things I implemented in the main engine was the ability to go to full screen mode. It's not a big thing, its pretty much in every game. Though you need to properly reset the Direct3D device and free up all your resources and load them in again in order for it to work. Which can be tricky for those unfamiliar with Direct3D to get their head around. I consulted many tutorials and got it working and then ignored it for several months.

I switched the game to full screen mode on the weekend and the screen resized to fit the entire screen but the rendering stopped, and the entire app hung. Obviously I'd broken something in the last few months. To cut a long story short, I'd implemented a new way of handling the Resize events and that was firing when it shouldn't and was stopping the rendering. After I fixed that, it worked again... mostly.

My UI elements, (which admittedly didn't exist when I coded the full screen mode) were not receiving mouse clicks correctly, as though the coordinate systems were offset somehow. I discovered that the actual dimensions of the full screen window weren't correct. Though I was setting it to be 1680x1050 (the max resolution of the laptop I do development on), the window was coming out as 1664x1015 or something. Stretched across the entire screen this would cause misalignment of the mouse cursor vs the controls and exhibit the behaviour I noted.

After much googling, I finally discovered that you need to set the borderstyle of the form to none when going to fullscreen and then restore it when switching back. When I originally implemented full screen mode that little quirk wasn't mentioned in the tutorials I looked at, and because it looked correct, I assumed it was correct, due to the perception that full screen mode should have been a cinch.

I guess the lesson here is never assume that you're done correctly just because it's a simple task, and the output seems correct.

Mar 14, 2011

It's overdue for me to talk about the "bigger picture" of what Bulldog is supposed to be, so in this post I'll hopefully begin to shed light on what I have in store.

Ambition
Bulldog is a very ambitious project. It may not seem that way based on what I've discussed so far in the blog, but my long term plan for Bulldog is grand in scope. It may take 5 years for me to fully realise what I have in mind, but the project is somewhat modular, and can be broken down into more manageable milestones.

As mentioned in previous posts I plan to have a release out by the end of the year. Beyond that I plan to release new content and upgrade the game at regular intervals, slowly building Bulldog to where I want it to be. This strategy is pretty much essential to have any chance of success, as I am doing this project in my spare time and if I decided to not release anything until its "perfect", there would never be a release. Something (albeit flawed) is better than nothing.

In terms of what genre Bulldog falls into, the best I can come up with is open world survival RPG. Open world is perhaps not the exactly right definition, it's more akin to how Minecraft or Dwarf Fortress generate new worlds and don't force a specific storyline on the player. Perhaps "open-ended" is more accurate, but I haven't really heard that term used when describing this sort of game. The key thing here is that the player drives the story through their actions (or inactions) rather than by completing a series of quests or puzzles in sequence and then getting a nice ending cut-scene.

Survival is the ultimate goal. There will be many variations to achieving this goal. To some players survival will mean exploring the gameworld, scavenging supplies, fighting off threats, amassing wealth and levelling up.

To others it will mean building up a thriving community, rebuilding civilisation and having to content with "the greater good", rather than just yourself.

Origin Scenarios
A key feature I'm planning for Bulldog is the ability to select a specific survival scenario when you start a new game which will define and shape the generated game world. This will hopefully allow more re-playability, as well as allow more options for the player to customise their survival experience.

The different origin scenarios will have a impact the game quite differently. For example, in a zombie outbreak scenario, you'll be fighting off hordes of the undead in a messed up but relatively intact world. There will be plenty of stuff to scavenge, but there will also be danger lurking around every corner, and you don't even want to contemplate what will happen if you don't get back to camp before dark.

In contrast, consider a post nuclear war scenario where most major cities will have been completely obliterated and entire areas will be uninhabitable due to radiation. Nuclear winter may have set in and food and drinkable water will be scarce, weather effects such as dust storms and intense thunderstorms will batter your settlements and destroy anything the nukes left standing.

The origin scenario I'm planning to include in the end of year release is a Desert Island, similar to the situation in the movie "Castaway", starring Tom Hanks. You've washed up on a desert island with a bunch of random stuff and have to survive. I chose that scenario for the simple reason that the player can be contained within a finite space as opposed to the practically infinite dynamic world generation I have planned for the final version. Getting that sort of terrain generation working correctly is going to be a major challenge, and I'd rather start with something simpler, such as a desert island.

An interesting point that people may not realise is that "desert island" doesn't actually imply the archetypal small pile of sand with a single palm tree. The "desert" part of the phrase doesn't even imply an arid, desert-like climate. It actually comes from the word "deserted", literally meaning there isn't anyone else around.

Mar 7, 2011

Since my last post I've been working on adding more controls to the UI, and in so doing managed to break the entire UI system for about 4 days. Argh. I didn't really have a lot of spare time to spend on fixing it, so the game engine was left in a non-functioning state for the entire time, which I hate doing. I could have rolled back the changes since I use source control quite religiously, but the change was necessary and I powered through and got it back up and running.

My initial implementation of the skinning system as detailed in my previous post made a few assumptions that came back to bite me when I tried to implement the checkbox control. I'd decided that controls will only need 4 different states, which I reasoned at the time was:

Normal

Highlighted (mouse over the control)

Disabled (that greyed out non functional look)

MouseDown (for buttons and the like).

When it came to the checkbox control I realised there are really 6 states involved:

Normal Unticked

Highlighted Unticked

Disabled Unticked

Normal Ticked

Highlighted Ticked

Disabled Ticked

The Button Control skinning was implemented naively, as it too should really have 6 states. Furthermore, some controls may want more than 6 states, and some may only require 3, so hardcoding the system to have 4 skinning states wasn't going to work. The coding change to allow for a flexible number of states was doing my head in so I ended up with a bastard child of different approaches all working against each other which broke everything.

The good news is that its working now, and I've pretty much implemented every UI control I'll need in the near future. I may need to tweak a few things in the existing controls to add functionality over time, but I shouldn't need to make big changes like the ones that spawned the unholy abomination this week.

The "game" parts of the game.

An important gameplay element that relies heavily on the UI is inventory management, which is pretty much ubiquitous in video games. Now that I actually have a rudimentary UI happening, I've managed to get a basic test inventory working, where you can drag and drop items from slot to slot and you have a tooltip window appear when you mouse over items.

It doesn't sound like it should be much work to implement, and truth be told it isn't. However, it relies on a lot of other elements (some small, some huge) being in place. Working on the UI for several weeks is fairly boring as you dont make any tangible progress on the "game" part of the game, as being able to click buttons and checkboxes without any actually context isn't exactly awesome fun.

Prototype game mode for Bulldog :p

In reality, there is a HUGE framework of non-game parts that have to be built before you can get anywhere, so in the beginning, identifiable progress can be slow, but once you reach a certain threshold you're mostly doing "game" parts, and it all starts to come together. Kind of like paying a mortgage - in the early years its all interest payments and very little principal, and later its mostly principal. Well, thats the theory anyway. :)

So, even though its a small feature in the grand scheme of things, the inventory screen is very important, and getting a working prototype up and running is a good feeling.