Casino Boss screenshot updates

Please enjoy some recent screenshots from the latest version of Casino Boss:

More screens after the jump

GameActions in Action

Here's a screenshot of working in Unity.  I've done more work fleshing out the GameAction and now I've got several ways to create them.  Publishers can be attached to physical objects or invisible publishers can exist at world locations.  For example during construction events invisible GameActions are created at the pending location of a material or object and wait to be fulfilled by a worker with the appropriate tools in their inventory.  Upon completion the physical object is finally created.  Actors are also able to visibly carry objects with them both while moving to and completing the given action.  In this screen shot you can see workers carrying materials towards pending construction projects and then using screwdrivers while constructing.  I've also gone ahead let some patrons randomly carry around moneybags too while they wander because why not :).

Architect Game July Update

So as you may know some time around the middle of May I stopped work on the Architect game and started experimenting with the Unity engine.  I didn't really particularly have a goal in mind other than to learn something new which in itself can be a very admirable goal.  I ended up learning a lot about the engine through 2 small projects and I decided I knew just enough to get started on the project again but this time using Unity instead of my custom engine.  Using Unity was actually a pretty easy choice, it's a very strong engine that also powers the game RimWorld which has a lot of similarities to my game.

CleaveFramework v0.2.0

Version 0.2.0 of the CleaveFramework is ready.  It includes a couple of new features:

• Auto dependency injection module
• Generic binding module
• A generic library of binders

It also includes some much more in-depth documentation.  The source code and documentation is available here: CleaveFramework on Github

