Committing

I can feel me and this blog drifting toward different destinations.  Drifting slowly.  Drifting predictably.  I can't post daily, at least not while school is in session.  That's fine.  Less attention fostering my growth here means more attention fostering it elsewhere.

I refuse to let myself abandon this blog, however.  I started writing to hold myself accountable.  I want to learn about games, and I'm convinced the best way to learn anything is to share what you've learned with others.  This blog is important to me.  Henceforth, I'm committing to posting every Tuesday and Thursday.  If I write more, I'll post more, but no Tuesday or Thursday shall pass without me making a potentially profound and hopefully interesting comment on the state of games as they exist in my life.

I'll see you Tuesday.  You can mark it on your calendars!

Cheers,

Danny

Race Game Prototype

Here's the first prototype I playtested for a race game I'm making.

The Board

A Track Card

The pieces:

• Four players
• One board
• A small stack of cards identical to the one pictured above
• Four game pieces (one for each player) to keep track of player positions on the board

Players start the game on the shaded spaces at the two ends (lengthwise) of the game board.  So, both shaded spaces on the upper edge of the game board as well as both shaded spaces on the lower edge of the game board will be occupied by players at the start of the game.  At any point during play, players can only occupy the shaded spaces - a player should never come to rest on an unshaded space.  Play starts with a player determined by some arbitrary method, and then proceeds clockwise based on the players' starting positions.

On a player's turn:

• He/she draws and places a track card onto one of the unshaded spaces of the game board.
• Track cards may be placed on top of existing track cards.
• The orientation of the track card is determined by the player at the time it is laid.
• After the track card card has been laid, the player moves his/her game piece.
• A player can move from his/her current shaded space to an adjacent shaded space only if a track card has been laid that connects the two spaces.
• A player can only move once per turn.
• If a move can be made, a player is not allowed to finish his/her turn without making a move.

Special considerations:

• The left and right edges of the game board "wrap".  This means that a player who exits the game board on the right side will re-enter the game board on the left side, and vice versa.  If you find this concept confusing, think of how Pacman levels operate.  It is important to note that this wrapping occurs only on the left and right sides of the game board, not on the top and bottom.
• Multiple game pieces cannot occupy the same space on the game board.  Game pieces can also not travel through other game pieces.  With these constraints in mind, it is possible to position your game piece to block an opposing player's movement.

The goal: The first player to successfully navigate his/her game piece to the opposite side of the game board (either of the two possible shaded spaces) from which he/she started is the victor.

Going into the playtest, I knew the game board was small.  My biggest worry was that players would complete the game in three of four moves.  What transpired was a surprisingly lengthy gameplay experience.  When a player was on the verge of winning, the other three players would coordinate their moves to stop the win and keep the game going.  Communication, coordination, teamwork.  None of these were things I considered when designing this prototype.

Coming out of the first playtest, I decided that I wanted to design the rest of the game to foster more of the communication I had just witnessed.  My first change: put the players on teams.  Rather than a free for all between four players, I wanted to pit two teams of two against each other.  This way, a single mind (teammates talking through possible moves) would have control over two game pieces.  This was the first of many changes to come.  Iteration is a beautiful thing.

Cheers,

Danny

Raph Koster

Here are my scribbles from Raph's talk Saturday night.  Personally, I feel the talk started a bit slow.  There was a lot of conversation about text-based MUDs (Multi-User Dungeon - had to look that one up afterwards) and other things that were either above or before me.  Once Raph got going though, the man practically exuded insight.

Without further ado (trouble or difficulty - had to look that one up too) and with sparse context, here's a haphazard and mostly nonsensical list of some genuinely interesting thoughts from an experienced (legendary, actually) game designer:

