Wednesday, December 24, 2014

Ludum Dare 31 Post-Mortem: Hop 'N' Chop

A couple weeks ago, I participated in the Ludum Dare 31 72-hour game jam. I made a 1-button shooting/cooking game called Hop & Chop:

 Click to play

I'm pretty happy with how it turned out, and the response has been pretty positive. I thought I'd talk a bit about the development process and what I think of the final product.

Planning the recipe

I went into this Ludum Dare with a few goals in mind. First, I wanted to work solo. Collaborating with other developers is one of my favorite parts of game jamming, but I had some social obligations that prevented me from being available all weekend. I didn't want to flake out on anyone, so I decided to go it alone this time. I did end up reaching out to the multi-talented Teo Acosta, who took time away from his own game jam to compose the awesome music track in the game.

Second, I wanted to keep the scope very small. I've participated in quite a few game jams so far, and this is by far the most important lesson I've learned. I try to come up with a game so simple that I can get it up and playable in a matter of hours. That's the only way I've ever been able to end up with something even remotely polished by the end.

For Hop & Chop, I'd had already brainstormed an unrelated a 1-button shooting game where your gun bounced and rotated out of your control and all you could do was time your shots. When the Ludum Dare theme "Entire game on one screen" was announced, I wasn't feeling particularly inspired by it, so I decided to try out the "bouncing shooter" concept.

My third goal was to draw some sprites of food. For whatever reason, I find drawing food to be satisfying, so I figured I'd pick a food-related theme. Just like that, the shooting/cooking idea came together.

Cooking up a storm

With my simple concept in mind, I managed to get something playable Friday night: a cook avatar that bounced around shooting cleavers and some fish that could be chopped up:

If you look closely, you'll notice that the fish are first chopped into large chunks, which are then chopped into medium chunks, which are then chopped into small chunks, which don't get chopped any smaller. This is the beginnings of the "ingredients system", which would later allow me to build out the various recipes in the game. This system is nothing fancy, but it ended up taking the most time to fully implement.

I'm going to go into some of the details of how the ingredients were set up in Unity. I'll try to keep the technical stuff to a minimum, so bear with me!

This is a screenshot of some ingredients in the Unity editor. On the left are the "prefabs" for ingredients of various stages. On the right is the inspector window for the currently selected ingredient prefab Fish0 with the various Food script fields I exposed from code. Each of the ingredient prefabs on the left have the same Food script on them.

The most interesting fields are the Next Stage Foods and Combines With lists. These are lists of objects that I can drag-and-drop ingredient prefabs into in order to establish relationships between ingredients or the different stages of an ingredient.

For example, the Fish0 prefab has Fish1 and Fish2 listed in the Next Stage Foods list. That means when the Fish0 game object collides with a flying knife, the Food script will destroy it and create new game objects based on the Fish1 and Fish2 prefabs. You can see on the left that those prefabs have sprites that look like the two halves of a fish. As a result, the whole fish appears to be chopped into two halves. If we were to inspect the Fish1 and Fish2 fields, they'd both have Fish3 listed in their Next Stage Foods lists, and Fish3 would have Fish4 in its list as well. The idea is to set up a chain of ingredients for the player to progress through by chopping. 

Similarly, when two ingredient game objects collide, each of their Food scripts check to see if the other is on their Combines With list. If so, both ingredients are destroyed and a new ingredient from the Next Stage Foods list is created. For example, the Dough1 prefab you see on the left might have Pork1 in its Combines With list. If two of those ingredient game objects collide, they are both destroyed and a new Dumpling0 is created. The pork ingredient chain and the dough ingredient chain are then merged into a new dumpling ingredient chain.

All of the recipes in the game were put together by dragging-and-dropping ingredient prefabs into each other's lists to establish these chains of progression and combination. It took a while to build the ingredient system out in code, but once it was in place, I could quickly assemble and tweak recipes in the editor. This proved to be very useful when I decided to squeeze in the fried rice and mochi recipes during the final hours of the game jam!

Taste testing

So how did the game turn out? I had fun working on it, and the finished product still makes me chuckle. The comments I've gotten on the Ludum Dare page and in face-to-face playtests have been mostly positive. That said, player feedback and my own observations have revealed a number of design issues. I'm going to list just a few of the issues and then describe how I might go about addressing them.

