Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts

Saturday, July 6, 2013

Why Every Aspiring Game Designer should DM



All video game RPGs have their roots in Dungeons and Dragons. In some games it shows more strongly than others, in everything from the main stats (STR, DEX, CON...) to even names of specific spells or powers. A friend of mine got me into tabletop a few years ago, and after joining a 3.5e D&D game over Skype with the rest of the SA crew a few months ago, I've become thoroughly hooked.

Two things led to the idea of this post: a D&D exercise in the game design class that I TAed for earlier this summer and my first foray into Dungeon Mastering. For the uninitiated, tabletop roleplaying involves people sitting around a table (or Skype call) with dice, character sheets, and occasionally dungeon grids and miniatures. One person, the Dungeon or Game Master (DM/GM) runs the session. He or she is in charge of putting forth the story, "You receive a letter from courier. It is addressed to you in a flowing hand, but there is no mark of the sender save for a sigil on the seal you've never seen before." She controls the enemies in encounters and enforces the rules of the system (be it D&D or other), or doesn't, as the case may be.


After a brief lesson on balancing, the Game Design professor directed the class to four character sheets for 4e 9th level characters as well as a variety of monsters they might run into. He then challenged them to create two monsters of their own and design an encounter for the four characters to run into. The next class, we playtested some of them. As most of the class had no D&D experience and none of them had any with 4e, there were many balancing problems. A few had monsters with reasonable stats except that they were very difficult to hit, while another group made interesting monsters that weren't hard-hitting enough to pose a challenge to the players. My favorite, however, was the group battling a cyclops that had 1000 HP, keeping in mind that, at this level, characters are doing 14-15 damage per hit on good strike.

I was thinking of that lesson as I approached my first experience DMing. While I love our Skype shenanigans, I longed to have face-to-face conversation and missed the feel of real dice in my hands. So I recruited my brother and housemates to join me in an adventure. I wrote a simple campaign in a system that was effectively D&D-lite to teach them how to play. Despite a few balancing problems of my own, the campaign went well and we're looking for another chance to play. They started as strangers in the dungeon of an unfamiliar mansion and worked their way up to the lord's chambers, where they confronted him in the midst of a blood magic ritual to revive his dead wife. Battling off shadow creatures and crippling fear, one player rolled a critical hit after dipping his arrow in what they assumed was holy water. I described in detail as the arrow zipped through the air, piercing the lord's head and filling him with a brilliant light as he screamed and collapsed. The day was saved.


Sounds a lot like a video game, right? Between these two experiences, I've come to the conclusion that budding game designers should give DMing a shot. While there are aspects of it that don't come up in video games, such as managing rambunctious friends, I still think it's a valuable experience.
  1. Story design: The DM is responsible for crafting a story that the players can bring to life. You determine how to throw a disparate set of characters together and what to throw at them to make them grow. Our Skype campaign started with us defending a town and has progressed through our investigation to battling angels and racing to preserve the very fabric of space itself.
  2. Dungeon design: Most D&D campaigns involve a bit of dungeon crawling, and that requires putting together a floorplan, as well as a series of enemies, traps, and even puzzles. 
  3. Following the rules: D&D has a set of rules that are put forth in the Player's Handbook and the Dungeon Master's Guide. Other books expand the setting and enrich the experience. This gives you an idea of the scale of creating a game and how to work within the restrictions of the medium.
  1. Breaking the rules: Sometimes a rule doesn't serve the experience you're trying to create. In our Skype game, one of us had never roleplayed before and three of us had never done D&D. To that end, our DM removed the level penalty for death. (I greatly appreciate this, playing as a sorceror.) We still want to avoid death, of course, and resurrection still costs 5000 gp, but it's much less discouraging this way, which has been helpful to a beginner's campaign.
  2. Thinking outside of the box: PCs do some wacky things. I've used my raven familiar to untie ropes and give us another view on something. We've had players attempt to scale a giant worm to rescue a team member caught in its maw. The DM has to call for the proper checks and decide how well a plan will go off.
  3. Balancing: As in the example from class above, balancing is a vital but tricky part of game design. Tabletop systems try to help out by using things like challenge ratings, but the dice gods are fickle and some classes aren't built to take on certain threats. For that matter, ask why different dice types are used for different attacks. What's the difference between rolling 2d6 and 1d4+4?
  4. Managing player expectations: This is generally built into the system, but still an important point. Players can't generally see the stats of the enemies that they fight, but they'll bring some assumptions to the table: a vampire will be harmed by sunlight, a zombie will have bad reflexes, a dragon won't be likely to fail a Will save, and so on. See how these expectations are built into the system and why they're important.

