Tim Schafer On Game Development

I love this.

The way it felt, I know this doesn't make any sense, but in my head, the creative process of making a game is like you're looking at this field of floating, multi-colored dots.  They're drifting slowly to the ground.  And eventually when they hit the ground, they're going to make like a painting on the floor.  But you've got to kind of like move them around… And as they fall, you start to see where you need more color and you move them around.  And slowly they settle.  And then you're done.

Cheers,

Danny

New Twine Project

I'm announcing my next Twine project.  I don't have a name for it yet, but I do have a theme and I know how player choices will affect the flow of the story.  Expect to see it posted on this blog sometime this weekend.

[Update 08/05/2012: My next Twine project]

Cheers,

Danny

Game Making Tools

This is a great time to be interested in games.  We live in a time where game making tools have reached that special level of sophistication where everyone interested in making games can actually do it.  No previous experience required.  No coding necessary.  You don't even have to purchase your own domain name to share your work online.  For those with some programming experience, we live in a time of copious game libraries and dedicated SDKs for game creation.  Pick a language, any language, and I'll bet somebody somewhere has created game making tools specific to that language.  These truly are great times.

With so many options, I don't know where to start.  There are just too many damn things I want to learn!

It only took me three or four minutes to compile the following list of potential tools, libraries, languages, APIs, and development kits I'd like to utilize in my projects at some point:

• Construct,
• Stencyl,
• Corona SDK,
• cocos2d,
• Slick-2D,
• GameMaker,
• Scratch,
• Unity,
• Torque,
• Flixel,
• ActionScript,
• FlashPunk,
• Klick & Play,
• Games Factory,
• Inform 7,
• Knytt Stories, and
• ZZT.

Obviously, everything listed serves a different purpose and requires a different time commitment to gain proficiency.  Some are all-in-one game making tools that require nothing in terms of programming.  Some are entirely new languages for me that require everything in terms of programming.

Like I said above, I don't know where to start.  Slow.  I think I'll start slow.  When I get moving, I'll post something.

Cheers,

Danny

Understanding Games

Understanding Games is a series of flash games designed to teach players about games through gameplay.  There are four games in the series.  This post includes the major ideas presented in each of them.  Even after reading through this post, I encourage you to play through the games yourself.

Understanding Games 1

Rules of the game define the possible actions of the players.  Rules are unambiguous, intelligible and apply for all players.

No game can be played without the interaction of the player.

The outcome of a game has to be uncertain, otherwise it loses its appeal.

Computer games simulate or change properties and processes of the real world.

Rules and representation of a game are not independent but interact with each other.

Understanding Games 2

Players require clear and immediate feedback to understand the relationship between action and outcome.

Players require a clear goal so they can perform meaningful actions within the game.

Conflict and competition are essential for the player's motivation.

The challenges of a game should match the skill of the player: Neither too easy (boring), nor too difficult (frustrating).

Understanding Games 3

Many computer games are playable without having to read the manual.  Instead the player learns to play them through trial and error.

The player performs actions within the game world and observes how these actions change the state of the game.

The player forms a hypothesis about the meaning of an object or action on the basis of his or her studies.

The player recognizes and learns fundamental patterns within the game and can apply these to different situations.

Understanding Games 4

The game theme has an impact on how the game appeals to different kinds of people.

The more abstract a game character, the more players will be able to identify with the character.

The controls of a game character can be direct or indirect and have an impact on the relationship between player and character.

Often the player can select between different characters, which facilitate different strategies to play the game.

Cheers,

Danny

Iteration

The challenge: Play your 15-minute race to the finish game you made during the last challenge.  Is your game fun?  Why or why not?  What could you change about your game to make it better?  After playing your game, make at least one change and play again.  Note the differences this change has brought.  Has the change made your game better or worse?  Are there any additional changes you can think to make?  Continue iterating until you are satisfied with your game.  Identify the elements of your game that have changed and reflect on why these changes have improved the experience.

My first go at a board game was not particularly fun and very much unbalanced.  Playing it, the games were rarely close.  Either the game ended almost immediately, or one player pulled too far ahead of the other for the game to be fun.  This was the first problem I hoped to solve with iteration of design: Introduce elements that provide a greater likelihood that the players will remain close together while traveling across the game board.

I redrew my game board before beginning the iterative process.  Before, the path was a single straight line.  Now, the path weaves back and forth creating a box-like shape.  This new path layout proved very influential in my design decisions.

My new game board and pieces

