games++

Guess what?  I'm participating in another game jam!  games++ is taking place near my stomping grounds this Saturday.  It's a ten hour jam hosted in the basement of a local art center.  Like Ludum Dare, there's a secret theme to be revealed the morning of the jam.  As such, participants are encouraged to show up with empty pockets having not done any preliminary work prior to the jam's start.  Including myself, a group of seven students from my university (many I've just met this semester) will be entering as a group to compete.  Taking the ten hour limit into consideration, our plan is to create a highly polished analog game - board, card, whatever - as opposed to a digital game.  You can be sure I'll post our results here next Tuesday.  Wish us luck!

Cheers,

Danny

XNA

XNA is a set of development tools built to facilitate PC, Xbox 360, and Windows Phone 7 game development.  XNA is a free download.  It extends Microsoft's Visual Studio IDE which is also free.  XNA games are built in C# which is a language very similar to Java, so if you know that, there isn't much syntax to learn.  I've been playing with XNA for about two months now, and have made some (very) small games.  My experience thus far is limited, but with the amount I feel I've accomplished thus far during my brief time with the tools, XNA gets a gold star from me

So, how does XNA facilitate game development?  First, creating a new XNA project creates a Game class for the developer to work in.  This Game class includes class-level variables to help interface with the graphics card of the targeted platform and draw sprites (basically, any 2D or 3D image in a scene).  The Game class includes methods to create and initialize a game as well as a method for loading any content (images, models, sounds, effects, fonts, etc.) a game requires.  Most importantly however, the Game class manages what is known as the game loop.

The game loop is a set of methods that are called continuously while the game is running.  In XNA, this loop consists of only two methods: Update and Draw.  Draw is used to draw any element in the scene seen by the player while everything needed to run a game that isn't drawing takes place in Update.  Typical actions housed in Update include moving objects, checking for collisions, updating scores, and checking for end-game logic.  The bulk of the logic housed in Update involves polling for events.  Polling is what differentiates the way games execute from that way many other types of software applications execute.  Polling is also why the game loop is such a vital part of game development.

Outside of games, a typical application might prompt the user to take some action, and then wait.  Once the user performs the prompted action, the application is notified, and execution continues.  Games never wait.  They perform actions constantly, and actively ask the system whether or not certain events have taken place.  For instance, the game is not notified by the system when a player moves the mouse.  Instead, every time the game updates, the game polls the mouse for its current position, and then checks this current position against the position of the mouse from the previous update.  Computers are quick, so it's not uncommon for a game to call it's Update method, where much of the polling takes place, 60 or more times a second.

My first XNA project involved displaying two animated sprites that bounce around the screen.  Among other tasks, this project involved making or finding a sprite sheet, loading the sprite sheet into a Texture2D variable, and in Draw, cycling through the images on the sprite sheet to simulate motion.  On each call to my games Update method, I adjusted each sprite's position on the screen based on an initial direction.  In Update, I also polled the sprites for their current positions within the game's window so that I knew when a sprite's bounds overlapped the bounds of the window.  When I detected this overlapping, I simply changed the sprite's direction.  Changing direction this way made is appear as if the sprites were colliding with the game's window, and ensured that the sprites always remained in view.

For the curious, here's a link [coming soon] to an executable of my first XNA project (Windows only).  For someone with zero game programming experience prior to XNA, not counting Stencyl or Twine, I can tell you it's easy to pick up, and it takes very little to make yourself feel super accomplished.  Don't forget about the gold star!

By far, the most difficult part of this project for me was finding useable sprite sheets.  If you need sprites for a project, Spriters Resource is a great place to start.  Also, many of the sprite sheets you'll find online will not have consistent spacing between sprites which is pretty important when calculating which pixels of the sprite sheet to draw in-game each frame.  So, if you find a bunch of sprites, but need to assemble the sprite sheet yourself, Alferd's Sprite Sheet Unpacker is great.  It might save you some time.

Cheers,

Danny

Programming Advice

Do not ever leave the computer if your program does not run.

Andy Gavin, Naughty Dog Co-Founder

Cheers,

Danny

Renga

Renga is a game that makes me want to make games!

Full disclosure, I haven't played Renga.

I few days ago, some local developers who made the trek to IndieCade showed me a video they took of a game called Renga.  I've had a few days to think about what kind of experience Renga offers players based on what was shown me, and I still can't believe how unique that experience is.  Games have come a long way, but there are still a staggering number of directions no developers have even thought to face yet.  I love my blockbusters, but the holiday release schedule often makes the potential of this industry to create truly new experiences easy to overlook.  I'm thankful for games like Renga to remind me how exciting game development is right now.  There's nothing I want more than to have a hand in crafting a unique experience that contributes to this excitement.

So, what is Renga?

Renga is a cooperative game played with 100 players.  It's an abstract space strategy game where players must defend their collective mother ship from hostiles and gather the resources necessary for expansion.  Before play begins, each player is given a laser pointer.  This laser pointer acts as their ship in game.  Enemy ships have a number of nodes lining their perimeters.  To destroy an enemy, at least one laser pointer must occupy each of these nodes.  Larger enemies have a greater number of nodes.  The mother ship too is lined with nodes.  These nodes however, influence translation rather than destruction.  To move the mother ship away from danger, players must navigate their lasers to the node facing the desired direction of movement.  The more lasers in a node, the faster the mother ship will move in that direction.

Remember, there's 100 people playing this game at one time.  Who's harvesting resources?  Who's on defense?  Who's looking after the mother ship?  It's easy to see how this game works to foster teamwork through both spoken and unspoken communication between players.

I can't convey in any written form how excited I am that this game exists!  There's a lot about this game that has to shown to be appreciated.  In the video below, 100 people are playing, 200 more are watching.  Listen for the spoken direction.  Watch the cooperation.  Feel the joy!

Cheers,

Danny

This Is Timely

Extra Credits - Aesthetics of Play

This is a pretty brilliant analysis of game genres and aesthetics, and something I've been thinking a lot about recently.

Also, I totally beat the Extra Credits team to the punch on this one.

Cheers,

Danny

Describing A Game's Aesthetics

Think of your favorite game.  Now, pretend you're telling a friend about that game.  Do your best to describe the game's aesthetics.  Before you start, stop thinking about graphics.  When I say aesthetics, I mean the emotional responses evoked in you as a player when you're interacting with the game's systems.  Try to describe that.  It helps to think out loud.  It's easy to recognize incomplete thoughts when you try to convert the generalities in your head into something more concrete.

Here are some words I've used to describe the "aesthetics" my favorite games in the past: fun, innovative, interesting, challenging, pretty.  What do these words say about the gameplay experience I'm trying to convey?  Absolutely nothing.  I think that's a problem.

Too often, people discuss games in generalities, never traveling beyond the surface of "fun."  I'm definitely one of those people.  Too often, I talk about games without saying anything meaningful - something that myself or those I talk to can take with them to help inform their next gameplay experience.  This is one area of my relationship with games I'd like to improve.  I know a language exists for discussing games in meaningful ways, a language for use by both developers and players.  Most people just don't speak it yet.

Thankfully, lots of people, including the people who wrote this paper, have been looking at this problem much longer than I have.  Some of their suggestions for better ways in which to describe player experiences, or the aesthetics of a game, include:

• Sensation: Game as sense-pleasure
• Fantasy: Game as make-believe
• Narrative: Game as drama
• Challenge: Game as obstacle course
• Fellowship: Game as social framework
• Discovery: Game as uncharted territory
• Expression: Game as self-discovery
• Submission: Game as pastime

They provide some great examples of this game vocabulary in action:

• Charades: Fellowship, Expression, Challenge.
• Quake: Challenge, Sensation, Competition, Fantasy.
• The Sims: Discovery, Fantasy, Expression, Narrative.
• Final Fantasy: Fantasy, Narrative, Expression, Discovery, Challenge, Submission.

As is shown above, games are not limited to pursuing one aesthetic goal while forfeiting inclusion of the others.  Rather, games pursue multiple aesthetic goals to varying degrees in order to best achieve the desired gameplay experience.

I encourage everyone to try this as an exercise: Using only the eight words listed above, describe the aesthetic experience of a game you've spent considerable time with.  It doesn't sound challenging, but I, personally, find it rather difficult.  I plan on writing up my conclusions and justifications for some of my attempts at game aesthetics breakdowns at some point, so expect that soonish.

Cheers,

Danny

Hours Of Behind-The-Scenes Game Talk

I've been following this blog: tiny Build Games.  tiny Build released one of my favorite launch trailers of all time for their game No Time to Explain.  Also, No Time to Explain is awesome.  Also, their new game looks fucking rad.  I love the blog, but I think I love their most recent post most.

Check it out!  Seriously.  If you're looking for enough quality game dev related content to last until 2013, stop searching.  I found it for you.  Well, tiny Build found it for you.  Here are some of the videos they link to:

• Portal 2 Post-Mortem
• How Fruit Ninja Happened
• Extended Interview With Gabe Newell
• How Bioshock Infinite Got Started
• David Jaffe's PAX Keynote
• Making Crash Bandicoot
• Building The Bastion
• Robert Khoo Talks About Running Penny Arcade
• Super Metroid Analysis
• AND SO MUCH MORE!!

I'm not linking to any of this awesome content directly.  Be kind, go to tiny Build.  Watch.  Watch everything.

Cheers,

Danny

MDA

Back in July, out of the sunshine, in front of my computer, I read a paper.  Apparently, while reading, I was taking notes.  If you stopped by today looking for some free advice, affix your eyes to this next bit: Write things down!

I don't enjoy assuming, but I do it lots, so let's assume you, dear reader, and I share a process.  Specifically, a reading process.  Here's your cycle:

• Finish reading something you think is important.
• Mentally reflect on the piece's supposed importance for a moment - two moments if that's how long it takes your browser to load up the four to nine Web pages you've already managed to navigate to since you finished reading the important thing.
• Read something else.
• Forget all that came before the current thing.
• Repeat.

So many interesting thoughts get lost this way!  Not this time though.  I read a paper I found useful, took some notes, and managed to find those notes months later before someone tossed them into a recycling bin.  Cool.

With only a bit more ado, here are some interesting things:

MDA: A Formal Approach to Game Design and Game Research
Robin Hunicke, Marc LeBlanc, Robert Zubek

First off, MDA stands for mechanics, dynamics, and aesthetics.  Mechanics describes the particular components of the game, at the level of data representation and algorithms.  Dynamics describes the run-time behavior of the mechanics acting on the player inputs and each others' outputs over time.  Aesthetics describes the desirable emotional responses evoked in the player, when he/she interacts with the game system.  MDA is a formal approach to understanding games - one which attempts to bridge the gap between game design and development, game criticism, and technical game research.

Games are consumable goods.  Inevitably, games are purchased, used and eventually cast away.  Unlike other entertainment products however, the ways in which games are consumed is largely unpredictable - the events and outcomes that occur during gameplay are unknown at the time a game's development is finished.

Partly due to their unpredictable nature, the authors argue that games more represent artifacts, things not viewed as inherent elements but as products of human conception, than media.  To help convince yourself of this, think back to any story you've ever told about a game you played.  These kinds of stories are seldom about the polygons and algorithms the game presents you, the player, but rather about how you interpret this content in the moment and later relive and reshape the experience inside your own head.  As such, the behaviors of a game, rather than the media, represent a game's content.

Interesting, interesting.

The authors had a lot more to say, specifically about productive ways to discuss the aesthetics of a game.  Remember, aesthetics refer to an emotional response from the player while engaged in a game.  It's a great read.  Click the paper title above for a PDF download.

There's more I want to say.  I'll WRITE some more things down in a future post.  Also, Raph Koster talked positively about this framework during the talk he gave to the Omaha Game Developers Association.  I remember his mention of MDA because I WROTE it down.  I'm serious about how important I think the writing process is.

Carry a trustworthy pen with you always.

Cheers,

Danny

Four Phases

This is the second part of something.  Here's part I.

Lay Track - Phase I

At the start of your turn, your team should have three track cards laying face-up in your factory.  During this phase, you and your teammate move one or more track cards from your factory onto the game grid.  A track card can be placed onto any tile of the game grid that is not already occupied by a cart or a pit card.  This mean that teams have the option to lay track cards on top of existing track cards.  Any orientation of the track card is allowed so long as the track card occupies only one tile.

At the start of the game, teams can only lay one track card per turn.  The number of track cards a team is allowed to lay per turn can be increased if teams achieve specific objectives during play:

• For two track cards per turn: One of your team's carts (not the gold cart) must move at least three spaces in a single turn.
• For three track cards per turn: One of your team's carts (not the gold cart) must move at least five spaces in a single turn.  See phase III for details on cart movement.

When laying down track cards, a team must lay down all allotted track cards.  This means if your team has earned the ability to lay down three track cards per turn, you must lay down all three track cards every turn (not one or two).  This phase ends once you and your teammate has laid all of your allotted track cards.

Pull Lever - Phase II

During this phase, you and your teammate must decide which of the colored tiles (green, orange, fuchsia) to place the switch on.  This decision plays a critical part during the next phase of play.

Move Mine Carts - Phase III

• For the first turn of the game, your mine carts will be positioned inside your towns.
• To move a cart out of a town and onto the board, the cart must "hop" onto a track that has made a connection to the town.  The image below shows three track cards that have made a connection to a red town.  Note: This cart can only hop onto the green colored track if the switch had been placed on the green tile during the previous phase.

A Town And Some Tracks

• Once a track has been hopped onto, your cart follows the path created by connecting tracks until no more track exists to follow.
  
• When a junction is encountered, the cart must follow the track colored the same as the tile the switch occupies.  The switch should have been placed during the previous phase.

A Junction

• If the color of the tile the switch occupies is not present on the junction track card, the card follows the black track by default.
• When your cart reaches the end of the path it is traveling, your cart comes to a rest on the tile containing the last piece of track that was part of the path.  A cart should never occupy a tile on the game grid where track has not been laid.

Sample Movement - Before & After

• On your next turn, your cart will begin on the length of track your cart came to rest on during the previous turn.
• If a path exists for your mine cart to travel on, your cart must move this phase.  This rule includes the case of moving your cart out of your town and onto the game grid.
• Each team controls two carts.  These carts are labeled "1" and "2."  The order that a team moves carts is important.  First, the "1" cart moves.  Next, the "2" cart moves.  Finally, the gold cart moves.

Special notes on cart movement:

• The edges of the game grid wrap on all four sides.  The simplest way to grasp this concept is to think of the game Pac-Man.  In Pac-Man, when a player leads Pac-Man off one side of the screen, he emerges from the opposite side of the screen.  The same concept applies here.

Wrapping - Before & After

• Carts cannot pass through each other.  If the path of one cart is blocked by another cart, the moving cart will come to a halt on the tile before the collision world occur.

Blocking - Before & After

• If your cart begins phase III on a colored section of a junction track, the position of the switch (green, orange, fuchsia) does not affect your cart's ability to move off this length of track onto a connecting path.

  
Discard/Draw - Phase IV

During this phase, discard all remaining track cards (if any) in your team's factory.  Draw three new track cards from the deck, and place these new cards face-up in your team's factory.

Play now passes to the opposing team.

Cheers,

Danny

Mine Cart Mayhem

Last week, I posted about my first prototype for a race game I spent some time working on.  After its first playtest, I threw that prototype into a pot with some additional playtests and a plethora of unremarkable art skills, and a game started brewing.  It's been a few weeks, and I need the counter space, so I'm going to go ahead and serve this game up whether it's ready or not.  Here's the first part of a write-up detailing what's in the pot.

This is going to be wordy, and I can't promise it'll be entertaining.  I want to better my ability to convey game mechanics through text.  It's an exercise I've done a few times before, and each of those times sucker slapped me in the face with a surprising amount of challenge.  It's hard.  I want to improve.

So, if you're not feeling this, this isn't for you.  This is for me.  Thanks for understanding.

Mine Cart Mayhem - A Race Game

The year is 1893.  You live in a small Colorado town that didn't exist before the Colorado Silver Boom.  For 14 years, your town prospered.  Then, with little warning, the boom ended.  Most towns in the area have been abandoned.  Your own town is a shell of its former self.  Lining your town's borders, miles of crisscrossing railroad tracks lie in disarray.  Once used to shuttle precious metals, now they exist to rust.  Your town is poor, but worse than that, your fellow townspeople have grown despondent.

Hope looms on the horizon, however!  Word has just come in that a golden mine cart has been spotted a few miles outside of town, resting on some of the out-of-service tracks.  Where did it come from?  An eccentric philanthropist, perhaps.  Who knows?  Not you!  No more time for questions!  Bringing this golden mine cart back to your town could be just what the townspeople need to lift spirits that have been falling for years.

The objective:
You and your teammate must lay down track and build a path that will lead the golden mine cart from the abandoned tracks to the open arms of your town's people.  Securing this treasure will bring pride and prosperity back to your town.  Hurry though!  It seems the golden glimmer has caught some hungry eyes from a neighboring town.  It's a race to see who can guide the golden mine cart back to their town first.  It's a game of gold and wits!  The race is on!

Game components:

• 1 game board
• 2 red mine cart game pieces
• 2 blue mine cart game pieces
• 1 gold mine cart game piece
• 1 track switch game piece
• Game cards (track cards and pit cards)

The Game Board

The Game Pieces

The Card Types

Setup:

Lay the game board out flat on a hard surface.  Pick a location where each of the four players can sit along a different edge of the game board.  A small, four-sided table is ideal.

From this point on, all mine cart game pieces will be referred to as follows: color + "cart".  For instance, "gold cart" references the golden mine cart game piece while "red cart" references one of the red mine cart game pieces.  The track switch game piece will be referred to as the "switch."

Place the gold cart on the center tile of the game grid.  This center tile is the only tile with tracks printed on it.

Lines, both black and colored, printed on the game grid and game cards are called tracks (see "The Card Types" image above).  When tracks on adjacent tile connect, a path is formed (more on this later).

Place the switch on any of the three colored tiles (green, orange, fuchsia) found on the game board next to the game grid.  Your color selection at this point is not important as you will be given the opportunity to move the switch during your first turn of play.

The remaining four carts get placed on the four towns, one cart per town.  The colors of the town must match the color of the cart placed onto it.  For instance, a red cart cannot be placed on a blue town.

Remove the four pit cards from the deck of game cards.  Pit cards have a black hole printed on their faces.  Shuffle the deck of track cards, and then lay the deck face-down on the game board on top of the space labeled "deck."

Next, each player takes one pit card and places it onto an empty tile of the game grid.  The only restriction on placing these pit cards is that pit cards may not be placed on the four tile surrounding the tile the gold cart occupies.  The tiles marked with red X's in the image below cannot have pit cards placed on them.

Nope!

Make sure your game grid contains four pits before proceeding.

Each team draws three cards from the deck and lays them face-up on the their factory spaces.  Factory spaces are the spaces with images of factories printed on them.  There are six factory spaces - three for each team.  The factory spaces attached to your team's town is your team's factory.

Order of play:

The game is played with four players separated into two teams of two players each.  The red team controls the two red carts, and the blue team controls the two blue carts.  Teammates share control over their carts and track cards.  Teammates are expected to communicate each turn and come to an agreement on the optimal moves to make.

To determine the order of play, all players must reveal their middle names.  Play starts with the team whose player has the most embarrassing name as determined by consensus.  Players who choose not to reveal their middle name automatically forfeit the chance for their team to move first.  If a starting team cannot be determined with the aforementioned middle name shenanigans, players must play a rote (read: not very fun) game of rock, paper, scissors to determine the order of play.

What does a turn look like?

Each turn is separated into four distinct phases:

• Lay track
• Pull lever
• Move mine carts
• Discard/draw

These phases will be described in detail in a future post.

Wordy.  I warned you.

Cheers,

Danny

Things You've Learned

I listen to a lot of podcasts.  Walking - /Filmcast.  Homework - Idle Thumbs.  Cooking - Latest in Paleo.  Working - Rebel FM.  It's a long list.  You can tell a lot about a person solely from the podcasts they subscribe to.  I always seem to have earbuds in.  If there isn't anybody around for me to talk to, I'd rather not sit in silence.

Anyway, I recently went on a podcast downloading spree.  Doing so, I felt like I imagine I would if everything at Toys R Us were free - me with a cart running down the aisles grabbing four of everything, second guessing myself on the way out the door, dumping the cart, filling it again exclusively with Nerf guns and LEGOs, shooting Nerf darts at cars on my drive home.  When my download queue emptied, I ended up with a library full of guided conversations about game development and unguided conversations about current happenings in the game industry.  I was grabbing blind, but I may have pulled out a winner: The Game Engine.  Tagline: A podcast about game development by developers, for developers.  I haven't dug too deep yet, so I have no idea which studios these guys work for, but from listening to the episode, it's obvious at least a few of the hosts/guests are indie developers.

I caught up with the cast on its one year anniversary.  Here, the five developers each shared three things they've learned over the past six months about making games.  Some of the things that were said hit me harder than I thought any of it could, so I'm going to sling it back into the ether in hopes that it connects with someone else.

In an indie game studio, change is the only constant.  Be prepared to wear a lot of hats.

Game development is like steering a car crash.

Make games for yourself.

Remember why you do what you love and pick your path wisely.

Choose values, not goals.  Choose directions, not objectives.

It is vitally important to teach yourself how to switch between your left and right brains, between regimentation and stream of consciousness.

Being young is the opportunity to drop everything and hold on to the one thing you want.

Values are discovered through process of elimination.  These values are the last things you will let go of when everything else is gone.

As a young person, you don't know your limits, so don't impose limits on yourself for what you want.

Maintaining a presence is a lot of work.  Realize what energy you have, and what in your life subtracts from this energy.

For the curious, here are some other podcasts I frequent:

• Another Castle
• Brainy Gamer
• Double Fine Action Cast
• The Game Developer's Radio
• Gamewave
• Giant Bombcast
• IndieGames.com Podcast
• The Infinite Ammo Podcast (I wrote something about Infinite Ammo in August)
• A Life Well Wasted
• The Pixar Podcast
• Pixel Junk Radio
• Retronauts

Moment of irrelevance: No idea why, but I can't help but imagine all who podcast sipping something from a mug while recording.  I like to imagine these mugs are filled with hot chocolate.  Hot chocolate seems like an exemplary beverage to build a conversation around.

Relevant: I'm young and trying to find that one thing I want.  Maybe game development is it.

Cheers,

Danny

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

LD24 Prototype

Musings from LD24 part III.

Friday, 11:06 PM.

I was still doubting my ability to create a compelling game experience from my color idea.  I knew dwelling on this doubt and uncertainty would only waste time, so, instead, I decided to prototype what I believed would be the primary mechanic  - two squares mating with each other.

First, I listed out everything I thought I'd need to implement in order to get this mechanic into a playable state:

• I need to be able to detect when the player square is interacting (colliding) with an NPC square.
• I need to be able to detect player keyboard input for movement and the "sex" command.
• I need to create a new character on screen after the "sex" command has been input.
• After this new character is created, I need to transfer player control from the currently controlled square to the new square.
• I need to perform some process so that characters who have already mated cannot mate again.

Next, I opened up Stencyl and started learning.

A few hours of tinkering later, this popped out:

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

Move left and right with the arrow keys.  Jump with X.  Have sex with F.  You must be on top of an NPC square to have sex.

Cheers,

Danny

Down To Business

Musings from LD24 part II.

I decided to roll with the color idea I introduced in my last post.

I wanted my game to consist of a single, tall screen.  The initial game screen would contain only the player square and an NPC square.  Everything on screen, barring the two characters, would be a single, flat color.  Starting the game, the only thing the player would be able do is walk over to the NPC and mate with it.  Mating would produce a new character on screen that the player would immediately takes control of.  Along with the new character, every act of mating would cause new elements to appear in the environment.  Some of these elements would be purely aesthetic while others would serve as a means of helping the player explore more of the world that would exist off the top of the screen.  For instance, after the first act of mating, a series of platforms acting as a staircase would reveal themselves, encouraging the player to travel upwards off the screen in search of a mate for their new character.

The goal of this game was for players to explore the world.  Tasking myself with creating a world that players would genuinely enjoy existing in was daunting.

If you've played what I ended up crafting, you know the final product is far from this initial vision.  What happened?

That's a story for tomorrow (or the next day).

Cheers,

Danny

Brainstorming

Musings from LD24 Part I.

8 PM.

Evolution.

The first thing I did was make a list of things I think about when I think about evolution:

• Pokemon
• Spore
• The Evolution movie with David Duchovny
• (I drew a picture of a smily face with three eyes)
• Now --> better
• Neolithic Age
• Hunter-gatherers --> farmers
• Wolf --> dog
• Water --> land
• Metamorphosis
• Mutation
• Natural selection
• Genetic drift
• Simple --> more complex

My first idea came shortly after my last bullet point.  I wanted to make a game about the evolution of color vision in primates.  Weird.  Interesting.  I liked it.

I jumped into the Internet, and pulled out some research.

Evolution of color vision in primates
Primate Color Vision

Ability to perceive red and orange hues allows tree-dwelling primates to discern them from green.  This is particularly important for primates in the detection of red and orange fruit, as well as nutrient-rich new foliage, in which the red and orange carotenoids have not yet been masked by chlorophyl.

Another theory is that detecting skin flushing and thereby mood may have influenced the development of primate trichromate vision.

Taking this, I wanted to make a side-scrolling platform game about colors.  To start, the game world would consist of a single color.  As the player progressed, more and more colors would populate the world.  These colors would represent new obstacles, destinations, and points of interaction.  This was perfect for me because I could do colors without complex sprites or animations.  I was unsure how a player would unlock new colors for the world, however.  This lack of primary game mechanic put a pretty large hole in my idea and initial high.

Concurrently, I was playing with the idea of making a game about forming communities.  The Neolithic Age was a turning point in human civilization as that was when farming became a widespread practice.  With farming came large, settled communities of people.  This community building was a huge step in the evolutionary process to modern man.  I liked the big picture idea, but no interesting ideas for a game came to me from it.

All of this happened in the first 90 minutes.  Like I said yesterday, it'll take me a few days to recount my Ludum Dare experience in full.

Cheers,

Danny

Evolution

Here's my submission for Ludum Dare 24.

The theme was Evolution.

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

Move left and right with the arrow keys.  Jump with X.  Have sex with F.

I learned a lot.  I'll be ruminating for the next few days.

Note: I didn't actually submit my game into the Ludum Dare competition.  I just used the competition's theme and deadline as a motivator.

Cheers,

Danny

Some Inspiration

http://www.doitmotherfucker.com/

Cheers,

Danny

Ludum Dare 24!!

I'm participating in Ludum Dare 24!!

What is Ludum Dare?  Here's some knowledge:

Ludum Dare is a regular accelerated game development Event.  Participants develop games from scratch in a weekend, based on a theme suggested by the community.

Ludum Dare was founded by Geoff Howland, and held its first competition in April 2002.  Since then the community has run more than 22 regular Events, several dozens of practice competitions, collectively creating many thousands of games in just a weekend each.

The events attract developers from all sides of the industry.  Students, hobbyists, industry professionals from many well respected game studios, as well as many independent game developers.

For many people, it can be difficult to find or make the time to create a game or prototype for yourself.  We're here to be your excuse.

My tools: Stencyl and Paintbrush (a Mac equivalent to Paint)

My plan: Tear down the theme to a mechanic or concept that can be conveyed with simple geometry.  Use a music track from my iTunes library without permission.  Learn Stencyl along the way.

T-minus 53 minutes.

Cheers,

Danny

Here's A Breathing Exercise

I found this while reading this.

Take a deep breath and hold it tight.  As you hold it tightly in your chest, imagine the tightness is shrinking you down into a bug.  You've held your breath so hard that you're an insect.  And all the other bugs saw you shrink and they loved the stunt.  They're clapping and rubbing their feelers together madly.  But you had an apple in your hand when you were big and it just caught up with you, crushed the whole crowd.  You're dead, too.  Now exhale.

Try it.  Right now.  You'll feel better.

Cheers,

Danny

Don't Be A Vidiot

From snow-draped forests filled with lunatics carrying paint guns, to convention centers filled with people wearing costumes and playing 'in character,' to schoolyards where kids pore over looseleaf binders containing MAGIC cards, to pudgy 40-something guys in glasses hunched over a sandtable where lead Napoleonic armies clash, to blaring arcades and smart- assed 20somethings with near-obscene online nicks, the sheer variety of game styles is staggering.

So how come you're working on another goddamn shooter?

If the universe of gaming if filled with so many diverse styles, why is computer gaming stuck in such a rut?

Let's see some imagination, guys.

This excerpt was from a rant Greg Costikyan gave at the 1998 Game Developers Conference.  1998!  The rant was titled Don't Be a Vidiot: What Computer Game Designers Can Learn From Non-Electronic Games.  What Greg said in 1998 remains true today.

We have a lot of work to do.  I think I can help.  Give me time.

Cheers,

Danny

Defused

If you haven't read yesterday's post, read now or forfeit the fun of deciphering a first-timer's attempt at writing riddles.

Riddle 1

The order of the wires: yellow, green, blue, orange

The riddle: "My primary focus is avoiding compliments."

Answer: yellow

This riddle centers around the color wheel and there are two (similar) thought processes to arrive at the correct solution.

First, the word "primary" is meant to suggest one of the three traditional subtractive primary colors (yellow, red, blue).  The phrase "avoiding compliments" is meant to suggest that the complimentary color that pairs with the color of interest is not present.  Only two primary colors exist here: yellow and blue.  Orange is blue's compliment, so the yellow wire is the correct wire.

The solution can also be found without realizing that the correct wire is a primary color.  Blue and orange are a complimentary color pair.  "Avoiding compliments" suggests that the wire we're looking for is not physically near the blue or orange wires.  The green wire is sitting next to the blue wire, so the yellow wire is the only possible answer.

Riddle 2

The order of the wires: blue, yellow, purple, red

The riddle: "I live in a well-known circle with all of my best primary and secondary friends.  Including myself, our circle numbers six.  Today, my neighbors are absent, and I seem to be the only one receiving any compliments."

Answer: yellow

The first two sentences suggest a color wheel consisting of only the primary and secondary colors.  Starting from yellow and traveling clockwise, this wheel would include the following colors: yellow, orange, red, purple, blue, green.  "... my neighbors are absent" suggests that the two colors that sandwich the color we're looking for as they exist on the color wheel are NOT present.  "... I seem to be the only one receiving any compliments." suggests that the color that forms a complimentary pair with the color we're looking for IS present.  With the six possible colors written out, it's easy to see that orange and green (yellow's neighbors) are absent while purple (yellow's compliment) is present.  Thus, the yellow wire is the correct wire.

Cheers,

Danny

It's Da Bomb!

This comes straight out of Challenges for Game Designers.

The challenge: You're designing a game based on the old TV show MacGyver, and part of the storyline in the game involves the main character diffusing a bomb.  Rather than making it a non-interactive cutscene, you've chosen to make it into a timed puzzle, where taking too long to solve the puzzle or solving it incorrectly results in the game being over.

Consider the different kinds of puzzles mentioned in this chapter, choose your favorite type, and create a working prototype puzzle.

First, the kinds of puzzles mentioned in the chapter: riddles, lateral thinking, spatial reasoning, pattern recognition, logic, exploration, and item use.

I found myself eyeing the riddles pretty aggressively.

Riddles are questions that have one right answer, but that answer is not obvious.  Typically, a riddle involves a play on words that requires the player to interpret it in a nonstandard way in order to solve it.

For fun, grab a stopwatch and see if you can solve each of these in a minute or less.  Read fast!

Riddle 1:

Before you sits a bomb and a handwritten note.  You're actually not sure if it's a bomb, but there's a mess of wires sticking out of an ominous looking metal case with a timer strapped to the top.  So, it's probably not a bad guess.  You are confident that the note is a real note however.  And what a befuddling note it is!  You've got 30 seconds left before the timer hits zero.  Still not entirely convinced what sits before you is capable of exploding, you feel compelled to be proactive.  Following the directions on the note and with no better ideas, you decide to cut one of the wires.

The wires sticking out of the case, connecting the case to the timer exist in the following order:

Yellow, Green, Blue, Orange.

Besides telling you that you must sever the correct wire to save yourself from painting the wall behind you, the note offers only a single line:

"My primary focus is avoiding compliments."

Riddle 2 (identical setup):

Before you sits a bomb and a handwritten note.  You're actually not sure if it's a bomb, but there's a mess of wires sticking out of an ominous looking metal case with a timer strapped to the top.  So, it's probably not a bad guess.  You are confident that the note is a real note however.  And what a befuddling note it is!  You've got 30 seconds left before the timer hits zero.  Still not entirely convinced what sits before you is capable of exploding, you feel compelled to be proactive.  Following the directions on the note and with no better ideas, you decide to cut one of the wires.

The wires sticking out of the case, connecting the case to the timer exist in the following order:

Blue, Yellow, Purple, Red.

Besides telling you that you must sever the correct wire to save your current dimensions, the note says the following:

"I live in a well-known circle with all of my best primary and secondary friends.  Including myself, our circle numbers six.  Today, my neighbors are absent, and I seem to be the only one receiving any compliments."

If you're looking for a hint, highlight between the vertical bars.

| The Color Wheel |

I'll post my solutions and reasoning tomorrow.

Author's note: It's Da Bomb! is the title of the challenge as printed in Challenges for Game Designers, and it's my favorite title ever!

Cheers,

Danny

Constraints

Freedom to work in the most logical and efficient way possible is the very opposite of gameplay.

Take golf.  The goal of golf is to land a ball in a cup in the ground.  The most logical and efficient way to achieve this goal is to pick up and carry the ball to the cup.  This isn't golf.  This isn't fun.  Golf is formed from the goal by adding constraints.  Constraints such as: A player may only move the ball by striking the ball with a club.  Add: A player's club swings for each hole will be counted and a handful of other constraints, and you end up with something that resembles golf as we know it.  Constraints, or rules, are integral to games.  I cannot think of a single game where the most efficient way to accomplish the goal is the recommended way.

Cheers,

Danny

My Apologies

While reading yesterday's post for typos, I realized the size of the text between and within published posts has not been consistent.  My apologies.  I'm pretty sure the problem exists because sometimes I type these things up in a text editor and then paste them into Blogger rather than typing directly into the Blogger interface.  I think Blogger has a hard time seeing this pasted text and cannot properly adjust its properties.  The text discrepancies are not overtly apparent, but I bet things will start to look funny if I ever change the default type.  I'll be more mindful of this going forward.

While I'm apologizing, sorry for how random my posts are.  Besides playing them, everything about games is new and exciting to me.  I write about what I learn, and right now I'm learning a lot from a ton of different resources.  Further down the line, my focus may narrow, but until that time, expect things to continue as they've been.

Cheers,

Danny

Back To School

Classes start on Monday.  I usually don't care much about school, but I'm pretty excited this time around.  Mostly, I'm looking forward to the huge amounts of free time the early part of a semester (usually) grants us students.  Coming off of a full-time job, this change in available free time can be welcomingly drastic.  Even while maintaining a part-time job, until midterms roll around, I usually have enough empty time on my hands to take two naps a day.  I can't promise anything, but this semester I'm going to attempt to turn some of that nap time into 'Danny is learning how to make games' time.  This semester also has me excited because two of my classes are actually about games!

Here's my schedule:

• Database management systems
• Advanced game programming
• Operating systems,
• Introduction to applied statistics for IS&T
• Game design as art
• Internship in computer science

Here's the course description for advanced game programming:

This course is intended for those with an interest in video game programming. This course introduces the advanced concepts of game programming including 3D programming, game networking, and development of a multiplayer, networked game by learning and using the XNA environment.

I read the introduction of the textbook for this class, and it looks like I'll be learning some C# and .NET.  I've never had any exposure to C# as a language or .NET as a framework, and I'm excited to learn something completely new that I'm not sure I'd ever peruse on my on time.

And game design as art:

This course will encompass theory and practice of game development, game creation as an art process, and an exploration of the work of artists who have created game based work. 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.

I'm really excited about this one!  Even with the course description, I don't know what expect.  There's no required text, so sky's the limit I guess.  I'm really glad this course is offered through the art department rather than the CS department.  I haven't spent a whole lot of time around art majors during my university time, and am looking forward to different perspectives on games.

These two classes are obviously pretty darn relevant to what I've been documenting on this blog the past 40 or so days, so expect to hear some of my tales from the classroom.

If you're curious, here's where I go to school and here's where I take most of my classes.

Cheers,

Danny

Cadence

The challenge: Design a board-game adaptation of any video game.  This game should be playable without the player having to design anything!

My first idea was to turn Mario Kart into a board game.  Mario Kart lends itself perfectly to a race to the finish-style game, and most of the elements from the digital game could be directly ported to a physical game with little abstraction.  While not difficult to get a prototype up and running, I think creating a genuinely fun board game from Mario Kart would prove challenging, but I wanted to try something less obvious.

My second idea was to transform the battle and progression systems of Paper Mario into a card game.  I had a lot of ideas, but ultimately, I felt like my game design was  becoming too similar to a card game called Munchkin.  Because of the similarities, I decided not to pursue this idea.

For some reason, the next game the jumped on my brain was Amplitude.  If you derive any kind of joy from rhythm games, you need to track down a copy of Amplitude!

Amplitude is set in a future where street lanes represent musical instruments, and each lane is studded with copious amounts of music nodes.  In this future, people don't drive cars, they drive magic, music-generating vehicles.  These vehicles have the power (some argue the responsibility) to hit the music nodes as they hover over them.  Every hit node adds a beat or note to the song.  If a vehicle hits enough nodes in sequence on a single lane, that lane will jam all by itself for a while.  In Amplitude, the player is given control over one of these vehicles and is responsible for hitting the nodes.  The idea is for the player to hop between lanes, nail the patterns, get the music going, and keep as many elements of the song playing for as long as possible before the song and level ends.  Within each lane nodes can take one of three positions.  Buttons on the controller are mapped to these positions.  Blah, blah.

That's Amplitude.  It's awesome!

After reading about a bunch of alternate reality games in Reality Is Broken, I wanted to create a game that forced players to interact in a very direct manner.  I wanted to crate a social experience.  What I was looking to do, I didn't know how to do with a card or board game, so this design is a little out there.  I took some liberties with the challenge rules by not making a board game, but the idea beckoned.  Who am I to ignore?  The game is simple, requires little setup, and if it plays anything like it does in my head, there should be a lot of laughing.  You'll need a metronome, three or more friends, and enough space to wiggle your limbs about.

For those not in the know, a metronome is a device used by musicians to keep time.

It might look like this.

Or this.

In Cadence (My game has a name!), one player takes on the roll of the magic, music-generating, hovering vehicle while every other player (there really isn't an upper limit) takes on the roll of a lane.  The lane players stand in a row facing the vehicle player.  The goal of the game is for the vehicle player to simultaneously activate as many of the lane players as possible which in turn will create many layered rhythms.  It'll sound beautiful, I promise.

In order for the vehicle player to activate a lane player and get some music going, he/she must first choose a lane player to face off with.  The vehicle player can only face off with a single lane player at a time.  During a face off, the lane player performs some action that the vehicle player must mimic.  Before starting the game, players may place restrictions on the actions a lane player may do, but as far as I'm concerned, anything goes.  Actions can include dancing, singing, hugging a stranger, sprinting to a nearby tree, or even scaring a small child who got just a little too curious about the teenagers having fun in the park.  Whatever the lane player does, the vehicle player has to copy if he/she wants to activate that lane.

This game isn't played with any hard and fast rules, so the success or failure of the vehicle player's mimicry is determined by the lane player who initiated the action.  Upon failure, the vehicle player may attempt the action again or move on to an unactivated lane.  Once the vehicle player has completed the action, the lane player who owns that action starts clapping a pattern to the timing of the metronome.  Clapping continues for as long as the lane player deems appropriate (again, no hard and fast rules).  The vehicle player hops between lane players, mimics their actions, and by doing so, adds more clapping patterns to the mix.  Each lane player must clap a different pattern.

Lane players may also change the action they want mimicked every time the vehicle player comes to them for a face off.  This includes the scenario where the vehicle player attempts to copy the lane player, fails, moves on to a different lane, and then comes back to the original lane player for another go.

Again, the goal of the game is to create music from different clapping patterns.  The music gets more complex the more lanes get activated.  The game continues for as long as they players want to keep playing, or until one of the lane player wants to take a crack at being the futuristic, magic, music-generating, hovering vehicle.

I haven't had a chance to play Cadence yet outside of my head.  I know, I know.  90 percent of the battle is iteration.  But, as you can probably imagine, Cadence can be a tricky idea to sell.  When I do convince some friends to play, I promise I'll film it.

Cadence is a synonym for rhythm, so that's where the name comes from.  Also, to me, cadence sounds serene.  I like the dichotomy between what cadence sounds like and the craziness of the gameplay.

Cheers,

Danny