Thesis: It Plays Great, I Promise

Sometimes you have a great-looking prototype that sells itself.

Sometimes . . . you’ve got this.

screen-shot-2016-10-14-at-11-03-29-pm

Advertisement

Prototyping: Online Resources

I use the same sites over and over in my prototypes, and while I credit individual contributors there’s rarely a chance to mention the sites as a whole. Let’s rectify that here.

Freesound.org is a great resource for sound effects. It’ll rarely have exactly what you want, but it probably has something close enough to be worth editing into the right form.

If you’re looking for music rather than effects, the Free Music Archive is just the ticket. Aesthetic preferences make it harder, in my experience, to find “just right” music than SFX–and of course, editing music is more difficult as well. Nevertheless, it’s a valuable resource.

Art isn’t trivial to come by, but I get a lot of use out of Game-icons.net. Easy-to-parse and attractive is what I want for prototypes.

When it’s time to use colors (e.g., for layouts), Adobe has a database of attractive color swatches. Their tool for automatically applying color theory is remarkable, too.

Font Squirrel has become my go-to site for typographical assistance. It gets bonus points for making it easy to tell up front how the different fonts are licensed.

All of these sites have been very helpful to me. I highly recommend giving them a look; I expect you’ll find them the same.

Inquiring Minds Want to Know

OK, Unity question:

What is the actual mathematical relationship between the scale of a parent object and the local position of a child object? It doesn’t seem to be 1-1; if the scale of the parent increases by 10%, the child object’s local position doesn’t reliably increase 10%. Anybody know what the equation is?

Theory: Maintain a Changelog

Long projects have a way of getting away from you. It’s hard to keep track of everything you’ve done, and it’s especially difficult to remember why you did it. Those times are the reason to keep a changelog.

You might have heard of a changelog in the context of programming. If you haven’t, it’s just a list of what you did for each version of your game/program/whatever. “Version 3–Reduced player chits from three to two, increased food to five units/player” is a perfectly good changelog entry.

Just doing that much will be a big help to your design. If nothing else, it will help you reverse course when something goes wrong (and I guarantee you, things will go wrong). A summary of what changed from version to version makes it easy to undo changes and get back to a version of the game that worked.

To get even more value out of your changelog, include a brief statement of why you did it. “Reduced player chits from three to two to avoid stalemates” is a short statement, but it allows you to reverse course selectively. If you’re still having a problem with stalemates, you can undo just the change that was meant to deal with them and try something else. If you’re happy with the stalemate situation but something else is wrong, you can roll back everything else.

Adding that extra detail to your changelog will also keep you from making stupid mistakes (of a sort, I will admit, I’ve made 😉 ). It’s very easy to forget which changes responded to which problems. You can very easily undo or modify a change that you need to keep, simply because you’ve forgotten what it was doing for you. Being able to quickly reference the changelog and say “wait, this thing that’s about to be altered is doing important work” can save a lot of time going down blind alleys.

For an example of a good changelog for a tabletop game, check out the one Mantic Games just put up for its Warpath rules. Most changes include a specific statement of why the change was made, so it’s clear which ones are safe to fiddle with and which ones aren’t.

(Disclaimer: I’m a backer for the current Warpath kickstarter, but only for about $20 to get a couple of specific models to use for other games. I don’t need more stretch goals met. ;))

Keeping this sort of changelog is the kind of thing that will take a few minutes each design/playtest session, and will save you hours of completely unnecessary design/playtest sessions. I can’t recommend it enough.

Theory: Coding Lessons Learned the Hard Way

  • If you can’t say with certainty how many times a loop is going to run, it’s going to cause crashes.
  • There’s a limit to how many statements can be nested before code becomes unreadable. A three-deep nest is OK. Five deep is a lot. Seven is begging for errors.
  • Comment every function with, at the least, a brief statement of what it’s meant to do and what its arguments are.
  • Javascript will let you get away with anything. That doesn’t mean you should feel free to do everything. Stick to good form; it might not be interesting, but it will only break in relatively predictable ways.
  • Learn coding best practices, and force yourself to use them. Formatting, good use of functions, even proper variable naming–all of these will save you time in the long run.
  • “If you’ve only backed up in one place, you haven’t backed up.”
  • Don’t set code aside for too long; you’ll forget how it all hangs together, and lose time working back through it from scratch. Keep it current in your mind.
  • On the flip side, don’t beat your head against a wall. If you haven’t solved a problem over the course of a few hours’ work you’re not going to solve it in that session. Do something else for a while.
  • Coding involves working on the computer, and that can be distracting–not least because you’ve probably already got a browser window open to look at Stack Exchange or documentation. Be rigorous with yourself about not doing fun stuff when you should be working.
  • As a game designer you can solve technical problems in two ways: the technical route and the design route. If a technical problem is proving unmanageable, put your design skills to good use. Find a way to change the game so that it’s in line with your technical skills.

