Brian Crick

Blog

Regression

In the last few days, I have been working to finalize the details of my Tinselfly story. For the most part, it’s going well. I have many more concrete plans for scenes and puzzles and environments than I had before, and am generally feeling good about the story as a whole.

However, I’m having trouble with the beginning. It just doesn’t make a lot of sense, thematically.

* * *

In programming, a regression issue is where you update one part of your program, only to find out that your update broke something that was working previously.

It happens all the time, sadly. Most recently, an attempt I made to streamline the object interaction UI resulted in a broken action menu on certain objects.

Tinselfly’s story has some regression issues.

* * *

In an old version of the story, space-dwelling aliens lay eggs in the main star in humanity’s civilization. When the eggs hatch centuries later, the star collapses, giving up all its energy to millions upon millions of baby aliens who will live thousands of years each, growing up to build planet-sized megastructures humans could only dream of. To the aliens, humans are little more than bugs in a nest. The humans flee to another star system upon realizing what’s going to happen, and everything the humans built is lost.

At least, I think that’s how it went; that version of the story is well over a decade old.

The artwork I produced during this period was all meant to evoke a feeling of nostalgia and fragility and profound loss.

The player would start in the ruins of the old world, picking up some items of personal significance before the story proper–told in flashback–started.

The story changed, but the designs remained the same, and I was still planning on starting the player in floating ruins.

I just forgot why I was doing it.

* * *

Spoiler alert: human civilization isn’t demolished in the new story. It’s just not that bleak anymore. Sure, there’s a little bit of destruction. But it’s not exactly on a huge scale.

In many ways this is a good thing, which is probably why I changed the story in the first place: damaging something small of great personal significance to the protagonist will be far more affecting than obliterating whole planets.

So… I think I can keep the ruins. I think, thematically, it can still work and set the mood; there’s still a theme of loss going on here–a sort of loss of innocence, expressed via the loss of just a handful of structures in this world.

I think I just need to be more specific about what specifically is getting reduced to ruins here.

Thoughts on Star Trek: Discovery

I like Star Trek: Discovery.

But… I don’t love it. I really want to love it.

As with many other pieces of entertainment I’ve consumed lately, it’s taking real work to engage with the show on its own terms. Specifically, I’m having trouble with the long-format storytelling. I want my TV episodes to end. That doesn’t mean I only want happy endings and simplistic morals and the bridge crew telling jokes before the credits roll. It means I want each episode to feel like a story, not a sequence of events with no beginning or end.

My wife and niece have been watching some of the early-ish seasons of Supernatural and I’m really impressed with how many of those episodes feel like self-contained monster-of-the-week stories with emotionally satisfying endings, and move the whole-season arc along.

But.. I don’t get the impression Discovery is going for that approach. Most episodes just feel like… chapters in a book.

Which is ok I suppose, if the season as a whole ends up being a satisfying story when viewed as a whole. I’ve never felt like a whole-season-story arc was any more satisfying or interesting than my favorite self-contained tv episodes (A Series of Unfortunate Events and the one season of American Horror Story came close)… but I’m willing to entertain the possibility that if any show is going to sell me on long-form storytelling, it’s going to be Star Trek.

Bad Thumbnails

I don’t know what the player’s spacesuit in Tinselfly will look like.

It’s been bugging me. Real spacesuits are super bulky and wouldn’t feel right for this rather magical universe. Your typical video game space suit looks too militaristic and armored for this story. I don’t want my character in something skin-tight, and, oh–since the character could be spending the majority of the game in said spacesuit, I want something really iconic.

So I drew this wonky sketch to sort out my thoughts:

It’s not great, but I think I can work with this.

And when I say I drew this, I mean I had no idea what I was going to draw before drawing it. I drew a basic body shape, layered some clothing ideas over it, erased those, drew something new, erased bits of it, refined my drawing. I drew some loose-fitting pants at first, realized upon seeing them that I wouldn’t buy someone flying with slacks on, and changed them to tights. I drew stuff at random and did Google Image searches at random just to see how I would react to what I saw.