I tried solving the problem in a number of ways.  First I adjusted and then re-adjusted the special spaces on the board.  These special spaces, if landed on, influence player movement.  If this doesn't sound familiar, check out the post where I discuss my 15-minute race to the finish game.  Some configurations of the special spaces worked better than others, but none achieved the result I was looking for.

Next, I tried giving the compiler player a head start by as many as six spaces.  Again, some playthroughs with this rule in place showed promise, but it was far from a solution to my problem.

After this, I introduced a second play piece for the syntax error player to use.  With this second play piece, the rules governing my game, especially for the syntax error player, changed drastically:

• The syntax error player rolls one die per turn.
• Each turn, after rolling the die, the syntax error player must choose one of his play pieces to move.  I will refer to these two play pieces as the "Hero" and the "Sweeper" from this point forward.
• The Hero can only move forward and must follow the path laid out by the game board.
• The Sweeper can travel either up the columns of the game board or right across the rows of the game board. (this movement was inspired by my new square game board with the weaving path)
• The Sweeper can only travel in a single direction per turn.  For instance, if the syntax error player rolls a five and chooses to move the Sweeper, the Sweeper cannot travel two spaces to the right and then three spaces up.
• If the Sweeper reaches the top of a column or the right edge of a row, the Sweeper continues movement from the start of that same column (bottom of the column) or row (left side of the row).
• If the compiler player crosses paths with the Sweeper during his/her turn, movement for that turn stops no matter how many more spaces the dice afforded him/her.
• If the Sweeper lands on the same space as the compiler player, the compiler player is not allowed to move at all during his/her next turn.

These new rules co-existed with the ones I had already established.

I really enjoyed the results this mechanic produced.  The players were experiencing the game much closer together on the path which is what I set out to do.  After playing a few times, I noticed another problem with my design: For the compiler player, there was nothing to do but roll dice.  There was no decision making, no way for him/her to influence the game at all.  I liked the new mechanic I had introduced to the syntax error player and decided to run with that just a bit further.  I bestowed a second game piece upon the compiler player as well, rewrote the victory conditions, and scrapped my initial theme.

New rules:

• The game board is arranged in a square with the play path weaving back and forth across the board.
• The game can be played with two-five players. (I will describe the rules in terms of only two players for simplicity)
• Each player controls two game pieces, the "Hero" and the "Sweeper".
• Both players (all four pieces) begin on the same space of the play path, the space labeled "Start".
• Order of play is determined by a dice roll.
• Play alternates between the players (two players) or in a clockwise fashion (more than two players).
• On a players turn, he/she rolls two dice.
• The player decides which die to associate with which game piece (Hero or Sweeper).
• The Hero can move forward and must follow the path laid out by the game board.
• The Sweeper can travel either up the columns of the game board or right across the rows of the game board.
• The Sweeper can only travel in a single direction per turn.  For instance, if the player rolls a five with one of the dice and associates that die with the Sweeper, the Sweeper cannot travel two spaces to the right and then three spaces up.
• If the Sweeper reaches the top of a column or the right edge of a row, the Sweeper continues movement from the start of that same column (bottom of the column) or row (left side of the row).
• Both game pieces must be moved each turn, i.e., one piece cannot move a number of spaces equivalent to the sum of both dice.
• If the Hero crosses paths with the opposing Sweeper during his/her turn, movement for that turn stops no matter how many more spaces the die afforded the Hero.
• If the Sweeper lands on the same space as the opposing Hero, the opposing Hero is not allowed to move at all during his/her next turn.
• If the Sweeper crosses paths with the opposing Sweeper, the opposing Sweeper is forced over one column to the right.  The Sweeper is not affected by crossing paths with the opposing Sweeper and continues movement normally.
• The game ends when one of the player's Hero pieces reaches the space labeled "End".
• The player whose Hero piece reaches the "End" space first is the victor.

Reading through the rulesets, my new game has little in common with its source material.  Behold the power of iteration!  My new game, while not perfect, is much more fun to play.  I'm happy with how it turned out.

In the future, I might reskin this new game with a new theme since the syntax error/compiler theme doesn't fit the new rules.  If I come up with something clever, you can be sure I'll write about it here.

The one big takeaway from today is that the more you iterate on a game, the better it becomes. Great designers do not design great games. They usually design really bad games, and then they iterate on them until the games become great.

You want to have a playable prototype of your game as early in development as possible.  The faster you can playtest your ideas, the more time you have to make changes.

Lots of words.  Sorry for the length.

Cheers,

Danny

What Is Meant By Game Design?