Announcing CleaveFramework v0.1.1 (Open-Source Unity3D C# Application Framework)

I'm officially announcing the release of CleaveFramework v0.1.1  It's been in development for a little less than 3 weeks now and it is usable now in it's current state.

Public github repository here: CleaveFramework on Github.

There is some extensive documentation regarding the framework and it's specific features on the Github but here is the overview straight from the docs:

Why you use a framework

 This framework is meant to facilitate the implementation of a better structure for Unity3D game project code. It is by no means perfect, and I welcome any and all feedback and potential contributions in regards to improving its functionality and easing its usability. Thanks!

If you've ever finished, or worse started and not finished, a project using the Unity3D engine you realize the importance of well structuring your code. This framework was created to assist in maintaining that structure. The framework does not limit or shoehorn you into developing into a particular pattern however I personally believe it is most useful when utilizing a MVC/DI object pattern. You are however free from being constrained to one specific architecture pattern, be it DI, Service Location, or whatever magical Voodoo you personally have created.

Feature overview

The core functionality of the framework is two-fold based around an executable command delegate callback system and a SceneObjectData container for objects, automated system updating, and global data. Any amount of unique Objects are able to subscribe to commands and then implement callbacks upon execution of the command. Commands can be utilized to pass data to another object, as event messaging, or a virtual Execute() method can be implemented to directly manipulate the data within the command object itself before or after propagating to the delegates. Commands are pushed into the Framework via static methods which can perform commands on that frame, or after a given delay of frames or seconds. Commands can push other Commands during their execution giving the ability to create sequences of events.

I'm interested in some test users, feature requests, bug reports, potential contributors (of which we have received one so far), or any feedback in general regarding its usability and code quality.

Totally on schedule monthly update

Pretty short update here.  I spent the past couple weeks porting what I had written in C++ to C# and the Unity engine.  Once I did that and got a lot of it working I decided to take some time and write a more generic framework to drive the application within the engine.  I've got a decent base of that now to work with and I've begun the job of refactoring the code I had written in the last few weeks to work with the new framework.  At this point I should be capable of using this base to drive the progress to a reasonably playable state, as long as things in my life do not change drastically in the next coming weeks.  I also wanted to share that I've made the code for the game itself available online for free as I develop it.  You're able to follow the code progress here: https://github.com/cleavetv/Architect if that's something you're interested in.  If you're able to get a copy of Unity (and assets) you can even build it yourself.  If anyone is interested in helping with compatibility version testing when I have builds ready let me know, I can provide compiled binaries for PC, Linux, or Mac.

Messing with Unity

I took a break from working on the construction game to take a look at the Unity game engine.  I've been working on a control scheme for a 3D platformer game for the last couple of days.  Starting with some random guys physics package which had decent math but wasn't really set up for making an actual game.  I started by ripping up the movement into a state machine which now supports motor and grab functions.  You can operate the arms independently of the feet and utilize it to pick up, push, pull, and move objects around in the world.  Movement and jumping states were constructed so that we can add functionality for things like wall jumping more easily.  The state machines are run by a Controller object and then I wrapped the controller scheme into a Character system that can swap out the controllers at runtime based on other inputs.  This lets you change control schemes on any character depending on collision or game state.  So far it works fairly well, my first game test was using the system to swap control schemes on the player for moving in and out of zones tagged for water.  The results are pretty nice, I am able to craft an entirely separate group of states which control water movement and then immediately swap out of them when you exit the water by any means.

Cooling off in the water.

Dev Diary -- Construction is fun

in-game Toolbars

The main bar (top) in horizontal orientation and
a nested bar below it also in horizontal displaying
file options: new, save, load, exit, and quit, respectively.

Hey guys.  I've got a short update today.  I spent some time implementing a toolbar interface for the in-game HUD.  Toolbars are able to be oriented either horizontally or vertically.  For now toolbars can only contain buttons.  Buttons can be text, image, or both and they can also have a tooltip attached to them.  The toolbars function similar to a menuing system, a button can either be the parent to another toolbar or it can have a function bound to it directly.  This lets us do nested toolbars within toolbars within toolbars, a bit redundant but I'm hopeful it will let us do some neat things later on.

I also spent a considerable amount of time refactoring the game's build tools system into a much cleaner state.  I'm now able to create new or modify existing tools much easier which should speed up their development.  In the past this was a fairly tedious process because the tooling was coupled very tightly with the game class and state manager.  In it's place I've developed a tool template class with appropriate input callbacks which is much easier to use, and in addition also executes much faster and is easier to debug.

I'm bad at this blogging thing

Wow I went a week between blog posts, I'm sorry about that.  Hopefully that will not happen again but, no promises :).  I can promise that I've still been hard at work here on the project.  It's taking a little bit more shape but more importantly so is the codebase.  In the last week I've incorporated a lot of new capability into the code,

Path finding

Hey guys, I'm here with another blog update.  Today I want to show you the progress I've made on the implementation of pathfinding algorithms that the simulated people in the game world will utilize.

If you're familiar with building and sim games you know that a huge part of the gameplay revolves around creating the world for your sims to live inside of.  Obviously a large part of living in a world is knowing how to navigate inside of it.  Pathfinding is the mathematical solution to having our sims be able to navigate through the world you build.  Without it they would run into walls, nobody would ever figure out how to leave their rooms, let alone graduate and this would make the game pretty unfun.

Tile Engine Part Deux

The tile engine will be an integral facet of the project so it's important that I make it as robust as
possible.  In today's update I will show off the progress that has been made to it and the engine itself.  Yesterday I showed off painting tiles with solid colors, today I'm going to show you how I've added sprite sheets (collections of tile images), layering, game saving, and game loading.

A tile engine is born

If you're familiar with a bit of the project I'm working on you'll know that a 2D tile engine is a major part of the game.  A major part of the game will involve creating building foundations, the floor plans of the interiors, and placing objects on top of those floor plans.  To make doing so fun we're going to need a strong suite of tools available to the user to manipulate the world with.

Since my last update I've begun to construct the tile engine and tile objects for the game and the beginning of the tool suite that will be available for building in game play.  Let's take a look at the visible progress made so far:

Driving windowing with data

I've decided to utilize XML to manage a lot of the data in the project.  XML is a great format that's been around for ages.  It's got some nice advantages to it, one being that it's fairly easily readable by an actual human being.  This is a big plus in two areas, one being it can speed up development considerably which is important when I'm trying to prototype out ideas.  Additionally it means that most of the data will be exposed in a very friendly manner which means modding will definitely be possible from a very early state, although it may be frustrating at first, as tools and code mature the process will become smoother (I promise!).

I've decided to use the open source project called RapidXML for my xml reading and writing needs.  It's a very proven product and used on several projects that are deployed in the real world.  Utilizing this code has allowed me to start pushing data into xml very rapidly (^_^)!

Yesterday I showed off a bit of the windowing.  Today I will be showing you how I am now utilizing the XML data to drive the system.

Starting a project is brutally fun -- First post

Yesterday was an exciting day, getting back into it with all of the game ideas racing through my head it was almost hard to concentrate at first.  It's actually been a long time since I buckled down and wrote some code. Once the initial jitters wore off though it felt like it was back to business as usual.

The first day involved setting up some basics.  I'm going to work with SDL (Simple DirectMedia Layer) as a base.  If you don't know what that means it's basically a wrapper around Direct3D/OpenGL which allows me to do some very basic functions without having to write very low level code.  The SDL Library can compile on Windows, Linux, and MacOS which is very nice if and when it comes time to do some porting. I'm still very much in the planning and prototyping phase of the engine development so decisions about possibly utilizing plug-ins for things like collision/search algorithms will be made in the next few days & weeks.

On to what I've actually done...