I really need to get out of the habit of starting these posts with “gee, it’s been a while since I posted on the blog”

I’ve been working on mech game for about six months now (according to Bitbucket I started it on February 9th), and shockingly I’m still making slow progress on it. Networked multiplayer works, the base code for all weapons is largely implemented, and I’ve even got some basic animation done for the Geon 3 chassis.

And yet, once in a while still get this overwhelming “what the fuck am I doing?” feeling. The sense that I’m biting off way more than I can chew with this project, and it’s never gonna get done or work right. Even though I’ve got the basics all laid out already, I still feel like I won’t finish it. Like it’s gonna be shit. And both of those things could realistically happen. That’s a pretty intimidating feeling at times.

Part of it comes from this tendency I have of reading into things and getting super granular on subjects that I really shouldn’t be worrying about right now. For example, yesterday I was researching different ways of handling the network aspect of the game and the Low Level API offered by Unity, which is basically a multiplatform UDP implementation. Right now I’m using unity’s High Level API, which does a lot of things behind the scenes to make stuff work, and for the most part it’s fine – but there’s a part of me that doesn’t like the black box nature of it and wants to get a deeper understanding and tighter handle on what’s happening. So I started reading up on the LLAPI and spinning your own networking code and serializing data to send as packets and packet compression and suddenly I’m drowning in this pool of information that realistically is totally unnecessary right now.

This isn’t the first time I’ve done this. A couple years back I felt that Unity was too much of a black box, so I went about writing my own entity component game engine in C++ with SDL2.


I did get it working (and pretty well too, all things considered), but it took me months just to write up a framework that created a window and bounced some sprites around. Whereas if I had just dealt with my weird feelings towards Unity I could’ve written a 3D pong clone in a fraction of the time.

So after delving down the rabbit hole that is advanced networking techniques, I started getting all those dreaded “this project is too big and I just suck so let’s quit and be done with it” thoughts. It took a good chunk of time, focus, and lecturing from my better half to remind me that I gotta keep this stuff broken into manageable parts. This morning I started writing the code for the weapon management system, so I think that’s a good step in the right direction.

This was a far longer ramble than I intended it to be, apologies for the longwindedness about largely nothing. Future posts should be a bit shorter as I’ll be posting more frequently about smaller updates on mech game.


Minecart – The “Vomit Comet” from BGSjam6

BGSjam6 was over a week ago now, so my writing a bit about it is a tad overdue. Better late than never, right?

So the theme of this jam ended up being “The Wild West”, which was a pretty awesome theme IMO. We had TONS of ideas, everything from shootouts to saloon simulators to gold mining to whatever else you can think of that’s out of a Sergio Leone film.

The idea of a gold mine stuck with me for a bit, and then someone else said something about minecarts and train tracks, and THEN someone else mentioned the minecart chases from Temple of Doom and Donkey Kong Country, all of which clicked in my head – “it’s simple,” I said. “I’ll make a networked multiplayer minecart shootout with procedurally generated tracks.”

…I don’t know if you’ve ever tried to make a game or participated in a game jam, but this is exactly the kind of idea that’s (A) never simple and (B) absurdly out of the scope of a 48-hour game jam. So naturally I made half of it anyway.

The game I created turned into a (literal) rail shooter in which the player rides a minecart on a randomly generated track and attempts to set a new high score by shooting as many of the duck targets as possible before flying off the rails. I dubbed it “the vomit comet”, and if you haven’t played it yet or skimmed passed the animated GIF at the start of this post, take the time to check out either and the reasoning behind the name should become abundantly obvious to you.

So, what worked?

Surprisingly a lot more than I expected. The first thing I did was create a quick test in Unity with a single piece of track, a cart, and a little bit of code. Some logic behind the cart moved it along a loose path constructed of waypoints (empties in a sequential order) that followed the curve of the track piece, simulating movement along the track. I quickly realized that assembling multiple pieces of track would require a lot of waypoints, so I slapped together a quick editor script that allowed me to easily generate new waypoints on a piece of track.

I next rewrote the movement system. For something that’s supposed to go forever, you want to move the world around the player instead of the player around the world. So I build a world controller that was controlled by the cart’s speed, thus moving the track around the cart. In the editor view it looks goofy, but to the player it’s the same thing as moving the cart itself.

Next I added some logic to connect the track pieces to one another. This involved adding another empty (I called it a “link point”) to the end of the track piece. Something I should’ve mentioned earlier is that the origin point of each piece of track is at the start of it. This way, when the world manager needs to attach a new piece of track to the end, it simply creates it and sets the transform of it to match the link point of the previous piece.

To save on resources, I made a “library” script that, at launch, instantiated something like a bazillion track prefabs that the world manager could grab and place at the end of the track. Once the cart had passed that track piece, it got moved to a queue in which, at some point, it’d get removed from the world and placed back in the library. This helps keep things from constantly being instantiated and destroyed (something I’m told is very bad).

After all that, I added a little bit of gun/raycast code (mostly pulled from my previous shooting-related projects) and added some targets that get created alongside the track pieces. I also added a super simple game manager that handled switching between scenes and kept track of the player’s score and high score. This was my first time really implementing any sort of game manager in a project, and I’m now appalled I’ve never done it before.

What didn’t

