It's been more than a year since the last one. Time for a new Active Sketch.
I made this to test out an idea my coworker suggested for indirect control through gravity wells.
In this little physics prototype, you can click to add planets and drag them around, and your little face person will zoom around, orbiting them according to Newton's laws of gravity.
Can you imagine playing with this on a touch screen?
Nothing fancy. Just a little experiment. Turns out that gravity among all these planets is a chaotic system, where it's almost impossible to predict where the orbiting face will go next. That might make this a little too confusing for a game, though who knows - maybe if you slow it down and draw motion trails showing the future paths of all the objects, it might be pretty interesting.
Still, I think springs might make a better physics-based mechanic than gravity, at least for a real-time action game.
So this Active Sketch was pretty quick to make - maybe an hour to get the basic mechanic working, and another hour to polish it up for release. This is encouraging, because it means I might be able to make more of these, even in the limited time I have now that I have a job as a game programmer.
I don't want to make any promises, but with any luck hopefully you'll be seeing a lot more of these little prototypes from me in the near future. I'm looking forward to it. :)
Showing posts with label physics. Show all posts
Showing posts with label physics. Show all posts
2011/04/17
2010/06/10
Game Idea Giveaway - City Basher
Last year, I wrote up this game idea giveaway for Emanuele Feronato to post on his popular Flash game development blog. But after waiting for many months without a reply from him, I decided to post it here so I can finally share it with all of you!
Be warned, this giveaway is epically long. My longest yet.
...continued from The Game Idea Giveaway Thread
Request by triqui:
The idea: City Basher
In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.
This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.
Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]
Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.
The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.
Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.
Gameplay
An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.
The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.
For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.
The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.
The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!
When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.
Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.
Monetization
In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.
Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.
This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.
So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.
Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.
Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.
Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.
Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.
Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!
Implementation
To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.
However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.
If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.
Good luck.
References
Required reading for anyone who wants to make a game like this:
Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)
Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!
Be warned, this giveaway is epically long. My longest yet.
...continued from The Game Idea Giveaway Thread
Request by triqui:
- what sort of game idea you're looking for
intriguing but difficult-to-implement ideas will do
- what your goals are in making this game
I would like to make a post about gameplay ideas
The idea: City Basher
In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.
This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.
Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]
Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.
The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.
Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.
Gameplay
An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.
The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.
For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.
The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.
The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!
When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.
Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.
Monetization
In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.
Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.
This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.
So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.
Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.
Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.
Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.
Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.
Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!
Implementation
To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.
However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.
If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.
Good luck.
References
Required reading for anyone who wants to make a game like this:
- Testosterone and Competitive Play
- Space Crack: Financial Mechanics
- Flash Love Letter (2009) Part 1
- Flash Love Letter (2009) Part 2
- Designing for Virtual Item Sales
- Ten Ways to Monetize Your Flash Game
Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)
Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!
2009/12/10
Game Idea Giveaway - Prejudice
...continued from The Game Idea Giveaway Thread
Request by kokosan:
The normal idea: Metastability
The weird idea: Prejudice

In short, the idea is Geometry Wars combined with Crayon Physics, with rules based on the dynamics of racial or cultural discrimination.
Like Geometry Wars, the game takes place in a field with a bunch of shapes in it. Everything in the game is a polygon, of varying shape, size, color, texture, and mass. Random shapes appear on different sides of the screen, proceeding past each other and disappearing off the opposite side, somewhat like Mondrian Provoked, or a large volume of pedestrian traffic. Unlike Geometry Wars, however, you cannot shoot. Instead, with deft strokes of the mouse, you ram into enemies with your sharp corners to do damage, while avoiding theirs.
Not every shape is an enemy, however. This is where the "prejudice" part comes in. At the top of the screen is a row of icons, each one depicting a particular shape. When the game begins, there is only one icon in this row - that is, the evil shape who has somehow wronged you in the past. Perhaps it killed your father. Anyway.
This evil shape, like all shapes, has several defined characteristics, such as area, number of edges, perimeter length, shortest distance across, longest distance across, color, and texture. Any shape that you encounter in the field is an enemy if it shares at least one of these traits with the evil shape. That's the prejudice part. The more traits it shares, there more points you get when you damage it and kill it. But if you attack a shape that does not share any of these traits, you lose points. Pretty simple.
There's more. You can add shapes to your "evil" list. How? If another shape happens to damage you, bumping into you with one of its sharp corners, then, naturally, it's evil. And it gets added to the row of icons at the top of your screen as a new evil shape. When your "evil" list is full - when it has more than, say, four icons in it - then the oldest shape is bumped off the list.
So any shape that shares a trait with any of the "evil" shapes in your list is an enemy that you can attack. These shapes are given a suspicious dark tint, for your discriminatory convenience. But in general, most shapes are content to mind their own business on their journey across the screen. Few shapes will attack you outright unless they are provoked, and some might even run away. This personality trait has nothing to do with a shape's "enemy" status - it's simply a way to modulate the difficulty of the game as you progress.
As if that's not complicated enough already, there's another twist to the idea. Not only can you have enemies, but you can have allies, too. This is where the Crayon Physics drawing engine comes into play.
When you have earned enough points from lynching enemy shapes, you can choose to spend some of those points to create allies. When you create an ally, you simply draw a shape in the mouse with the handy ally editor, and assign it a color and texture. Then, the ally gets added to a second row of icons at the bottom of the screen - your "good" list. There is always at least one shape in the "good" list - your own shape. The twist is that any shape in the field that shares a trait with any good shape - any ally - is not considered an enemy, even if it shares traits with an evil shape. So having allies reduces the number of shapes that you can legally attack.
But allies can be useful. Marked with a white tint, they swarm around you to shield you from aggressive shapes, and can also help you attack. When you hold down the mouse button, they swarm in tighter and flock with your velocity, so you can direct them in coordinated attacks. And if your very own shape is killed, then you can continue playing as the next ally in the list.
Like your "evil" list, your "good" list has a limited number of slots. If an ally is killed, its icon stays in the list. You wouldn't want to forget an ally killed in battle, would you? But if your list is full and you buy a new ally, the oldest icon is pushed off the list, though its corresponding ally remains in the field.
I want to explain the movement controls in a little more detail, as well. You move your shape with the mouse. One vertex of this polygon is the forward vertex, the point of a spike most easily used for attacking, and this vertex is made to follow the mouse cursor. This allows you to control both rotation and velocity with simple mouse movement. Allies swarm around you loosely, using a simple swarming algorithm. Just like your shape, they move from their forward vertices, which you would assign when you first draw them. When you hold down the mouse button, they try to swarm closer, and they also try to match your velocity and direction with a flocking algorithm, making their forward vertices point in the same direction as yours. This should allow you to direct their attacks.
That is all. Let me know what you think of the idea!
Request by kokosan:
- what sort of game idea you're looking for
a game involving physics
- what your goals are in making this game
Have fun developing it, and to get players to have fun playing it
The normal idea: Metastability
The weird idea: Prejudice