Link: GameMaker Humble Bundle

After Wednesday’s post it might seem weird that I’m linking to the GameMaker Humble Bundle. However, the product on offer here is different from Super Mario Maker in three key respects:

1. GameMaker is a proper engine, not just a level editor. Even if you start from the position that level editors are subject to limitations, GameMaker doesn’t suffer from them.

2. GameMaker is great for beginners. The strength of GameMaker is that it’s simple enough to learn quickly, while still being powerful enough that you can make some engaging stuff with it. I’ve heard of academic game design programs that use GameMaker as part of their introductory curriculum, and I can understand why it’s their choice. If you’re at an introductory stage, GameMaker is a good option.

3. The bundle includes source code. Although GameMaker is as accessible as a serious engine can be, it still involves programming–and that can be a real hurdle to clear. Having solid, working code to start from is a tremendous benefit to those new to programming, and easily makes the higher tiers of the bundle worthwhile.

I’ve only used GameMaker briefly, but I’ve been impressed with what I’ve seen. I think you’ll be more than satisfied with what you get for $12.

Build a Prototype! Right Now!

Since you’re reading this blog, I’m betting you have a game knocking around in your head. I want you to go prototype it, right now. Not later, not Sunday afternoon, not next week. Right now.

The fact is that some problems won’t be identified at the theory stage. It shouldn’t be so, but it is, every time. None of us are so good at envisioning how a game works that we can see all the permutations that will emerge during play.

So too, some really neat elements that deserve to be expanded on won’t be found just by thinking a game through. Fun is, in part, a matter of aesthetics and experience. It’s not easy to predict where people will find it.

You might be thinking that your game is too complicated to prototype. I guarantee you that it is not. Figure out what the bare minimum elements of the game are—the absolute fewest things you need to get through the simplest possible turn. Mock those up and start.

Is the game intended to be digital? That’s fine. Put together a paper version anyway. It’s faster, and easier to make changes. Code has a way of locking you in that 3” x 5” cards don’t.

Playtesting isn’t just important for refining a game. It’s important for discovering what the game is going to be in the first place. Build the prototype and start making progress.

In the Lab: Building With 3×5 Cards

Just as some examples of what building with 3×5 cards can do:

IMG_0324

A simple structure. Note that the slight differences in the shape of the cylinders allow them to stack just like solid blocks would. In addition, it’s possible to build high even with fairly shaky architecture.

IMG_0325

There’s no need, however, to be content with poor architectural design. This tower is quite stable; the cards are light, but everything is balanced and supported.

IMG_0330

It’s even possible to be a bit fancy while retaining structural strength. The bottom of this tower has fewer parts than the top, but there’s enough weight to keep it together. It survived for quite some time just sitting on the rug while I walked around.

A side benefit of building towers out of 3×5 card “blocks” is that they fall without making a tremendous racket or (assuming they’re used in a reasonable way) causing any damage. New parents playing Jenga will wake up a sleeping child when the game ends; card “blocks” fall with a sound like, well, rustling paper.

3×5 cards can also be written on to create marked blocks. That isn’t an option with when dealing with nice wood. 😉

Ultimately the neat thing about 3×5 cards isn’t that they’re ideal for any one purpose; it’s that they can be put to a multitude of uses–some of which don’t look very much like traditional applications of a card. Every time I need to prototype they’re the first tool I turn to, and they rarely prove unsuitable. I can’t say it enough: keep 3×5 cards handy. They’ll work more often than you think they will.

In the Lab Again

Administration relating to starting at NYU has taken up a lot of time recently, but yesterday and today I’ve finally been able to set some time aside to sit down and design. I’m glad of that, because I’ve had an idea I’m keen to try out.

This idea happens to involve blocks–lots of them, in various shapes. I don’t have blocks in my home, though, and I wasn’t excited about purchasing them just to test an idea that might not work. So, what to do?

The answer, as always, was: 3×5 cards.

It turns out that 3×5 cards keep their shape when folded, so long as one applies a bit of tape. Furthermore, they don’t have the natural curve that paper does. A 3×5 card folded into a box stays a box, with flat sides suitable for stacking.

I know I’ve said it before, but it bears repeating: don’t ever let a lack of prototyping materials stop you from pursuing a design. Prototyping doesn’t have to be complicated, and it certainly doesn’t have to be expensive. Dollar store supplies are plenty for a first run of a new concept.