Buffalo Game Space on Kickstarter

BGS Kickstarter Social Media Banners

Why I didn’t make a post about this earlier, I don’t know. Alas, better late then never, right?

A couple years ago I started digging around online, searching for other people in the Buffalo area that were interested in making video games. I myself had just gotten back into it and finished up work on Botrunner (which you can play on Game Jolt if you haven’t already), and kept thinking to myself how great it’d be to hang out with some like-minded folks. Eventually I found my way onto TIGSource’s forums, and wouldn’t you know it? Someone beat me to the punch and had already posted, asking the same question I had.

Cut to two years later. Futch and I, along with the help of some other incredible people, have created Buffalo Game Space. BGS has been a solid group for these past two years, consistently growing in terms of both members and output. We’ve proven the demand for this sort of group exists here. And that, to me, is absurdly exciting.

The thing is, Buffalo should have a game development industry here already. We’ve got all the makings of it – programmers, artists, musicians, designers. All right here. But these talented people keep leaving the area because they can’t find work. So what better way to provide these people with jobs than by bringing the benefits of a multi-billion dollar industry to Western New York?

That’s what we’re trying to do with this Kickstarter. Create jobs for talented people. With successful funding, we can get a better functional space that can be used by developing studios trying to get off the ground. Providing these teams with a space, equipment, and legal/accounting/publishing assistance means solid games. Which means revenue for the studio. Which means jobs. And like I said, multi-billion dollar industry – there’s money to be made there.

Let’s make these jobs a reality. Donate to the BGS Kickstarter and help us bring this incredible industry to Buffalo.


SUPER BotRunner

Hey, first post for a new project! I’ve decided to re-learn Unity (again), and figured a good way to do that would be to remake Botrunner. Before I get into the details, I thought I’d just post a few little videos of what I’ve done so far:

So basically what’s going on here is I’m toying with both 2D and 3D physics, using a sprite character in a traditional platformer format but using 3D models instead of traditional sprite tiles. And so far, it’s working pretty well! Naturally, I’ve still got plenty of stuff to work out. Here’s what’s at the top of the list right now:

    • How to handle level data – do I want to make one main model in Blender or do I want to create lots of little “tile” models?
    • Should I just make a separate scene for each stage, or design some sort of “stage loader”?
    • Camera code – it must be sexy
    • What version control system should I use for this thing?

Anywho, I figure I’ll be posting a good deal about this in here. As always, any and all input is greatly appreciated. More updates soon!



At BGSJAM 3 this past weekend, the theme was Let’s Get Weird!, which was a pretty awesome theme IMO. To that end, Damon McKernan and I made this awesome game called Thumbwars.

Thumbwars is an intense, two-player thumb wrestling game. Each player picks one of the two sticks on a Xbox 360 pad – moving the pad moves your hand, while clicking it locks your thumb down. Hold your thumb down to accrue points, but if the other player manages to pin your thumb you’ll lose a TON of points while trying to shake off the pin. Give it a go, it’s a lot of fun!

p.s. – I made the 3D models for this game, which might get included in the $20 tier reward of this awesome Kickstarter you should totally back.

BGSJAM 3 – Or, Why I’m Dropping My Custom Engine (For Now)

A Very Valuable Lesson

I learned a very valuable lesson this weekend – if I want to make games, I should probably make games.

For the last year or so (Jesus, that’s a long time) I’ve been messing around with what I’ve been calling cldECS. It’s a framework in C++ for creating programs using the Entity-Component-System method. It’s pretty simple, but it works well enough. Originally I wanted to use this framework to build a 2D game engine to make stuff with.

Goddamn, did I bite off more than I could chew.

In that time, all I’ve done is made a few little programs that put some text to the screen, and one that had some bouncing sprites. But nothing came close to the complexity that is even a simple game engine. Nothing.


On the last day of BGSJAM 3 I was messing around with some more advanced features I knew I’d need in a simple engine (serialization, JSON library integration, that sort of thing) and I realized two things:

  1. The level of stress I was getting just trying to get a simple library to do what I wanted was something I didn’t want to deal with
  2. I was dooming myself to spend more time reinventing the wheel (badly) than making an actual game

I want to make games. I really do. But a little voice in my head keeps saying “dude, you gotta do it from scratch, that’s the only real way to make a game.” And that’s bullshit. This is the part where I tell you why.

Why It’s Bullshit

There are SO MANY GAMES out there that are made in things like Unity or GameMaker. SO MANY. Games that I love, even! Hotline Miami. Fotonica. Super Crate Box. Thomas Was Alone. Shadowrun Returns. Superhot. I mean, why WOULDN’T I want to make a game using one of these engines? Clearly they’re beefy enough to make games I would want to both make and play.

“Well,” says my brain, “don’t you think you’re smart enough to spin your own solution? What are you, an idiot or something?” Yes, I am an idiot. For thinking that I should try to make something as ridiculously complex as an engine right now. I’m by no means a great programmer. I’m not even a very good one. And that’s okay.