In short, the idea is Geometry Wars combined with Crayon Physics, with rules based on the dynamics of racial or cultural discrimination.
Like Geometry Wars, the game takes place in a field with a bunch of shapes in it. Everything in the game is a polygon, of varying shape, size, color, texture, and mass. Random shapes appear on different sides of the screen, proceeding past each other and disappearing off the opposite side, somewhat like Mondrian Provoked, or a large volume of pedestrian traffic. Unlike Geometry Wars, however, you cannot shoot. Instead, with deft strokes of the mouse, you ram into enemies with your sharp corners to do damage, while avoiding theirs.
Not every shape is an enemy, however. This is where the "prejudice" part comes in. At the top of the screen is a row of icons, each one depicting a particular shape. When the game begins, there is only one icon in this row - that is, the evil shape who has somehow wronged you in the past. Perhaps it killed your father. Anyway.
This evil shape, like all shapes, has several defined characteristics, such as area, number of edges, perimeter length, shortest distance across, longest distance across, color, and texture. Any shape that you encounter in the field is an enemy if it shares at least one of these traits with the evil shape. That's the prejudice part. The more traits it shares, there more points you get when you damage it and kill it. But if you attack a shape that does not share any of these traits, you lose points. Pretty simple.
There's more. You can add shapes to your "evil" list. How? If another shape happens to damage you, bumping into you with one of its sharp corners, then, naturally, it's evil. And it gets added to the row of icons at the top of your screen as a new evil shape. When your "evil" list is full - when it has more than, say, four icons in it - then the oldest shape is bumped off the list.
So any shape that shares a trait with any of the "evil" shapes in your list is an enemy that you can attack. These shapes are given a suspicious dark tint, for your discriminatory convenience. But in general, most shapes are content to mind their own business on their journey across the screen. Few shapes will attack you outright unless they are provoked, and some might even run away. This personality trait has nothing to do with a shape's "enemy" status - it's simply a way to modulate the difficulty of the game as you progress.
As if that's not complicated enough already, there's another twist to the idea. Not only can you have enemies, but you can have allies, too. This is where the Crayon Physics drawing engine comes into play.
When you have earned enough points from lynching enemy shapes, you can choose to spend some of those points to create allies. When you create an ally, you simply draw a shape in the mouse with the handy ally editor, and assign it a color and texture. Then, the ally gets added to a second row of icons at the bottom of the screen - your "good" list. There is always at least one shape in the "good" list - your own shape. The twist is that any shape in the field that shares a trait with any good shape - any ally - is not considered an enemy, even if it shares traits with an evil shape. So having allies reduces the number of shapes that you can legally attack.
But allies can be useful. Marked with a white tint, they swarm around you to shield you from aggressive shapes, and can also help you attack. When you hold down the mouse button, they swarm in tighter and flock with your velocity, so you can direct them in coordinated attacks. And if your very own shape is killed, then you can continue playing as the next ally in the list.
Like your "evil" list, your "good" list has a limited number of slots. If an ally is killed, its icon stays in the list. You wouldn't want to forget an ally killed in battle, would you? But if your list is full and you buy a new ally, the oldest icon is pushed off the list, though its corresponding ally remains in the field.
I want to explain the movement controls in a little more detail, as well. You move your shape with the mouse. One vertex of this polygon is the forward vertex, the point of a spike most easily used for attacking, and this vertex is made to follow the mouse cursor. This allows you to control both rotation and velocity with simple mouse movement. Allies swarm around you loosely, using a simple swarming algorithm. Just like your shape, they move from their forward vertices, which you would assign when you first draw them. When you hold down the mouse button, they try to swarm closer, and they also try to match your velocity and direction with a flocking algorithm, making their forward vertices point in the same direction as yours. This should allow you to direct their attacks.
That is all. Let me know what you think of the idea!
Game Idea Giveaway - Metastability
...continued from The Game Idea Giveaway Thread
Request by kokosan:
The weird idea: Prejudice
The normal idea: Metastability