The design process happened almost entirely on a few square inches of paper and my web browser. Very little of the design process happened in my head. And little effort was given to making the drawing look good–the purpose of the drawing isn’t to look good. It’s to quickly explore ideas. I’m guessing that the more I accept that these drawings will look bad, the more useful they will be to me as a designer.

I don’t know how other designers work, but this was very, very different than my usual process. Usually, I try to come up with a clear idea in my head before drawing anything at all, and then I try to do a nice, detailed drawing.

But… I suspect that’s never going to work. I always find that frustrating, and I suspect it’s because, well, I have no mind’s eye that I’m aware of. (Seriously, I don’t, and only recently learned most people do, like this guy.) But I’ve trained myself to do design as if I do.

If I want to design something, I really need to just get to drawing.

And erasing.

And drawing some more.

My sketchbook is my mind’s eye. I should use it better.

* * *

The player in Tinselfly will be spending several hours in a strange, alien world. I have no idea what that looks like, either.

I Googled alien landscapes.

I want the alien world to feel a bit fairy tale, so I Googled mushroom forests.

I thought maybe building-sized mushrooms were both too on-the-nose and too Myst so I looked at crystals for a while.

I Googled crystal forests.

None of this was particularly helpful. Everything felt so… mundane. But I only realized that when looking at actual pictures. So I have come up with a new strategy. This place is supposed to be alien, right? So I’m gonna come up with a list of feelings I want the environment to evoke. I’m gonna come up with a list of technical requirements (like, will there be platforming?). And then, without thinking of landscapes or aliens at all, I’ll start drawing some abstract shapes that I think express those feelings and work mechanically. And I’ll build alien vegetation and rock formations and other scenery based on those shapes.

With any luck, by virtue of the process being so divorced from actual landscapes, I’ll come up with something truly alien and unique to this world.

 

Tinselfly: Post-GDEX Steps

So now that GDEX is over, it’s time to turn my attention to a Mini Maker Fair right here in Cleveland, next month.

As before, I have no desire to rush out features just for a demo–my goal is still to work on the transport-whirlwind that is the beginning of my game. Thankfully, I do have a variety of things to work on in the next four weeks, all related to that goal:

Add even more transportation links.

The sequence of events in the beginning of the game is supposed to be as follows:

  1. Start in the ruins of a city.
  2. Find a handheld VR-like game, and play it for a couple minutes.
  3. Take off the headset, and find yourself in a farmhouse instead of the ruins.
  4. Take a gondola from the farmhouse to a balloon.
  5. Take the balloon to an outer-space city.
  6. Take a wormhole from the city to another planet, collecting an inventory item there.
  7. Return to the outer-space city through the same wormhole.
  8. Watch a spaceship land on the docks at the outer-space city, and board it.
  9. Watch the floating city recede into the distance as the ship flies off with you on it.

All of this involves insanely complicated behind-the-scenes level and camera juggling to make the transitions seamless, like you’re really traveling, but 1, 2, 3, and 5 are basically done (though 1 clearly needs some cleanup, having watched people play it at GDEX, and 5 has a couple visual hiccups that irk me).

might be able to knock out 4 or 6 in the next four and a half weeks. 6 would be especially satisfying for me since I love the idea of walking through a wormhole, and it would probably be memorable for players. And I’m pretty sure I can implement it quickly. However, that would require me to model your destination, and have it be of a similar level of quality as my existing environments… I would need a very clear, specific idea of what that area will look like in the next couple days to knock that out in time.

Even if I can’t make that area in this time frame, it still makes sense for me to quickly come up with a design so I’m not wasting too much of my time on it.

2 would, surprisingly, be harder to implement… though it doesn’t add that much to the overall ‘feel’ of the demo: you’ll just spend an extra 10 seconds riding on a swinging car. And, again, I need to do lots of modeling: the gondola, cables holding it up, and the station it goes to.

