Computer Games – Page 2

Immediate Deresolution

I’d like to talk about modeling a bit. I’m saying that up front because it’s gonna take me a minute to get to that part. 🙂

* * *

For a brief period in high school, I regularly had three dance classes in one day. At the time, and up until just now, I focused on the time I was putting into it: an estimated 14 hours a week. It was a pretty decent chunk of time.

But looking back on it, the number isn’t the only thing that’s important. The other important thing was that I had three separate and distinct dance-related activities.

Every morning I had a class on technique. Every afternoon was spent rehearsing pieces for an upcoming show. And frequently, between classes, I’d run off to the studio to work on choreographing and practicing a solo piece.

And in each of these three activities, my mindset was different. Sometimes I was focused on being creative; sometimes I was not. Sometimes I was trying to stay in sync with my classmates; sometimes it was just me, learning to keep an eye on myself in the dance studio mirrors; sometimes I wasn’t looking at anything at all, trying to develop a good sense of balance and positional awareness. There was a specific time for each little thing I needed to learn, to get better at what I did. And while I wouldn’t say I ever got to be a great dancer, having those things separated out, was, in hindsight, a great thing to have happen.

* * *

In an attempt to improve my skills and efficiency in, well, pretty much every creative thing I do, I am going to try integrating small-scale game-making exercises into my regular project rotation. It’s kind of like a different classroom environment. I’ve always been a fan of having multiple projects at once so they can kind of creatively feed on each other, but I don’t think I’ve specifically drawn a line before and said, these things are for production; these things are for learning. I want to make sure I spend time in both mindsets, and really commit to one or the other when I’m working so I can learn more about whatever I’m working on.

* * *

My first assignment is an arcade-style thing meant to teach me about level design. My second, which I’m working on at the same time, is a spaceship flight sim where the emphasis will be on modeling and making responsive, natural-feeling player controls. I’m afraid I don’t have much to say about the former right now, but in regards to the latter, I learned a little bit more about how to make low-polygon meshes this week.

My first job is to model a spaceship cockpit. Right now, it looks vaguely Star Wars-y: there’s a big, round window with a decorative grill.

And here’s what I’ve learned the hard way: making a low-polygon mesh is not about making a high-polygon mesh and then simplifying it. You have to think in terms of the simplified version before you even start modeling.

I’ll explain that by way of a simplified example. Suppose you want to model this:

If you want to use this shape in a video game, you have to turn it into something a video game understands: a mesh made of triangles. Like so:

While each triangle has perfectly flat sides, the appearance of curves can be simulated by using very small triangles. When you use enough small triangles, you get the appearance of smooth curves.

Unfortunately, more triangles frequently means slower games. It’s not the only thing that can affect the performance of a game, but it is something you need to worry about. And I always start off by making meshes with too many triangles.

The obvious solution here is to take the high-resolution mesh and systematically remove detail from it. Here, I’m using a subset of the points used in the detailed mesh.

Check out the area where the small circle meets the big circle — there’s a sort of Y intersection there. And in this mesh, the widths of the strokes all around that Y feel totally wrong. And the inner circle is a little thinner than the outer one.

What’s happening here is that I’m reducing the number of triangles in the mesh without any real awareness of or respect for when the mesh actually represents. I’m treating this as a series of outlines, like so:

The relationships between each of those shapes is getting totally lost. What’s really happening here, of course, is that I have two outlined circles that need to feel circular in the final product.

I need to not reduce the triangle count the intersection of the two circle outlines. I need to reduce the triangles in the individual parts of my mesh —

— and then combine the derezzed versions.

Now, that Y intersection where the small circle meets the big one looks much better.

I’ve also made a change to how the simplification of the circles happened here.

If I have this circle:

And this overly-detailed mesh:

And then systematically remove points on my mesh, I get this–

–I get a shape inscribed within my original, a shape which is much too small to be an accurate interpretation of the original.