• systems vs. story
• chess as a sandbox game - "explore the world"
• static storytelling (i.e. interactive movies)
• Raph studied English in college
• Who is Chris Crawford?
• MDA (mechanics, dynamics, aesthetics) framework
• "Rules of Play" - Eric Zimmerman
• "Chemistry of Game Design" - Dan Cook
• "Game Grammar" - Raph Koster
• formalism of game design
• Playdom - Raph's company
• formalism in game design as notation, akin to music notation
• verbs, objects, currency - game grammar; Raph creates this game grammar before he creates any prototypes
• curiosity - first common trait of the most bad ass game designers Raph knows
• both brained (meaning left- and right-brained) - second bad ass game designer trait
• Raph thinks we should reduce the role of narrative in games
• you've made it as a game designer when you can see nothing but the play of math underneath your game but at the same time, come to your game, forget how it all works, and see just the surface
• a classic liberal arts education is beneficial to aspiring game designers (take physics AND poetry)
• games driven by systems over narrative
• games designed to be replayed are more systems-driven
• Raph's favorite game of all time is Mule for the Atari 800 - "the most elegant multiplayer design ever"
• Raph still plays Joust on every available platform
• Raph advocates formalism in games
• when designing games, Raph focuses on creating the experience of the game before the systems of the game
• metaphor and mechanic
• What is the game about?  What is the surface experience of the game as well as the mechanical experience of the game?
• Clint Hocking
• ludonarrative dissonance (Bioshock has it)
• Harmonix's Rock Band vs. Amplitude (related to ludonarrative dissonance)
• beat matching on a plastic guitar made "no ludonarrative dissonance"

Some of the things I wrote down will never again make sense outside of the moment my pen hit the notebook.  Still, there are plenty of items here begging for investigation.  Rest assured that any and all sleuthing born from this talk will make its way onto this blog.

You can watch the entire talk here or here.

I included a bunch of Raph-related links at the end of a previous post.  Go there if you want to be transported to other nooks of the Web sprinkled with Koster.

Cheers,

Danny

Jane McGonigal And TED

For one of my classes, my classmates and I were asked to watch Jane MaGonigal's 2010 TED talk Gaming Can Make a Better World, and post our thoughts on a class forum.

Everyday, gamers max their focus, cooperation, and determination, among other skills, to solve the many problems of countless virtual worlds, and McGonigal hopes to harness some of this power to solve real world problems.  She truly believes that gamers have the power to save the world.  So, if world saving sounds like your cup of tea and you fancy a game from time to time, you're going to want to watch this.

I drank the Kool-Aid before I ever heard McGonigal's talk at TED.  Games are ubiquitous.  The population of gamers is huge and growing.  What excites me most, however, is how truly young the medium of digital games is.  It's only been 40 years.  For perspective, look at how much film has grown and evolved as a medium since the 1940's.  We're experiencing digital games in their infancy.  I'm with McGonigal 100 percent.  There's just too much unexplored potential in the digital games' space to think anything other than that unbelievable things are achievable with games by gamers!

Here's what I actually posted on my class's forum:

Through TED, Jane McGonigal shares a simple but radical idea: People spend billions of hours in virtual worlds because these virtual worlds are fulfilling genuine human needs many cannot find in the real world.  The time and commitment people dedicate to games can be harnessed to solve large-scale real world problems, but only if the real world starts taking notes from virtual ones.

McGonigal's enthusiasm for games and the impact she believes they can have is infectious.  She continues to convince people that video games can be a force for good through both words and action.  I'm amazed at the success she's already had with many of her alternate reality games.  McGonigal's vision of what games can become is a young one.  It's exciting to think about what will be accomplished if others follow McGonigal's lead and take the leap.

Cheers,

Danny

Busy

School and work have been keeping me busy.  I severely underestimated the amount of time I'd have to devote to less-than-essential pastimes (blogging) once school ramped up.  I was proud of the posting consistency I'd built up over the past two months.  Unfortunately, currently, daily posts aren't likely.  I'm still learning a hell of a lot about games, and I want to share it all!  No worries.  I'll get to everything, it'll just trickle slower.  ... it'll just trickle slower.  What a weird thing to say.

Today, I want to write briefly about a course I'm taking this semester called Game Design as Art.  When I started college in the fall of 2009, my university had nothing to offer in terms of game design/development.  Since then, a small handful of faculty members have managed to convince whoever's in charge to offer an equally small handful of courses related to game design through the art department and game development through the computer science department.  It's not much, but I'm thankful for it.

