Conversation with an Industry Insider!

Dear My Adoring Public,

This past week, I had a conversation with my friend Zach Lome, who is awesome and a really cool guy.  He has also worked on Real Life video games in the past, and lent me his insight during a conversation we had recently.  I'm sharing that insight with you, My Adoring Public, both for your benefit and so that I can remember it later.  Cheers!

T:  OK, so I accept that I will have to start everything over at least six times on this project.  But what would you recommend I learn more about first, now that I have the game running?  Should I build more world, work on combat, make menus and items, set levels…  If the whole team had to work on one thing at a time, what would they tackle first?

Z:  The first thing to tackle in game design is just that:  the design of the game.  Step one, write down (no programming!) how you want the mechanics to work.  Step two, create tools that let you implement your design.  Step three, use your tools to generate the scenario the user interacts with.  Step four, figure out whether or not the mechanics you designed are fun and engaging.  If you write a lot of flexibility in your game engine, you should be able to tweak variables and info without having to do a lot of extra coding.

T:  OK, I wrote two pages in Word about what I want there to be buttons for and how to interact with things, so that’s at least a start on the design document.  Step two is where you lose me, I have no idea how to get started on the “create tools” part, but step three is exactly what I want to do to those tools and I can picture a sort of tech demo in my head.  I’ll worry about step four after I have something at all functional.  I guess right now I need a clearer idea of what actual work I’m going to be doing in step two, so I know how much detail to use in step one.  What should I be Googling?

Z:  [REDACTED FOR GOVERNMENT SECRETS.]

T:  HOT CHA!

Z:  doo hoo hoo,hello hello!  This will be much easier. I can type faster and [REDACTED FOR PUBLIC HEALTH BENEFIT.] <_<

T:  Rock, rock on.

Z:  okay so when I said 'make tools' that's really more of a build-from-the-ground-up thing. Since you're using RPG Maker that's sort of… done already.  the problem is, I've never used RPG Maker, so I'm not entirely certain how much flexibility it offers in terms of implementing what you want.

T:  rpgtoolkit, actually. Those are two distinct things, it turns out.  I was surprised.

Z:  ah

T:  But yeah, they got forums and everything. And I see from having done the quick-start tutorial what sorts of things there are to do, I just have no idea what part of the game I want to make more of first.  But for when I do eventually make my own game-making engine, that's what I would be doing? Basically coding a program that enables me to edit the game?

Z:  so the way I would suggest doing it is pretty much what I texted: first, figure out how you want the game to be played. Determine every individual action a player can take (pick up an item, drop an item, fight a monster, use an ability on a monster, defeat a monster, recover loot from a monster, talk to an npc, hit an npc, flee from battle, exist in a cutscene, etc.)  Split things up into distinct sections of functionality — don't worry about story or art or music, but consider whether or not you'll need to do particular things with story or art or music (do you want a certain sound effect to be able to play when a text box pops up? make sure you have some way to do that).  And then what I do is just go from easiest to hardest in terms of functionality implementation.  So the easiest is having a guy that walks around.  But to do that there's gotta be the map, so you need to be able to generate a map.  So once you can make a map you have the guy walk around on it… what does walking entail?  There has to be input from the controls, animation, and probably a sound effect  once you have all of those implemented look at how you can extend it — collision detection for instance.

T:  OK. Wow. Crazy. OK, so make more land, make more mans, make more stuffs, make more menus. Yeah, I got the animation and was able to work the controls.

Z:  What kind of things can the user collide into?  Is there a difference between colliding with a wall and colliding with an NPC?  What does an NPC detail?  Let things spiral out of control naturally.  :)  Always focus on functionality though. if you've got a good list of what you want things to end up looking like then you won't suffer from feature bloat.

T:  Right on. OK, well I won't [CENSORED FOR EXTREME OBSCENITY.], but you've given me a lot to work on and think about. Thanks for your help!

Z:  S'all good :)    It's a bit harder in some ways when you're using an already-written toolkit, because you're limited by what the toolkit can do.  But it's also easier because you don't have to know C++ or C# and you don't have to write your OWN toolkits :)  

T:  Right.  I’ll do that later.  For now, I want to learn somebody else’s tools so that I have better ideas when I build my own.

Full Disclosure:  I sent an email to Zach, asking the following:

Dear Zachary,May I post our conversation from the other day to my blog?  I shall redact the parts about [REDACTED FOR PARENTALLY EMBARRASSING INFORMATION].  Well, one of them.  I'll censor the [CENSORED FOR ABSURDLY SPECIFIC PORNOGRAPHY].  For adult content, you see.

He replied:

Oh, absolutely! Feel free to take any ramblings I have and reprint them. You have my explicit permission unless otherwise stated by me during the course of the conversation to repost anything I say.
Feel free to print this out, laminate it, and frame it. As you do.