The new mesh should have around the same area as the old one. Like this:

Note that the vertices of the hexagon here aren’t on the circle. My simplified mesh doesn’t actually contain any of the points on the old mesh.

* * *

Of course, it probably wouldn’t be that useful to model individual parts of something and then use your modeling program’s boolean tools to combine them. Rather, the thing I’ve learned here is that I should start thinking in terms of a simplified mesh earlier, and model that–rather than modeling something that’s too detailed, and then programatically simplifying the detailed version (whether it’s an actual simplification utility in your app, or just thinking too programmatically).

Global Game Jam Post #4: This is the Jam that Never Ends

Gonna wrap up my Global Game Jam 2014 writeups by talking about how I’m going to approach my next game jam, which will probably happen this summer. Usually I don’t decide on an approach until the jam is about to start or shortly after the theme is announced, but in this case, it’s relevant that I’m deciding early.

I have tried to approach each of the four game jams I’ve been to with a different mindset. As someone who tends to do game jams solo, I have many roles to fill on my own — programmer, designer, modeler, composer. What I’ll usually do is really push myself and take a lot of risks with one role, and work just in my comfort zone in the other roles. So for example, in this last game jam, I made way more complex models than I usually do, but designed the project in such a way that I’d only have to do programming tasks that I was absolutely comfortable with.

The goal here is to focus on one skill and try to learn as much as I can about it during the jam. It’s basically calculated risk-taking in a controlled environment.

But for my next game jam, I will drastically reduce the amount of risk-taking I will make, everywhere. I will make the highest-quality, most complete product I can, only using skills I’m completely comfortable with. That might sound silly; one might assume that creating a quality product is always the goal at a game jam. But it’s never been my goal before. And the implications of setting that as my goal, now, are kind of huge. It means the game jam is a test, not so much of a learning experience in and of itself.

The learning must happen in the months leading up to the jam: I am going to try to force myself to keep working on all of my skills, on a consistent schedule.

If I want my game to have good music, I need to start improving my composition skills now.

If I want my game to have good graphics, I need to have good, efficient modeling and texturing practices down cold.

If I want my game to have a fun mechanic, I need to get comfortable experimenting with new mechanics in self-contained test environments.

And wherever my skills are when the next jam starts, I’m going to play it safe and do things I am reasonably certain I can do.

I don’t know how I’m going to feel about all this once the next game jam starts. I may very well find it all less exciting than previous jams, less intense, less fun, because of the reduced risk-taking during the jam proper. But I’m willing to try this approach.

Because I think that potentially squandering one game jam by playing it safe is a risk worth taking.

Global Game Jam 2014 Post #3: Trying for Once to Talk About Music

I don’t think I’ve ever gone into specific detail about music in a postmortem, except to say things like ‘I liked this’ or ‘this was hopelessly derivative’… I generally talk about my feelings, but not the music. So I suppose it’s time to start talking about specifics.

I’m not real sure how to talk about this. I can’t even read sheet music, and my musical vocabulary is somewhat limited.

But here’s what I’ve got:

A moody, haunted ship type thing that’s more ambience than music.

A somewhat happier, out-to-sea theme.

(Sadly, the 30 second clips above are not, like, samples of larger works. 30 seconds is all I’ve got.)

Anyway.

You were suppose to be on a spaceship. Can you tell?

Ok, not really. But it was supposed to be a spaceship. With, like consoles and windows into space and blinky lights. So I wanted something that sounded like a haunted ship.

When you were in an unlit area, the first theme would play; when you were in a lit area, it would fade to the other theme. I’ll just talk about the two separately.

the moody ambient thing

Generally, I like it, but I can’t really take credit for how it sounds. I’m using a software package called Garritan Instant Orchestra that includes pre-made instrument combos you can use, and while most are symphonic textures with names like ‘Splatty Ostinatos’ or ‘Sweeping Melodies’, some are more ambient…