One of the most common issues was that players couldn't tell what's going on with all the chaotically bouncing ingredients. It is pretty easy for players to spam their way through the first few recipes without understanding how ingredients are chopped and combined. They typically get stuck on the fried rice or dumpling levels because those require more deliberate tactics. It turns out my precious ingredient chains can be pretty inscrutable when they're represented by dozens of sprites bouncing around the screen.

To make the underlying system more apparent to the player, there are several techniques I could try out. One solution that wouldn't require additional code functionality is to simply add in more recipes that introduce each mechanic more gradually so the player can observe and internalize them in isolation. Another approach is to explain how the game works to the player explicitly through text, illustrations, or a directed tutorial, although that would be work-intensive and risks boring the player. A third option is to just change the system itself to something more comprehensible. What if each level was a discrete step in a recipe instead of making the entire dish? What if the ingredients don't move at all? What if the game was turn-based?

The issue that was most often voiced by the players themselves was how the control scheme worked. People seem to understand quickly that they can't control their avatar, but shooting accurately is still a significant timing challenge. I'd already taken steps during development to make hitting targets easier: I slowed the avatar rotation several times and made the default projectile fire 3 cleavers in a spread pattern, increasing the odds of hitting something.

I could continue to tweak and tune in this manner, or I could change the control scheme entirely. Sure, the "spinning gun" was the original concept, but that doesn't make it immune to change. What if the avatar moved side to side and didn't rotate, like a traditional SHMUP? What if the avatar stayed stationary and shot towards wherever the player tapped, like a "turret style" shooter? What if there was no avatar, and projectiles shot up from the bottom of the screen? These would all be cheap experiments, so they'd probably be worth trying out.

Finally, lots of players get stuck due to the level structure. Recipes typically require the player to perform chopping, combining, and cooking actions in sequence. There is also limited "ammo", which consists of different cooking tools they can shoot to perform each action. There are several awkward situations that occur if the player doesn't perform a given step in a recipe. Players often run out of "knife" ammo before they've finished chopping. This is especially noticeable if the recipe then requires combining and cooking steps, which can't be completed with the un-chopped ingredients. The player has to wait for the level timer to run out and the level to end so they can try again.

In fact, I added the 10- to 15-second time limit as a quick and dirty way to reduce the pain of these "stuck moments" by only making the player wait a few seconds for the level to reset. Kludgey design fixes like that are typical of game jams, but now that there's time to think the problem through, I should do better. What if there was no limited ammo, and the appropriate cooking tool became equipped based on the current recipe step? What if there were no discrete levels, and new ingredients kept spawning for successive recipes? 

Food for thought

All this reflection might be overkill for such a simple game jam project, but hopefully it was interesting to read. It was certainly a good game design exercise for me. This game jam was just what I needed after a recent string of uncompleted projects. It's so refreshing to finish something, even if it's small and low-risk. Now I've got to learn what I can from this experience and carry over the enthusiasm into my next game.

Thanks for reading!

Monday, July 28, 2014

Stuff I've been making (other than video games)

Hey folks, it's been a while since my last post, but I've still been busy working on stuff. No real news with Peak Condition, but I've started a new game prototype which I will be posting about soon. First though, I thought I'd talk about some of the non-game projects I've been working on lately.

Pixel art beads

I ran across an artist named Sarah Haghayegh (aka Pixelosis) at a convention who makes awesome beaded classic video game sprites, and I thought it looked like a lot of fun. I've pretty much copied her idea, only I'm designing my own pixel art patterns instead of using existing sprites. Here are a few I've made for friends:

