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.

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.


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.



Whoo! Talk about madness and mayhem. In case you don’t want to read up on what I worked on/accomplished today and would rather just shoot some stuff and do a bit of rocket jumping, hit up 7dfps.hellocld.com and play my current prototype, complete with a weapon pickup that turns a rocket launcher into a shotgun, a mini health pack, and some very dumb enemies. Here’s the controls:

  • W/A/S/D – Move forward/left/backward/right
  • SPACE – Jump (hold for a higher jump)
  • MOUSE – Look around
  • LEFT CLICK – fire weapon

So I spent a good part of yesterday afternoon and this morning trying very hard to craft a sort of controller for all the enemy and player movement. The main reason behind this was I needed a way to apply a force from an exploding rocket to all enemies within the vicinity. As far as I could see, the CharacterController object couldn’t take forces like a rigidbody, so I started trying to figure out how to simulate simple forces on them. I’d venture to say I tried a good twenty or so variants on the code, but nothing seemed to work. Finally, after getting sick and tired of it, and almost eliminating rockets and explosives from the game, I decided to take one last look at the CharacterMotor provided by Unity for the character controller templates. GUESS WHAT IT CAN DO. So yeah, hours spent trying to find a solution to something that already worked, and worked better than I could craft.

The code for the weapons was designed to be as flexible as possible. Tweak a couple variables, and suddenly a pistol becomes a shotgun becomes an uzi becomes a rocket launcher. This worked very much in my favor, as I wanted to be able to modify the weapons via items, or powerups, similar to “Contra”. And just as I had hoped, it worked like a charm. A simple script modifies the weapon’s specs when the player collides with the item box, and presto! A new weapon. After that, I did a much simpler implementation on health items, and can have medkits of any size in the game as well.

One thing that’s going to need a rework is the enemy AI. Fortunately the setup I landed on today seems to be pretty straightforward, so implementing a few different AI scripts should be pretty simple. Outside of coding, tomorrow I’m going to start working on some sketches for enemy and level designs, and create a few new level kits. If all goes well (hint: it probably won’t) there should be a much prettier build to play with tomorrow night. Who knows, I might even get lucky and come up with some decent sound effects too!

Click here to play the current prototype of my game for 7DFPS!


So day 2 was not quite as awesome as day 1. I’ll do the good stuff first.

My priorities for the day were to get weapons systems and items systems set and in place, and for the most part I did. I managed to work out how to do proper raycasting for any variety of bullet-based weapons, so now with just a few changes in the editor I can make a pistol into a shotgun or a machine gun, each with varying levels of accuracy/spread. I also managed to get rockets working, and explosives that do varying levels of damage to objects depending on how near the center of the explosion they are. So all in all, pretty solid. Items I didn’t do yet, but the implementation is super easy with how I’ve got the weapon class done up.

I discovered when testing the explosions that I had no way to actually make objects react in accordance to the explosion. Enemies would get hit by rockets and just stand there like statues, and that’s no good. To top it off, I realized I wouldn’t be able to implement rocket jumps, and I reaaaaaaaaaally want rocket jumps. So after a fair amount of digging I came to the conclusion that I’ll have to build a new interface for moving all the characters around, both the player and the enemies. And that’s pretty much where I called it a day. I’ve spent the last couple hours trying to implement a basic physics set-up, something I’ve done before pretty easily, but for some reason or another I just couldn’t get it working. I think I’m a little burnt out; getting those rockets and explosions to work was no easy feat, so after that I think I just can’t math anymore today.

So that’s where we’re at at the moment. I livestreamed most all of it again today, so you can watch what you like over on Twitch. I’m hoping with a good night’s sleep and a fresh pair of eyes I’ll be able to get that character movement fixed in the morning, and then I should be damn near finished with the hardcore code. And from then on out it’s level design and visuals/audio. Who knows, if I’m lucky I might have a playable prototype I feel’s worth sharing tomorrow night. Fingers crossed!


Well, the first day of 7DFPS has come and not quite gone, so I figure it’s time for a big ol’ update. It’s been extremely productive as first days go, and so far I think the project is showing a good bit of progress already.