This course will encompass theory and practice of game development and game creation as an art process. Areas of study during the course will include game design and mechanics, explorations of theory, narrative and storytelling with game paradigms, social and ethical concerns of gaming and gaming as cultural resistance.

The projects are intended to expose students to different aspects of game design. Students are expected to create four games, participate in “game testing” and in forum assignments and to meet class deadlines.

I'm not sure why the phrase "game testing" is quoted in the above course requirements.

So far, this course feels like a less intense version of Ian Schreiber's online Game Design Concepts course, which I've been slowly trekking my way through.  Our first assignment in the class was to design and build a race game.  You can read all about the assignment here.  A race game.  That sounds familiar.

I'll be writing a few posts about the race game I made for the class soon.  I'm calling my game Mine Cart Mayhem - A Race Game.  I stole the name from a Mario Party mini game.

Talking to my professor after class today, he told me that he wants to show students that they can, in fact, make games themselves.  So many people express a desire to make games, but few do.  They think the process is beyond them.  It's not.  I discovered this on my own not too long ago.

Some more news: Me and some guys have a Skype date planned with Raph Koster!  Raph has been described by some as a "legendary game designer."  I bought his book around the same time I started this blog.  I haven't read it yet.  Still, I'm fucking pumped to meet the guy!

Cheers,

Danny

Advanced Game Programming

This semester, I'm taking a course called Advanced Game Programming.  The class serves as an introduction to 3D game programming using the XNA framework.  It's an introductory course.  The only reason "Advanced" is in the title is because this course is the second of only two game programming courses offered by my university's computer science department.

If you've read any part of my blog, you know that game programming is new for me.  The course may not be advanced, but I'm confident it will prove challenging enough to keep me up past my bedtime once or twice this semester.  It's been three weeks, and so far, I love it!  I've already learned enough to develop a complete (simple) 2D game: drawing sprites to the screen, detecting user input, calculating collisions, and playing sound effects and music.  I'm learning what a game looks like in code, how to code in C#, and how to use Microsoft's Visual Studio IDE.  There's a lot of real learning going on, and so far, I've been genuinely excited to work on all the assignments.  This isn't a feeling I've experienced often during my time at university.  It's nice.

Our current assignment, and last assignment before adding the third dimension, is the recreation of a classic arcade game.  The game must include:

• object interaction,
• background music,
• a variety of sound effects,
• character animations, and
• user control.

We are to keep the essence of the original game intact, but otherwise are free to explore and experiment.  I want to remake Breakout.  In my version, player movement will not be confined to the x-axis.  Players will be able to move their paddle to any point on the screen where there isn't already a brick.  Bricks will not disappear on contact with a ball.  On contact with a ball, they will fall from their starting position until they drop off the bottom of the screen.  If the paddle is struck by one of these falling bricks, the paddle will become unresponsive for a very brief period of time.  Players will start the game with three lives.  Each time a ball falls off the bottom of the screen, one life will be deducted, as in tradional Breakout.  Players are not limited to the number of balls in play at one time, however.  If a player feels up to it, he/she may try to play 20 or 30 balls at once.  Adding an additional ball to the play field will be mapped to a keystroke.  Once three balls make their way past the paddle though, the game ends.

That's my idea.  It's due on September 25.  That seems manageable.

Here's the syllabus for my Advanced Game Programming class, if you're interested in reading something uninteresting.

Cheers,

Danny

Sunday

Musings from LD24 part V.

Sunday was tough.

I had finally settled on an idea, I had already made a handful of (very) small prototypes to test gameplay mechanics, Stencyl and I were beginning to understand each other, but the thought of working on my game didn't excite me like it did the previous 36 hours.

I was worried that my game wouldn't be any fun.

I'm sure thoughts like these aren't unique to me.  I imagine all game developer's run into similar thoughts, probably constantly, throughout the lifespan of their respective projects.  It's a tough wall to climb over.  I hope the wall gets shorter with experience, but my motivation took a pretty hard hit upon this first encounter.