…like the combo called ‘Ghost Ship’. I just opened it up and started pressing random keys. That worked well enough, but I certainly could have used it in a more interesting way.

Logically, the next step is for me to take manual control of what Instant Orchestra and my random-keys approach were doing for me automatically. If I want, Instant Orchestra allows me to play individually the instruments each pre-made combo is made of.

Ghost Ship is actually made of four unique instruments. At first glance, most seem to be drum kits, which means that they’re not playable, melodic instruments so much as collections of sound effects, each effect being tied to a different key on your piano. One key on a standard drum kit might be a big floor drum, while another key would be a cymbal crash.

So I should look at each kit, one by one, and listen to the effects, one by one, and try to think of interesting things you could do if you were controlling each kit independently, making the exact sounds you wanted, exactly when you wanted them. I should really get to know these kits, and the other kits Instant Orchestra has to offer.

the more melodic thing

When I think ‘nautical’, I think of music whose volume or pitch (or probably both) rises and falls in a gentle, rocking sort of way. I really don’t know if that would qualify as a musical cliche, but even if it does, I suppose it’s a cliche I really like.

I tried to do that with the arpeggios, trying to go for something like bubbling water there. Sadly, the arpeggios are a little hard to hear. Probably could have emphasized those more and the melody less.

As for the melody, it occurs to me just now that I probably want an instrument with a slow attack and release — meaning that when you press a key on your piano, the volume would start off really soft; as you hold the key down it gets louder, and when you release the key, the note doesn’t stop instantly, but fades out slowly.

Again, this is something I can manually control, though I tend not to.

Luckily, I think I’m kinda close to this already, but I don’t think I was consciously thinking about that whole gentle rocking thing when picking an appropriate sounding instrument.

The melody is a little slow and plodding; lots of whole notes. That goes with the whole slow rocking thing I guess, but I feel like there should be something more dynamic, too. And again, maybe emphasizing the arpeggios over the melody could help with that. I could also play arpeggios for a while, and then have it grow into a full-fledged theme with a more complex rhythm played on the same instrument.

Side note: In general, I think I try too hard to fill up all the space in my music. In visual design terms, there’s no whitespace; there are fine details, but when viewed from a distance, everything looks like the same boring grey.

If I’m having trouble making clips more than 30 seconds long, perhaps it is because I am so focused on the fine details, without a larger-scale framework in which to place them.

Global Game Jam 2014 Post #2: The Great Indoors

I decided before the game jam theme was even announced that I wanted to do a maze-like indoor environment. Like, spaceship corridors or something. Because I’d never done that before.

I’m glad I decided to try it because, this gave me a quick overview of what sorts of problems you can expect while making such an environment.

First off,

indoor levels look weird in a level editor

Repeat image from yesterday: this is my level as it appears in Unity’s editor. It’s… dizzying. You’re kind of outside the world, seeing inside things you shouldn’t be seeing inside, and I got rather confused trying to select things and lay them out properly.

i haven’t the foggiest idea how to light this thing

You can’t just slap a directional key light and a fill light on the scene and call it a day. This should have been obvious, but I didn’t think of that before deciding to do an indoor environment.

Well, I suppose I could have had fixed key and fill lights. I’m not much for naturalism, after all, and I would never accept realistic, flat indoor lighting as acceptable. I’m always going to want my lighting to be kind of contrasty and theatrical.

But my mechanics involved turning lights on and off, so I went with multiple point lights. In fact, every single tile has a light attached to it.

I’m sure that’s the absolute worst way to do this.

I considered just baking soft light into my textures, but sort of forgot about that idea as the gamejam wore on. Probably should have done that. My final build was really, really slow, and I’m sure a big part of that was my lighting.

you can’t see your destination

The goal of the game is to get to this one particular area on the upper right of the level. Which is totally not communicated to the player at all.

