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.

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.

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.

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.