Fix bugs.

I should, of course, start fixing all the bugs I found at GDEX. Having better gamepad support is probably the best, quickest thing I can do towards making the beginning more playable. Fixing the swordfighting would ease the awkwardness of having to tell everybody, well, this part is a bit wonky but I’ll guide you through it.

Make it feel right.

I can also focus on the storytelling aspects of Tinselfly. Specifically, I can:

  1. Continue cementing details in my whole-game story outline.
  2. Make my first few minutes feel more like the beginning of a story and less like a tech demo.

Like the bugs, I’ll probably be doing 1 no matter what. But 2… 2 is interesting.

See, I don’t know what my game feels like yet. I can talk about how I want it to feel, how I want the puzzles and environment traversal to do all the storytelling, I can talk about my approach… but it’s not something I’ve experienced myself, and it’s not something I’ve ever tested with others. If I can start on 2, it will greatly ease future work, as I’ll have a more concrete sense of how other scenes might play out and need to be designed.

I’m kind of leaning towards concentrating on this, with little bits of everything else: the more varied my work plans are, the more efficiently I’ll work, so it behooves me to try to look at everything I’ve listed here, if only for a short time.

And hopefully by the Mini Maker Fair I’ll have a better sense of what this project is all about–which is great for me and my audience.

GDEX 2017 Wrap Up

…or, How I Learned to Stop Worrying and Love My Buggy Demo.

I was really reluctant to go to GDEX and demo Tinselfly this year.

My swordfighting demo–which I’d been showing basically unaltered for the last couple years–was in significantly worse shape than it was at last year’s GDEX, the last time I’d demoed my game. I’ve been busy rebuilding big pieces of Tinselfly to be more maintainable and efficient, and the demo broke because I completely ditched a couple different third-party tools it was running on… and I never fixed it.

I bailed on MatsuriCon because I had no demo.

I bailed on IngenuityFest because I had no demo.

I seriously considered bailing on GDEX.

See, my demo wasn’t really part of my game proper. It was a standalone thing I threw together for some expo years ago just to show my sword fighting mechanic. And the more I worked on it, the more I wasn’t working on finishing real game levels that would be in my final product. It pained me to miss out on MatsuriCon and Ingenuty, but I just couldn’t justify fixing the demo. I needed to move the project forward.

So about a week before GDEX, I decided I’d just have a gameplay-light demo and show what I’ve got so far with the beginning of my game.

Transportation is a big part of the world and story of Tinselfly. You work in a shipbuilding town. The plot revolves around the decline of the shipbuilding industry due to new transportation technologies. Your character loves spaceships and the idea of space travel.

So the beginning of my game is all about transport: you’re supposed to start playing a game-in-the-game, stop playing and wander your childhood home, take a gondola to a balloon, take the balloon to a floating city, walk through a wormhole to a bazaar on another planet, jump back through the wormhole, board a big spaceship and fly off–with no loading screens, all in the first 10 minutes of play. A veritable whirlwind of transport.

The opening scene as designed would really be the perfect demo for showing off the environments I’ve built for my game — and I was much of the way there. I figured I could get just one more of those transitions working in time for GDEX — and I did, the morning of.

There was very little traditional gameplay. You could wander, you could pick up a few objects and hear your character comment on a few others, but the gameplay was limited to a rather old, rather buggy first pass at rewriting my old sword fighting stuff.

And this was a good thing.

* * *

From a logistics standpoint, things went great this year. This was the first year I brought an external monitor and gamepad, so that visitors wouldn’t see my laptop–it was more inviting than just having a laptop sitting on a table.

This also allowed me, behind my table, to see what the player was seeing, as the external monitor and laptop screen were showing the same thing.

Sadly, my gamepad support was terrible; the game is really designed for keyboard and mouse. But I was able to walk everybody through the most unintuitive bits of my interface.

* * *