I've always enjoyed the austerity of pixel art design, and these definitely scratch that itch. When making retro pixel art sprites for games, I typically work with a self-imposed limited palette, so it's amusing to actually be restricted to the bead colors I've purchased. Once I've designed the pattern, the actual beading process is fairly rote. That means I can bead while carrying on a conversation, which is great for occasions like my weekly Make Stuff Night (which I've been meaning to blog about!)


Feiya and I are going to Burning Man this year, and we're building a PVC shade structure called a MonkeyHut. The MonkeyHut is designed to shelter our tent from the sun while being flexible enough to stand up to strong desert winds. It's also cheap and easy-to-assemble. Here's a slideshow of our test-build in the park:

(Feiya took all the pictures, which is why you only see me working. Off-camera, Feiya was pounding rebar, bending PVC, and assembling the tent.)

The assembly was a success, and we discovered a few things we need to tweak. For example, we oriented our silver shade tarp incorrectly, which is why it doesn't reach the bottom of the PVC "ribs" in the last picture.

I've been stressing out over getting this thing made, so it was a huge relief to see it come together so well. Now I'm only slightly terrified that a strong wind will rip it up and fling it across the desert. 

Wooden dice

Another Burning Man related project I've been working on is my playa gift that I'll be giving out: handmade loaded dice. I bought some wooden craft cubes and went to work with Feiya's wood-burner to score the pips. The 6-side pips will actually be hollowed out and filled with Tungsten weight putty to weigh that side down and increase the odds of rolling a 1, which is represented by the iconic Man logo. Here's a picture of the dice in progress:

I'm making about 60 dice, so I've got plenty of work left to do. I've still got to putty most of them, sand their edges, touch up any pips that need it, and finish them with mineral oil. I've made a few prototypes to test the "loaded-ness" of the weighted pips, and I've gotten pretty good results. Here's a picture with a loaded die with tallies showing the test roll distributions:

Well, that's all for now. Next time, I'll talk about the new video game prototype I'm working on!

Friday, June 6, 2014

Peak Condition Log 06: It's finished! (for now?)

Download Peak Condition for either PC or Mac.

I finished the game by the end of May as I'd planned, but "finished" is a relative term, apparently. More on that below.

 Here's the new stuff:
  • Settled on the title "Peak Condition". Thanks J. Walton!
  • Added sound effects. Thanks!
  • Added a "lunge" maneuver. Hit space bar when both of your climbing picks are attached and you'll lunge upwards and forwards, which is great for getting up onto ledges. Careful though: lunging drains all your pick stamina.
  • Added 4 difficulty levels for mountain generation: Easy, Medium, Hard, and Expert. The difficulty for a mountain is determined by the random seed string length, so longer mountain names are more difficult.
  • Added a ring of trees around the mountain to fence the player in and add some scenery.
  • Added a very rough tutorial which is played when the mountain seed is set to "Mt. Tutor".
  • Added a new death animation.
  • Fixed the victory detection.
  • Miscellaneous bug fixes and tweaks.

Phew, that last weekend in May was pretty busy! I squandered an entire Saturday's worth of gorgeous Summer weather, but I'm really happy with how much I got done. I completed all but one of the tasks in my "MVP" list on Trello. I can finally call this one finished and move onto my next prototype!

That was the plan, anyway. When I showed the game to my design meetup group last Sunday, I got a lot of great feedback and encouragement to continue working on it. When I look at my Trello board, there are still several features I'm just dying to get into the game. I feel like this concept has still got a lot of unfulfilled potential, and I'm not quite ready to call it quits yet.

However, I am ready to take a break for a while. I'll probably play around with some other prototype ideas I've been eager to start on before coming back to Peak Condition. In the meantime, I'd love to hear your thoughts on the current build and where you think the game could go in the future.

Sunday, May 25, 2014

Mountain Climber Dev Log 06: What's in a name?

Download the latest stand-alone build for PC or Mac. Or if you prefer, play in your browser. By the way, I don't have a Mac and I'm not really familiar with how best to distribute downloadable Mac builds, so I just zipped up the .app folder that Unity spat out. Please let me know how that works for you.

Changes in this build:

  • Implemented and styled the main menu.
  • Added a pause menu triggered by the "escape" key.
  • Reverted to the two separate pick stamina bars.
  • Iterated on the crosshair and stamina UI.
  • Experimented with an alternate "auto-hang" climbing style.
  • Added an altimeter.
  • Miscellaneous tweaks and bug fixes.
A week to go until my self-imposed deadline, and the game is coming right along. I styled the UI and added some simple fading transitions between screens, and it's already feeling much more like a "real" game.

Implementing and skinning the Unity GUI components was a lot less painful than I'd expected. I'd heard how limited the standard Unity GUI components were, but for a simple game like mine, they actually seemed pretty easy to use. Keep in mind that I'm coming from years of Flixel development, which required a lot of manual GUI work. I still plan to try out NGUI if I attempt a more GUI-heavy game, but for the time being, I'm glad I got a chance to try out the standard components and form my own opinion.

I switched back to the "per-pick" stamina bars so I could separate out two pieces of feedback that were previously both signaled by the crosshair: whether a pick is ready to use and whether the targeted surface is within range. The crosshair UI is now solely for reporting if a targeted surface is within range. Each pick's stamina bar now darkens when it is attached to a surface and brightens again when it is free and ready for use. I also added a pulse effect on a pick's stamina bar at the moment it impacts a surface. Hopefully this makes the climbing feedback easier to use while playing, but I wouldn't be surprised if I end up iterating on it one or two more times.

In response to some player feedback, I played around with a different climbing mechanic, which I dubbed "auto-hang." With auto-hang enabled, the player doesn't have to click and hold to keep a pick attached to the wall. Instead, they just click to attach the pick and click again to detach and attach to a new location. It makes the game quite a bit easier and consequently diffuses most of the tension. Ultimately, I decided it wasn't right for the game, but I left the functionality in as a debug menu option, so if you'd like to try it out, simply pause the game using the escape key and enable auto-hang.

I'm getting pretty sick of calling this game "the mountain climber game", and with a week to go, it's high time I settled on an actual title for the thing. My current ideas are mostly just cribbed from online thesaurus searches and mountain climbing glossaries:
  • Pinnacle
  • Ascent
  • Summit
  • Peak
  • Acro
As you can tell, I could probably use some help in the name department. If you've got any suggestions, I'd love to hear them in the comments.

Tuesday, May 13, 2014

Mountain Climber Dev Log 05: The Peak is in Sight

Click here to play the latest build. Here's what's new:
  • A single stamina meter instead of two "per-pick" stamina meters. The idea was to simplify the UI. The meter also turns red when you're running out of stamina.
  • A new mountain is generated each game according to a random seed in the form of the mountain's name. So "Mt. Rainier" will produce the same mountain every time. You can even type in your own mountain names and see what kind of mountain you get.
  • Player movement tweaks.
  • Terrain generation tweaks. See below.

I spent a fair amount of my time on the new terrain generation for this build. I tried to find a workable range of values to randomize so that each mountain felt climbable but somewhat unique. You may notice that the mountains have a lot less side-to-side vertex warping than in previous builds. The result is that the surfaces are mostly vertical and perhaps back to feeling more voxel-like. The reason I did this was to work around a problem I'd been having with the player movement.

As I added more and more angled surfaces to the mountains, I noticed that the player frequently "bumped their head" when jumping near a seemingly vertical surface. The problem is that the character controller doesn't have very complicated collision detection, so whenever the capsule-shaped collider hits anything on its top-most portion-- even a very slightly angled vertical surface-- it counts as a ceiling and stops the movement.

I tried making the climbing picks hold the player farther out from the wall, but that doesn't solve the problem when jumping from a standstill. I also looked into overriding or ignoring the default ceiling collision behavior, but it's tricky to tweak Unity's standard character collision code.

Eventually, I looked at the problem and the amount of other work I had to do, and decided to change the terrain to no longer produce the problematic geometry. It's definitely a sacrifice in terms of cool mountain shapes, but I'm hoping it's worth the saved time and effort.

My other news is that I've set an arbitrary deadline for myself: I'll release the finished mountain climber game by the end of this month (May 31st). My hope is that having a finite amount of time to spend will help me prioritize my efforts more efficiently, like with the ceiling-bumping issue. I'm also eager to move onto new projects, so knowing that I'll be freed up to do that in June is something to look forward to.

Thanks a lot for all the great feedback on the last update. I'd love to hear your thoughts on the latest build, especially on the terrain generation. Let me know in the comments if you find any particularly good (or bad!) mountain generation seeds.

Take care!

Sunday, April 20, 2014

Mountain Climber Dev Log 04: The Measure of a Mountain Climber

April has been a busy month for me, but I finally carved out a weekend afternoon to implement some new features: win/loss conditions and stamina.

Click here to play the latest build. I recommend trying it in fullscreen mode by right-clicking the Unity player and selecting "Go Fullscreen".

The first change you'll probably notice is that the picks are different colors and there are matching semi-circles around the cursor. The different colors are to help players keep track of which pick is associated with which mouse button. The semi-circles are individual stamina meters for each pick. You'll notice they drain when you've got a pick pinned to the wall. They slowly recharge when not pinned, and if you're standing on a stable surface, they recharge quickly. If a pick's stamina meter runs out completely, that pick will become unpinned from the wall, which typically causes you to fall to your death.

Oh, that's another thing: you can now fall to your death. The game currently just prompts you to return to the main menu, but the important thing is that you can now lose the game. You can also win the game by climbing to the top of the mountain. The game even tracks how long it took you to summit the mountain, starting from when you first step off of the ground below. My best time is 37.625 seconds. Can you beat me at my own game? Post your best time in the comments below.

Although all of these new features are still pretty unpolished, this is an important step in the prototype's development. Going forward, win and lose conditions give me some concrete heuristics for tweaking the player movement and terrain generation. When I make a change, I can measure its effect on the game quantitatively: does the new jump height result in faster times? Do steeper slopes on the terrain result in more fatal falls? Better still, this new quantitative game data can be gathered from playtesters instead of from my own playthroughs. How often do new players fall and die? What is their average time on a successful summit?

Going forward, I'll be soliciting playtests from new players and using my observations to decide where to focus my efforts. In fact, that bit where I challenged you to beat my time was a not-so-subtle effort to get more people playing the game. I'll probably subject some unsuspecting folks to in-person playtests, too.

Finally, I've been thinking about this project (and being distracted by ideas for new projects), so I figured I'd share my thought process. I fully intend to finish and release this game, but the question is what "finished" looks like. Some open questions:

- What would a bare-bones version of the game look like?
- What would a fully-realized version look like?
- How fun is the game, as is? How fun do I think it could be if I add a bunch of new features? In other words, what is the potential of this project?
- How much am I enjoying working on it?
- Shall I decide on a finished state for the game and work on it until I reach that state, or set a deadline for myself and work on it as much as I can until then?

I'd love to hear your thoughts, particularly on the "how fun is the game" question!

Monday, March 10, 2014

Mountain Climber Dev Log 03: Tetrahedral Rabbit Holes

So I decided to drop the mountain climbing theme. It's now about scaling a giant, Everlasting Gobstopper:

Okay, not really. That screenshot is the result of a spending some time down a programming rabbit hole. I ended up scrapping most of the work, but I figured I'd explain what I was going for and where I ended up.

A rabbit hole is an all-consuming task that derails your priorities. When you're down a rabbit hole, you tend to focus on the details of implementation and lose sight of the actual goal of the feature. 

My goal was to make the terrain feel less like a bunch of stairs that the player just hops up. I wanted the terrain to have longer, sloped surfaces that required the climbing pick to traverse. A secondary goal was to make the mountain look less like I lifted it straight out of Minecraft.

I started digging around on Wikipedia to find an alternative 3D shape to cubes that, a) was made of sloped surfaces, b) tessellated with no gaps, and c) fit on a regular grid, so my 3D array of voxel data was still applicable. I settled on a tetrahedral-octahedral honeycomb, which also happened to have an awesome name. I decided to horizontally bisect the octahedra into a pair of pyramids. That way, all the shapes would fit on a regular grid, and the downward facing pyramids would produce an occasional flat surface for the player to rest on. I was feeling pretty clever and excited to implement my solution. That's usually a rabbit hole red flag.