In short, the idea is Tower of Goo combined with Crayon Physics, with a little bit of Tetris on the side. I know I've expressed annoyance at the countless Crayon Physics clones out there that waste a powerful physics engine with narrow gameplay goals. This is my attempt to design an alternative, a game that makes use of Crayon Physics' full potential.
Like in Tower of Goo, your goal is to build a tower as tall as you can. The world consists of a large horizontal platform, an island in a sea of bottomless nothingness. Random polygonal shapes form a layer of rubble on this island, which you can drag around with the mouse to form structures or just to toss off the island, never to be seen again. You can also draw your own shapes as in Crayon Physics, and drag these shapes around as well. New shapes drop down from the sky every so often, providing you with new material as well as threatening the stability of your tower.
You use these shapes to build a tower, but crucially, they must alternate between drawn and found shapes. And the tower is only valid if no drawn shapes touch the ground, the island platform. Otherwise, you could just draw a really tall shape and use that as your tower. Alternating means that a drawn shape must not touch any other drawn shape, only found shapes, and vice versa. If two shapes of the same type touch, the tower is invalid, and the offending shapes are highlighted in a conspicuous manner. To make this easy to see, drawn shapes should be colored differently than found shapes, and perhaps a beam of light shines down from the heavens if the tower is valid.
The height of the tower, measured from the ground, translates into your score. While it may seem that you could just draw really tall shapes and cheat, this does not provide an advantage. Bigger shapes are less stable, and since mass would be proportional to area, they would be so heavy that they might simply crush the shapes beneath them.
The game could provide a special timed mode, though this is not necessary since the shapes raining down provide their own form of time pressure, and the width of the island limits the maximum height of the tower. There could also be modes for different island widths, and different amounts of rain. You could even include a mode where the player can build several towers on the same island, with their combined heights added up for the final score.
I think this game could be awesome. If I didn't have a ton of other projects already, I'd make it myself. So you'd better do a good job of it! ;) Please keep me involved if you go through with this, as I can help you playtest and polish the design to its full potential and connect you with some good artists who know how to awesome-ify a game like this. If it succeeds, who knows - I could see Metastability making the same transition as Tower of Goo, toward the full-blown, award-winning World of Goo. There's a lot you could do with it.
Request by kokosan:
- what sort of game idea you're looking for
a game involving physics
- what your goals are in making this game
Have fun developing it, and to get players to have fun playing it
- what games you've made already
Colorfill, a fill the screen type of game (Qix-like), SnakeBox, a snake game in 3D
- your favorite Flash games
Bloons, Bejeweled, this kind of games easy to grasp and where you have fun instantly.
- your abilities in game design, programming, art, and sound
mostly programming, game design OK, no artistic skills
- your preferences in game design, programming, art, and sound
Programming, definitely.
The weird idea: Prejudice
The normal idea: Metastability