I wandered around the expo floor a lot more than I did in expos past. Sure, that meant abandoning my demo for long stretches of time, but I’m really glad I did it. Seeing the creativity of other people’s works, feeling their enthusiasm, learning from them… that’s in many ways more important than showing off my own stuff.

I probably wouldn’t have tried wandering so much at the beginning of the expo if I thought my own demo was any good to begin with.

* * *

Tinselfly was never supposed to be about the unique visual sword fighting mechanic. I only concentrated on it first because, well, it was easy to talk about and demo and point at and say hey! this is what makes my game unique.

But Tinselfly is really about telling a story in a fun, unique way that relies neither on cutscenes nor static environmental details. And my level designs are supposed to be a big part of that. The transitions from location to location are a big part of that. This is what makes me excited about Tinselfly.

So in not having a particularly robust sword fighting demo, I was free to talk to players about what really excited me about the project. And I think my excitement showed. Players at this year’s GDEX seemed a lot more engaged, asked a lot more questions, and stayed longer at my demo than they have in the past.

On Sunday morning a highschooler was trying to tell me he thought my game felt like it could be ‘more’ than other games when it was done: more than the sum of its parts, perhaps.

I think that was the best compliment I’ve ever gotten at a demo.

Hiking

Been feeling pretty fried lately. In less than a week, I’ll be demoing Tinselfly–or maybe Gemslinger, insteadat GDEX, a video game expo in Columbus.

I’ve very deliberately not been rushing to get a demo of either project out. I’ve kind of learned the hard way that working too much on demos always ends up complicating real work that will move me closer toward finishing these projects.

So I’m focusing on doing exactly what I’d do if the expo weren’t coming up: solidifying my project plans, figuring out what exactly I need to be working on next.

I’m just doing all this… a little faster than usual. I’m still rushing.

* * *

Been having trouble the last few years finding a game I find really interesting and memorable. Sure, I love playing well-produced arcadey titles like Tron Run/R and Pac-Man Championship Edition, but they’re sort of like junk food. Delicious, wonderful, quick hits of junk food… but I’m yearning for a nice multi-course meal.

I don’t do a whole lot of things you’d call relaxing. I stress out about having fun, so frequently I don’t try.

I’m impatient to get to the fun part in any game. So I’d been going through some old games I bought and could never really got into: Arkham City, Mass Effect 3… wondering if I just bailed, in my impatience, before I’d gotten to the fun part.

Maybe I’m looking at this all wrong.

* * *

The first game I really loved was the original Myst. I couldn’t tell you why; with my memory as spotty as it is, whys always elude me. But I can tell you whats. What I loved was Myst.

My own work frequently gets comparisons to Myst games: and visually, I can certainly see that. But there’s certainly more to it than that, more than I consciously know. Myst is undeniably a core part of how I think of game design, but it’s maddening sometimes because I couldn’t tell you what that means.

* * *

I’ve done a couple 5k runs and one 5-miler, but I’m not really a trained runner. I’m not particularly fit (despite being rather thin).

Still, most of us can just decide to run and we run. We can decide to sprint and we sprint. After a little bit of practice, we get a feel for what speed we need to go at if we want to maintain that speed for such-and-such a distance. I’m confident I can walk several miles without issue; I can jog two or three miles; I can run one; I can sprint for about fifty feet before having to stop and rest.

Obviously, we don’t go everywhere at top speed; that would be absurd. But there are times when it’s fun, and times when it’s useful.

* * *

Been playing Obduction lately. I played it when it first came out, got frustrated, and now I’m back.

If you haven’t heard of it, Obduction is the latest game from the creators of the Myst series. You wander around vast, alien, beautiful, largely unpopulated environments, fixing broken machines and just soaking in the ambience everywhere.

And when I say these environments are vast, I really mean it. There’s a lot of just walking from place to place. My wife saw me playing as said the game looked like a hiking simulation.

That seems pretty accurate. I have no patience for hiking.

Sometimes I drop games and come back to them with a burning desire to just get them done, to tie up that loose end and move on. That’s not what I’m doing here.