Eventually, after several sessions worth of trial and error, I got it working as I'd planned. You can see the various tessellating shapes in the screenshot above: red "upward" pyramids, orange "downward" pyramids, and green and blue tetrahedra. Unfortunately, you might also notice that it looks like a disjointed, fractal nightmare-scape. In theory, the honeycomb can produce nice, mountainous terrain under very specific patterns. In practice, it tends to produce lots of convex gaps and erratic spikes. I'd hit a dead end in the rabbit hole. 

At that point, I could have tried to finagle the nice, mountainous terrain I wanted from the shapes, perhaps using rules enforced on the voxel data that reduced the undesired arrangements. Instead, I poked my head out of the rabbit hole and reevaluated my goals. I really just wanted terrain geometry that was more fun to climb on and nicer to look at. I decided to go back to the cubic voxels and try deforming the vertices with a combination of Perlin noise, scaling, and a sin-function "bulge".

You can check out the results here in the current build. The terrain's still not perfect, but it's already more fun and visually interesting. More importantly, it was quick and easy to implement. I now also have a bunch of simple parameters I can tweak to produce further variation. I'd escaped the rabbit hole!

I should probably point out that rabbit holes aren't always bad. Yes, they're an inefficient use of time, but that might be fine if your project isn't on a schedule. If you're working on a hobby project that you're not in a rush to finish, rabbit holes can be very fun and satisfying. That's why they're so "treacherous" in the first place. I know several programmers who work on hobby projects primarily so they can spend as much time down rabbit holes as they please.