Multiplayer. I don’t know what the hell I was thinking, but trying to come up with a clever way of implementing multiplayer in a procedurally generated game is insanity. I’d have to make sure the tracks stay close enough to each other enough of the time so players could shoot one another. I’d have to keep their speed in check. I’d have to come up with real logic for the track generation. AND I’d have to get Photon working nicely quickly. Fuck. That.

FUN FACT: the “lose” condition? Where you fly off the rails? Totally a bug. I actually couldn’t think of a good way to conclude a round. At some point during track generation and movement, the cart will occasionally lose track of the next waypoint and just fly right past it, letting the track fly away into the distance. No idea what caused it, aside from some very hacky code. So on the last day I took this as a sign and turned it into a cheap way to end a round. If you end up a certain distance past the waypoint you were supposed to hit next, you “flew off” and ended the round. So I guess this is both did and didn’t work.

The track is totally random. To a certain degree, this gives it a level of charm I didn’t predict. However, it would be pretty nice if it didn’t do things like just shoot through the terrain I put in last-minute to give the game a sense of place. So a little bit of logic could be handy.

What’s next

I honestly don’t see myself going back to this project for much beyond creating a VR build that’s being demanded by some folks at the Space. I’m not looking forward to testing that, so hopefully it kinda just plugs in and works.

I think the big takeaway I got from this jam was even a little bit of code organization goes a long, long way. That game manager class (and the world manager) made things just work, which was AWESOME. I’m currently working with some basic design patterns for my Mech project, and to start the “serious” work I’ve begun implementing a game manager with a pretty solid state machine. Fingers crossed it’ll provide me with as much help as the vomit comet’s did.

If you made it to the bottom of this post, congratulations! Also holy shit, I didn’t expect to go on this long talking about this little project. I enjoyed writing it though, so if you enjoyed reading it lemme know in the comments and I’ll try to post more updates like this more often. Also, if you’re interested in this goofy little game or the project’s source, feel free to give it a download and play away.

A New Site

ICYMI, I just updated my home page! Honestly, the whole “blog as your site” thing was easy, but ugly as hell. So I decided it was time to make something a little more flashy. I used fullpage.js as a base, added a bit of custom styling, put together a little database for easier updating, and voila! New website.

I should also mention I redesigned the page because I fully plan on putting up more content in the very near future. Expect to see stuff both there and on the blog very soon.

Fact01 v0.10 Walkthrough

I didn’t get the chance to livestream last night and won’t be able to tonight, so to make up for it I recorded this short little walkthrough of the level I’ve been working on the last couple of days. It’s a basic deathmatch stage built for Doom II that’s in dire need of more weapons and ammo items, and a few more player spawn points to boot. I’m planning on having it (and hopefully a couple other maps) done in time to playtest at the BGS Retro LAN Party next weekend (Facebook).

Livestreaming and Level Editing


I’ve recently discovered I have an affinity for level design. I love the idea of crafting a space that you can then run around in and explore. I also love Doom. So naturally, it seems to make sense that I’d like to make spaces you can run around and explore, with the added bonus of shooting demons in the face.

I just started playing with the tools for creating levels in Doom in the last month or so, so I’m still relatively new to the subject. However, I feel that I’ve reached a point of comfort where I can livestream myself trudging along in GZDoom Builder. The first of these went live last night at around 9:45 or so, and you can watch the whole thing on YouTube if that’s your cup of tea/coffee/kool-aid.

I’m aiming to livestream every night or two for at least an hour. It helps keep me focused, and scheduling it makes sure I actually work on stuff and get something accomplished. I’ll probably write something more in-depth on my thinking and process at some point, but for the time being you can catch my livestreams to see what I’m making and chat with me about level design/games/Doom/whatever.

BGSJAM 4 Game Pack


A few months back I participated in BGSJAM 4 with a bunch of super rad folks at Buffalo Game Space. Initially I was planning on just handling all the social media coverage of the event, but I ended up getting roped into a team and working on the game that became “Triple Threat”.

Five games were made in total, with four of them ready for release. You can check them all out on itch.io, so give it a go! They’re free to download, but please consider throwing a couple bucks in when you pick it up – all proceeds go directly to Buffalo Game Space.

Also, just for fun, I made this cool bit of promo art we ended up not using.

BGSJAM 4 Game Pack Render

House Rules Re-Release (v2)

I’m happy to announce the re-release of my first print and play board game, House Rules! You can download it from itch.io by clicking here or on the logo above.

From the game page:

House Rules is a print-and-play party game for people with a penchant for making their friends do ridiculous things.Take turns racing around the board, drawing cards with rules on them each step of the way. One turn you might get a Board Rule that advances you three spaces. On your next you might get a Player Rule telling you to:

  • Win a 10 second round of Charades
  • Sketch a player AND get their approval
  • Do your best Chewbacca impersonation
  • Prank call a friend on someone else’s phone and keep them on the line for five minutes
  • Play “Truth or Dare” with the player to your left – they get to ask/dare you

Sound ridiculous? It is. Download it, print it, and start playing

The game is free to download, but if you can donate a couple bucks it’s much appreciated. If you can’t donate but still want to help me out, tell me what you think of the game! It’s still work in progress to a certain degree, so feedback of any sort will definitely help make the game better.

Be sure to follow the House Rules Twitter account, and tweet your best Player Rules with hashtag #MyPlayerRule!

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.