In an outdoor level, I’d have some big building or monument or whatever that looks interesting and worth going to. In the indoor level here, I wasn’t sure how to express where you were supposed to go, when you were making progress, or even where you were within the context of the level, since all the corridors look alike.

I thought maybe having collectible items here and there, just out of reach, would be the way to go — something just behind one of my transparent force fields, or at the other end of a chasm you can’t jump over — things that say, hey! you can’t go here now, but you’ll be able to eventually, and you will have made some progress through the game by doing so. I even had the locations for these things planned out, but never got around to modeling them and putting them in the game.

I think this approach has merit, but since I didn’t implement it I can’t say for certain what the challenges here would be or how effective it would have been.

tiles are nifty

This was my first foray into 3d tiles, and I like how modular everything is, how I could notice a bit where a puzzle was unsolvable and quickly rearrange my tiles so things were ok.

Trouble is, I made my tiles in this really inefficient way, fully completing and polishing a straight corridor tile before moving on to completing and polishing a T intersection, and finally completing and polishing an L-shaped corner. It certainly would have gone much faster if I had a more assembly line style workflow, like making all the walls at once, then all the railings at once, etc. I could go into a lot of technical detail about beveling and uv mapping, but suffice it to say that there’s a lot of efficiency to be gained by limiting how often you switch tasks.

My one-time-at-a-time approach was motivated largely by a desire to see a completed hallway made of straight corridor tiles as quickly as possible; it was motivated by being insecure and wanting to prove to myself that the quality of the tile set I would eventually produce would be acceptable. Which is silly. Finishing all the tiles was inevitable. I should have done it in the most efficient way possible.

Global Game Jam 2014 Post #1: Planning on Failure

My Global Game Jam 2014 entry is up, and I thought I’d spend a few posts talking about it.

First, I want to talk about failure. One great thing about game jams is, they’re a safe environment in which to fail, and I haven’t really been taking advantage of that. I’ve always been cautious, limiting the scope of my projects in past game jams.

But for this game jam, I rather deliberately set out to make a project that I was certain was outside of my abilities to finish. The question was not whether or not I would fail. The question was how I would fail, which is valuable knowledge to have.

And this the most important thing I’ve learned: at every game jam, and in other projects, you will have a feature you just can’t complete. Because you don’t have time, or the skills to do it, whatever. And… I handle this situation very poorly.

example #1: the embarrassment factor

I always try to compose music pieces with multiple layers that are dynamically mixed together at runtime based on the game state, but for this to work, the music has to play long enough that the player can listen to the music and get used to it before it changes on them, so they can realize something changed.

I tend to make only get around to making a minute or so of music for game jams, and while that’s unquestionably short, that’s not all of my problem.

The problem here is that I always try to hide my short, incomplete music cues because I don’t want to make it that obvious how little music there really is. Allowing my short cues to loop endlessly is the obvious solution here. People do it all the time.

example #2: the coolness factor

In an attempt to make my game tie in with the theme for the jam, I made these ghost things, these swirling vortices, and they were very pretty, well-realized vortices.

They made the game pretty much unplayable. As soon as you touched one, you died, and they were everywhere.

See all this level? You can’t get to a fraction of it most of the time.

I tried to solve this really quick after the jam by reducing the number of ghosts, but they still just sat there, blocking your path, and weren’t very fun.

A quick solution during the jam would have been to remove the ghosts entirely, but I didn’t want to do that because they were the only thing tying the game to the theme.

why the embarrassment factor and the coolness factor are actually the same thing

These are both symptomatic of the same root problem: when I have a feature that doesn’t work as expected, and a deadline is approaching, I start to make decisions based on whether I want people to see the work I did, rather than making decisions based on the feature’s effect on the game as a whole. And it enters this weird limbo state where I’m unable to fix it properly, unwilling to cut it, and uncomfortable with bringing it to the foreground and looking at it long enough to think of a decent stopgap solution.

