Navigating The Flow

Hey Readers,
 
It's been a busy couple of weeks. My main focus has been on getting in some kind of backend interface to control all of the different commands that are going to be available for the user. I needed something that would be flexible since there are going to be so many different possible commands.

User Contexts

I decided to go with something I call User Contexts. The idea behind the user context is simple, It's basically a state object which contains all the logics to execute commands for that context. So for example

Main User Context =>Has two options, Build Item and Move Item            
*Build Item
    Build User Context =>Choosing Build Item spawns off a new Build User Context from the Main
    *Build Wall
    *Build Floor
*Move Item
    Move Item Context
    *Click on location to move item to

So each user context knows about it's current state and how to construct the next level of user contexts which are based on the available commands. When a new context is created it's returned to the main game state as the current context. In addition each previous user context is linked to the next context so that when the current user context is finished it can easily jump to the last context.

Interfacing with the User

This was all well and good for the back end but I needed a way to convey this to the user. To keep things simple I decided to build a console UI element which could be easily written to. I didn't want to waste a lot of time fooling around with creating new UI's for each User Context so I thought this would be an easy alternative that would still convey what the possible options are to the user. I set up a function in the User Context which takes in a UIConsole so that each context can print whatever information it needs to convey. There's also a number of functions for user input for overriding what the functionality should be when there's mouse or keyboard input.

Status of the Game World

While I was mucking around with setting up this user context console window I thought it would be great to have another console window for displaying information about the currently selected object. I haven't really taken this one too far but my thought is to set up a status component I can give to each of my game objects so they can convey useful state to the user. Some useful info might be how much resources are left in a crate, or what ability a character is currently using, or maybe how much is left to do on an object in construction.


In the coming weeks I'd like to flesh out a few more gameplay features: obtaining resources, the job system, item destruction. We'll see how far I get though. I've posted another video showing the progression I've made. You can see the User Context console is in the top right corner and the object status console is in the bottom right corner.
 



Having Fun With Behaviour Trees

Hey Readers,

The last two weeks I've been working on resource management and progressing on the job system.

Job System

My initial plan for the job system is essentially that every job has a set of abilities. These abilities can be learned by having that job assigned. The user can issue requests which need to be executed but not directly use the abilities. I iterate over all the character looking for a character that has an ability which can execute the request. Initially I implemented the abilities as a chain of actions. This worked good for my basic needs, my first ability being a build item ability, which consisted of an action chain with a move action and a build item action. This worked but then I started looking at resource management( like using resources to build something, not like in game assets ) and quickly realized that my simple chain of actions was not going to get the job done.

Behaviour Trees

What I decided to do was to make each ability it's own Behaviour Tree. This way I can define very detailed behaviour for how each ability will work. For example my initial flow for the build ability is:

• Check to see if character is holding construction resource
• If they are
• Check to see if character is in range of the item to build
• If they are
• Start using resources to build item
• If they aren't
• Move towards build area
• If they aren't
• Check to see if resources available on map
• If there is
• Check to see if character is in range of resource
• If they are
• Pick up as much resources as character can carry
• If they aren't
• Move towards closest resource pile
• If there isn't
• Fail out job can't be completed right now.

If the job can't be completed it's unbound from the character ability and returned to the bottom of the command queue.

Actions and Decisions

The way I've gone about implementing this is to set up two templated classes, Action and Decision. They both take a templated type which has the implementation for that type of action or decision. Decisions are designed to be the logic which decides which path to take in the tree.  Actions are designed to be small pieces of logic which are at the end of a chain of decisions. This is all then linked together with fast delegates. Every decision has a pass, and a fail delegate. Decisions and actions then have a function for get a delegate instance which can be hooked into the pass or the fail.

Abilities

These behaviour trees are then assigned to an ability. Currently the only implemented ability is the build ability. The idea is that every job has a number of abilities that can be used by the character that has that job equipped. For example the build ability is a part of the Handyman job. The user doesn't actually control these abilities. What they do is generate a request, so

• The user chooses a tile they want to build.
• They generate a build request. This request goes into a global request queue that the     characters have access to.
• On the character update if they aren't already fulfilling a request they will check the request     queue and see if any of their abilities can be used to perform a request.
• If an ability can be used, that ability is bound to the request and the character can start     performing the request.
• When the request is completed or can no longer be executed the ability is unbound and the     request is deleted.

I have a video demoing the evaluation of the build ability. The blue tiles are spots where I've laid down a build request and the crate in the corner is a resource crate that contains some construction resources.

Apologies for the frame rate. I recorded it on my mobile dev machine, a Toshiba Netbook, so the recording software taxed the system a bit.



I Love This Bar

Holy smokes its been a long time since my last blog post.

I've kind of switched gears in my codebase and I wanted to have something to show before I wrote up my next post. For the last year or so I've really been concentrating on getting a lot of the core components I needed to write a game at the level I'm used to from working on games professionally. After finishing most of the core front end code I finally felt like I had enough blocked out that I could start to write a game. So I pulled the trigger and got down to work.

The game I'm working on takes a lot from simulation heavy games like towns or gnomoria which both draw a lot from dwarf fortress, a game which I've read a lot about but never played. This game I'm building differs a fair bit from those games though in that I'm not trying to simulate a medieval world, what I'm hoping to simulate is a bar/night club. I spent a lot of my youth bar hopping and I feel there's a lot of material that can be pulled from that environment and translated to a really fun game.The basic premise is that you start off with 4 characters and an empty lot and you have to assign jobs to your characters, build up a bar, get patrons, build up a regular clientel and just try to have the best bar in town.