For many, myself included, game design is an ambiguous topic.

Here's a definition I like:

Game design is the creation of the rules and content of a game. It does not involve programming, art or animation, or marketing, or any of the other myriad tasks required to make a game. All of these tasks collectively can be called “game development” and game design is one part of development.

There are many tasks associated with game design: system design, level design, content design, user interface design, world building, and story writing.

Cheers,

Danny

Race To The Finish

The challenge: Create a race to the finish board game in 15 minutes.

We were to draw a path with defined start and end points, choose a theme or objective, create rules that allow the players to travel from space to space, and finally, think of ways for players to interact with each other.

Here's what I came up with:

The path is straight and travel occurs in only one direction.

The game is played with two players. One player takes on the role of a syntax error.  The other player is the compiler.  Up to this point, the syntax error has lived his entire life on the stack (the play path) with no conflict.  Everything changes for the syntax error when the compiler discovers exactly where on the program stack the syntax error calls home.  The compiler needs to trace its way back up the stack in order to document its discovery of the syntax error.  If this happens, the programmer will be notified of the syntax error, and the error will be eliminated.

Context.  Conflict.  The race is on!

The rules:

• Both players start the game on the same space at the start of the play path (the bottom of the stack).
• Players advance by rolling dice.
• Each turn, the syntax error player rolls one die and the compiler player rolls two dice.
• The compiler player always rolls first.
• Every sixth space of the play path is a special space (signified with shading).
• If the syntax error player rolls an even number, the compiler player must backtrack to the nearest special space before continuing forward.
• If the syntax error player rolls an even number, but the compiler player is already on a special space, the compiler player does not need to do any backtracking.
• If the compiler player reaches the end of the path, the compiler player wins the game.
• If at any point during play the syntax error player lands on a space that is ahead of the compiler player, the syntax error player wins the game.

One of my concerns before doing any playtesting was that the game could potentially end after a single turn.  This would happen if the compiler player rolls a lower number with two dice than the syntax error player rolls with one.  I knew this was possible, but was unsure of its likelihood.

After playing my game a few times, it was clear that my game had serious balance issues.  Many times, the game either ended after the first turn or the compiler player pulled too far ahead of the syntax error player for the game to be fun.

The objective of this exercise was not to create a great, or even good, game.  This activity is meant to get people over their initial fear of being incapable of designing a game.  EVERYONE is capable of designing games.  It takes practice, time, and persistence to design good games, however.

From Ian's blog post:

If you take away nothing else from this little activity, realize that you can have a playable game in minutes. It does not take programming skill. It does not require a great deal of creativity. It does not require lots of money, resources, or special materials. It does not take months or years of time. Making a good game may require some or all of these things, but the process of just starting out with a simple idea is something that can be done in a very short period of time with nothing more than a few slips of paper.

Check out submissions from the rest of the class!

Cheers,

Danny

Challenges Await

I've started reading Challenges for Game Designers by Brenda Brathwaite and Ian Schreiber.  This book takes a hands-on approach to game design by teaching through assigned challenges that readers are expected to participate in.  A typical challenge includes designing a pen and paper game to some criteria, creating a playable prototype, playtesting, and then iterating on your design.

In 2009, Ian Schreiber, one of the books authors, hosted a ten-week online course about game design concepts to supplement and reinforce the content of the book he co-authored.  This course included bi-weekly blog posts by Ian, activities to do at home between the blog posts (typically additional readings or challenges pulled from the book), and a community of people reading the material and participating in the challenges together.  This community served as an invaluable source of feedback and encouragement.

In 2009, game development was far from my mind.  I didn't participate when this course was hosted live, but thankfully, Ian was kind enough to leave his hard work and that of his students online for all to learn from.

Next time you hear from me, I'll be elbow deep in design challenges.  I'll be posting my progress as I complete these assigned challenges.  Expect to see the results of the first one tomorrow.

You can find the blog where the course content is being hosted here.  Follow along!

Cheers,

Danny

Omaha Game Developers Association

Last Saturday I took a major step toward becoming active in the local game development scene: I attended my first Omaha Game Developers Association meeting.

The Omaha Game Developers Association is a local group that meets once-a-month to talk about game development - programming, design, art, sound, anything that relates to game dev.  There were nine of us there on Saturday, but I was told that these meetings have housed as many as 30 people in the past.  Just goes to show that no matter where you are or where your interests lie, it's always possible to surround yourself with like-minded individuals.  For me, these like-minded individuals were packaged and delivered straight to my door courtesy of the Omaha Game Developers Association.