Will my game be fun to play?

I couldn't think of a way to answer this question without first building my game out into a playable state, so that's what I did.  Slowly.

I knew the player character's abilities would improve and evolve over time, so I made a list of abilities I wanted to include:

• Running speed
• Jump height
• Climbing (as in climbing up vertical faces)
• Sliding (as in sliding down vertical faces to prevent death from falling)
• Flying
• Speed of movement underwater
• Ability to breathe underwater

In hindsight, this list was ambitious.  I managed to squeeze in jumping and flying, but I scrapped everything else.

Another scrapped idea: I wanted to group NPCs into villages with each village specializing in a specific ability that would benefit the player.

Regardless of how short I fell of my ambitions, at the end of the weekend, I was damn proud of myself.  On Friday night, I set out to make a game, and by Sunday night, I was playing it!

That's it.  That's my Ludum Dare experience.  The way I've documented it, you'd think I had made something magnificent.  I don't expect anyone else to share my feelings, but when I look at my game, I do think it feels pretty magnificent.

Cheers,

Danny

Saturday

It's been a few days.  I'm not making excuses, but here's a pretty damn good excuse.

I got wrapped up in reading all of this and watching a lot of this.  It's been great.  I'm exhausted.

Musings from LD24 part IV.

I woke up Saturday morning, and for some reason, felt compelled to create animations for my game characters.  My characters were squares.  Not square as in describing their general shape.  Squares as in literal squares.  I settled on simple, geometric shapes for all my characters before the theme for Ludum Dare was even revealed.  This decision was a pragmatic one as I didn't want to spend time creating art assets when I could be spending that same time creating interesting and enjoyable gameplay.  For some reason, contrary to this reasoning, that morning, I wanted to plop some blinking eyes on all the squares.

I focused on two animations: blinking and breathing.  I guess I thought these animations would make my characters more cute and therefore more appealing.  Probably true, but on that Saturday morning, I didn't have a game made yet.  I barely even had an idea for a game.  I wasn't properly managing priorities, and in the end, I wasn't impressed enough by any of my animations to use them.  I got caught up in visual aesthetics.  Looking back, this time seems wasted.  It was a lesson I thought I knew, but I'm glad to have learned it firsthand.

Sometime in the afternoon, over the course of many lazy hours, I finally decided how my game would play.   Building from the generational idea I had previously, here's where I ended up:

• The player character will age and die on a timer.  I was thinking of a 60 second lifespan.  After the first 30 seconds, the player grows too old to reproduce.
• Every time the player character mates with an NPC, a new character is born that the player is given control over, and the life timer resets.
• The player character improves with each generation that passes.
• The player character's abilities that improve are dependent on which NPC characters are mated with.  NPCs live in clusters throughout the game world.  Each cluster possesses a unique ability.
• Generally, the longer that player character survives, the faster that player character will be able to run, the higher that player character will be able to jump, and the longer that player character will be able to swim.
• In addition, I wanted to include special abilities for the player character to attain such as flying, breathing underwater, and climbing vertical faces.
• The entirety of the game world cannot be explored by the player unless that player evolves his/her player character through many generations improving his/her player character's abilities with each one.
• The goal of the game is to survive for as long as possible.
• The game will keep track of and display the number of generations that has elapsed.

Two new prototypes:

Here, the player character's jumping ability increases every time he/she jumps on an NPC.  Try to get the red "fruit!"

http://dl.dropbox.com/u/64097119/Stencyl/LD24%20Jump%20Higher%20Prototype.swf

Here, I figured out how to implement a simple head-up display.

http://dl.dropbox.com/u/64097119/Stencyl/LD24%20HUD%20Prototype.swf

Move left and right with the arrow keys.  Jump with X.

It didn't take long for me to realize how ambitious of an idea this really was.  Especially considering that at this point, I only had 24 hours before the competition ended.  It didn't matter, I was committed.

Cheers,

Danny