Games I’ve Made

Over the past few months I have made a couple of games for Leapfrog devices, which have since been released. Overall, I am quite pleased with how they turned out – people seem to like them, which is always a good sign. I was the sole programmer on both of these titles, which lead to some efficiencies (though it also lead to some nasty-but-necessary corner cutting).

The first of the two games is Scholastic: Bug Genius. This is a fairly simple quiz/minigame-based downloadable title designed to educate the player about the wild world of bugs. As someone who grew up as a Scholastic kid, getting to work with Scholastic was a cool self-validating experience.



The second of the games to be released is Stretchy Monkey: Swinging Through Time. The third game in the Stretchy Monkey series, this installment follows the Stretchy Monkey family and their banana-powered time machine on adventures through history. Unlike Bug Genius, which I coded largely from scratch, I inherited an existing code base for the Stretchy Monkey games. On the one hand, not having to reimplement the complicated monkey character controller was useful. On the other, well, lets just say I have a greater appreciation for people who spend a large amount of time maintaining legacy code. This project also had the added design wrinkle of switching from a portrait view mode to a landscape view mode, which gave me a lot of interesting insight into how design changes like that can impact a large number of different systems.




I am officially declaring the Long Project on indefinite hiatus. It’s not dead, but only because I managed to get the body into a deep freezer in time. The core idea has stagnated, and many of the questions I was hoping to answer with it have been answered elsewhere in the intervening time (I highly recommend checking out the Spacebase prototype from Double Fine’s Amnesia Fortnight this year – it answers many of the questions I had when starting out on this game).

I have plenty of other plates spinning, though, so other things shall appear in this space.

Devlog 5

Ditching the old naming scheme for devlogs, trying out a new one. Adding the date was redundant, and I should probably try and spice things up a bit anyways.

Progress on The Long Project has been slower of late than I would like, but I do have a few other things on my plate right now. As of the third of December, I shall be leaving my current employment at cebas Visual Technologies to join InLight Entertainment. This is a pretty big milestone in my personal career, as I shall finally be paid to make video games! Woohoo! So most of my time has been devoted to getting my work for cebas wrapped up by the end of the month.

Anyways, I was able to get in some coding today. I’ve been working mostly on the AI crewmembers of late – setting it up so they can build things to start. This is the first step in setting up the more complex hierarchy of needs that you as a player will need to manage. As soon as I’ve worked out a few more kinks in the system, I’ll be working on adding resources to the game, as well as some preliminary buildings (resource storage first, then a few simple things like lights and doors).

So that’s my short little update.

But wait! You hear a forest troll approaching in the distance. If he spots you, his longs legs will quickly catch up to you and you shall be devoured. All you have is a single flare, some trail mix, your trusty Swiss army knife, and the forest around you. What do you do? (Answer in the comments)

Devlog Thursday 1st November

Devlog! Devlog devlog devlog…

Should have done this last week, but oh well, lots of things to talk about.

So last week I came to the conclusion that full-on Minecraft style block placement doesn’t work very well from a top down perspective. I was quite torn on this, as having a high level of creative freedom is very important in the design of The Long Project. The problem was that visibility and placing of blocks from the top down worked fine for a single layer, but once the third dimension was added to the mix it became very hard to keep track of what you had placed where, or where you should place your next block.

I had two choices. The first option was to drop down to a first- or third-person view. I know that configuration works in Minecraft, so if I wanted to preserve that level of creative control over the environment that would be a good (if derivative) route to take.

However, I was loathe to give up the top down perspective. At the core, The Long Project is a fortress/city sim game over an individualistic sandbox. As the overarching director of your crew’s lives, you should have minimal presence, instead relying on your crewmembers to follow your orders. Controlling from a top down perspective reinforces the fact that you are separate, different from your crew, as well as keeping you focused on the big picture. So how do I keep the top-down aspect while still allowing creative freedom?

In the end, I decided to take a page out of the Dwarf Fortress book (cribbing on design decisions being a long standing game development tradition) and separate everything out into “floors” and “walls”. Floors are one block deep and currently 4×4 blocks wide (though this latter part will likely change), and placing them places a counterpart roof block (which can act as the floor for the next level up). Walls are 3 blocks deep and 1×1 wide. I’m building everything on Minecraft scale, so players familiar with that will be able to transition easily. This means that crewmembers, like Steve, are two blocks in height. Having three blocks between floors gives a little extra room so it isn’t all too crowded.

Overall this setup is working swimmingly. Creation is a lot easier and really encourages the creation of rooms over more abstract spaces.