However, if you're concerned with keeping yourself on track, a good exercise is to periodically assess your goals. Is your current task in service to those goals? Is it taking longer than you'd expected? What's a faster, simpler alternative implementation?

My next goals are to add win and lose conditions to the game and further tweak the player movement and terrain. Hopefully I can hold myself to that!

Monday, March 3, 2014

Mountain Climber Dev Log 02: Climbing picks

I've posted a new build of the Mountain Climber game. Check it out:

The main changes in this build are the additions of the climbing pick model and animations.

Implementing the climbing pick animations turned out to be more interesting than I'd expected. I decided to animate the swing via code rather than animating them by hand, mostly because I wanted to say I'd lerped quaternions. Once I got a simple state machine implemented for the climbing pick (with states like "swinging", "pinned", "withdrawing", etc.), most of my time was spent tweaking the hard-coded positions and rotations for each state and the timing for transitioning between them. 

In order for the player to actually see the animation, I needed to add a time delay between when the player clicks the mouse and when the pick becomes pinned to the wall (the "swing time"). I also added a delay between when the player releases the mouse and when the pick becomes ready to use again (the "withdraw time").

Because the pick swing was no longer instantaneous, a new case was introduced where the player could miss a swing if they'd clicked the mouse when the pick was within range of a surface and then quickly moved the mouse away before the animation finished.