I’m trying to play Obduction in the spirit in which it was, I think, intended. I’m making maps and taking notes. I’m reading all the way through lots of journals and meditating over little visual storytelling details here and there. I’m walking from place to place and trying not to be annoyed at how long it takes to get from place to place.

I’m taking it slow. And you know what? I’m enjoying it a lot more now. I think it’s supposed to be a little slow. This is, in many ways, the fun I have been looking for, for so long. It’s not a longer version of the quick-hit arcade games I’m used to playing; my definition of fun evidently doesn’t scale that way. It’s meditative and relaxing and fun, if I’ll let it be that way.

* * *

Lately, I’ve been working on Tinselfly at a rate I can only describe as a run. I decide to think faster and I think faster.

This pace is not sustainable indefinitely… but I’m confident it’s sustainable until GDEX.

I’ll probably jump into a sprint the day before GDEX starts. That’s the way these things typically go. And that’s fine.

But once GDEX is over, I need to slow down my thoughts again. This is not a sprint. This isn’t even a marathon.

This is hiking.

Structured Dialogue

Chances are, I will not be writing the dialogue for Tinselfly, or any of my other games, for that matter. My wife, dialogue-writer-extraordinaire, will be fielding that.

Still, I think it behooves me to learn about dialogue writing, if only to figure out what I’d want, ideally. And I think what I want is dialogue like this one Doctor Who scene.

CLARA

So you actually live up here, on a cloud, in a box?

DOCTOR

I have done for a long time now.

CLARA

Blimey! You really know how to sulk, don’t you?

DOCTOR

I’m not sulking.

CLARA

You live in a box.

DOCTOR

That’s no more a box than you are a governess.

CLARA

Oh, spoken like a man! You know, you’re the same as all the rest: “Sweet little Clara, works at the Rose and Crown, ideas above their station”. Well, for your information, I’m not sweet on the inside, and I’m certainly not —

Clara walks into the Tardis and the Doctor turns the lights on.

CLARA

— little.

DOCTOR

It’s called the Tardis. It can travel anywhere in time and space. And it’s mine.

CLARA

It’s… look at it…

DOCTOR

Go on, say it. Most people do.

Clara runs around the outside of the Tardis.

CLARA

It’s smaller on the outside.

DOCTOR

Okay. That is a first.

CLARA

Is it magic? Is it a machine?

DOCTOR

It’s a ship.

CLARA

A ship?

DOCTOR

Best ship in the universe.

CLARA

Is there a kitchen?

DOCTOR

Another first.

CLARA

I don’t know why I asked that; it’s just… I like making souffles.

DOCTOR

Souffles?

CLARA

Why are you showing me all this?

DOCTOR

You followed me, remember? I didn’t invite you.

CLARA

You’re nearly a foot taller than I am. You could have reached the ladder without this. You took it for me. Why?

DOCTOR

I never know why. I only know who.

CLARA

What is this?

DOCTOR

Me. Giving in.

CLARA

I don’t know why I’m crying.

DOCTOR

I do. Remember this. Remember this, right now, all of it. Because this is the day. This is the day! This is the day everything begins!

So if I want dialogue like this, I need to tear it apart and figure out what makes it tick.

Structure

The most obvious thing is… there is nothing naturalistic about it. It’s very carefully paced and structured, and it’s as much about the repetition of certain words and phrases as it is about the meaning of the words themselves.

In songs and poetry, we talk about rhyming schemes and structures, like, this song has an ABABCB structure where A is the verse, B is the chorus, and C is a bridge.

  • Consider the first six lines: the words ‘box’ and ‘sulk’ form a sort of A-B-C-C-A-A structure: box-time-sulk-sulk-box-box.
  • The exchange from Okay, that is a first to another first is also highly structured and repetitive: first is of course used twice, ship three times in rapid succession, and the Is it magic? Is it a machine?… It’s a ship bit is almost like It’s a bird! It’s a plane! No, it’s Superman! in its rhythm.

 