In other news, I’ve started working on implementing crewmembers. The first baby steps were taken earlier this week when I got a crewmember to pathfind from point A to point B. Yay! I originally had plans to use an off-the-shelf solution for pathfinding, as my surfacer can get the data need for a navigation mesh very easily. However, none of these solutions seem to be very good at working in an environment that changes arbitrarily at runtime. I’ve ended up implemented pathfinding myself, which has turned out to be a lot easier that I thought it would (protip: reusable code is good code). As an aside, I would like to put out an hearty recommendation for the iTween extension for Unity. Really good stuff.

Next up is getting the crewmembers to building things!


Ninja edits: I totally did not mess up the date when posting this. Honest.

Devlog Friday Oct 19 2012

Earlier this week, as you may have seen, I got engines and basic physics up and running. Ships can now be pushed around by engines and edited in a nice and speedy manner. The mass of the ship is currently directly proportional to the amount of cubes you have used to build it, so the bigger the ship, the more (or better) engines you will need to get it moving. I also did some work to make sure that blocks can be placed as usual while the ship is in motion.

Now I am working on getting life support working. The version I am shooting for right now is an oxygen generator module that generates oxygen blocks within its radius (barring any obstacles, such as the ships hull). I have the functionality in place but I have once again run into some performance issues. I am currently doing a very expensive depth first search over every block in range to see if it is reachable. I’ve explored a few options for speeding up this algorithm, but I think the best idea at this point would be to add some Event functionality (which I should probably do anyways).

I’ve also switched to a different skybox, as the first one was a bit on the busy and distracting side. Eventually I’ll make more of these, or even have them randomly generated. I’m using Spacescape to generate these, which wraps up some useful Perlin noise functions into a nice previewer and skybox generator.

Devlog Friday Oct 12 2012

Most of my work of late has been focused around adding functional objects to ship creation. Specifically, I’ve been working on adding combustion engines that can push the ship around, but this work will form the basis for anything in the game that has some sort of function (be it creating a breathable atmosphere, healing crew members, constructing robits, firing lasers, or pretty much anything else I can come up with).

There are three parts to getting this engine in place and functional. The first (which I have largely finished) is being able to place the object into the game world, and have the block setup recognize there is an object here (so that you can’t do something silly like build regular blocks inside of an engine).

The second part (which is the current difficult bit) is to set up the ship with colliders and rigidbodies so that I can push it around with my engine. The actual specifics of this are pretty easy to get working, but I am struggling with getting it working well (and, importantly, fast). I have set the surfacer I have made to divide the ship into horizontal slices, as this provides a major speedup over resurfacing the entire thing as well as working well with the top-down view of the game. A few back-of-the-envelope calculations put this slice method at around 99.7% faster for placing a single block. Having the ship sliced up like this allows me to scroll up and down in layers quite easily, too, which is good. However, I’m running into a few issues getting this sliced up view and placing method to line up with how the physics engine operates. Ideally, I’d like to be able to throw two large ships at each other with complicated surfaces and have them bounce off of each other in a way that doesn’t look odd. Getting this done is a bit more complicated than just converting the surfaced mesh into a single large mesh collider, however.

The last part (which is the easy part) will be to add some basic functionality to the engine itself – namely, it needs to exert some force on the ship. In Unity this is a very simple task, thankfully.

And that’s the state of the game right now. Thanks for reading.

Spacey-time research

Closing some tabs from doing research for the Long Project. This may give you an idea of where I am taking this game. If not, at least I’ll trap you in a whirlpool of random knowledge.

Devlog: Friday Oct 5 2012

Most of my recent efforts (everything since the last set of screenshots) have been devoted to un-breaking save game functionality. While Unity in general is pretty amazing, save games are not something it does out of the box. For the Long Project I’ve been using Unity Serializer, which overall is a pretty great (and free!) solution. It’s not entirely free from bugs, however, as my recent diversions can attest.

Anyways, now that that’s fixed, I have a few different areas I could start focusing on.

  • I could start adding some more block types and come up with some non-shitty textures (plus, I think there might be a few bugs in the UV co-ordinates I am generating). I might do some of this this weekend, as I will be in Vancouver with only my netbook.
  • I could start adding some buildings (I need a better name for this concept – maybe “components”?). It’d be fun to hook up some sort of engine to the spaceships I am making.
  • Or, I could start working on generating some navmeshes and implementing some AI for the crewmembers.

Either way, I won’t be able to dig in very deep until sometime next week, due to the Thanksgiving weekend. Much as I’d just love to hide in my apartment and code all weekend, apparently there is this thing called “social obligation” and “I’m actually related to some people and they probably want me to show up at family gatherings”. Woe is me, and all that jazz.