We talked about the current projects people were working on, plans for future projects, necessary reading for game designers, psychology, and an armful of other topics I never thought about in the same space as games.  Last month, they watched Indie Game: The Movie together.  At other meetings, they've had professionals in the industry join the conversation via Skype.  Sometimes, they watch GDC lectures.  Some nights are demo nights.  There's a lot I hope to learn from these guys.

If you're interested, you can learn more about the Omaha Game Developers Association at their Website.

Something similar is bound to exist in your area.  It only took me a few Google searches to find the Omaha group.  If you try, I'm sure Google will show you the same kindness.

Can't wait for the next meeting!

Cheers,

Danny

1-1 Postmortem

1-1 story statistics:

• 28,223 characters
• 4,606 words
• 67 passages
• 103 links
• 2 spelling errors

These numbers are inflated due to some copy and paste between passages, but I still think they're damn impressive.

I'm thrilled to have completed my first project!  I set a goal, I set a date, and I made it happen!

Most of the production time was spent figuring out how I wanted to word each passage.  There are a lot of words when you choose a text-only medium.  Who knew?  I think I rewrote every passage at least three times.  Writing compelling narrative is tough, and this served as some much-needed practice.

1-1 is a very linear story.  I wanted it to be linear because I was working from some very specific inspiration.  If you haven't played through it yet, check it out.  You'll understand what I mean after completing it.

Linearity is not a strong suit of hypertext, so I will definitely be exploring a story with more meaningful branching for my next project.

Twine tips for the inexperienced user:

• When saving a Twine project, be sure to include the ".tws" extension.  Otherwise, Twine will not open your saved stories.
• When building a Twine project, be sure to include the ".html" extension.  Otherwise, you will be unable to view your work in a web browser.
• A nifty way to share your project with your friends, it to host the html files on Dropbox.  That's what I did.  It's easy.  You can learn how to do it here.

Cheers,

Danny

As Promised

Here's my first game!

http://dl.dropbox.com/u/64097119/Twine/1-1.html

Let me know what you think.

Cheers,

Danny

What Do I Want?

The title of my blog may be disingenuous to my hopes and desires of the moment.  With only one year of school left, it's time for me to start making decisions about where I want to take my life.  Honestly at this point, I'm not sure I want to work professionally in games.  I'm not sure I don't want to either.  I'm unsure because I don't fully understand the work involved.  Really, that's the entire focus of this blog.  I want to document my learning process.  I'm doing my best to learn something new about games every day, but who knows how long I'll need to keep at it before I find out whether or not I can (or want to) make it my career.

Sometime down the line if I stir all my game design and development experiences into a pot and deem it unappetizing, I won't pursue working in games professionally.  However, no matter what happens, I think I'll always want to make games.  There's a fascinating community of people connected to the games industry, and that's something I want to be a part of.

[Update 08/07/2012: I changed the name of my blog]

Cheers,

Danny

Ron's Wisdom

Ron Gilbert is widely considered the father of point-and-click adventure games.

"A good adventure puzzle never leaves you wondering what to do, only how to do it."

I want to make some puzzles in Twine.  I have no idea how to leverage Twine to handle complex or interesting puzzles or if these kinds of puzzles are even possible in a choose your own adventure-style game, but I want to find out.

That's an exercise for another time.  I have a deadline to make.

Cheers,

Danny

A Digital Goldmine

The amount of resources available online about game design and development is remarkable.  Here are three of the most thorough that I've found so far: Pixel Prospector, Ludology University, and Extra Credits.

If I were to do nothing else but read the content hosted on these sites, I'd be busy for a year.

And that's not saying anything about the 40 or so blogs by people living on the front lines of the industry I've bookmarked this past week.

I'll say it again, remarkable.  Through the work they're doing, these people continue to lower the barrier to entry.  That's great news for everyone who aspires to make games.

Cheers,

Danny

Prototyping

I read a phenomenal article about prototyping recently.

The article was written by four grad students at Carnegie Mellon.  In one semester these four students created more than 50 games!

Their rules:

1. Each game must be made in less than seven days.
2. Each game must be made by exactly one person.
3. Each game must be based around a common theme, i.e., "gravity", "vegetation", "swarms", etc.

Their results were truly unbelievable.

A good rapid prototyper would realize that failure is ok!  That's what prototyping is for...
Cut your losses and "learn when to shoot your baby in the crib"
Without a gameplay goal, a prototype is just a toy - not a game.