I think that’s the hardest part I’ve had trying to use other engines like Unity in the past. A part of me tells me I’m somehow failing by using an engine or solution I didn’t create myself. And that, quite frankly, is fucking insanity. When someone has created an engine that better, easier to use, and more supported than anything I could make on my own, why the hell wouldn’t I use it?  Because of my pride? Fucking please. I gotta get over that shit and just make rad stuff.

What’s Next

I’m gonna do the unthinkable – blank my desktop harddrive and make it purely a Windows machine. Don’t get me wrong, I still love Linux. But I want to work in Unity, which means it’s Windows time. And having that be my sole OS will make it that much easier for me to get into dev mode (much like booting straight into Linux has had me doing way more C++ coding lately).

Sooooo, yeah. TL;DR, I’m getting back into Unity. Again. Let’s hope for some rad stuff.

cldECS – Quick Update



What’s Shakin’

Just a quick update on the Entity Component System framework project! Yes, I’ve been working away on it, and it’s now running swimmingly. While I’m still working on some example projects using it, you’re more than welcome to download it and try it out for yourself. The docs (that is, the README) aren’t all that fleshed out, but the headers all have pretty solid explanations of what everything does. There’s only four of them, so it shouldn’t be too tough a read. https://github.com/hellocld/CLD-ECS

Cool Graphic

As you can see from the image above, I went ahead and made a logo for it. While I might be getting a bit too excited about things with that, I made it for a good reason; one which will be evident hopefully in the coming weeks. And those shapes in the logo weren’t just picked out of a hat. 😉

Landing What?

Finally, I’m confident enough in this simple framework that I also made a little landing page for it. Right now it doesn’t have much other than the logo that links to the GitHub project, but it’s something to keep an eye on. http://cldecs.hellocld.com/


CLD CES – First Post

In the past I’ve dabbled a bit with the component-entity system model of design, and with my recent endeavors in teaching myself C++ I thought it’d be a good project to create a simple CES framework. If you don’t know what the CES or ECS design model is, I’d recommend giving the Wikipedia article on it a read before continuing.

The approach I’m taking is very bare-bones, and for good reason IMO. I’d like it to be as simple as possible, so it doesn’t necessarily become restricted to being a “game engine”. Currently I’m using four objects in the framework:

  • Component: The Component class is just a base for other custom Components that will simply store data. I’m using simple class inheritance here.
  • Library: The Library will contain a database of all Entities and their corresponding Components. The database is an unordered map, with the key being an int that represents an Entity and the value being another unordered map that holds the Components. That “Component” map’s keys are the typeid of the Component object (so as not to store duplicate Component types) and a pointer to the Component itself. The Library also serves as a “Librarian” that can provide information on the Components and Entities; things like a vector of all Entities that contain Component X, a specific Component of a particular Entity, or whether or not an Entity contains a Component of type X. Creation and destruction of Entities is handled by the Library, as is addition and removal of Components to/from Entities.
  • System: The Systems will be where the messiness comes in, but that’s all up to the developer using the framework. It will have the ability to communicate with the Library contained in the System’s World (see below), access all the Library’s public methods and alter the data in Components.
  • World: The World is the encompassing object that holds a set of Systems and the Library they can access. It initializes all Systems and connects each to the Library. The World is also responsible for the main program loop that runs through each System one at a time, updating each.

I’m fairly certain that while I’ve got a good idea of how I want the framework to function I’m still a good ways off from having it in a relatively solid, functional state. For instance, I’m probably going to need to create some sort of messaging system so systems will have a better way of interacting with one another (Messages could easily be they’re own Component type).

You can follow the development of the framework at Github.

DUNGEONEERING (WIP Title) And Other Ramblings on GGJ14

TL;DR – Damon and I made a board game. It’s a little clunky, but definitely fun and playable. Click here to download the current version.

This was my second year participating in Global Game Jam, and I was all sorts of stoked for it. We were hosting the local jam at Buffalo Game Space (UB held it last year), and we had a pretty solid turnout! Coming off the heels of our own jam as well, everyone was pretty amped to be making more games.

The theme, revealed Friday night, was “We don’t see things as they are, we see them as we are.” This lead to a biiiiiiig discussion full of ideas for different games.

The BGS whiteboard, covered with all the ideas from Friday night of GGJ ’14.

We ended up all settling on two separate projects, one video game and one board game. From the get-go I was planning on making some sort of board game, partly because I didn’t want to lug my rig back and forth again, and partly because I just really wanted to make another fun print-and-play game. And I think we (myself and and Damon McKernan, co-developer) succeeded in doing just that.


Our game is (tentatively) titled “Dungeoneering“. It’s a sort of dungeon crawler, where two to four players have to complete randomly assigned objectives; the first to finish their objectives wins the game. The initial gameplay involves players constructing the board from a set of map cards (each a 4×4 tile grid), and populates it with item tokens that function similarly to the item boxes in Mario Kart. Each player starts at the “Spawn” tile, with one objective card and one item card. Items can be shown to other players, but objectives should be kept secret (tying in with the theme of “seeing things as you see yourself” while not seeing everything as it is).