I suppose there’s a certain amount of pride at work here. I want to fix these things without allowing myself to experience them in their broken state.

So that’s something I need to watch out for. In my next post, I’ll babble about some more mundane workflow type things.

Global Game Jam Goals

So there’s another game jam this weekend, and I thought I’d write up some goals.

And as I was writing, I thought to myself, it’s not about goals as in a desired destination as in having having successfully created a project with specific features at the end of the weekend. The goal is to learn. The end product is irrelevant. If I make something cool and fun, great, but the goal is always to learn.

Right now, there are some very specific things I need to learn to do better, and I’m more interested in constraints than goals right now.

So here are a handful constraints for myself:

I will work in an existing genre.

FPS, RTS, platformer, whatever seems most appropriate; I just don’t want to do my usual approach of finding an idea that fits the theme and then trying to invent the perfect mechanic that fits the idea. Instead, I want to concentrate on figuring out how to to add the right tweaks to the tropes of a well known genre to create something that feels fresh. I want, to some extent, to have experience fighting against my chosen mechanics.

I will not make procedural levels.

This is the most important one. Every one of my previous game jam entries has included procedural levels, and while it’s always an interesting challenge to write the code that writes those levels, I really, really need some experience doing more traditional level design and thinking about the overall structure of a game. I want to spend less time writing procedural level-building code and more time visually evaluating and editing levels in Unity’s level editor, learning about what makes a good level.

If there is music, it will be very minimal.

Instead, I’d like to concentrate on creating a sense of place and mood via sound effects. I could certainly use more practice with music composition, but I need even more practice with sound design.

Meeting my ideals may be beyond the scope of this project.

I’ve decided to change Operetta (or Spindle Sun, if you remember that) from 2D to 3D. Mostly because, if there aren’t, like, human characters involved, I’m much more comfortable making 3D models than 2D illustrations. And many of the troubles I’ve had getting this project off the ground have been related to the 2D graphics and interface.

So I started making a model for the spaceship you’ll be flying around. I really don’t like it.

Every time I try to design a spaceship, it seems it ends up looking like a Star Trek wannabe or a collection of random shapes.

And I think a big part of that is how small my toolbox is here. Tools are just development environments or new hardware. Tools can also be ideas.

When designing things, I have a toolbox of shapes: saucers, cylinders, Art Deco fans.

I’m comfortable with these shapes. I can get them to fit together in harmonious ways. And when I do, I get Star Trek or my usual Art Deco sort of aesthetic, which, honestly, I’m tired of.

But if I don’t use the tools I’m comfortable with, I get a mess, and that’s to be expected, I suppose. Getting comfortable with new shapes, learning how to use them in designs, will take time.

Having new tools is not enough. You need experience using them.

* * *

I’d like to make fun, exciting video games that don’t rely on combat to provide tension.

Combat in games is a known quantity. I have various tools with which to build a combat based game: levels designs and goals based on clearing areas of enemies. Randomly scattered ammo and health kits to keep the player moving. Life and magic bars that keep the player informed of their status.

Some of these tools will work for non-combat situations. Some will not. In any case, I need some new tools here.

* * *

Right now, all this is a bit paralyzing. The tools I’m most comfortable with to build Tinselfly are tools I’m unwilling to use. Even so, it can be much easier to use tools I don’t like than it is to force myself to abandon them and try new things.

With that in mind, I’d like to revisit Gemslinger, my gem-collection as arcade-shooter thing and see if I can get a minimal, workable product that’s fun and not based so much on killing monsters. I’d like to use this as an opportunity to expand my toolbox. Doing so here, with a small project, will hopefully make it easy to explore ideas that I can then apply to larger projects like Tinselfly.