I've done some research into what's out there but most of what's already out there just feels like farmville in a bar environment. That is not what I want to build, what I want to build is something for more core gamers with lots of different jobs to master, experience building, stats to track. I want to create an environment that feels somewhat alive.

So far I have a small lot working, with characters that respond to commands. Currently the only "job" I've implemented is "The Handyman" which will be responsible for construction in the game. The characters are able to build walls and that's about it.

Over the course of the next year I'm hoping to crank out something that's a lot of fun to play and filled with lots of quirky humor. I'll try to be better about the weekly updates. In the mean time here's a few screenshots from my progress. I'm not sure where those bright spots are coming from they don't appear in game. Also all art is just placeholder.

 

 



 

Quest for an Asset Viewer

Week 1

What a tough 2 week sprint!

The first task to pick off was getting screen saving and loading working. This was actually really easy to get going because serialization was built into my sprocket system. So in order to save and load all I had to do was serialize out the sprocket data to xml and then for loading I just had to write some code to place the loaded data into the right containers. I also ported over the code for throwing up the save/load dialogs. I kinda cheated when I originally setup the save/load dialogs. I just call the default win32 dialogs rather than create my own dialogs. I neatly packaged it up in my platform code so it should be easy to abstract it out when I do eventually get the code running cross-platform.

The next big thing was fixing the broken window drag functionality. I had a really tough time for this one for stupid reasons. It made for a really bad morning. Basically the problem was that all my mouse handling code was in local space. This works great for some things but when you're trying to move an object and the local space is changing everytime you move the object it creates some serious jitter! I didn't have a good way to expose the screen space deltas which is what I needed to move things properly. What I wound up having to do was calculate the delta based on the parent's coordinate space. I can't help but feel that's going to bite me down the road but for now the mouse drag is actually working better than before I started refactoring the UI system.

Once drag was working I was able to hook up the scale and translate buttons in the gizmo I created for manipulating UI Elements. I decided to leave rotation alone for now. Currently my UIClickable sprocket doesn't take into account rotation. I don't imagine it'd be a tough change, I already have a transformation matrix, it's just that I'm only using the translation element of it. Still I know it's going to be a lot more complicated then just multiplying by a rotation matrix.

I also spent some time just getting all the UI elements working with the UI Editor. While I was mucking around with that I needed to get arrays working with the protoform editor for certain create params. I managed to get them working the only problem is that they only work for simple types. So the problem is that I'm already using comma separated lists for the complicated types like Float3 which take multiple parameters for initialization and the way I'm parsing arrays is a comma separated list. This shouldn't be too tough to clean up in the future, just use brackets or something to separate items between commas.

Another big thing for this week was building a better way of viewing loaded assets as well as providing a means to select what textures to use in a UI element. The old way to select a texture for an element was to open up the xml package, check what I had set the id for on that particular asset and then type that id into the texture field in the protoform editor. I was about to start laying out the components in code when I realized this was a perfect test case for the editor! I always find when I actually start using a tool I find all sorts of bugs and come up with new feature ideas. The first bug/problem I ran into was that objects sorted in the order that they were placed. This was no good, I needed to be able to control the layering. For a simple solution to this problem I decided to use the z value I had been ignoring up until this point to sort the objects. I wrote some code that does a sort whenever an objects z value changed.

So once I had the sorting issue worked out I set about creating the asset entry ui element. This was easy, lay out a UISprite background, UISprite for a thumbnail placeholder and a UIText for the asset name and I was done. Then I realized that I had no way to load the object up and actually hook some code into it to replace the placeholder elements. I decided that the best thing to do was just start pounding out some code and see how it feels. I had the objects loaded into a UIContainer object and set up some code so I could clone that container so that I could create multiple objects using that template. I set up a UIAssetViewer class that held a bunch of these containers and did the logic for swapping out the placeholders. It works but I think it still needs some refinement.

Week 2

In the second week I managed to get the asset panels loaded and populating a UI container. There was another big cleanup operation, I needed to get scroll bars fixed up and switch my window class to use the UIComponentContainer for storing all the objects parented to it. This wasn't too bad of a change it was mostly copy and paste with a few little fix ups.  The scroll bar on the other hand.....

I spent the majority of the week working on getting this damn scroll bar working. Funny thing is it's still not working properly. The big problem was that I was trying to debug something that was a few layers deep. Getting all the math working properly was just turning out to be a huge pain. I managed to get something kind of working and that's going to have to do for now. The way it works is that it's designed to just move the components in the container around. It seems easy enough but for some reason I just couldn't get the math right for the life of me. I think it's one of those silly things where if I sit down and draw it out on paper it's going to become painfully obvious where the problem is coming from.

I also spent a little bit of time on cleanup. I cleaned up how I was calculating a lot of my element positions so that it's more data driven. This will make reskinning my UI elements a breeze. As it stood before I would had to have adjusted a lot of math but now it should just work.

WIP shot while I was getting the dragging working.

Showing off a few of the different UI elements.

First shot of the Asset Viewer working.

Adjusted the dimensions a bit to something that fit better on screen.

Showing off the scaled down UI. It makes better use of space but kind of loses the pixellated look I liked.