The main gameplay consists of trying to complete your objective. Players take turns rolling a die to determine how many AP (Action Points) they have for that turn. AP can be used for moving (1 AP per tile) or using items. Items, represented by cards in your hand, can be weapons, spells, traps, or “use” items. Most, but not all, items have an AP cost associated with them. Some items also require a second roll to see if they succeed in whatever action they conduct, and some are also restricted to a certain range in tiles. Here’s an example turn:

  • I roll for AP, and get a 4
  • My objective is to kill the player to my left, and they’re three spaces away from me, so I move two spaces to get closer to them. This leaves me with 2 AP this turn.
  • In my items I’m carrying a Spear, which has a range of two. This means the player I’m targeting is just within range. I make clear I’m attacking the player by telling them and showing my spear card to prove I actually have it
  • The Spear has a check roll to see if I can actually hit my target, which I use a second die to roll for. If I roll a 5 or a 6 I hit; otherwise the attack failed. I rolled a 5, so I succeeded in killing the player!
  • When a player is killed, you can take an item from their inventory. The player shows me the backs of all their cards, and I pick one at random. They then return to their starting point at the Spawn tile.
The Dungeoneering map, populated with item tokens and player pieces.

If that was all my objective was, then I get a point, play my objective card face up on the table, return to my spawn point, discard my inventory, and take another objective card and an item card.

And I’m sure by this point you’re probably incredibly confused as to how to play at all. It’s way easier than it sounds though, and the next iteration of it will be even easier to play. There’s a way to pick up more items while playing, but the current mechanic is super sloppy and tedious. We’ve come up with a way to make it infinitely easier, so that’s why I’m not getting into that right now. Traps are another element that really spice the game up, but it’d be easier to show once we’ve got some better graphics for it.

All in all, I’d call GGJ14 a huge success for Damon and myself. While I probably didn’t do a good job of describing the game, we’ve got a very solid core game built that was a lot of fun for everyone to play. Naturally it’s a jam game, so it needs a bit of polishing and tweaking. Fortunately we want to do just that, and eventually make it into a full-fleged, well tested, exceptionally fun game. Expect more updates on it soon!


I know, I know. I’m lazy. But still working on stuff! If you go to 7dfps.hellocld.com, you’ll see.

So I’ve been slacking on the blog a bit, and that’s because I’ve been getting a little burnt out working on this project for the last few days. Surprisingly enough my vacation time started seeming much more appealing as vacation time than project time, but I powered through and still got a little bit more done. I really shouldn’t be surprised, but most everything in this project has taken longer than I expected. Granted, I went into it thinking I could make something comparable to a smaller scale version of Quake, so that’s probably part of it. So what took lots more time?

My goodness, the code. Realistically there isn’t a whole lot of it going on, but still. Instead of just following some standard cookie-cutter tutorials on how to do this or that I wanted to come up with some magical stuff from scratch. And I gotta say, I’m pretty pleased with what little I wrote. A fairly flexible weapons system, some decent enemy AI (that ended up getting scrapped, but still), projectile shenanigans, and even rocket jumping and explosions and stuff. All things I wanted to do when I started, and so I guess I succeeded. It was still exasperating though, because naturally the problems I spent hours trying to solve ended up getting worked out in minutes. But hey, those are hours I won’t have to spend again next time.

Okay, here’s where I feel I really dropped the ball. I tend to think I’ve got a decent visual eye as a designer during the day, and though the stuff I like isn’t for everyone, I still think it’s easily described as “good”. So to say I’m disappointed by the visuals I cranked out would be a mild understatement. It looks like shit. I know I only had so much time to work on it and I spent more time working on code and mechanics because they’re important, but even with that I could’ve put more time into at least making it kinda visually appealing. Fortunately, I think I’m going to keep working on it weekends to make it more into an actual game, but I’ll get to that in a minute.

This isn’t really THE big lesson, just A big lesson. And that lesson is: plan better. The things I left out of that horrid design doc are embarrassing. Who leaves a “win condition” out of a design document for a shooter? Menus? Scope? Influential materials? Kinda important stuff there. So yeah, I need to up my game in the planning department. Also, more pen and paper stuff. All this doodling on the computer crap seems to result in nothing but garbage. I should draw more.

A lot of this probably makes it sound like this was a miserable experience for me, but I don’t actually feel that way. On the contrary, I though the whole thing was ridiculously educational. I learned more about Unity in the last week than I have the previous three months. And I think I got a little bit of my creative spark back, which is something I’m going to have to try to keep lit. With what I started on here for 7DFPS, I think I can keep at it and make it into a full-fledged game of some kind. It’s still got a long, long, long, long, long way to go, but it’s still a start. And with a good deal more planning, designing, and pen-and-paper shenanigans, it’ll turn into a complete game someday. And that’s pretty damn exciting. At the very least I’ll put a few hours into it every weekend until it’s done, so at the latest expect a shiny new post on the 24th.