My first few attempts to do this will undoubtedly fail. And by fail, I mean I may end up with something fun and polished… but which is more combat-based than I would like. And that’s ok. I need to fail before I can get better — I can’t just refuse to make anything with combat mechanics on the hopes that I’ll replace my entire toolset, all at once. I need to explore new ideas a little bit at a time so it’s not overwhelming and paralyzing, and that means a couple new, interesting ideas in products with mostly old, blow-up-monsters type ideas.

And maybe, just maybe, whatever I do after Tinselfly and Gemslinger and Operetta will have a higher proportion of new things made with my new tools, and a little less blowing up monsters.

And eventually I’ll get where I want to be. Eventually.

One Eighty

So I’ve been toying with the idea of including combat sequences in Tinselfly, a project that was once defined in my head as being absolutely bereft of violence. And I’ll get to that heel turn in a moment, but first I wanted to talk about cameras.

If there’s going to be action, I want it to be first-person action, and if it’s going to be first-person, there was this one niggling problem I wanted to solve, that pops up in every first-person game I’ve played: tunnel vision.

Humans have a nearly 180 degree field of vision horizontally. In contrast, a video game with a wide camera might give you 100 or 110 degrees, if I’m remembering things correctly.

I’d like to give you a wider field of vision than your typical game. If there’s a threat coming at you from the side, I want there to be a good chance that you’ll see it onscreen.

I’m shooting for 150 degrees here. So here’s a swiveling camera with a 150 degree field of view, and you can see why games generally don’t go this high.

There’s this really awkward pinching effect when you make standard video game cameras wide angle. Things on the edges look really distorted, and everything in the center looks farther away than it ought. This is what I’m trying to avoid.

The animation above uses what’s called a planar projection. A projection is the process of taking your 3d game world and figuring out how to translate that to a 2d medium, your screen.

In this illustration, you’ve got a camera, a point in the 3d game world, and a 2d rectangle sitting a fixed distance from the camera, onto which the point is drawn. You draw a line from the point to the camera lens, and wherever that points intersects the rectangle, that’s where it will be on screen.

But this is just one kind of projection. You know how there are different map projections? Like the one where Greenland is way bigger than it should be, and the one that looks kinda like a banana peel? They all express the same thing, but try to reduce distortion in different ways. You can totally do the same thing with video games, though I’ve rarely, if ever, seen it done.

My first idea was to go with a cylindrical projection.

This time, the camera is in the center of a cylinder. You figure out where your point-lens line intersects the cylinder, and then unwrap part of the cylinder so it’s flat like your computer screen.

So that looks like this. Same camera position, same 150 degree horizontal field of view, same 180 degree swivel:

This removes the edge distortion. Completely. So completely, in fact, that it doesn’t even look like you’re turning anymore. It looks like there’s this flat image scrolling sideways across your flat screen. Which, basically, is what’s happening. You’re just unwrapping and flattening a different part of your cylinder.

This isn’t quite what I want either — a little bit of distortion can be an important visual cue that you’re turning around in a 3d world, and I want to preserve that.

So I went for a hybrid solution — something between a planar projection and a cylindrical one. There’s still a cylinder, but the camera isn’t in the center of it. It’s sort of like a flattened cylinder.

And that looks like this:

I’m really, really happy with this. I think I’ve struck a good balance here between reducing distortion and preserving the visual cues you get when you’re turning around.

That having been said, there are a couple possible issues here:

This might cause some people to get motion sickness. Personally, I just don’t ever get motion sick, so I really don’t know.
It’s a burden on the computer, to produce this effect. I’ve got seven cameras in my scene, all writing to a different part of the screen. That doesn’t make the frame rate a seventh of what it used to be — it’s more like, I dunno, two thirds — but it’s still noticeable.
Also, since your field of view is wider, there’s more stuff to draw, further reducing the framerate.

I should probably just allow the user to set the field of view/ cylinderiness if they so wish.

* * *

So about that whole violence thing.

I’m not completely against violence in games. I’m ok with it if the violence is leveled against stylized spaceships or inanimate objects. And with the right approach, I’m willing to include violence in a more naturalistic setting:

