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.