Double Meanings

  • When the Doctor says That’s no more a box than you are a governess, he’s pretty much explicity saying there’s more to Clara than she’s letting on, just as the Tardis is small on the outside and bigger on the inside.
  • Back to Clara saying I’m not sweet on the inside, and I’m certainly not little: the line is also as much about the Tardis as it is about Clara.
  • Previous watchers of the show will know when Clara says the word souffle, that single word is packed with meaning.

 

Odd Transitions / Subverting Expectations

Jumping from subject to subject keeps the audience on their toes.

  • When Clara walks in the Tardis, she doesn’t ask what’s going on. The dialogue just goes straight from Clara protesting I’m not sweet on the inside, and I’m certainly not little to the Doctor interjecting It’s called the Tardis. Makes the exchange punchier, I think. The what is this? question is implied.
  • Anyone familiar with Doctor Who will expect Clara to say it’s bigger on the inside, just as the Doctor himself expects her to say it. But instead, she flips that common phrase around to it’s smaller on the outside.
  • When Clara asks about the kitchen, it’s quite unexpected — but it’s doesn’t lead to a discussion of souffles. As soon as the Doctor realizes something is wrong, the conversation switches to Clara asking why she’s been led here.

 

Not Answering Questions

Questions are rarely answered directly.

  • The Doctor doesn’t say if there’s a kitchen.
  • Clara doesn’t respond when the Doctor questions her about souffles.
  • When Clara asks why are you showing me all this?, the Doctor turns the question back on Clara.
  • When Clara asks about the ladder, the Doctor answers a different question.
  • When Clara asks what the Doctor’s key is for, the Doctor responds by talking about himself.

 

Overall

Overall, I think I’d say that this style of dialogue is all about favoring thematic flow over conversational flow. Every unanswered question and every odd transition makes sense if you look at the themes of the answer in relation to the themes of the question. It’s like subtext? But it’s not about what the characters are thinking so much as the narrative intent.

Copycat

My latest practice drawing is done: the Enterprise from the old Star Trek movies.

I’ve drawn this ship many, many times. Mostly in grade school and high school while bored. I don’t have any of those old drawings around anymore, but I suspect this is my best rendition of it.

Part of that, I hope, is that I’m simply getting better at drawing things like this.

But part of it is probably also that I had access to a lot of reference material online, resources I didn’t have access to as a kid. I studied my subject very closely, more closely than I ever had before.

* * *

I think I saw my first vector-drawing program in 1989. The Michael Keaton Batman had just come out, the drawing program has a quarter-ellipse drawing tool, and so the first vector art I ever made was the Batman logo, made of nothing but straight lines and quarter-ellipses.

Later on, I would reproduce logos as a way of learning whatever new vector drawing programs I found. And when I discovered 3d modeling, I modeled the starship Enterprise.

I’ve made the Enterprise in Alias Sketch, AutoCad, TrueSpace, 3DS Max, Blender, Strata 3D, and even a custom modeling program I once worked on.

I’ve drawn the Enterprise on paper more times than I can count.

And this work has no value. None at all. It never occurred to me, while making these copies of logos and spaceships that I might want to spend my time producing work that had value. I was just learning.

* * *

I tried drawing many of the details of the Enterprise above from memory… and I could never do it. I always got something dramatically wrong. You’d think, after so many times drawing this, I’d be able to just do it… but to my surprise, I can’t.

I forget if I’ve mentioned it here before, but I cannot make pictures in my head. I only recently discovered that other people can. For a great overview of what it’s like to realize that, check out this Facebook post from Blake Ross.

I have no desire to dwell on it; I don’t see it as a huge limitation or disability or anything. But it does behoove me to keep it in mind — for example, I’m reading articles about learning to draw or write or compose music and the instructor mentions a technique involving visualizing something in your head, I’m going to have to remember to find a different strategy.