At the end of the day, DMing and game design both endeavor to deliver an immersive experience to the player. The extensive rules involved in any tabletop system, though particularly D&D, will prepare game designers for the sort of thinking that programming a game requires. Designing a campaign has direct parallels in designing video games of many genres. Dealing with player characters will give you instant feedback and insight into how PCs tackle obstacles and view challenge.

If you've never played tabletop, head to your local game/hobby store and ask - many will run weekly or monthly game nights or host local groups. Look for people playing online. See if any of your friends play or would be interested. If fantasy isn't your cup of tea, give a system like Savage Worlds a try, which is designed to be extensible to any setting you can think of. Get off the computer, grab some dice, and pull up a chair.

It's time for adventure.

Tuesday, January 31, 2012

Thoughts on Global Game Jam 2012

Global Game Jam 2012 took place this last weekend, and the three of us participated! In the span of about 48 hours, we built a game themed around Ouroboros essentially from scratch (we did have to search online for music and sound effects, but other than that we created all the code and assets in the two days). Here are a few thoughts:
1. Keynote speaker Gonzalo Frasca was absolutely right. The important thing isn't how well you end up doing, it's about leveling up while doing it. And I can say for sure that this helped me level up. Before, I've worked on a video game over the course of a semester, and then over the course of a month, but a weekend is a whole other beast. You just need to really buckle down and work, and if there's something you don't know you are going to learn it VERY quickly.

2. Possibly the most important thing to know as a developer is your own limits. No matter how good you are at coding, 48 hours isn't a very long time, and plans for a game will ALWAYS be too ambitious. You have to know what ideas to cut, what to keep, and what to change. And you have accept that the finished product will pretty much never be quite what you imagined. But it will still be awesome.
3. And probably the most important thing for you to do during a game jam is of course to have fun. Hopefully, you're doing the game jam because you want to, so don't get too stressed out by the impending deadline. There will be times where things aren't moving as smoothly as planned, but that's inevitable. Go with the flow, don't stress out, and in the process learn how to deal with unexpected events!

That's really all I have to say about it. In short, participating in the game jam was absolutely amazing, and I highly recommend participating to any prospective game devs out there. It's an eye-opening experience, and even if you don't manage to get very much done, remember: it's not about what you end up with, it's about leveling up and becoming better than what you were before. Just do your best and have fun, it'll be worth it.

Saturday, January 7, 2012

Lessons Learned: Tips for Beginning Game Designers

