I was thinking about this the other day, so I wanted to get it down here. What makes game design / programming different from all other types of software development? Sure, it tends to be more difficult due to the melding of many forms of technologies, different programming/scripting languages, advanced math, physics, the list goes on. But I'm getting at something else entirely.
The thing that intrigues me about game programming is simply this: As the developer, you have the ability to write some code, that when finished, can be able to provide endless fun and entertainment. The whole idea of writing something once, putting it on a disc or into an EXE and sending it out, only to be able to play that game and "create fun" each and every time you play it in new ways is really astounding. The game that really got me thinking about this was of course Grand Theft Auto. Therein lies a game in which all the work has been done, disc printed, shipped, sold. From there, anyone who plays this game can create their own fun, their own experience, and can do so for an unlimited number of years. All of this can be separate from what the makers of the game "intended" you to do, or it can include those elements as well.
Another way to think of this is that someone can create something, and from that something, they can turn it into anything they want. Think about a car. The car maker produces this vehicle to get its customers from place to place safely. The customer can then take that car and choose to do anything they want with it. They can race it, enter it into demolition derbies, enter it in car shows, use it to transport materials, etc... It's a limited example in comparison to Grand Theft Auto, but the same motif of creating a system of some sort, and then being able to jump into that system and envelop yourself in it, creating fun and experiences as you go.
Clearly, not every game is cut out for this type of adaptation, but I believe elements of this are possible in nearly every game. Keep this in mind as you design your game. Ask yourself, "Can the players of my game use elements inside the game to create their own fun/experiences that I didn't explicitly program into the game?"
-Z
Monday, July 21, 2008
Designing A Hockey Power-Play System: Part 2
After thinking about this for a few days, I've got some new thoughts about the whole thing. First off, in my previous post, I made a mistake. I stated that if the same team commits a second penalty prior to the first penalty expiring that we should set the 5 on 3 timer to (duration of the second penalty) - (remaining duration of the first penalty). In fact, each successive penalty situation after the first would be set to the lowest remaining time of all current penalties against that team. Even simpler is the fact that there are only 3 possible penalty levels: 5 on 4, 5 on 3, or 4 on 4. Remember, if a team commits a penalty when they are already at a 5 on 3 disadvantage, they remain at that disadvantage, but they have to sub a player out.
The reason this problem is so tricky is that all of this work is only to provide the heads up display to the user. That is, when you watch hockey on TV, it tells you when it's a 5 on 4, 5 on 3, or 4 on 4. Because of that, we can't simply just pull guys off the ice, each with their own timer, and put them back on when it expires. We have to keep track of the penalty situation (5 on 4, 5 on 3, 4 on 4, etc...) and also provide the user with the proper timing information for how long that particular situation will last.
In the background we'll handle penalties in that simple fashion of giving each player in the penalty box a timer and then when it expires, place him back on the ice. However, the tier system is what will handle the proper heads up display for the user.
That's all for now, I just wanted to write down the areas that I've cleaned up in these past few days. More to come soon.
-Z
The reason this problem is so tricky is that all of this work is only to provide the heads up display to the user. That is, when you watch hockey on TV, it tells you when it's a 5 on 4, 5 on 3, or 4 on 4. Because of that, we can't simply just pull guys off the ice, each with their own timer, and put them back on when it expires. We have to keep track of the penalty situation (5 on 4, 5 on 3, 4 on 4, etc...) and also provide the user with the proper timing information for how long that particular situation will last.
In the background we'll handle penalties in that simple fashion of giving each player in the penalty box a timer and then when it expires, place him back on the ice. However, the tier system is what will handle the proper heads up display for the user.
That's all for now, I just wanted to write down the areas that I've cleaned up in these past few days. More to come soon.
-Z
Wednesday, July 16, 2008
Designing A Hockey Power-Play System
In hockey (using NHL as my reference here), there is something called a "power-play", or alternatively referred to as a "man advantage". In hockey each team has 5 players on the ice at 1 time: 3 forwards, 2 defense men, and 1 goalie. Teams are allowed to pull their goalie out and add an extra skilled player (usually a forward) in order to increase their chances of scoring, but that's not important here. When a team commits a penalty (more accurately, when a player commits a penalty), that player must sit in the penalty box for a duration of time, either 2, 4, 5, or 10 minutes (depending on severity). During this time, the opposing team is said to have a "power-play" and a 5 man to 4 man advantage. Naturally, if the team on a power-play commits a penalty while they have a man-advantage, they will lose that player to the penalty box, and the teams will be in a 4 on 4 situation.
Additionally, if a team commits another penalty while they are already at a disadvantage, they can be reduced another man, and then they are on a 5 man to 3 man disadvantage. In the event a third penalty is committed by the same team prior to any of the previous two offenders being released from the box, that player will be substituted out of the game for a backup, and he too will go to the penalty box. Teams must always have at least 3 men on the ice, and no more than 3 in the penalty box. To make things even more troubling to deal with, power-plays carry over between periods. That is to say, if there is 1:30 left in the 2nd period and a team commits a 2:00 penalty, then that player will have to remain in the penalty box for the first :30 of the 3rd period.
So, what does this have to do with game programming? Quite a lot if you're making a hockey game! So, what are we left with? A very complex problem that needs solving! Being a huge hockey fan and clearly a game developer, I wanted to see what I could come up with solve this tricky issue. Sure, it's been done before, but not by me, so what good does that do me?
My rough general overview of how to deal with this goes something like this:
Anyhow, the way I'm working on tackling this is by using a tier system. The way it would work is that you could easily move up/down the penalty tier, sort of like Linux runlevels. For instance, if the teams are at equal strength and then team 1 commits a penalty, you move that team to penalty tier 1, which is a 4 on 5 disadvantage. If they commit yet another penalty, you move them to penalty tier 2, which is a 3 on 5 disadvantage. You handle the timers the same way as stated above, as all of that behavior would be encapsulated in the tier system. Then, when the first penalty expires, you move team 1 down from penalty tier 2 to penalty tier 1 (4 on 5 disadvantage), and etc...
If designed properly, any sort of flip-flopping with the team on the power-play committing a penalty should just work because the system would simply adjust the penalty tier of both teams, or something similar.
The details aren't clear yet as I'm just starting this, but I'll update this with what I've come up with as time goes on, but I'm very excited to find a decent solution!
Additionally, if a team commits another penalty while they are already at a disadvantage, they can be reduced another man, and then they are on a 5 man to 3 man disadvantage. In the event a third penalty is committed by the same team prior to any of the previous two offenders being released from the box, that player will be substituted out of the game for a backup, and he too will go to the penalty box. Teams must always have at least 3 men on the ice, and no more than 3 in the penalty box. To make things even more troubling to deal with, power-plays carry over between periods. That is to say, if there is 1:30 left in the 2nd period and a team commits a 2:00 penalty, then that player will have to remain in the penalty box for the first :30 of the 3rd period.
So, what does this have to do with game programming? Quite a lot if you're making a hockey game! So, what are we left with? A very complex problem that needs solving! Being a huge hockey fan and clearly a game developer, I wanted to see what I could come up with solve this tricky issue. Sure, it's been done before, but not by me, so what good does that do me?
My rough general overview of how to deal with this goes something like this:
- When a penalty occurs, remove the player from the ice and start a timer for the appropriate duration
- If another penalty occurs by the same team during that time, we'll need to save the time remaining in the first power play. Then, set the 5 on 3 timer to the Remaining Duration Of The 1st Penalty
- When the 5 on 3 timer expires, set the 5 on 4 timer to the remaining duration of the 1st penalty that we saved earlier.
- When the 5 on 4 timer expires, place the offender of the 2nd penalty back on the ice and return as normal
Anyhow, the way I'm working on tackling this is by using a tier system. The way it would work is that you could easily move up/down the penalty tier, sort of like Linux runlevels. For instance, if the teams are at equal strength and then team 1 commits a penalty, you move that team to penalty tier 1, which is a 4 on 5 disadvantage. If they commit yet another penalty, you move them to penalty tier 2, which is a 3 on 5 disadvantage. You handle the timers the same way as stated above, as all of that behavior would be encapsulated in the tier system. Then, when the first penalty expires, you move team 1 down from penalty tier 2 to penalty tier 1 (4 on 5 disadvantage), and etc...
If designed properly, any sort of flip-flopping with the team on the power-play committing a penalty should just work because the system would simply adjust the penalty tier of both teams, or something similar.
The details aren't clear yet as I'm just starting this, but I'll update this with what I've come up with as time goes on, but I'm very excited to find a decent solution!
Sunday, May 25, 2008
Blackjack
Been a while since an update, been busy, blah blah blah...
Now with that out of the way, Blackjack!
I decided to write a Blackjack game tonight. I've been thinking about it for a while. The real reason for the game is to create an AI for Blackjack which counts cards (tactic used to take advantage of the game). I wanted to see how much I could get done in a single night, starting from scratch.
In just 90 minutes, I have the following classes:
Player
Card
Deck
Player and Card are trivial. Player currently only keeps track of the money they have to bet as well as the running total of their current hand. Card has an enum for the Suit of the card. It contains a function to print out the name of the Suit (instead of just the 0,1,2,3), as well as a number holding the face value. Note that I don't care about the rules of Blackjack within the Card class which pertain to the value of each card, I follow the standard of 4 suits that hold cards valued 1-13. 4x13 = 52.
Deck is where the fun happens! A Deck object has an array of 52 Cards. Basically, a Deck is an array of 52 Cards, but you get the point. The Deck of Cards gets populated by the default CTOR using a nested for-loop. It's pretty straightforward beings that enums are treated as integers, so increasing the Suit is as simple as incrementing a counter, and the same of course goes for the face value of each card.
The fun stuff comes in when you realize you need to shuffle the deck. For the sake of brevity and getting something "quick and dirty" working, I implemented a really terrible swap mechanism. It's so terrible. Wow, is it bad. Well, O.K, it's not that bad... Here's how it currently works:
1. I maintain a list of available positions. Initially the values 0-51 appear in this list.
2. I loop over the Deck of Cards and I first save the current element in a temporary Card object.
3. Inside a do-while structure I generate a random number between 0-51 and then call a search function I wrote which iterates through my list of available positions.
4. If the number is found in the list, that means it's available for swapping. The return value is set and that number is removed from the list. If it isn't found, the do-while generates another value and tries again.
5. With the available position in hand, we swap the current Card with that in the position of the random number we generated.
6. Now, we place our temp Card object into the position of the element we just swapped (the one in the random number position of the Deck array)
7. All done, we've "swapped" one Card, now we do it again for the next card.
See, isn't that awful? Oh well, it works, and it will get better. So, basically I've got all of the basic mechanics for a card game working, whether it be Blackjack or anything else. Now I can focus on (fixing the above "problems" and...) implementing the Blackjack logic.
This just goes to show how much work you can get done in a very short period of time if you sit down and really focus. Of course, I had been thinking about the basics of how to develop this type of system, and I think that's a big reason I was able to flesh this out so quickly, but it was more about focusing on a task and just "doing it". That's the reason why I wasn't too concerned with how terrible of a Shuffle mechanism I was implementing. I knew it would work, albeit contrived and inefficient, but that's the key: Get it working, and then get it better.
I'll try to update this more now that Summer is here, but I will be busy with Google Summer of Code, so don't hold me to that. Cheers.
Now with that out of the way, Blackjack!
I decided to write a Blackjack game tonight. I've been thinking about it for a while. The real reason for the game is to create an AI for Blackjack which counts cards (tactic used to take advantage of the game). I wanted to see how much I could get done in a single night, starting from scratch.
In just 90 minutes, I have the following classes:
Player
Card
Deck
Player and Card are trivial. Player currently only keeps track of the money they have to bet as well as the running total of their current hand. Card has an enum for the Suit of the card. It contains a function to print out the name of the Suit (instead of just the 0,1,2,3), as well as a number holding the face value. Note that I don't care about the rules of Blackjack within the Card class which pertain to the value of each card, I follow the standard of 4 suits that hold cards valued 1-13. 4x13 = 52.
Deck is where the fun happens! A Deck object has an array of 52 Cards. Basically, a Deck is an array of 52 Cards, but you get the point. The Deck of Cards gets populated by the default CTOR using a nested for-loop. It's pretty straightforward beings that enums are treated as integers, so increasing the Suit is as simple as incrementing a counter, and the same of course goes for the face value of each card.
The fun stuff comes in when you realize you need to shuffle the deck. For the sake of brevity and getting something "quick and dirty" working, I implemented a really terrible swap mechanism. It's so terrible. Wow, is it bad. Well, O.K, it's not that bad... Here's how it currently works:
1. I maintain a list of available positions. Initially the values 0-51 appear in this list.
2. I loop over the Deck of Cards and I first save the current element in a temporary Card object.
3. Inside a do-while structure I generate a random number between 0-51 and then call a search function I wrote which iterates through my list of available positions.
4. If the number is found in the list, that means it's available for swapping. The return value is set and that number is removed from the list. If it isn't found, the do-while generates another value and tries again.
5. With the available position in hand, we swap the current Card with that in the position of the random number we generated.
6. Now, we place our temp Card object into the position of the element we just swapped (the one in the random number position of the Deck array)
7. All done, we've "swapped" one Card, now we do it again for the next card.
See, isn't that awful? Oh well, it works, and it will get better. So, basically I've got all of the basic mechanics for a card game working, whether it be Blackjack or anything else. Now I can focus on (fixing the above "problems" and...) implementing the Blackjack logic.
This just goes to show how much work you can get done in a very short period of time if you sit down and really focus. Of course, I had been thinking about the basics of how to develop this type of system, and I think that's a big reason I was able to flesh this out so quickly, but it was more about focusing on a task and just "doing it". That's the reason why I wasn't too concerned with how terrible of a Shuffle mechanism I was implementing. I knew it would work, albeit contrived and inefficient, but that's the key: Get it working, and then get it better.
I'll try to update this more now that Summer is here, but I will be busy with Google Summer of Code, so don't hold me to that. Cheers.
Friday, March 21, 2008
Team Game Project - Update
We had our first meeting today, it went really well. I met the girl from the music department for the first time today, she's really into the software side of the game, so that's a huge plus. At the meeting I basically gave them the run-down of my idea for the checkers game that I've mentioned in a previous post. It was more or less an absorption session for them to sort of get on the same page with me. I was/am open to another game idea, but they seemed to like it.
We seem to have agreed on using C++ and SDL, so I'm happy about that. I've got a pretty substantial project already completed using these technologies, so that should save us some time right off the bat.
They asked me to put together a design doc for the game, and I've now done that. I may attach it to the end of this post if I remember... As I was outlining the gameplay features I'd like to have in the game, it was amazing how quickly things branched into other things. It really sparks the creative process. I imagine that increasing when the other members of the team get into it and they'll form their own ideas as well, should be exciting.
The goal is to meet up again sometime soon and essentially play checkers offline and incorporate some of the gameplay tweaks. This will allow us to see what will work, what won't, and what needs to be adjusted. It should also give us some other ideas too. I can't wait for this stage, should be really fun. After that, the design document should be close to finalized and then we can start breaking the project down into tasks and assign people to them.
Sometime concurrently to all of this we'll be getting some server software setup to house some version control, simple website, maybe even spring up a blog just for the project, etc...
All in all the meeting was a total success. We were all able to communicate freely, everyone got along, and things just flowed. Very good signs. I'll keep you updated.
We seem to have agreed on using C++ and SDL, so I'm happy about that. I've got a pretty substantial project already completed using these technologies, so that should save us some time right off the bat.
They asked me to put together a design doc for the game, and I've now done that. I may attach it to the end of this post if I remember... As I was outlining the gameplay features I'd like to have in the game, it was amazing how quickly things branched into other things. It really sparks the creative process. I imagine that increasing when the other members of the team get into it and they'll form their own ideas as well, should be exciting.
The goal is to meet up again sometime soon and essentially play checkers offline and incorporate some of the gameplay tweaks. This will allow us to see what will work, what won't, and what needs to be adjusted. It should also give us some other ideas too. I can't wait for this stage, should be really fun. After that, the design document should be close to finalized and then we can start breaking the project down into tasks and assign people to them.
Sometime concurrently to all of this we'll be getting some server software setup to house some version control, simple website, maybe even spring up a blog just for the project, etc...
All in all the meeting was a total success. We were all able to communicate freely, everyone got along, and things just flowed. Very good signs. I'll keep you updated.
Tuesday, March 18, 2008
You are what you play
I figured it would be a good idea to compile the list of games that I have played extensively throughout the course of my life. I'll list them in no particular order of favoritism, but chances are they will be in chronological order simply because it will be easier to remember them that way as I'm making the list. For a game to qualify for this list, I should be able to name it off the top of my head after having been removed from it for over 10 years or more. I was serious about these games! Something to note is that when I was just a wee lad playing these games, I played them because I wanted to beat them, they weren't just entertainment. I'm sure a lot of people in this realm of life are the same way, though.
NES
(Note: This list is small due to the fact that I became semi-professionally involved with Madden, and it was just not ideal to play anything other than Madden)
(Yeah yeah, limited mainly to outdated first person shooters)
NES
- Mario Brothers 3 - Who didn't love this game
- Tecmo Super Bowl - The godfather of football games, step aside Madden
- Smash TV - Very fun, unique smash-em-up game
- Micro Machines - Great racing game, surprisingly challenging in areas
- Dig Dug II - Highly addicting, unique gameplay
- Adventure Island II - Cooler version of a Mario-style game
- Legend of Zelda - One of the best games ever made
- Mario Brothers - Again, everyone loves this game
- Ms. Pacman - Classic
- Al Unser Jr. Turbo Racing - Great simulation racing game
- Mike Tyson's Punch Out - Talk about a fun game
- Teenage Mutant Ninja Turtles II Arcade - Challenging gameplay
- Excitebike - Ahead of it's time. Level editor, are you kidding me? Fun!
- R.C Pro-Am - Great racing game, pretty challenging
- Bad News Baseball - Really fun
- Gunsmoke - Addicting, great sleepover game
- Sonic 2 - Just like Mario, everyone loves this great game
- Battletoads - Great gameplay, classic
- Madden 1995 - The start of a long relationship with me and Madden
- Ultimate Mortal Kombat 3 - One of the best games made for the platform
- Mutant League Football - Great alternative take on football. I still play this game!
- NHL 1995 - Really fun to play
- World Series Baseball - Very impressive on all levels. Home Run Derby mode is more addicting than crack.
- NBA Jam - One of the most fun games I've played
- Joe Montana Football - Absolutely great football game, better than Madden on this platform. I still play this!
- Columns - Basically tetris with some nice aesthetics and a few tweaks. Really fun
- G-Loc Air Battle - Very impressive fighter jet combat game
- Deep Duck Trouble - Addicting adventure game, sort of like Mario. Challenging in areas
- Super Mario - Amazingly in-depth game. Lots of fun
- Legend of Zelda Ocarina of Time - I don't think I have to explain this one. Put Mario to shame as far as I'm concerned.
- Cruisin' 64 - Great racing game, very addicting
- Doom 64 - Not as good as the original PC version, but still a load of fun as is to be expected
- Goldeneye 007 - Quite possibly the greatest gameplay ever. How much fun was it playing multiplayer on "Facility" and guarding your side of the map with hidden proximity mines?! I still play this game today.
- Wave Race 64 - Highly fun and addicting game.
- Pilot Wings - The freedom given to the player in this game is what makes it so fun.
- WWF War Zone - Super fun!
- NFL Blitz - Probably one of the most fun games I've played. This was always a nice aside from my friend and I's intense Madden games. We took this pretty seriously though, as well.
- San Francisco Rush Racing 1 and 2 - Challenges Goldeneye 007 for most addicting and fun games. The scope of these games is staggering.
- Wayne Gretzky's 3D Hockey - Great gameplay, a ton of fun
- Madden (all of them) - Madden is the game closest to my heart, and it really took off for me on the 64.
(Note: This list is small due to the fact that I became semi-professionally involved with Madden, and it was just not ideal to play anything other than Madden)
- Madden - This game deserves it's own post, so I'll spare details but to say that I have traveled all over the country playing this game, and made some money in the process.
- GTA (all of them) - Hands down one of the most addicting and fun games
- Midnight Club Racing - Really fun, looks great too
- Medal of Honor Front Line - Really solid game
- Tiger Woods Golf - Who thought golf could be so fun?
- Madden - See above.
(Yeah yeah, limited mainly to outdated first person shooters)
- Original Doom - This game is still fun today. It needs no introduction.
- Quake 3 Arena - Again, another id Software masterpiece that still has people playing it online. I've spent more time with this game than I'd care to admit, including both playing and editing source code.
- Final Doom - More of the same: greatness.
- Saints & Sinners Bowling - Really fun gameplay tweaks transform bowling into a whole new realm.
- Pogo Bowling - Great casual game
- Sam & Max - First PC game I really got into other than Doom, loads of fun.
Friday, March 14, 2008
Team Project Update
Sorry about the delay on this, by the way. The original meeting never took place, scheduling issues I suppose on part of the other programmer. I sort of anticipated that, but it's a busy time of the year, so no hard feelings. In the mean time I've been thinking about various game design ideas and some of the basic utility classes that any game may need, and how I may implement them.
I had planned on coding the game in C++ because, well, it rocks, I love it, and C++ sits atop the Kingdom of Game Programming throne and shuns non-believers with it's 7ft scepter. The other programmer seemed fine with this, but now he's suggesting we use Java with some 2D graphics lib he's found online. Meh. I checked it out, seems alright I guess, but it is Java and that's usually a deal breaker for me. It does however offer us the ability of fast iteration of ideas and whatnot, so I'm willing to do it. I'm really not too stubborn on this stuff, but if I can use either C++ or Java, I'm almost always choosing C++, but I don't want to even get into that...
He didn't seem to have any details on how "involved" the girl from the Music department wanted to be, so we'll see how that unravels. Along that note (get it, note?) though I have thought more about my idea of a music-driven gameplay element.
The basic abstract concept is to have a simple 2D world which is very stage oriented such that you only see the current area until you complete all tasks or whatever it may be. The visuals would be very vivid. The vision I have for one stage is that of a very drab and dramatic village which is actually more like a small neighborhood. The view is behind the little character and it's viewing 3 or 4 huts. The huts would be very dark colored with really intense colors and the sky would share that sentiment. Just picture a sky before a really terrible storm. The music would coincide with this of course. The gameplay concept I've got in mind is that the music in each stage (coupled with the look of the scene) would lead the player to perform their tasks. Changes in tone, speed, etc... should be evident enough as the player moves or does something that ideally it would be apparent what they need to do. I've tossed around the idea of the character needing to save the inhabitants of these small villages, whether they be creatures or plants, or something. It would incorporate some sort of time incentive which would be pushed by the music, so as you were running out of time the music would get more dramatic sort of like in a movie. An image that comes to mind is as the clouds roll in for a storm more and more of an area is covered in shadow. I think something like that could work well with my idea.
Game design is a process, so I'll just have to keep working it out, but I welcome any comments. Oh, and sorry if I just described someones favorite game that they've played for 30 years, I don't exactly "get out much". Oh, and, don't steal my idea =p
I had planned on coding the game in C++ because, well, it rocks, I love it, and C++ sits atop the Kingdom of Game Programming throne and shuns non-believers with it's 7ft scepter. The other programmer seemed fine with this, but now he's suggesting we use Java with some 2D graphics lib he's found online. Meh. I checked it out, seems alright I guess, but it is Java and that's usually a deal breaker for me. It does however offer us the ability of fast iteration of ideas and whatnot, so I'm willing to do it. I'm really not too stubborn on this stuff, but if I can use either C++ or Java, I'm almost always choosing C++, but I don't want to even get into that...
He didn't seem to have any details on how "involved" the girl from the Music department wanted to be, so we'll see how that unravels. Along that note (get it, note?) though I have thought more about my idea of a music-driven gameplay element.
The basic abstract concept is to have a simple 2D world which is very stage oriented such that you only see the current area until you complete all tasks or whatever it may be. The visuals would be very vivid. The vision I have for one stage is that of a very drab and dramatic village which is actually more like a small neighborhood. The view is behind the little character and it's viewing 3 or 4 huts. The huts would be very dark colored with really intense colors and the sky would share that sentiment. Just picture a sky before a really terrible storm. The music would coincide with this of course. The gameplay concept I've got in mind is that the music in each stage (coupled with the look of the scene) would lead the player to perform their tasks. Changes in tone, speed, etc... should be evident enough as the player moves or does something that ideally it would be apparent what they need to do. I've tossed around the idea of the character needing to save the inhabitants of these small villages, whether they be creatures or plants, or something. It would incorporate some sort of time incentive which would be pushed by the music, so as you were running out of time the music would get more dramatic sort of like in a movie. An image that comes to mind is as the clouds roll in for a storm more and more of an area is covered in shadow. I think something like that could work well with my idea.
Game design is a process, so I'll just have to keep working it out, but I welcome any comments. Oh, and sorry if I just described someones favorite game that they've played for 30 years, I don't exactly "get out much". Oh, and, don't steal my idea =p
Monday, March 3, 2008
How sweet the sound...
I recently contacted a friend of mine here at school to get together and work on some games. He told me he'd definitely be interested, and not only that but he knew of a girl in the music department (student) that would probably love to get involved. Turns out, he was right. I must say, I'm really excited about the notion of sitting down with someone that isn't a programmer but still wants to be involved in the process by contributing their art form to the overall "product". This will definitely be my first experience of that sort.
I think what intrigues me most is the fact that sound is often ignored/overlooked in games, and I'm as guilty of that as anyone. The only game music that comes to mind that wasn't immediately replaced by my mp3 collection is Doom / Quake III Arena. Granted, I don't play a large variety of games, but the music in the ones I have played annoyed the hell out of me. It may seem weird to see a game developer (aspiring nonetheless) that doesn't play a large variety of games. Well, I guess you'd be right, it is. However, I've played games like Zelda and Sonic since I was just a tiny lad. Not to mention the fact that I learned my multiplication tables of 7 from Tecmo Super Bowl for the NES (great music, by the way) and Joe Montana's Football for the Sega Game Gear. More recently though, for the past 5 years I've been a competitive gamer on the Madden tournament circuit. I tend to stick to one group of things that I like in all aspects of life, not just games. I'm sort of backwards in the sense though that my love of programming has inspired me to play as many different games as possible. Most people are the opposite. They love games, they love computers, let's program games! I digress...
The part that really excites me about this is that I love music. I always have my music playing, and I honestly can't function without it. I'm huge into playing guitar as well. I'm really interested to see if/how she will propose a game idea based on something she wants to do with music. I think that would be so cool if she had an idea for something she wanted to do with music that would be instrumental (no pun intended) to the game itself, aside from just serving as a supplement. Of course, she may not have that idea, but now I have it, and anyone reading this does as well, and I'm sure someone else has already made a game like that, so go nuts!
I'll keep you posted and let you know how the first meeting goes on Thursday and hopefully I'll have a constant supply of updates related to the game we make.
I think what intrigues me most is the fact that sound is often ignored/overlooked in games, and I'm as guilty of that as anyone. The only game music that comes to mind that wasn't immediately replaced by my mp3 collection is Doom / Quake III Arena. Granted, I don't play a large variety of games, but the music in the ones I have played annoyed the hell out of me. It may seem weird to see a game developer (aspiring nonetheless) that doesn't play a large variety of games. Well, I guess you'd be right, it is. However, I've played games like Zelda and Sonic since I was just a tiny lad. Not to mention the fact that I learned my multiplication tables of 7 from Tecmo Super Bowl for the NES (great music, by the way) and Joe Montana's Football for the Sega Game Gear. More recently though, for the past 5 years I've been a competitive gamer on the Madden tournament circuit. I tend to stick to one group of things that I like in all aspects of life, not just games. I'm sort of backwards in the sense though that my love of programming has inspired me to play as many different games as possible. Most people are the opposite. They love games, they love computers, let's program games! I digress...
The part that really excites me about this is that I love music. I always have my music playing, and I honestly can't function without it. I'm huge into playing guitar as well. I'm really interested to see if/how she will propose a game idea based on something she wants to do with music. I think that would be so cool if she had an idea for something she wanted to do with music that would be instrumental (no pun intended) to the game itself, aside from just serving as a supplement. Of course, she may not have that idea, but now I have it, and anyone reading this does as well, and I'm sure someone else has already made a game like that, so go nuts!
I'll keep you posted and let you know how the first meeting goes on Thursday and hopefully I'll have a constant supply of updates related to the game we make.
Sunday, March 2, 2008
Checkers
I love Checkers. Chess is too complicated for my likes, but Checkers has just the right mix of fun and strategy for me. I'm currently working on my own version of the game. Basically, I'm taking Checkers and adding a few tweaks to the gameplay, and hopefully that will create a new realm for the game that will be as enjoyable as the original. The point of this post, however, is to discuss the underlying structure of the Checkers board.
Coding a Checkers board is similar to coding a deck of cards: there are countless ways you could go about doing it. I tend to like to find my own way of doing something like this without looking at how someone else did it first. I think Checkers is one of the most re-done games out there, or at least tile-based board games in general are, so I could be making life a lot easier for myself but where is the fun in that?
The current idea that I'm toying with on paper is that of a custom linked list that not only has links to the item in front/behind, but also left/right. It took about 20 minutes of staring at a checkerboard to come up with this due to the orientation of the board. Pieces in Checkers can only move in diagonal directions, so thinking of a traditional linked list doesn't work too well...but if you simply turn the board on it's corners, you'll see you have a linear path up each column. That's when it clicked that adding left/right linkages to a traditional linked list setup could be a neat way of representing a checkerboard.
The issue I'm working out now is the initial creation of the board and the subsequent management of the board when a new game is started or a saved game is loaded. Currently I'm thinking that I'd need an array that held 64 tile objects, and then I'd create each tile object in some init function. It would go through and setup the front/back/left/right links, the occupied flag, and the color of each tile on the board. As opposed to having 64 ctor calls in a row, I thought about storing tile data in a data file of some sort and then iterating over a vector to create each tile object. Then, that would also be the mechanism to save/load games. The game would simply write out each tile's data to the file and then upon resuming the game it would load them back in.
The objects would be fairly small, so I don't think this would be too terrible of an approach, but I'm sure I could do it better. I need to do it this way first, though. After all, if you sit around and think about how to make something better, you'll never end up making it AT ALL!
Coding a Checkers board is similar to coding a deck of cards: there are countless ways you could go about doing it. I tend to like to find my own way of doing something like this without looking at how someone else did it first. I think Checkers is one of the most re-done games out there, or at least tile-based board games in general are, so I could be making life a lot easier for myself but where is the fun in that?
The current idea that I'm toying with on paper is that of a custom linked list that not only has links to the item in front/behind, but also left/right. It took about 20 minutes of staring at a checkerboard to come up with this due to the orientation of the board. Pieces in Checkers can only move in diagonal directions, so thinking of a traditional linked list doesn't work too well...but if you simply turn the board on it's corners, you'll see you have a linear path up each column. That's when it clicked that adding left/right linkages to a traditional linked list setup could be a neat way of representing a checkerboard.
The issue I'm working out now is the initial creation of the board and the subsequent management of the board when a new game is started or a saved game is loaded. Currently I'm thinking that I'd need an array that held 64 tile objects, and then I'd create each tile object in some init function. It would go through and setup the front/back/left/right links, the occupied flag, and the color of each tile on the board. As opposed to having 64 ctor calls in a row, I thought about storing tile data in a data file of some sort and then iterating over a vector to create each tile object. Then, that would also be the mechanism to save/load games. The game would simply write out each tile's data to the file and then upon resuming the game it would load them back in.
The objects would be fairly small, so I don't think this would be too terrible of an approach, but I'm sure I could do it better. I need to do it this way first, though. After all, if you sit around and think about how to make something better, you'll never end up making it AT ALL!
Intro
This blog will be dedicated to topics related to game programming. I'll discuss current projects I'm working on or thinking about, certain problems I'm having or solving, things that I have/want to do, things that I've seen others do, etc... I'm starting this so that I'll have something to refer back to in the future, and also so that others can possibly learn something about my experiences. I'll try to keep this sort of updated, no promises. I welcome any comments from anyone as long as they are semi-intelligent... Enjoy.
Subscribe to:
Posts (Atom)