If reading's not your thing though, I also recently listened to a great podcast about prototyping.  Hearing these guys talk about their prototyping processes made me want to start carrying lots of little dice around with me in my pockets.  You never know when you'll need to test a gameplay mechanic!

In other news: Warioware: D.I.Y. arrived in the mail yesterday.

1-1 update: Writing is hard.

Cheers,

Danny

Deadlines

I've heard that a lack of deadlines is the reason many projects spiral into nothing.  I suppose that's why so many people find success in game jams.  Or why events such as the Independent Games Festival are so important for the community.

With that in mind, I'm setting a release date for my first project - this coming Saturday (July 21, 2012).

Here's what I'm thinking:

• Today: In written form, establish the series of events that are to take place.  Even though I've already spent some time thinking about the story, I still haven't written anything down!
• Tuesday and Wednesday: Get all of the story elements into Twine.
• Thursday: Write the story in a clever and witty manner.
• Friday: Commission my family to find word errors that have managed to sneak their way into all the great stuff I wrote.  Resolve any broken links.  Play the game lots and lots to make sure my brainchild doesn't explode when taking its first steps.
• Saturday: 1-1 will be playable from this blog.

That's my plan.

[Update 07/21/2012: My first game!]

Cheers,

Danny

1-1

1-1 is the title of my first game.  My first game!  That feels really good to type out.  1-1 is a choose your own adventure-style game made entirely with Twine, a game making tool I talked about recently.  It's a work in progress.  I'm not ready to show anything yet, but I've learned a few things since starting this project that I want to share.

First, Twine comes with an "actions" macro that I've been using quite a bit.  This macro allows a developer to define a list of actions that will be presented to the player.  The cool thing about actions is that Twine will only show the player actions that have not yet been seen in the current play session.

For instance, suppose a player enters a room with a bunch of doors (cyan, magenta, yellow, black) that can be entered.  These four doors would be mapped to an action, lets call it "doors action".  The player decides to open the yellow door and is greeted with a brick wall.  The next time "doors action" is called, yellow will no longer be displayed as a possible choice since that outcome has already been seen by the player.  I think that's pretty neat!

Second, working on this game has given me something to consider when making my next text-based game: Should I map all of the possible character interactions and branching paths first and worry about fine-tuning the writing last, or should I fine-tune the writing in tandem with brainstorming all of the decision making?  Currently, with 1-1, I'm spending a lot of time getting the text of each passage just right before moving on to any other parts of the story.  Example: I wrote the first passage with very little notion of the content that would be contained within the second, third, or fourth passages.

Whoa!  After writing down some thoughts, the way I'm currently working doesn't seem optimal, does it?  This blog is already giving back.  Who woulda thunk?  So, for the rest of 1-1's production (every game's a production people!) I'm going to try to map things out before drilling too much into the detail.

I love productive blog posts.

[Update 07/21/2012: My first game!]

Cheers,

Danny

Three Sample Twine Stories/Games

I'm unsure whether to refer to works created in Twine as stories or games.  They're interactive, so does that automatically suggest a game?  This seems like an topic that would benefit from a bit of pondering in the coming weeks.  What exactly is a game?

