For all of you mobile freaks out there, check out Kick Butt Applications, a new mobile application blog. Very humorously written, with good info for those addicted to mobile apps.
It's always a bonus for me when I find a blog that is funny, relevant to my interests, and with a refreshing lack of spelling errors.
kickbuttapplications.blogspot.com
Monday, June 22, 2009
Friday, June 19, 2009
Ball Physics
This is not a tutorial.
There, I said it. I probably just lost a bunch of potential traffic, but hey, at least I am honest. I've faced some real challenges in coding one of my upcoming top-secret games. Actually, the code part is easy. It's the math and physics involved that make me crazy. Last night I came close to looking up my Grade 12 Calculus teacher and asking for assistance. Then at around 12:30am I stumbled upon a great tutorial by Senocular, and it really saved me.
I'm sure you've seen Flash games where a missile gets launched into the air, and it flies a nice smooth arc back to earth. Many of these games are two-dimensional, meaning there is no depth to the scenario. My project involves the launching of various objects into the air, but in a three-dimensional world. When an object in the game is fired "into the screen" it should shrink if you want it to look believable, and it should grow if it gets fired outwards, toward the player's face.
The trouble lies in calculating the proper motion of an object at varying depths. A ball that appears to be traveling fast at close range will appear slow when viewed from a great distance. The trick, as I have learned, is to first realize what the real problem is. You have a three-dimensional scenario that needs to be displayed on a 2-dimensional screen.
In games, information such as speed and direction are stored in digital containers known as variables. A ball that is thrown across the screen is said to have a vx (x speed) and a vy (y speed). In the real world there is a third dimension, depth. Depth is an object's position on the z-axis. When making the necessary conversion from 3D to 2D, it becomes apparent that these 3 dimensions must be made to interrelate. For example, an object up close always appears faster than an object viewed from a great distance. This means that when the z value is large, the vx and vy values must be made smaller. Coding this up is not as simple as plugging a bunch of values into the Pythagorian Theorem. It is messier.
The big trick is to create virtual x, y and z values. Huh? You keep track of an object's position along the three real-world axis: x, y and z. When you convert this real-world scenario to 2D, the z value doesn't really do much except scale the size of the object, and scale the size of the x and y values. When an object is far away it has a large z value, and therefore the object needs to be scaled down to a small size. If the ball is travelling from left to right, it's speed must be scaled down in accordance with it's depth, or distance (or z value, to be technical).
If you have read this far and are not daunted in the slightest, I would highly recommend anything written by Keith Peters. Have a look at his amazing book on the left. He discusses in depth how to make things move with actionscript. Easy enough for beginners, but certainly not boring for experienced coders. He even has a second book, Advanced Actionscript 3.0 Animation which picks up where the first one ends.
This blog is not going to get technical very often. The inner workings of 3D programming is really fascinating, and it has been a lot of fun to learn. Creating this next game of mine has made me feel somewhat like a mad scientist (except I'm not in a creepy underground lab with bats and spiderwebs, I'm usually sitting at Starbucks!).
There, I said it. I probably just lost a bunch of potential traffic, but hey, at least I am honest. I've faced some real challenges in coding one of my upcoming top-secret games. Actually, the code part is easy. It's the math and physics involved that make me crazy. Last night I came close to looking up my Grade 12 Calculus teacher and asking for assistance. Then at around 12:30am I stumbled upon a great tutorial by Senocular, and it really saved me.
I'm sure you've seen Flash games where a missile gets launched into the air, and it flies a nice smooth arc back to earth. Many of these games are two-dimensional, meaning there is no depth to the scenario. My project involves the launching of various objects into the air, but in a three-dimensional world. When an object in the game is fired "into the screen" it should shrink if you want it to look believable, and it should grow if it gets fired outwards, toward the player's face.
The trouble lies in calculating the proper motion of an object at varying depths. A ball that appears to be traveling fast at close range will appear slow when viewed from a great distance. The trick, as I have learned, is to first realize what the real problem is. You have a three-dimensional scenario that needs to be displayed on a 2-dimensional screen.
In games, information such as speed and direction are stored in digital containers known as variables. A ball that is thrown across the screen is said to have a vx (x speed) and a vy (y speed). In the real world there is a third dimension, depth. Depth is an object's position on the z-axis. When making the necessary conversion from 3D to 2D, it becomes apparent that these 3 dimensions must be made to interrelate. For example, an object up close always appears faster than an object viewed from a great distance. This means that when the z value is large, the vx and vy values must be made smaller. Coding this up is not as simple as plugging a bunch of values into the Pythagorian Theorem. It is messier.
The big trick is to create virtual x, y and z values. Huh? You keep track of an object's position along the three real-world axis: x, y and z. When you convert this real-world scenario to 2D, the z value doesn't really do much except scale the size of the object, and scale the size of the x and y values. When an object is far away it has a large z value, and therefore the object needs to be scaled down to a small size. If the ball is travelling from left to right, it's speed must be scaled down in accordance with it's depth, or distance (or z value, to be technical).
If you have read this far and are not daunted in the slightest, I would highly recommend anything written by Keith Peters. Have a look at his amazing book on the left. He discusses in depth how to make things move with actionscript. Easy enough for beginners, but certainly not boring for experienced coders. He even has a second book, Advanced Actionscript 3.0 Animation which picks up where the first one ends.This blog is not going to get technical very often. The inner workings of 3D programming is really fascinating, and it has been a lot of fun to learn. Creating this next game of mine has made me feel somewhat like a mad scientist (except I'm not in a creepy underground lab with bats and spiderwebs, I'm usually sitting at Starbucks!).
Upcoming New Game
I am especially psyched about a new game that I am working on. I can't share a lot of details yet unfortunately, but it will be available here on July 10, 2009. I should hopefully have some screenshots up by July 1, 2009.
One of the great difficulties I experienced while programming the Airport Madness series was testing. I would receive an email about some aircraft that wouldn't line up with the runway properly, so then I'd fire up AM2 and wait patiently for 20 minutes until the scenario in question would finally occur. I would perform debugging sessions that lasted hours on end. What a time eater. I could be doing other stuff, like filing my taxes late.
During the creation of Airport Madness 2 I tried to be good about posting details of delays and troublesome bugs. Then finally somebody emailed me and said, "If you spent as much time coding AM2 as you spend writing about coding AM2, it would be done already!". Good advice, however I do intend to post my progress regularly on projects old and new.
Although I am moving forward with some new projects, I have not forgotten the existing ones. Airport Madness 1 is in need of an overhaul. Some bugs still exist, and it could use some of the features included with Airport Madness 2, such as pause and mute. Airport Madness 2 has some minor issues, and there will be a version 1.8 coming out for that in August.
Please don't hesitate to email me if you have any ideas for new or existing games of mine. Many of my ideas come from email that I receive. And if my emails sound a little short and blunt, please don't take it personally. I am trying to answer them all. Thank god for the iPhone.
One of the great difficulties I experienced while programming the Airport Madness series was testing. I would receive an email about some aircraft that wouldn't line up with the runway properly, so then I'd fire up AM2 and wait patiently for 20 minutes until the scenario in question would finally occur. I would perform debugging sessions that lasted hours on end. What a time eater. I could be doing other stuff, like filing my taxes late.
During the creation of Airport Madness 2 I tried to be good about posting details of delays and troublesome bugs. Then finally somebody emailed me and said, "If you spent as much time coding AM2 as you spend writing about coding AM2, it would be done already!". Good advice, however I do intend to post my progress regularly on projects old and new.
Although I am moving forward with some new projects, I have not forgotten the existing ones. Airport Madness 1 is in need of an overhaul. Some bugs still exist, and it could use some of the features included with Airport Madness 2, such as pause and mute. Airport Madness 2 has some minor issues, and there will be a version 1.8 coming out for that in August.
Please don't hesitate to email me if you have any ideas for new or existing games of mine. Many of my ideas come from email that I receive. And if my emails sound a little short and blunt, please don't take it personally. I am trying to answer them all. Thank god for the iPhone.
Friday, June 5, 2009
Bathroom Simulator
Here is a project that I originally published as an iPhone application, and last week decided to distribute it as a Flash game as well.
There are several versions of this urinal game circulating the internet, so admittedly it is not an original concept. Here is my version of this great game idea, and I hope that you enjoy it.
The idea here is to test and improve your public washroom etiquette. You choose the most appropriate stall in a variety of
situations. The Bathroom Simulator was inspired by several other games that are based on this concept, but mine has enough "extras" to hopefully get your attention.
The other urinal games are fairly basic, offering the player a variety of situations such as, "There's a guy on the left and a guy on the right, so which urinal will YOU choose?". I've really tried to pimp things up by adding sit-down stalls, busted urinals, and pervert bikers. The game is loaded with graphics, sound effects and music.
I always appreciate fresh ideas from people, so let me know if it is missing anything, or if it could be made better in some way.
There are several versions of this urinal game circulating the internet, so admittedly it is not an original concept. Here is my version of this great game idea, and I hope that you enjoy it.
The idea here is to test and improve your public washroom etiquette. You choose the most appropriate stall in a variety of
situations. The Bathroom Simulator was inspired by several other games that are based on this concept, but mine has enough "extras" to hopefully get your attention.The other urinal games are fairly basic, offering the player a variety of situations such as, "There's a guy on the left and a guy on the right, so which urinal will YOU choose?". I've really tried to pimp things up by adding sit-down stalls, busted urinals, and pervert bikers. The game is loaded with graphics, sound effects and music.
I always appreciate fresh ideas from people, so let me know if it is missing anything, or if it could be made better in some way.
Wednesday, June 3, 2009
Airport Madness 2 Progress
Since I haven't posted any Airport Madness updates since its' release May 2nd, I thought I would bring everyone up to speed on what is happening with the project. In it's first two weeks, I released no less than seven updates, bringing the build number to the latest 1.7.
It was never my intention to release so many new builds so quickly. This action was in response to the many emails I received that brought various bugs to my attention. Airport Madness 2 still has a few minor bugs which I have every intention of fixing in the future. However, I must focus on other projects first, partly due to time constraints and partly because, well, I'm kind of burned out from AM2 and need a change of scenery for a while.
The current build is very functional, with only minor inconveniences such as aircraft landing lights that don't always turn on when they are supposed to. I am keeping a list of such issues, and will likely release another update in August.
"August? Are you kidding me?" August is realistic. Heck, it's already June, and I've got stuff to do. If I get a build out in July I will be the big hero, won't I?
It was never my intention to release so many new builds so quickly. This action was in response to the many emails I received that brought various bugs to my attention. Airport Madness 2 still has a few minor bugs which I have every intention of fixing in the future. However, I must focus on other projects first, partly due to time constraints and partly because, well, I'm kind of burned out from AM2 and need a change of scenery for a while.
The current build is very functional, with only minor inconveniences such as aircraft landing lights that don't always turn on when they are supposed to. I am keeping a list of such issues, and will likely release another update in August.
"August? Are you kidding me?" August is realistic. Heck, it's already June, and I've got stuff to do. If I get a build out in July I will be the big hero, won't I?
Subscribe to:
Posts (Atom)