When drawing, I may need visual references more than most illustrators — even if those visual references are sketches I myself made. If I’m designing something, rather than just copying, I should keep my initial quarter-sized thumbnails around when making notecard-sized sketches. And keep those sketches around when making full renderings filling a page. I can’t keep my initial design explorations in my head, so I need to keep them somewhere out of my head.

* * *

For whatever reason, it never occurred to me to take this copying-things approach with music composition, not until yesterday. I have always been trying to learn to compose music by producing music for games. I decided last night it’s time to take a step back. It’s time to copy things.

So last night, I got to work reproducing this one track from Tomorrowland. After an hour, I had one measure. Which was incomplete. It was kind of stunning, how little I got done. My problem wasn’t writing; my problem was listening.

I can’t identify the instruments being used in the piece.

There are these frenetic arpeggios in the beginning and I can’t place all the notes.

My music composition software offers portato, marcato, and martele strings, but I have no idea what these styles sound like in real music.

Taking a further step back, it’s time to listen more. Not just listen to pieces and understand the melodies, but listen to the sound and learn how to deconstruct what’s going into any particular sound.

This is going to take a lot of willpower to do. I know me. I have a few things I’ve composed that I like, and I know that I’ll resent having to go back to the basics here because I can already do things. But doing isn’t my problem right now. Knowing is.

I can do things without really knowing what I’m doing, and that’s not good.

Staying on Track

A month ago, I came up with a system to improve my productivity, a variation of something I used years ago, that seemed to work quite well, though I kept… not using the system. But thankfully, the new variation has been extraordinarily useful and seems to be sticking. So I thought I’d share. It all revolves around a giant sticky note on my desktop, which at present, looks like this:

Before I get into how and why this is structured the way this is, it must be understood that the whole thing is built around the fact that my memory is very, very bad. If I do not work on Tinselfly for a week, I will forget what I was working on last. If I do not work on Tinselfly for a month, I will forget I ever worked on it. And if I’m not constantly reminded that I came up with a system to make me more productive, I will not use my own system.

With that in mind, my goals were to come up with a system that:

  • I wouldn’t forget to use.
  • Was error tolerant.
  • Had very little overhead.
  • Encouraged me to practice and improve my skills generally.
  • Made sure I made progress on specific projects.
  • Encouraged me to reflect on my progress from time to time.

 

So here’s how it works:

Every time I open my computer, I see this sticky note. It’s actually kind of hard to hide. Projects are listed in bold, with tasks indented underneath them. Whatever project I need to work on next has a * in front of it. Yeah, Blog has a * in front of it right now, so I’m blogging.

When I sit down, I work on the *’ed project. If, for whatever reason, I can’t — forgot to bring headphones to the coffee shop and can’t do video tutorials or I’m having software issues — I’ll put a * after the project name to remind myself to try to squeeze it in later, and move on to the next project. So right now, I’m behind on Play — I’m having trouble getting Metroid Prime running on my Wii.

So I’ll work for at least half an hour and at most a full hour, and then move the * to the next item in the list. Rinse, repeat.

(Not all the ‘projects’ are projects really — some are just general activity guidelines, and those are in square brackets.)

If I follow my own rules, this usually works well. But that’s a big if.

* * *

My biggest problem is following my own time constraints. With that in mind, I’ve gotten a simple timer app where I can type in a time limit and I see a progress bar showing how much time I have left right on my taskbar. It opens when Windows starts up and is visible at all times, which, again, is super important, because I’ll forget to use it.

As I write this, I’m running out of time on Blogging. 😉

That has really helped me remember that I have time limits.

My second biggest problem right now is burnout: when I came up with my rules, I wasn’t getting much done at all and the idea of burnout was the farthest thing from my mind. So in many ways, this is a good problem to have.

I think the proper solution to that is to take breaks between tasks. The way I’m working right now, as soon as my time’s up I excitedly update my sticky note, move onto my next project and restart the timer.

I will instead try setting the timer to some fixed amount, like five minutes, and use that time to… not do much. Or at least not much that’s project related. Check mail. Catch up on social media. Do housework. Getting away from the computer would be good.