Your targets must not be living things, or sentient things like thinking humanoid robots.
Winning a fight against a target must not have any intrinsic value, like showers of coins or experience points. The player must never be encouraged to pick a fight with a random bad guy because they’re behind on character advancement.
Winning a fight against a target must not destroy the target. (It may, however, temporarily disable the target.) The player must never be encouraged to see eradication of all targets as the long-term solution to the threats the targets represent.
To defeat a target permanently, the player must solve puzzles or do other non-violent things that cause the targets to do productive things instead of harmful things, or move them to a safe place.
Each target must present a specific threat to your community, or the game world. Being a mortal threat to the player is not enough. Said threat must express itself in terms of real mechanics, like targets blocking a path, disabling a piece of equipment belonging to the good guys, or enabling the use of equipment belonging to the bad guys.
Targets may never respawn unless it is made clear that respawning would naturally happen in a believable way in this universe.

Shooters are fun. Jumping on funny monsters and watching them fall off the screen in Super Mario Brothers is fun. Swinging your sword in Zelda is fun.

Point and click adventures are many things, but I’m not sure fun is one of them, generally speaking. And Tinselfly has mostly been defined as a high tech point and click adventure. I’ve been worrying about the fun factor.

I’ve been asking myself, can I have fun, action-based — dare I say it, violence-based — gameplay in Tinselfly that follows these rules above? And I think I found my solution within the TV show Supernatural.

* * *

Supernatural has this character Dean who’s a badass, shotgun-toting, Impala-driving, bacon cheeseburger devouring action hero who goes around ridding the world of nasty ghosts, among other things.

Here’s the deal:

Dean looks badass.
He carries guns.
He shoots ghosts.
He eventually defeats the ghosts, sending them to the afterlife where they belong.

And… Shooting the ghosts can never defeat them.

Now, Dean is not above outright murdering evil people if he thinks it’s for the greater good. But I just want to focus on the ghosts. Dean looks like a violent action hero, but the manner in which ghosts are defeated in his universe is (arguably) non-violent. To defeat a ghost, you have to find the bones of the dead person the ghost came from, and burn the bones. This usually involves lots of research trying to figure out who the ghost is, where they’re buried, who might have stolen the bones if the bones aren’t where they’re supposed to be, etc.

Research.

But, ya know, badass research.

The shotgun Dean carries around is loaded with salt. In this universe, throwing salt at a ghost causes it to disappear temporarily and stop bugging you — but the ghost will come back after being salted. A shotgun just delivers salt in an amusingly badass way.

And it works. I’m seven seasons into this show and just now realized that Dean is a shotgun-toting, ghost-destroying badass who doesn’t dispatch a single ghost with his shotgun. The shotgun is an affectation.

* * *

So I can give Robin a sword. She can temporarily disable mechanical baddies by destroying their shields, as described here. She can solve puzzles trying to figure out what’s controlling the baddies, and re-purpose them or send them to safe places where they will do no harm. Her mental state can affect her fighting, so this can mesh with the character-driven puzzles I want to include as well. And her fighting can affect her mental state, which could lead to more interesting character development.

Robin can look and feel like a sword-swinging badass, without ever running anyone through. And I think this can work, and I’m comfortable with this approach.

Gotta go design and model a mechanical baddie now.

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.

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:

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:

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.

Brian Crick

Category: Computer Games

Immediate Deresolution

Global Game Jam Post #4: This is the Jam that Never Ends

Global Game Jam 2014 Post #3: Trying for Once to Talk About Music

Global Game Jam 2014 Post #2: The Great Indoors

Global Game Jam 2014 Post #1: Planning on Failure

Global Game Jam Goals

Meeting my ideals may be beyond the scope of this project.

One Eighty

Postmortem: The Butterfly and the Beanstalk, Part 2

what went wrong

to sum up

What You See