In short, the idea is Tower of Goo combined with Crayon Physics, with a little bit of Tetris on the side. I know I've expressed annoyance at the countless Crayon Physics clones out there that waste a powerful physics engine with narrow gameplay goals. This is my attempt to design an alternative, a game that makes use of Crayon Physics' full potential.
Like in Tower of Goo, your goal is to build a tower as tall as you can. The world consists of a large horizontal platform, an island in a sea of bottomless nothingness. Random polygonal shapes form a layer of rubble on this island, which you can drag around with the mouse to form structures or just to toss off the island, never to be seen again. You can also draw your own shapes as in Crayon Physics, and drag these shapes around as well. New shapes drop down from the sky every so often, providing you with new material as well as threatening the stability of your tower.
You use these shapes to build a tower, but crucially, they must alternate between drawn and found shapes. And the tower is only valid if no drawn shapes touch the ground, the island platform. Otherwise, you could just draw a really tall shape and use that as your tower. Alternating means that a drawn shape must not touch any other drawn shape, only found shapes, and vice versa. If two shapes of the same type touch, the tower is invalid, and the offending shapes are highlighted in a conspicuous manner. To make this easy to see, drawn shapes should be colored differently than found shapes, and perhaps a beam of light shines down from the heavens if the tower is valid.
The height of the tower, measured from the ground, translates into your score. While it may seem that you could just draw really tall shapes and cheat, this does not provide an advantage. Bigger shapes are less stable, and since mass would be proportional to area, they would be so heavy that they might simply crush the shapes beneath them.
The game could provide a special timed mode, though this is not necessary since the shapes raining down provide their own form of time pressure, and the width of the island limits the maximum height of the tower. There could also be modes for different island widths, and different amounts of rain. You could even include a mode where the player can build several towers on the same island, with their combined heights added up for the final score.
I think this game could be awesome. If I didn't have a ton of other projects already, I'd make it myself. So you'd better do a good job of it! ;) Please keep me involved if you go through with this, as I can help you playtest and polish the design to its full potential and connect you with some good artists who know how to awesome-ify a game like this. If it succeeds, who knows - I could see Metastability making the same transition as Tower of Goo, toward the full-blown, award-winning World of Goo. There's a lot you could do with it.
2009/07/12
Several Intriguing Ideas
More ideas? Yes, indeed! I'd like to share with you several intriguing gems I've recently unearthed from my idea notebook:
2009/07/12
A game about guerrilla gardening, where you collect seeds and construct seed bombs. You would go on bombing runs where you try to turn vacant lots into gardens or break open pavement by putting certain kinds of seeds in the cracks. Like a collectible card game, it would support a variety of play styles that would appeal to different kinds of people. But instead of collecting cards, you collect different types of seeds, and instead of building decks, you strategically construct seed balls, and instead of dueling, you go out and try to plant your 'bombs' without getting caught. The concept also makes use of a slowly evolving world that changes as the plants grow, much like a turn-based strategy game such as Civilization. I think it could really fun.
2009/07/02
Try making a physics-based strategy game that derives its gameplay and complexity from the basic physical rules rather than a complicated set of components and interactions. The purpose of this approach would be to make the game intuitive enough to pick up and play without a tutorial, which is very difficult for the typical RTS.
2009/05/26
A game to help you notice the weather and how it changes. In this game the weather would have a big impact on the gameplay. Your character could be warmed up by the sun, or rained on, or snowed on. There would be a sort of 2D map of clouds blown around by the wind, so if you look up into the sky and see which way the wind is blowing, you can predict what sort of weather will be coming your way.
2009/05/17
An art tool where you manipulate shapes or direct streams of particles, but instead of choosing options and colors with a toolbar, there are 'seeds' that appear. You can either ignore these seeds or cultivate them and use them as new colors or shapes in your drawing. There would be a sort of genetic algorithm at work, where new seeds would appear based on existing elements on the screen, while neglected seeds fade away. The idea is kind of similar to the way that new goo balls are actually crawling around on the structure itself in World of Goo, not in a menu.
Like the sound of these? Let me know what you think! :)
I especially like the first one, about guerrilla gardening, and I'll probably try to make it into a real game some day. Let me know if you want to help.
2009/07/12
A game about guerrilla gardening, where you collect seeds and construct seed bombs. You would go on bombing runs where you try to turn vacant lots into gardens or break open pavement by putting certain kinds of seeds in the cracks. Like a collectible card game, it would support a variety of play styles that would appeal to different kinds of people. But instead of collecting cards, you collect different types of seeds, and instead of building decks, you strategically construct seed balls, and instead of dueling, you go out and try to plant your 'bombs' without getting caught. The concept also makes use of a slowly evolving world that changes as the plants grow, much like a turn-based strategy game such as Civilization. I think it could really fun.
2009/07/02
Try making a physics-based strategy game that derives its gameplay and complexity from the basic physical rules rather than a complicated set of components and interactions. The purpose of this approach would be to make the game intuitive enough to pick up and play without a tutorial, which is very difficult for the typical RTS.
2009/05/26
A game to help you notice the weather and how it changes. In this game the weather would have a big impact on the gameplay. Your character could be warmed up by the sun, or rained on, or snowed on. There would be a sort of 2D map of clouds blown around by the wind, so if you look up into the sky and see which way the wind is blowing, you can predict what sort of weather will be coming your way.
2009/05/17
An art tool where you manipulate shapes or direct streams of particles, but instead of choosing options and colors with a toolbar, there are 'seeds' that appear. You can either ignore these seeds or cultivate them and use them as new colors or shapes in your drawing. There would be a sort of genetic algorithm at work, where new seeds would appear based on existing elements on the screen, while neglected seeds fade away. The idea is kind of similar to the way that new goo balls are actually crawling around on the structure itself in World of Goo, not in a menu.
Like the sound of these? Let me know what you think! :)
I especially like the first one, about guerrilla gardening, and I'll probably try to make it into a real game some day. Let me know if you want to help.
2009/02/20
Game Idea Giveaway - Bacon Frenzy
...continued from The Game Idea Giveaway Thread
Request by Mini Chris:
The normal idea: Swan Song
The weird idea: Bacon Frenzy