To handle this, I added an "overswing" state with an animation of the pick swinging downwards. When the swinging animation finishes, I check to see if the pick has a valid surface in range. If it does, I attach the pick to the surface based on the geometry's normal and the angle from the player. If there is no valid surface in range, I switch to the overswing state. A nice bonus is that it covers the case where the player swings the pick in mid air with no extra effort on my part. 

The animation delays also prevent a degenerative tactic that I'd found in earlier builds where you could click rapidly to easily scale a vertical surface. See if you can get the exploit to work in the build I posted earlier. I want the player to be able to scale a sheer surface, but I want it to feel taxing and dangerous. Let me know in the comments how you think the climbing feels in the latest build.

My next task is to overhaul the terrain generation. I might be saying goodbye to the cubic voxels...

Sunday, February 23, 2014

Mountain Climber Dev Log 01: A new game!

Here's the project that's been occupying my weekends lately. It's in an early state, but I like where it's going. Check it out:

 Click to play the Mountain Climber prototype.
I got the idea for this protoype while doing some Unity 3D tutorials on FPS controls and voxel terrain. I combined the results of those tutorials and started just goofing around in the game. It felt like a bare-bones Quake-meets-Minecraft at that point. 

While I was playing around in this voxel sandbox, I kept building these giant spires and trying to climb them. Climbing the structures felt surprisingly dangerous and challenging. I was staying engaged with the same activity for more than 5-10 minutes, which is a good sign.

This is a great prototyping trick if you're not concerned with testing a specific design. Start with a toy-- a simple game mechanic with no particular objective-- then play with it. Try out every way to interact with it that you can think of. Make up goals for yourself. Make up rules that you must obey. Keep everything self-imposed to save yourself coding time. For example, I set a rule for myself: "I can only place one voxel at a time." Holding myself to that self-imposed rule, I could then try how that constraint felt without having to actually code a limit on voxel placement.

Eventually, I decided I'd run with the climbing part of the prototype and drop the voxel editing parts. I wrote a quick-and-dirty mountain generator using a sin function with some Perlin noise, which actually worked pretty well. I added distance fog, rock textures, snow particles, and a cloudy skybox. I picked those features to implement primarily to learn more Unity tricks, but they also contributed quite a bit of atmosphere.

I brought the prototype to my regular game design meetup, and the feedback was encouraging. People said it was very evocative and that moments like leaping from ledge to ledge or looking down a steep cliff felt genuinely harrowing. Their enthusiasm made me decide to keep working on it, and what you see now represents the 3-4 Saturdays' worth of progress since.

I've written out the short-term features I'm planning for the game in a Trello board. Feel free to comment on the prototype so far or where it's going in the future. More updates coming soon!