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
Tuesday, November 6, 2012
Tuesday, October 30, 2012
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
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
Friday, October 26, 2012
Programming Advice
Do not ever leave the computer if your program does not run.
Andy Gavin, Naughty Dog Co-Founder
Cheers,
Danny
Andy Gavin, Naughty Dog Co-Founder
Cheers,
Danny
Wednesday, October 24, 2012
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
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
Sunday, October 21, 2012
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
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
Thursday, October 18, 2012
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:
They provide some great examples of this game vocabulary in action:
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
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
Tuesday, October 16, 2012
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:
I'm not linking to any of this awesome content directly. Be kind, go to tiny Build. Watch. Watch everything.
Cheers,
Danny
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
Subscribe to:
Posts (Atom)