Brian Crick

Postmortem: The Butterfly and the Beanstalk, Part 2

Now for the fun part! Tearing my stuff to pieces is nifty.

I have a new, much more playable build now, and I’ll be talking about the changes I made with that.

what went wrong

class bloat

The code for my original version of the game contains a single Pipe class that stores the general shape of the pipe, handles the rendering of the pipe, and controls the placement of trees. The class got very big and complicated, and halfway through the jam it became a bit of a pain to find the specific bits of code I needed when I needed to make edits.

For the revision, I’ve separated this out into three classes: one for rendering, one for controlling trees, and one for the general structure and coordinate transforms. Basically a model/view/controller approach, which makes it much easier to edit.

regression issues

I made the butterfly mid-Sunday, just a couple hours before the deadline. Before that, the player was represented as a plain ball, a stock Unity object.

When I replaced the ball with my butterfly model, all the behaviors attached to the ball object had to be re-done for the butterfly object. The bounding box got bigger, which made the game much harder. And I didn’t copy over the music thing right (it was attached to the player) and the music didn’t loop anymore.

What I should have done is make a really simple, properly sized placeholder in Blender while working on other parts of the game, and then edit that Blender model when I decided it was time to flesh that out — that way, Unity would have automatically imported the changes to the mode without destroying the behaviors attached to it.

difficulty

The version I turned in for the jam is absurdly hard. I was never able to win it. For the new version, I spaced out the trees more, spread out the initial bumps, and made it so that your score only takes a hit once for each tree, even if you get stuck hitting the same tree over and over. Those simple changes made the game much more fun, and gives the player more of that calm, focused feeling I wanted for the theme.

the scoring thingummybob

The score meter was added an hour before the deadline, and it shows. Functionally, it does its job of giving the player win/lose conditions based on obstacle avoidance and not moving too much, but it’s not real clear when the meter is going to go up or down. And having it based on a whole number point system is just kinda weird.

the instructions screen

That was made fifteen minutes before the deadline. Obviously, it’s very spare and rushed.

feedback

Sometimes — just sometimes — when you hit a bump or move too much, you can see the pipe in front of you get all twisty, and it’s a really cool effect. But you don’t see that often, and in general, it’s not real clear what effect your actions are having on your environment.

My solution for the revision is to express this relationship though a visual intermediary: the storm clouds. When you hit something or turn too fast, a cloud appears, and you immediately know something is up. The cloud hovers near you for a while, causing visible havoc right in front of you. And you can see the cloud draining away, so you know when the havoc is going to end.

This also replaces the scoring meter. It’s still numeric, but it’s expressed in a way that feels like part of your environment.

It’s now unquestionably harder to see your score, i.e. the number of clouds in the scene, but overall I think this is a step in the right direction.

stalemate

You can easily reach a place where you’re not making progress towards winning, but the game isn’t ending, either.

Part of the issue there is that just tapping a key in the original version makes your score get one point closer to losing. To win, you’d have to be on 1 and then stay absolutely still and not hit anything while the score meter takes its time dropping to 0.

For the revision, I’ve made it so short taps don’t count against you, but if you hold down a key for any length of time, you get penalized. Things can still drag a bit, though. I think I might need something where the difficulty increases if you take too long.

to sum up

I’m still very happy with this, even the first, unwinnable build. I dare say it’s the first thing I’ve ever made — having been puttering around with video game programming since I could type — that I really like playing. And that says a lot.

I’d like to keep working on it, balancing things, making the cause and effect more clear, and really rewarding the player for being calm and measured in their movements. I think that’s a unique aspect of this project, that I can highlight more.

The Butterfly and the Beanstalk Postmortem: What Went Right

(This got a bit long, so I’m splitting it up into parts.)

This last weekend, I attended my third game jam. It’s a thing where you have a couple of days to make a complete video game, based on a theme that’s not known until the start of the jam.

This jam’s theme was The Butterfly Effect. I ended up with a racer type of thing, without the racing. You can play the version I completed for the jam here… though it’s nearly impossible to win. In my next post I’ll put up a new, more playable version and talk about what went wrong and what I was focusing on fixing post-jam.

what went right

the theme

I was really, really unenthusiastic about the theme when it was announced Friday night. So at first I decided to just do something pretty, where you were a pretty butterfly racing along this pretty, convoluted pipe with pretty, perfectly round trees in your way. Like this Unity contest winner. And… going with the theme of the butterfly effect, your small movements should affect the shape of the level globally… somehow.

Which is what I did for my other two jams. Nothing terribly original or exciting here.

But that — that not caring about the theme, or even my own mechanics — led me to what I think is an interesting mechanic that fit with the theme.

By the time Saturday was halfway over, I had sort of numbly forced myself to implement an unchanging pipe, and you could move along the pipe, and there were trees in the way. And I played several times through this empty, endless experience, each time imagining a different goal for the player, and different complications, and that helped me find an approach to the theme I could get excited about.

I kind of liked not starting with a concrete approach in mind. Instead, I started with a stock mechanic, the pipe racer thing, and that helped me think. And that’s the exact opposite of what I’ve done in my other jams.

the pipe

The game has only the vaguest concept of your position in three dimensional space, or even the fact that you’re traveling on the outside of a convoluted pipe.  As far as the game mechanics are concerned, you’re traveling in a straight line along a straight, two-dimensional track. What I’m doing is storing everything — the player location, the position of the trees, even the points that make up the surface of the pipe — in a simplified coordinate system with the following components:

coordinates

  1. Distance along the pipe.
  2. Height above the pipe.
  3. An angle representing your point’s orientation around the pipe.