I’ll try that for a while and see if it helps.

Catch ’em All

I love sets of things. On some level, perhaps we all do.

When I was growing up, my family had those Time-Life book collections. 23 books talking about the history of flight. 20 books about different countries of the world. 20 volumes on astronomy. Every now and then, we would get a new book in one of these sets in the mail, and excitedly add the book to its collection. I remember scouring flea markets many weekends with my dad, trying to find the last few records in some Time-Life music collection we’d gotten used. Our set was incomplete.

This could not stand.

Sets are fun. Sometimes, it’s infuriatingly difficult to know when you’re done with something. You wonder if you’re definition of complete isn’t complete enough. You want to add one more thing. You worry that there might be something out there you need, something that you don’t know you don’t know exists. But with well-defined sets… you know what you’re missing. You know what to look for. Most importantly, you know when you’re done. And it’s just such a satisfying feeling to know that, finally, something of yours is complete. Finished. And you can move on with your life.

I have started thinking about game developments in terms of set collection.

* * *

My still-in-development Global Game Jam game is all about finding new ways to traverse a world that doesn’t make walking from place to place very easy. So my first job, as I saw it, was to design a complete set of power-ups that let you move in new ways. I will know if my set is complete if you ways ways to:

Move, laterally, farther than normal, across chasms.

Jump up higher than normal.

Fall down greater distances without dying.

Move through things you couldn’t move through before.

Walk on things that were once hazardous to touch.

Skirt around and below things that were once dangerous to approach.

In very general terms — if you think in terms of what axes you can move on and where hazards are in relation to you — there are a finite number of ways one can move around one’s environment. I will know I have a workable, complete set of player upgrades if my upgrades cover all of these movement cases. And once I have those upgrades designed, I will be able to move on — because at that point, I will be done. And while I may tweak my upgrades throughout the development of this game, I will feel confident knowing that the vast majority of my conceptual work is done. I finished my set.

* * *

My wife recently alerted me to a simple approach to figuring out what scenes you need in your story:

Write down every major character, setting and concept in your story, in a big circle:

Then connect all of them.

Every one of those lines is a possible scene.

Write a scene developing Rey and Kylo’s relationship.

Write something exploring what Finn thinks about this whole Force thing.

Write a scene showing how Poe and Finn meet.

Write scenes with each of the characters doing something interesting in or around Starkiller Base.

Once you have scenes for each of those lines, each of those relationships, you have a good start of a story. You have a complete set.

* * *

I am working on a board game where you wander around a fantasy world exploring fun and interesting locations. I’ve been having the hardest time figuring out what those locations should be. So I forced myself to think about it in terms of set collection.

I made a list of everything I wanted the players to be able to do in the game, in general: they should be able to find clues about the main plot somewhere. They should be able to buy and sell items somewhere. They should be able to heal up somewhere, and investigate suspicious characters somewhere.

I ended up with some 15 items: a complete set of things I wanted players to be able to do. Then I shuffled them and put them in groups of three. No matter what ended up in what group, my groups would represent a complete set. Each group would become one location. Some of them were… odd.

What kind of place would you go to heal up, sell your old gear, and get clues about the main plot?

I don’t know, but that sounds like a really interesting place.

* * *

I tend to express my design requirements in terms of feelings. I want my players to feel like they’re excitedly exploring a fantastic world. I want my players to feel nostalgia. I want my players to feel like they can fly.

This doesn’t really help me find the specifics I need to do real development work.

Expressing my requirements in terms of sets has been immensely helpful. I have a specific destination: a filled bucket. I know what I’ve done towards reaching that destination: what’s in my bucket. I know what I have left to do: the empty slots in the bucket.

The bucket is filled, or it isn’t. I’m done, or I’m not. I have real requirements with concrete, measurable criteria for completion.

And if it’s not measurable, it doesn’t exist.

Copyright © 2017 Brian Crick.