Another thought (the one eye flirting with the title of this post): I've been talking about Twine and hypertext stories/games for the past few days, and I realize my descriptions of both have been less-than stellar.  So, I thought it was high-time I slapped some faces with examples of what I'm talking about.  These stories/games (Games!  I'm committing to games!) are not my own.  I happened upon these while clicking thorough the interwebs.  For me, these three games do a great job of showing the diversity of content and emotional responses possible with strictly text-based gameplay.

These games will each only take a few minutes to click through, and they're all worth checking out.  So without further ado, here are the works of some guys and gals that beat me to the Twine party:

First, by Xebedee, the first part of a Medieval tale about romance, cheese, and windows, Kulhwch.

Next, by Skylar Moss, a poetic story of despair, peace, regret, and acceptance (one or even all of them at once), Drowning.

And finally, by Emma Fearon, emotionally impacting reflections on body image and the complexities of familial relationships, Calories.

Enjoy!

Cheers,

Danny

I Need To Play More Games

I need to play more games.  One: They're fun and they make me happy.  Two: How will I learn how to design and create fun games without learning and taking inspiration from what others in the industry are doing?

It really is pathetic how interested I am in making games contrasted with how little time I invest in actually playing any of them.  For the last year or so, I've spent considerably more time reading about games online than immersing myself in wonder and adventure (in that order) with controller in hand.  I think that's weird, and I want to change that.  There's definitely no shortage of great content to check out either.  I have plenty of games sitting on my Steam account that I haven't even bothered to open yet, including Amnesia: The Dark Descent, Bastion, Gish, Limbo, Lone Survivor, Psychonauts, Super Meat Boy, Superbrothers: Sword and Sworcery EP, Swords and Soldiers, and Toki Tori.

You don't have to say anything, I'm already embarrassed.

I do plan on writing a few posts about these games and others as I play them, but since the Internet is littered with whiny people posting gameplay commentary, I'll do my best to refrain from whining.  Even if I do partake in the occasional whine, however, I want to write about more than simply what I've been playing.  I plan on learning something from every game I play that will help lead me to a potential future in the industry, and that's what I want to write about.  That's all I can tell you for now because honestly, I'm not sure what I'm supposed to be looking for when playing these games yet.

Also, I started brainstorming some ideas for text-based games, so expect to see my Twine creations soon!

Cheers,

Danny

Twine

Today, I spent a few minutes reading about Twine.  Twine is a tool used to facilitate the creation of text adventures.  I've never played a text adventure game, but I'd like to make one (or a dozen).

Text adventure games are games presented to players entirely through text (or so I'm told).  Players interact with the text to solve puzzles, discover story elements, and progress towards some endgame condition.  Successful text adventure games connect passages of text in logical and clever ways.  Today, many text adventures utilize hypertext.  Hypertext is computer text that contains references to other pieces of text that users can access through mouse clicks.  Twine is a tool for writing hypertext so it's a perfect fit for managing a text adventure.

Twine comes with a nifty graphical interface to layout every passage of text in a story.  Passages linked in a story are connected visually in the interface.  Twine also informs users when broken links (links that don't connect to corresponding passages) are present.  Twine understands variables, conditional statements, and expressions.  These features can be used for simple things like inventory management or for more interesting things, like introducing randomness to a scenario.

Another cool thing about Twine: Twine publishes completed works in html.  This means the only thing your friends need to play through your stories is a Web browser.  Sharing doesn't get much easier than that!

I haven't made anything with Twine yet.  But I did go ahead and ask the Internet to borrow a copy of it for my desktop.  You can do it too!

Cheers,

Danny

I Want To Be A Zinester

A few weeks ago, I finished reading Anna Anthropy's Rise of the Videogame Zinesters: How Freaks, Normals, Amateurs, Artists, Dreamers, Drop-outs, Queers, Housewives, and People Like You Are Taking Back an Art Form.  The term zinester (he said without consulting wikipedia) refers to any self-published work of minority interest.  The self-published works of minority interest, in this case, being indie games.

What I took away from this book is this: There aren't enough people making games.  Recently, game making tools have progressed to a point where virtually anyone with access to a computer can create a digital game.  We're not talking months of development time either.  Thanks to these tools, in many cases, we're talking an afternoon!  Don't worry about perfection.  No excuses, embrace your ideas and just make something!  Make anything!

Did you notice all those exclamation points?  I must be fired up.  It's a good read.

Some of the game making tools Anna recommends in her book, include:

• Klick & Play and the Games Factory,
• Gamemaker,
• Scratch,
• Twine,
• Inform 7,
• Warioware: D.I.Y.,
• Knytt Stories, and
• ZZT.

First on my list, Warioware: D.I.Y.  I just ordered my copy from Amazon this afternoon, in fact.  I'll write about these tools (including my adventures with Warioware) in future posts as I become familiar with them.

I also just ordered two new books about video games and game design.  The first is Reality Is Broken: Why Games Make Us Better and How They Can Change the World by Jame McGonigal.  The second is Challenges for Game Designers by Brenda Brathwaite and Ian Schreiber.  Let the journey continue!

Cheers,

Danny

An Introduction

I've decided that I want to work in the games industry.  Shocking, huh?  A 21 year-old computer science major wants to make video games.  Definitely not an original story, like not even a little.  Honestly though, I never thought it'd be my story.  A year ago, I had little interest in games.  I didn't even play games, aside from the occasional round of 2 AM Geometry Wars, Castle Crashers, or Left 4 Dead with some buddies.  What changed?  No fucking clue.  But here I am.

I've never made a game.  I've never even tried.  I have no sense of what it takes to design games or the challenges that come with coding them.  This really is ground zero.  I read somewhere that it's important to document your progress when embarking on a new project.  This blog is my documentation.

It's gonna be long, dirty journey, and I couldn't be more excited.

[Update 07/21/2012: What do I want?]

Cheers,

Danny