I then wrote a single positioning function to translate this coordinate system to the world system, bending everything around an array of points I had that defined the curvature of the pipe in world space. Everything went through this function, so once that was nailed down, it became very easy to place things where they needed to be, relative to the pipe. To create the pipe, I call my function on different combinations of distance and angle, all with a fixed height (the radius of the pipe) and those are the vertices on the final pipe mesh. Every frame, the player’s distance goes up a fixed amount and the angle changes if keys are pressed, and then I call my positioning function to place the player model in the scene. As the player moves through the scene, trees are created with 0 height, a random angle and a random distance and positioned with my function. When trees spin, I change their angle slightly and call the function again.

Nothing here cares that the pipe is twisty. Nothing at all.

the music (sort of)

I’m not thrilled with the music. I spent all of half an hour composing it, and it has more than a little in common with this bit of Doctor Who (at the 1:55 mark ). I consider this a win, because I had the presence of mind to just throw some music up there, and move on. There were more important things to work on.

the graphics

My initial goal was just to make something pretty. I think it’s fair to say I got that. 🙂

I’m especially proud of this tree.

tree

More on how I made that in another post.

the revision

I’m considering the post-jam revision an essential part of this process, which is something I’ve never done before. Rather than simply think and blog about what went wrong, I decided to go ahead and try to make fixes for the most glaring problems, and that has helped me learn more about what I need to work on here.

So that’s it for now. Stay tuned for What Went Wrong, which may be even longer! 😉

What You See

On some basic level, most programming languages are kind of the same.

Until they’re not.

Sure, ifs are ifs and loops are loops no matter what the syntax, but development environments can vary greatly in terms of how they want you to work. And if you fight that, you can be making things way harder on yourself than you need to.

I’ve recently run into this with Unity.

I picked up Unity because I was tired of trying to make games in environments designed for writing apps. And I loved it. Unity has a really nice library that contains functions for editing meshes, writing shaders, and working with object relationships in three dimensions.

However, this is what Spindle Sun looked like, in Unity:

Editor-1-June-2013

It… didn’t look like anything at all. There are no spaceships, no planets, no game board to look at. Just an anonymous sprite sheet, which is an artifact of the way I was approaching everything: everything was made in code. When you started the game, it would randomly make some planets, and give them random names, and put you in the center of the map… but you couldn’t see any of that in the editor. And it was hard to imagine, looking at the editor, what was going on, what the gameplay might be like.

So I’ve decided to ditch the procedural maps thing and just make a level in Unity’s very nice level editor, and this is what editing looks like now:

Editor-3-July-2013

Here, you can see a couple planets. They have names in the Hierarchy list and in the Scene preview. There are stars, and you can see your spaceship’s starting position.

Spindle Sun is sort of a spin on 4x take-over-the-galaxy games, and you sort of expect those to be procedural. But I’m working out the gameplay as I go, and doing that with a procedural world has proven to be rather annoying. What I need to really get the gameplay right is a concrete map, so I can look at it and see what sorts of challenges the player will face and what obstacles I can put in their way and see how the player is going to progress through the map.

It’s about being able to work hands-on with the design of the game. Which, previously, I wasn’t really doing.

I’ve tried studying levels in other games like Metroid Prime, but I’ve never actually designed a level before, in a level editor. Most stuff I’ve done has been procedural, or I’ve made little maps you could walk around that weren’t really levels in the sense that there was a flow through the level. So all this is new to me.

Unity is much more than a code library, and I’m pretty sure Unity wants you to work in a visual sort of way. And I’m rather liking it so far.

Personal Archaeology

Some people have formative experiences. Among other things, I have a formative logo, which I’ve just seen for the first time in thirty years. Always an odd experience, seeing things like that.

* * *

When I was little, we had this computer. And we got magazines written just for users of this computer.

robochase-cover

Every issue had code for simple games; if you typed the code verbatim into your own computer, you could play these games. I did this a few times.

This particular issue about ‘education with the home computer’ had a game called Robochase. I don’t remember the gameplay at all, but I do vaguely remember the instructions screen, which had a logo that looked like this:

robochase

This is me.

This is my life.

* * *

To make that title card, you didn’t use a graphics program or anything. You did it in code.

robochase-code

See all those DATA statements with incomprehensible gobbledygook after them? Those are custom letters. A font, if you will. E0F0F8F0E0F0F8 is an R. F8F8D8D8D8F8F8 is an O. But it’s not a whole font. It’s just the letters you need to spell out ‘robochase’.

And one of the first things I did with a computer that wasn’t typing in a canned game or playing an existing game, was try to fill out the rest of the letters in this sort of Tron-ish font.

I don’t remember how far I got, or how good my results were. But I remember that I tried. I found this endeavor far more enjoyable than playing kickball with my friends.

And being a programmer, and puttering around with game projects, and having an interest in making fonts, and typography, and graphic design in general, this is a big part of who I am.

* * *

I love being able to dig up stuff like this. The stuff that made us. Not that it’s a particularly straightforward process. It’s taken years for me to find a pdf of this magazine.

Part of the fun is the random other stuff you discover along the way. An ad for floppy disks. An article about how great computers will be at teaching mentally disadvantaged kids.

And once I see this stuff I’m made of, it all becomes a little more mundane, and it’s reminder that every mundane thing I do still makes me, for better or worse. I’m well out of my formative years, but I’m still being made by the things I surround myself with. So I’d better make sure I’m being made of the right things.

Copyright © 2017 Brian Crick.