The first item on the agenda was to create a design doc. Shockingly, this was my first time drafting one up, but with no point of reference I think I did quite well. It started as a sort of declaration of purpose, but then went off into outlining the games aesthetics, weapons, enemies, controls, and so on. Some might think writing up a design doc for a game jam game is silly, but I think, especially for a jam as long as 7DFPS, it’s an excellent idea. It gives me something to focus on and work towards, instead of just shooting in the dark to and hoping I hit something worthwhile. I also decided early on that I’d stop adding things to it by tomorrow night, and once that time hits I won’t allow myself to add any new features; it’s a way for me to prevent feature creep. I also decided I can remove items from the doc if I decide it was a bad idea, either due to time constraints or just not being any fun. If you’d like to read through the doc, you can find it here.

So once that was drafted up I started up Unity and began working on what I believed to be the most challenging aspect of the project: the enemy AI. A first-person-shooter with no enemy AI is, art games aside, rather dull. You want something that will instigate and make the player fight back, something that’ll come after them and attack. So I started cracking away at two basic behaviors: wandering around the environment and following the player if it sees them.

The wandering behavior was relatively easy to write up. I created a variable that holds a random point in space, and the enemy slowly turns and moves towards it. While it’s moving towards it’s imaginary target, a countdown timer is ticking away. Once the countdown reaches zero, it picks a new random target and begins moving towards that. There were a couple hiccups here, the big one being for some reason or another the enemy strafed around the object as it moved in, but a quick rewrite fixed it.

Tracking the player was slightly more challenging, but fortunately I’d been playing around with this a bit before. The basic idea is if the player falls within a certain field of view, the enemy would mark it as a target and come after it or attack it. I’m sure there’s a million ways to do this, but my solution was this:

  • There’s an empty with a sphere collider on it that’s a child of the enemy. This sphere is the view distance of the enemy, and is set to Trigger mode. When an object sets off the trigger, it’s immediately checked to see if it’s tagged with “Player” or another potential target tag.
  • If it is a potential target, it then checks to see if falls within the enemy’s Field of View. This is accomplished by checking the angle of the potential target relative to the transform.forward vector of the enemy. If it the value falls within the assigned field of view, the target is seen by the enemy.
  • There is one final check, in which the enemy casts a ray directly in front of itself to see if the target is visible or not. If the target is behind a wall or other obstacle, the first thing to come back from the check will be the obstacle and not the target, and therefore the enemy cannot see the target.

With this check in place, if an enemy sees the player it simply replaces the random imaginary target it was walking towards with the location of the player. If the player walks out of range of the enemy, or runs behind a wall, the enemy walks towards the last point at which it saw the player, and then picks a new imaginary target to walk towards. This gives the player the chance to run away if necessary and hide, and gives the enemy a chance to find the player and continue pursuit.

I did a few other tweaks after this, like finding a new target if the enemy is about to walk into a wall, but this is essentially the whole system. I tried running around a room with about twelve of these guys, and it was surprisingly fun, even in the barebones state it’s in.

The next big puzzle piece was how to handle weapons and health. I decided to make the health system an independent component that could be assigned to any object. It has a public variable for assigning it’s health value, and three public functions:

  • A damage function, that reduces the health value
  • A damagePoint function, that returns the position where the damage occurred (this might change to the point where the weapon was fired)
  • A function that returns true if damage has occurred

The damagePoint function is exceptionally nifty, because I can use it to give the enemy a chance to “feel” damage, and react in a semi-realistic way (by turning and attacking in the direction in which it was shot). The damage function, however, is utilized by the Weapon class. Weapons in my game are essentially all the same, much like any other shooter if you stop to think about it. In my project, they boil down to these basic elements:

  • Power, or how much damage it does
  • Range, or how far it can fire
  • Firing Rate, or how frequently the gun discharges while the trigger is held
  • Whether it fires a single or multiple shots
  • Accuracy
  • Whether it fires bullets (raycast) or projectiles (instatiated objects, like rockets)

So far the code only handles single-shot weapons (like a pistol or machine gun), but other weapons shouldn’t be too difficult to implement. I’m particularly excited to add rockets for rocket jumping.

Well, I think tomorrow I’m going to complete the weapon code and try to create a few different enemies based on the template I built today. Once that’s in place I’ll work on the item system, which shouldn’t be too difficult (health pickups and weapon modifiers). Finally, I’ll craft up a basic modular level kit and build a stage to test out. After that, if everything works out well from there, it’ll be level design and polished assets the rest of the week! With a bit of work on menus, UI, and all that jazz. Exciting stuff!

If you want to check out any of the stuff I worked on today, hit up my Twitch channel. You’ll find all the day’s recordings there for your viewing pleasure.