(I meant to post this earlier, but then my computer got a nasty virus and it took time to get it running again... but it's back, so here we go!)

This past semester the whole Silver Asterism team took a Computer Game Design course. It was so awesome, but so much work. I thought a good way to ease back into posting after a hellish semester would be a small retrospective on things learned over the course of the semester. The course was set up so that we did three month-long games. Each was on a different platform, beginning with Android (using AndEngine), XNA, and either Unity or Unreal (all of us picked Unity). We worked in three-person teams and had a short list of requirements from the instructor (like having AI or implementing gravity). So here's a few things I learned in the course of the semester, in no particular order:

1. Don't bite off more than you can chew
This is a really hard one to get as a beginner. You have so many cool ideas and things that you want to do with the game, but the reality is, maybe you don't have the know-how. Or, like in our case, maybe you don't have the time.
They told me I could be anything I wanted...
2. Dare to dream big
Yes, this is somewhat contradictory to #1, but bear with me. Likely, it was some of the major titles that got you interested in game design. (I'm fascinated by fantasy RPGs like Skyrim and Dragon Age and cool mechanics like in Portal, personally.) Maybe you've been fired up by a grand idea that you've had (we've got a neat one in the pipeline that I can't wait to make...). That's great! Don't let go of it! Maybe you're not ready to program it yet, but that doesn't mean that you can't plan. Maybe you're ready to hack together a prototype in your spare time. Whatever it is, don't let that dream game die, because that's what got you into this, and that same passion is going to keep you in the game.

3. Scoping is hard
My two points above really come together in one thing: scoping. Understanding the feasible scope of your project is really important. It's also really hard. And I don't think that it's something you can get without practice. My first group had more planned than we could code in a month (partially due to AndEngine's lack of documentation, but that's another story...) and my second group, in reaction to that, wasn't ambitious enough. Our school's student game development club has seen many projects fail because the director(s) didn't know what was possible in a semester. Which brings me to...

"You know, not everybody likes onions. Eh, cakes! Everybody loves cake! Cakes have layers!"
4. Try out incremental development
For incremental development, you divide the project into sub-projects and order them based on necessity. Then code in that order, so that at any point in development you have a complete, playable game. For instance, the first sub-project would be to get the basic graphics and mechanics working. The next level may add on a more advanced HUD, or keys that open doors. This also lets you easily debug as you go, and if you run out of time, you'll have a complete project. It's also called the onion model, and it works well for small projects. Give it a shot, and it can help you get a better handle on scoping while still creating a complete game.

5. Learn art, or make friends with an artist
This is a smaller, less important point, but once you've laid down all the code, you're going to want your game to look nice. If you're someone like me, with some artistic ability, then maybe you're set. If not, go make friends with someone who is. It's a small touch that's nice. Try out Photoshop or Gimp to make pixel art - it's not very hard and rather fun! 3D stuff is a little more daunting, but it can be really rewarding when you get something right. Give Blender a shot, a free, open-source editor with plenty of tutorials available (www.blender.org). At the end, your game will look better for having original assets, and you'll be prouder of it.
Fun fact: That weird clef on the left there is the movable clef. In that position, it's called the alto clef. Music nerd, out.
6. Make some noise!
On that note, find some good background tracks, or someone who can make them for you. www.freesound.org is a pretty good spot to find simple loops and such. For dialogue and sound effects, I recommend recording them yourself. It's a lot of fun, and you can probably find some friends to lend their vocal talents to your characters. Again, having original assets can really help you feel proud of your game.

7. Learn from every project
I'm not jumping up and down to show off two of the games I made this semester (the last one was pretty nifty). But that doesn't mean that I'm just scrapping them. The first one wasn't very original, but I learned from it. The second could still use some work, and I may yet go back to it. Even if a project fails, which can be frustrating and embarrassing, don't just delete the code and never look at it again. There may be things to learn there, or even useful pieces of code. Take some time away from it, then go back and see how much you did accomplish.
Google thought this picture would be useful.
8. Don't be afraid to try
Honestly, this one's mainly on the list for me. I have a tendency to underestimate myself, which holds me back in things like this. Never programmed a game before? Just try. You start to figure out how to handle updates smoothly or how triggers work in Unity, but only if you start messing around. (Okay, the tutorials might help, but I never have the patience to read through all of them.)

9. Play indie games
Thanks to Jeremy and Steam sales and Humble Bundles, I've gotten really into indie games as of late. They tend to be smaller in scope and revolve around one or two core mechanics or ideas. These are the kinds of games that you can start out programming, and they may give you a start for more realistic scoping than just working off of AAA titles. Besides, they may give you some ideas and inspiration.

10. Have fun
It seems obvious, but it's really important: make sure you enjoy what you're doing. If one engine or game style is frustrating you, find something different. Hit your stride and get used to programming games, then return to the things you're less happy with. If you're working in a team, try to find something that everyone can get excited about. My most successful project this semester involved a team that was universally excited about the idea. If you're enjoying it, working on it will seem less like a chore, and you're more likely to wind up with a finished game.
Oh, the lies...
11. For the love of God, start with a well-documented engine
The first game I ever did programming for was on AndEngine. It wasn't a good idea. Don't do it. I still have no idea what on earth we were doing. XNA had more documentation available, which made it a lot easier to get started in. Working in Unity or Unreal was a little different, and personally I'd try something a little less elaborate at first, since the larger engines take care of a lot of the small things for you. Just don't start with AndEngine, or anything similarly terribly documented. You'll thank me for it.

And there you have it, my thoughts after a semester of a programming course. Some of them are kinda obvious, but hopefully they're helpful nonetheless. Now I'm off to do some more planning on my game project for this coming semester... :-)