In short, this idea is physics-based platformer (like Gish) with graphics consisting of photographs of food from restaurant advertisements (kind of like And Yet It Moves except with food). That's right. I'll start with the first part.
First of all, you must play Gish if you haven't already. There's a demo. Play it. If for some reason you cannot download and install the game right now, at least watch this excellent design tour video to get an idea of what it's about.
So, now that you understand why it would be desirable to make a physics-based platformer, like Gish, in Flash, we may turn our attention to how. The blob of tar that stars as your avatar in Gish is a mass-spring system consisting of a large number of particles, too many for our poor, overworked Flash Player to reasonably handle. So, for our character, we will use the smallest mass-spring system possible - that is, three particles connected into a triangle. That, as luck would have it, is precisely the shape of a corn chip (or if you prefer, tortilla chip). Thus, our character is a corn chip. With a face, of course.
Here is how our corn chip moves: rotate left and right with the arrow keys (to roll along the ground) and compress into a very short triangle (and make a cute scrunched-up face) when the space bar is held down. Release the space bar and the corn chip jumps. If you want to get a feel for how this would work, try this suspiciously similar physics demo and hold down the left and right arrow keys at the same time, then release them. To get a feel for how the rolling along the ground movement would work, try this other physics demo. Not quite the same, but enough to show that it works.
Here is how our corn chip fights: (there's gotta be fighting, right?) corners are deadly, edges are vulnerable. Pretty simple. Mario can land on a Goomba anywhere as long as he's going down, but our corn chip has to land on a corner. Perhaps some corners are more powerful than others. Anyway, here you've got the basics for a vaguely Gish-ish platformer, where our triangular hero may jump and tumble around a playground of platforms, massacre entire species of innocent food items, collect salsa or something and rescue his girlfriend. Whatever. You are free to flesh out the story and actual gameplay as your inspiration takes you.
Here is how our corn chip is rendered: three lineTo() commands and a beginBitmapFill() with a photographic corn chip texture. You could even crop a rectangular piece out of this image and just use that for the texture bitmap. Anyway, the point is that everything in this game is made of food (or rather, images of food). And not just any food, but that hyper-real, airbrushed food that seems only to exist in advertisements for big restaurant chains. You want the player to be drowning in saliva after just a few minutes of playing this game. Frolicking among rolling hills of crispy bacon glistening with cholesterol, leaping from atop gloriously shiny apples to land on a golden-crusted loaf of artisan bread, obliterating a hostile crowd of sentient jello cubes... There are so many possibilities.
Request by Mini Chris:
- what sort of game idea you're looking for
A platformer that has a different element then the normal platformer or a creative twist on current platformer elements
- what your goals are in making this game
To create my first great game, as so far all my ideas have been not so good and I end up stop making them before they are even finished.
The normal idea: Swan Song
The weird idea: Bacon Frenzy

In short, this idea is physics-based platformer (like Gish) with graphics consisting of photographs of food from restaurant advertisements (kind of like And Yet It Moves except with food). That's right. I'll start with the first part.
First of all, you must play Gish if you haven't already. There's a demo. Play it. If for some reason you cannot download and install the game right now, at least watch this excellent design tour video to get an idea of what it's about.
So, now that you understand why it would be desirable to make a physics-based platformer, like Gish, in Flash, we may turn our attention to how. The blob of tar that stars as your avatar in Gish is a mass-spring system consisting of a large number of particles, too many for our poor, overworked Flash Player to reasonably handle. So, for our character, we will use the smallest mass-spring system possible - that is, three particles connected into a triangle. That, as luck would have it, is precisely the shape of a corn chip (or if you prefer, tortilla chip). Thus, our character is a corn chip. With a face, of course.
Here is how our corn chip moves: rotate left and right with the arrow keys (to roll along the ground) and compress into a very short triangle (and make a cute scrunched-up face) when the space bar is held down. Release the space bar and the corn chip jumps. If you want to get a feel for how this would work, try this suspiciously similar physics demo and hold down the left and right arrow keys at the same time, then release them. To get a feel for how the rolling along the ground movement would work, try this other physics demo. Not quite the same, but enough to show that it works.
Here is how our corn chip fights: (there's gotta be fighting, right?) corners are deadly, edges are vulnerable. Pretty simple. Mario can land on a Goomba anywhere as long as he's going down, but our corn chip has to land on a corner. Perhaps some corners are more powerful than others. Anyway, here you've got the basics for a vaguely Gish-ish platformer, where our triangular hero may jump and tumble around a playground of platforms, massacre entire species of innocent food items, collect salsa or something and rescue his girlfriend. Whatever. You are free to flesh out the story and actual gameplay as your inspiration takes you.
Here is how our corn chip is rendered: three lineTo() commands and a beginBitmapFill() with a photographic corn chip texture. You could even crop a rectangular piece out of this image and just use that for the texture bitmap. Anyway, the point is that everything in this game is made of food (or rather, images of food). And not just any food, but that hyper-real, airbrushed food that seems only to exist in advertisements for big restaurant chains. You want the player to be drowning in saliva after just a few minutes of playing this game. Frolicking among rolling hills of crispy bacon glistening with cholesterol, leaping from atop gloriously shiny apples to land on a golden-crusted loaf of artisan bread, obliterating a hostile crowd of sentient jello cubes... There are so many possibilities.
2009/02/12
Game Idea Giveaway - Paint Physics
...continued from The Game Idea Giveaway Thread
Request by kcaz_rel:
The normal idea: Monk Tactics
The weird idea: Paint Physics
This is a game born of hatred. Or at least disdain, for the legions of Crayon Physics clones that have so shamelessly made their success, most notably Magic Pen. So, the player starts up Paint Physics, anticipating perhaps some delightful fluid dynamics and colorful creative fun with paint. They are soon dismayed to see that this apparent Crayon Physics clone does not take fingerpaint as its nostalgia-inducing motif of choice, but that the Paint here is in fact MS Paint, the maligned instrument of art noobs and of course, Satan. The word for today is anti-aesthetic. Clicking the inexpertly scrawled play button, they are greeted with the sight of a familiar blue ball and yellow star, rendered in MS Paint's distinctive style. Oh, how cute - the mouse cursor looks like the pencil tool from MS Paint. A line of text at the top, artfully displayed in an aliased Times New Roman font, suggests to the player that they use their mouse to trace around the dashed outline of a square placed above the blue ball.
Here is where the fun begins. The player dutifully proceeds to trace a line around the shape, and there it is - a messy but passable square hovering in the air above the blue ball. Now, will this shape suddenly solidify and fall to the ground with a graceful crash, nudging the blue ball delicately toward the waiting yellow star? The player releases the mouse button, expectantly. Nothing at first, but then, slowly, this squiggly outline begins to peel away like a wet noodle thrown on a wall, until the whole thing collapses into a limp, tangled heap on top of the ball. Oh dear. The player mouses over to investigate. Oh look, the cursor changes to a drag icon when the mouse is over the blue ball. Can you drag the ball? The player drags the ball around, and shakes off the ropes. Drag to yellow star - level complete!
Now, if this were the whole game, it might be somewhat amusing as a parody but not really worth all the work necessary to develop it. Fortunately, that's not the game. It's just the intro. The true game would be a physics-based mouse avoider combined with a physics construction toy. Given that the basic action is to drag a blue ball all the way to a yellow star in order to beat each level, you've got a lot of options for mouse avoider obstacles and puzzles right there. And given that you'd be using a physics engine like Box2DFlash or similar, there are lots of creative physics-based ways you could take this without having to simply imitate an existing avoider game. But anyway, let's just say that certain shapes, as well as perhaps more actively swarming enemies will result in you losing the level if the blue ball touches them. Let's say that these are all the red shapes. Well, how might the player ease their way through the hazards that lie in wait, using the humble limp noodle pencil tool that is their sole accessory?
Having the ability to create flexible, perhaps stretchy, ropes is more useful than you might think. If you draw a rope with either end inside an existing object. like a floating platform or a box sitting on the ground, the end of the rope will stay attached to it. If you draw a rope from the blue ball to, say, a heavy black box, then all of a sudden you've got a weapon against your reddish attackers - pick up the ball and starting bashing them away with the heavy black box, a la Hammerfall. Basically, you use the stretchy ropes to connect the objects that already exist in the level, rather than drawing your own. I haven't seen this mechanic used anywhere yet. But if you really feel like the player must be able to add shapes of their own, I guess you could also make use of MS Paint's circle and rectangle tools, or even the others if you can figure out how. ;) Either way, I imagine that level design and testing would take up most of the development time of this game, at least if you're using an existing physics engine like you should. The success of Paint Physics will hinge entirely on its level design.
Request by kcaz_rel:
- what sort of game idea you're looking for
I'm not quite sure, something simple but with a twist an idea I had was a sort of physics RPG.
- what your goals are in making this game
Again a new twist that is completely different from what you would expect.
The normal idea: Monk Tactics
The weird idea: Paint Physics
This is a game born of hatred. Or at least disdain, for the legions of Crayon Physics clones that have so shamelessly made their success, most notably Magic Pen. So, the player starts up Paint Physics, anticipating perhaps some delightful fluid dynamics and colorful creative fun with paint. They are soon dismayed to see that this apparent Crayon Physics clone does not take fingerpaint as its nostalgia-inducing motif of choice, but that the Paint here is in fact MS Paint, the maligned instrument of art noobs and of course, Satan. The word for today is anti-aesthetic. Clicking the inexpertly scrawled play button, they are greeted with the sight of a familiar blue ball and yellow star, rendered in MS Paint's distinctive style. Oh, how cute - the mouse cursor looks like the pencil tool from MS Paint. A line of text at the top, artfully displayed in an aliased Times New Roman font, suggests to the player that they use their mouse to trace around the dashed outline of a square placed above the blue ball.
Here is where the fun begins. The player dutifully proceeds to trace a line around the shape, and there it is - a messy but passable square hovering in the air above the blue ball. Now, will this shape suddenly solidify and fall to the ground with a graceful crash, nudging the blue ball delicately toward the waiting yellow star? The player releases the mouse button, expectantly. Nothing at first, but then, slowly, this squiggly outline begins to peel away like a wet noodle thrown on a wall, until the whole thing collapses into a limp, tangled heap on top of the ball. Oh dear. The player mouses over to investigate. Oh look, the cursor changes to a drag icon when the mouse is over the blue ball. Can you drag the ball? The player drags the ball around, and shakes off the ropes. Drag to yellow star - level complete!
Now, if this were the whole game, it might be somewhat amusing as a parody but not really worth all the work necessary to develop it. Fortunately, that's not the game. It's just the intro. The true game would be a physics-based mouse avoider combined with a physics construction toy. Given that the basic action is to drag a blue ball all the way to a yellow star in order to beat each level, you've got a lot of options for mouse avoider obstacles and puzzles right there. And given that you'd be using a physics engine like Box2DFlash or similar, there are lots of creative physics-based ways you could take this without having to simply imitate an existing avoider game. But anyway, let's just say that certain shapes, as well as perhaps more actively swarming enemies will result in you losing the level if the blue ball touches them. Let's say that these are all the red shapes. Well, how might the player ease their way through the hazards that lie in wait, using the humble limp noodle pencil tool that is their sole accessory?
Having the ability to create flexible, perhaps stretchy, ropes is more useful than you might think. If you draw a rope with either end inside an existing object. like a floating platform or a box sitting on the ground, the end of the rope will stay attached to it. If you draw a rope from the blue ball to, say, a heavy black box, then all of a sudden you've got a weapon against your reddish attackers - pick up the ball and starting bashing them away with the heavy black box, a la Hammerfall. Basically, you use the stretchy ropes to connect the objects that already exist in the level, rather than drawing your own. I haven't seen this mechanic used anywhere yet. But if you really feel like the player must be able to add shapes of their own, I guess you could also make use of MS Paint's circle and rectangle tools, or even the others if you can figure out how. ;) Either way, I imagine that level design and testing would take up most of the development time of this game, at least if you're using an existing physics engine like you should. The success of Paint Physics will hinge entirely on its level design.
2008/01/25
Environment Sketch 01 - Spring Rain

Considering that "Environment Sketch" is a term I made up, I should probably explain. An Environment Sketch is neither an animation nor a game, but something in between. It is a scene that you observe. It's like a window into a world.
The idea is to take some piece of my environment that I appreciate, and put it out for other people to notice and appreciate. But it's not simply a photograph - the idea is to capture the mood and feel of a place as it moves through time, not doing anything, just being.
So with that in mind, I present to you my first Environment Sketch!
Spring Rain is my first Environment Sketch, a simple but evocative depiction of a scene or place.
This is not a graphic sketch but a procedural one, a viewpoint generated by code that describes how the scene is to be constructed and how it evolves over time.
Spring Rain is a tribute to plants and rain. Please enjoy.
It's all procedurally generated - different every time - and running a real-time physics simulation. The background is created from blurred particle trails, the plants are assemblages of particles connected by springs, arranged with some amount of randomness, and the background sounds are mixed randomly.
Spring Rain was made in Flash, so I actually ended up reusing a lot of the code from my earlier ragdoll games! :) I think Flash is the perfect medium for these Environment Sketches, because it is so easy to combine hand-drawn art with code-generated graphics, not to mention the huge audience that already exists for Flash content. With any luck, the Environment Sketch will someday become recognized as a legitimate genre alongside Animations and Games. I'll do my best to help it along. :)
I've had many sources of inspiration in defining the Environment Sketch concept and in making Spring Rain. Most significant was simply my appreciation of the world around me, finding beauty in bits of my surroundings which I felt compelled to share with the rest of the world. But there were also some Flash pieces I found across the web that have helped to point me in the direction of these procedural sketches as a way to share that appreciation.
The first one I found was perhaps Ferry Halim's Raindrops. It's nice to know that I'm not the only one out there who loves rain. :D But the biggest influence on me I think has been the Flash developer and artist IvoryDrive. The first time I mentioned my intention to make these procedural sketches in a comment on his excellent interactive piece City. His thought it was a great idea, and guess what - he also really liked Spring Rain! Wow! So I'm very grateful for IvoryDrive's encouragement. :) He's got a lot of other work you should check out too, including his latest, 5 Differences, which is basically a game wrapped around a bunch of little Environment Sketches.
Another nice example of what I would consider an Environment Sketch is this real-time Hogwarts scene. While it looks to me like almost all the graphics in that piece are made by hand rather than generated procedurally, I think the intention behind it is similar enough to qualify as an Environment Sketch. It depicts a place as it exists through time, and while it contains many hand-drawn and animated graphics, they are only used to reinforce a momentary feel rather than to push a story along.
One place that Environment Sketches might find a home is in website design. How about giving your site a more natural sense of place by putting in a virtual window into a dynamic scene? One person on the Fisix Engine forums had the same idea and I've given him permission to add Spring Rain to his site. Looks nice, don't you think? :)
If any of you out there are thinking of making something like these Environment Sketches, or think they might be cool to use on your site, let me know! It'd be great to hear from you. :)
2007/06/28
Why Hasn't Anyone Thought of This Yet?
Okay, this needs to happen: A marionette fighting game for the Nintendo Wii. The PS3 could work too, with its motion-sensing controller.
Admit it, this is a brilliantly obvious idea. Haven't you ever picked up a Wii Remote and wished there was a frightening, battle-ready puppet suspended beneath it? No? Well, neither have I, probably because I don't have a Wii, but still, I'm sure you can see the connection.
This idea arose as a possible solution to the problem of physics-based avatar control. In most games, you move around a character, like Mario, for example, who is represented by an animated image moving around on the screen. But there are some games where instead, your character is made up of many physically simulated parts. You then have a direct control over the movement of these parts, whether you are individually controlling each joint or moving a ragdoll's head around with the arrow keys. This freedom allows players to develop their own playing style within the physics of the game world, but also tends to result in games that are very difficult to learn.
As Matthew Wegner of Fun-Motion said in his review of Toribash,
"Other games have attempted to implement full body, physics-based control mechanisms. The problem lies in the complication of movement. As a designer, you either need to simplify the control mechanism, automate some aspect of the process, or rely on convoluted controls. It’s a very hard problem to solve for a real-time game."
That's the problem. If you want a game that lets players do realistic, physics-based kung fu, well those players are going to have to be real kung fu masters. Either that or you're going to have to take some control away from them or simplify the game until it isn't really like kung fu. The ability to distill a complex activity into something controlled by a few buttons, while still retaining that interesting complexity, is central to the art of designing physics games.
So anyway, how about taking a ragdoll and rather than strapping a jetpack to its head (basically what Ragdoll Masters does), try attaching virtual strings to its arms and legs? I originally envisioned this as a way to combine individual control of limbs with an analog input device like the mouse. But it would work even better with a 3D motion-sensing controller like that of the Wii.
Puppetry also provides a wealth of inspiration for the visual style of a game. Tons of different cultures around the world each have their own puppet traditions from which one can steal ideas. And they all look really freaky. It's quite relevant to games because puppetry is basically the oldest form of virtual reality. Puppets are not just pictures, they are virtual actors, not made for their own sake but as part of a larger production intended to convey a story, to create the illusion of an imagined world (yes, that did need to be italicized). As a result, they offer a long history of approaches to representing people and things within restrictive technical limitations. Puppets are not "photo-realistic" and neither are games. It might do us games people some good to take a look at how stylization has been done in the past. I think puppets make a better example than animation in this respect.
And yeah, that's my idea. I'm sorry for the lack of activity on my blog. There is much to write about, and little time or motivation with which to do it. Not that I'm just too lazy, necessarily, but when I get a great idea of what to write, I usually don't have the time, and once I do get the time, I'm just not feeling it anymore. But occasionally those two occurrences coincide, like now. Though this has taken way longer than I expected. Oh well. Thanks for reading. :)
Admit it, this is a brilliantly obvious idea. Haven't you ever picked up a Wii Remote and wished there was a frightening, battle-ready puppet suspended beneath it? No? Well, neither have I, probably because I don't have a Wii, but still, I'm sure you can see the connection.
This idea arose as a possible solution to the problem of physics-based avatar control. In most games, you move around a character, like Mario, for example, who is represented by an animated image moving around on the screen. But there are some games where instead, your character is made up of many physically simulated parts. You then have a direct control over the movement of these parts, whether you are individually controlling each joint or moving a ragdoll's head around with the arrow keys. This freedom allows players to develop their own playing style within the physics of the game world, but also tends to result in games that are very difficult to learn.
As Matthew Wegner of Fun-Motion said in his review of Toribash,
"Other games have attempted to implement full body, physics-based control mechanisms. The problem lies in the complication of movement. As a designer, you either need to simplify the control mechanism, automate some aspect of the process, or rely on convoluted controls. It’s a very hard problem to solve for a real-time game."
That's the problem. If you want a game that lets players do realistic, physics-based kung fu, well those players are going to have to be real kung fu masters. Either that or you're going to have to take some control away from them or simplify the game until it isn't really like kung fu. The ability to distill a complex activity into something controlled by a few buttons, while still retaining that interesting complexity, is central to the art of designing physics games.
So anyway, how about taking a ragdoll and rather than strapping a jetpack to its head (basically what Ragdoll Masters does), try attaching virtual strings to its arms and legs? I originally envisioned this as a way to combine individual control of limbs with an analog input device like the mouse. But it would work even better with a 3D motion-sensing controller like that of the Wii.
Puppetry also provides a wealth of inspiration for the visual style of a game. Tons of different cultures around the world each have their own puppet traditions from which one can steal ideas. And they all look really freaky. It's quite relevant to games because puppetry is basically the oldest form of virtual reality. Puppets are not just pictures, they are virtual actors, not made for their own sake but as part of a larger production intended to convey a story, to create the illusion of an imagined world (yes, that did need to be italicized). As a result, they offer a long history of approaches to representing people and things within restrictive technical limitations. Puppets are not "photo-realistic" and neither are games. It might do us games people some good to take a look at how stylization has been done in the past. I think puppets make a better example than animation in this respect.
And yeah, that's my idea. I'm sorry for the lack of activity on my blog. There is much to write about, and little time or motivation with which to do it. Not that I'm just too lazy, necessarily, but when I get a great idea of what to write, I usually don't have the time, and once I do get the time, I'm just not feeling it anymore. But occasionally those two occurrences coincide, like now. Though this has taken way longer than I expected. Oh well. Thanks for reading. :)
2007/01/15
The Fisix Engine
The Fisix Engine has been released! If you haven't heard of it before, it's a physics engine for Flash that lets you easily make games with ragdoll physics. It's not completely done yet, but you can still download it and try it out.
The cool thing about it is that it is so professionally done. It even has an API documentation page where you can browse through descriptions of all its packages and classes, just like Java does! The downside is that it is only for ActionScript 3.0, which is not completely done yet, and not integrated into Flash 8. You have to download some separate programs to get it all working, which is something I haven't gotten around to doing yet. And of course Flash programs you make with AS3 will not work for people who don't have the latest version of Flash Player.
That said, it is worth looking into, especially as AS3 becomes more widespread. I've registered on the forums, and have already made a few posts. I think it will be fun. :)
That reminds me, I still haven't gotten around to posting on the Tale of Tales forum. :/ Maybe I'll think of a good game design topic to post there. Sometime.
The cool thing about it is that it is so professionally done. It even has an API documentation page where you can browse through descriptions of all its packages and classes, just like Java does! The downside is that it is only for ActionScript 3.0, which is not completely done yet, and not integrated into Flash 8. You have to download some separate programs to get it all working, which is something I haven't gotten around to doing yet. And of course Flash programs you make with AS3 will not work for people who don't have the latest version of Flash Player.
That said, it is worth looking into, especially as AS3 becomes more widespread. I've registered on the forums, and have already made a few posts. I think it will be fun. :)
That reminds me, I still haven't gotten around to posting on the Tale of Tales forum. :/ Maybe I'll think of a good game design topic to post there. Sometime.
Subscribe to:
Posts (Atom)