Saturday, 24 December 2011
not a bundle
Oh, and maybe I'm a bit late posting this here, but Vertex Dispenser is 50% off over Christmas, until Jan 2. Here are some other cool games that are discounted too (thanks Dejobaan for the mention!):
Thursday, 22 December 2011
Glitch Tank
Released a game for iPad: Glitch Tank (app store)
(edit: now on iphone also, but ipad recommended)
It's a competitive two-player game, made with the same constraints and aesthetic as Exuberant Struggle (160*100 resolution, 8 colours, 2 players, arrow-keys only as input*, minimalist real-time strategy, high randomness).
It's somewhat inspired by RoboRally, but takes things in a different direction. You have a hand of four random actions which are replaced when you play them, and have to try to use them to destroy the other player. Basically I made up a list of all the things I could think of that tanks do and made them be actions in the game: drive around, lay minefields, fire lasers, jump, reproduce. The twist comes from that last one: you end up with multiple tanks, and the same commands are given to all of them.
* Since I've put it on iPad the control restriction doesn't apply anymore, but it influenced the design.
Something that came up when playtesting this was that sometimes people would spam actions as fast as they could instead of trying to pick what was best to do. This didn't turn out to be a good strategy - you're more likely to kill yourself than your opponent - but it tended to dominate the game if someone did it; their opponent couldn't effectively do much more than wait for them to kill themselves. So I added an "overheating" effect, where your tank will lock up for several seconds if you press actions too quickly. It feels like a bit of a hack since it wasn't a viable strategy, but since players were doing it anyway and not enjoying it something had to be done. (I may need to adjust the parameters for when this happens - let me know if you're finding games dominated by button-mashing.)
At some point I'll release a PC version, but probably not on its own - it just doesn't work as well on PC, because there's an extra layer of indirection in the controls. Will probably do a telephone build as well, although the screen does seems too small for it to be very natural with two players; I'll have to get hold of one to test.
(edit: now on iphone also, but ipad recommended)
It's a competitive two-player game, made with the same constraints and aesthetic as Exuberant Struggle (160*100 resolution, 8 colours, 2 players, arrow-keys only as input*, minimalist real-time strategy, high randomness).
It's somewhat inspired by RoboRally, but takes things in a different direction. You have a hand of four random actions which are replaced when you play them, and have to try to use them to destroy the other player. Basically I made up a list of all the things I could think of that tanks do and made them be actions in the game: drive around, lay minefields, fire lasers, jump, reproduce. The twist comes from that last one: you end up with multiple tanks, and the same commands are given to all of them.
* Since I've put it on iPad the control restriction doesn't apply anymore, but it influenced the design.
Something that came up when playtesting this was that sometimes people would spam actions as fast as they could instead of trying to pick what was best to do. This didn't turn out to be a good strategy - you're more likely to kill yourself than your opponent - but it tended to dominate the game if someone did it; their opponent couldn't effectively do much more than wait for them to kill themselves. So I added an "overheating" effect, where your tank will lock up for several seconds if you press actions too quickly. It feels like a bit of a hack since it wasn't a viable strategy, but since players were doing it anyway and not enjoying it something had to be done. (I may need to adjust the parameters for when this happens - let me know if you're finding games dominated by button-mashing.)
At some point I'll release a PC version, but probably not on its own - it just doesn't work as well on PC, because there's an extra layer of indirection in the controls. Will probably do a telephone build as well, although the screen does seems too small for it to be very natural with two players; I'll have to get hold of one to test.
Sunday, 16 October 2011
Two-player Lessons
Some thoughts from designing two-player games:
1) Damage and score are equivalent. This isn't quite true: score can be unbounded if there's another condition for the game ending, but a target score is equivalent to a target amount of damage; competing to be the first to deal 100 damage is identical to competing to be the first to score 100 points. There are some perceptual differences: numbers going up feel different to numbers going down, and being able to recover damage done to yourself feels quite different to being able to reduce your opponent's score. The abstractness of score is generally more appropriate for more abstract games.
In multiplayer (in the sense of "more than two players") this symmetry is broken, and score/damage lead to quite different dynamics.
2) Everything is zero-sum. In multiplayer games it's common for different objects to have different values for each player, and this can add a lot of depth. In a two-player game, everything has the same value for both players; anything that helps one player is just as much hurting the other. If there's something only one of us can get, it's value to me is "what good it does for me to have it" + "what good it does for me for you not to have it". The value to me of you not having it is exactly how good it would be from your perspective for you to have it, so this equation is symmetric in the players - for example, something worth 3 points to me and 5 to you makes a difference of 3+5=8 points between our scores, no matter which of us gets it.
So lots of mechanics common in multiplayer games just don't work very well in two-player. If something is more effective for one player because of synergies with other powers, it's equally desirable for their opponent to prevent them getting. If an auction determines who gets something, each player should be willing to pay the exact same amount. If an action benefits an opponent as well as yourself, that is a strict disadvantage.
As a side-effect, when balancing a game sometimes the value of an object turns out to be double what you might expect - for example, in Exuberant Struggle sometimes a "new life" powerup appears; collecting this is actually a swing of *two* lives, because it gives you one and prevents your opponent getting one. (If you're in a situation where you can't possibly get the powerup, there is a third option - destroy it so that your opponent can't get it; a swing of one life, equivalent to killing them!) In ADAM ATOMIC's Terratri, capturing an opponent's territory is worth twice as much as capturing unoccupied territory but has the same cost - this gives rise to a degenerate "snaking" tactic of continually exchanging territory (Vertex Dispenser would suffer from the same problem if capturing enemy vertices were not sufficiently more slow and risky than capturing neutral ones).
3) In order to break this symmetry and get each player doing something different (without which the game is not very interesting) it's necessary to obscure the choices somehow so that it's hard to select the best option*. Some level of obscurity also helps to soften the essential viciousness of a pure zero-sum game - e.g. in games like Magic, Race for the Galaxy, Dominion (2-player), both players have a constructive feeling of "building up", even though with each action one player's raw chance of victory decreases.
Obscurity can be achieved through:
- Computational complexity (as in Chess, etc.). There may be an optimal choice, but it's very hard to work out what it is. If there's a tight time limit on making decisions then the difficulty of finding the best move doesn't have to be so high, and if there is unlimited time available and the complexity is too high this can lead to "analysis paralysis" as a player tries to compute their ideal move.
- Randomness or hidden information, so that it's impossible to determine the best choice using the information currently available. This isn't a completely satisfactory method because there will still be a statistically optimal choice based on what you do know (often this optimal choice is to randomly select between several alternatives with specified weights on each).
- Difficulty of execution, so that even if you know the best move it is still challenging to perform it.
- Secrecy of rules: simply not giving players access to what they need to know to make the best choice. This option is interesting to me, because it's only really possible with videogames, but it's not entirely satisfactory - it's more elegant for a game to offer difficult choices even when the rules are fully understood. It's also not very reliable; a sufficiently motivated player can always reverse engineer the rules.
* While obscurity is of special importance to two-player games, it is a key element of games in general, and in this they are distinct to puzzles - you want a puzzle to be eventually solved, even if the solution may be very difficult, but it's better for a game never to be completely solved.
1) Damage and score are equivalent. This isn't quite true: score can be unbounded if there's another condition for the game ending, but a target score is equivalent to a target amount of damage; competing to be the first to deal 100 damage is identical to competing to be the first to score 100 points. There are some perceptual differences: numbers going up feel different to numbers going down, and being able to recover damage done to yourself feels quite different to being able to reduce your opponent's score. The abstractness of score is generally more appropriate for more abstract games.
In multiplayer (in the sense of "more than two players") this symmetry is broken, and score/damage lead to quite different dynamics.
2) Everything is zero-sum. In multiplayer games it's common for different objects to have different values for each player, and this can add a lot of depth. In a two-player game, everything has the same value for both players; anything that helps one player is just as much hurting the other. If there's something only one of us can get, it's value to me is "what good it does for me to have it" + "what good it does for me for you not to have it". The value to me of you not having it is exactly how good it would be from your perspective for you to have it, so this equation is symmetric in the players - for example, something worth 3 points to me and 5 to you makes a difference of 3+5=8 points between our scores, no matter which of us gets it.
So lots of mechanics common in multiplayer games just don't work very well in two-player. If something is more effective for one player because of synergies with other powers, it's equally desirable for their opponent to prevent them getting. If an auction determines who gets something, each player should be willing to pay the exact same amount. If an action benefits an opponent as well as yourself, that is a strict disadvantage.
As a side-effect, when balancing a game sometimes the value of an object turns out to be double what you might expect - for example, in Exuberant Struggle sometimes a "new life" powerup appears; collecting this is actually a swing of *two* lives, because it gives you one and prevents your opponent getting one. (If you're in a situation where you can't possibly get the powerup, there is a third option - destroy it so that your opponent can't get it; a swing of one life, equivalent to killing them!) In ADAM ATOMIC's Terratri, capturing an opponent's territory is worth twice as much as capturing unoccupied territory but has the same cost - this gives rise to a degenerate "snaking" tactic of continually exchanging territory (Vertex Dispenser would suffer from the same problem if capturing enemy vertices were not sufficiently more slow and risky than capturing neutral ones).
3) In order to break this symmetry and get each player doing something different (without which the game is not very interesting) it's necessary to obscure the choices somehow so that it's hard to select the best option*. Some level of obscurity also helps to soften the essential viciousness of a pure zero-sum game - e.g. in games like Magic, Race for the Galaxy, Dominion (2-player), both players have a constructive feeling of "building up", even though with each action one player's raw chance of victory decreases.
Obscurity can be achieved through:
- Computational complexity (as in Chess, etc.). There may be an optimal choice, but it's very hard to work out what it is. If there's a tight time limit on making decisions then the difficulty of finding the best move doesn't have to be so high, and if there is unlimited time available and the complexity is too high this can lead to "analysis paralysis" as a player tries to compute their ideal move.
- Randomness or hidden information, so that it's impossible to determine the best choice using the information currently available. This isn't a completely satisfactory method because there will still be a statistically optimal choice based on what you do know (often this optimal choice is to randomly select between several alternatives with specified weights on each).
- Difficulty of execution, so that even if you know the best move it is still challenging to perform it.
- Secrecy of rules: simply not giving players access to what they need to know to make the best choice. This option is interesting to me, because it's only really possible with videogames, but it's not entirely satisfactory - it's more elegant for a game to offer difficult choices even when the rules are fully understood. It's also not very reliable; a sufficiently motivated player can always reverse engineer the rules.
* While obscurity is of special importance to two-player games, it is a key element of games in general, and in this they are distinct to puzzles - you want a puzzle to be eventually solved, even if the solution may be very difficult, but it's better for a game never to be completely solved.
Wednesday, 7 September 2011
Vertex Dispenser updated
I've updated Vertex Dispenser. Main changes:
- added mouse control for selecting abilities: scroll wheel to select colour, left/right button to activate ability. (also middle mouse to delete vertices; if you're using this instead of the alphabet keys you'll probably want to set movement to WASD instead of arrow keys.)
- slightly improved how it handles lag. (still some work to be done here.)
- fixed crashing on startup on some Macs with MacOS 10.5.
- small balance tweaks: Damage All does +2 damage to objects, Roaming Mine does +1 damage on a direct hit, vertices captured by Local Capture are invincible for a short duration.
A lot of people complaining about the large number of keys used for abilities. This really surprised me, because nobody mentioned it as a problem in playtesting, and because the keys are laid out in a really clear logical manner. I added an option ("Horizontal") to display the abilities across the bottom of the screen instead of to the right, so their positions map directly to the key positions - I find this a less convenient position for seeing when they're charged, but the option is there if anyone wants it. And now I've added an option to activate abilities with the mouse. It took quite a bit of experimentation to find a system for this that felt vaguely okay, and this is the result.. moving the mouse to select abilities didn't feel anywhere near as good (even with visual and audio feedback) as using the scroll wheel. It seems a bit inelegant to use the mouse just for buttons and scrolling, and not for the main thing that a mouse actually does (continuous movement), but I guess that's what you get when the game is discrete. The option is now there if you want it.
I doubt that this will make much difference to anyone. The game has been pretty unsuccessful, and small fixes like this aren't going to change that - I'd have to make it a completely different game, something I'd like less, something much closer to what's gone before. (Preferably a puzzle-platformer, that's how you make a successful indie game, right?)
- added mouse control for selecting abilities: scroll wheel to select colour, left/right button to activate ability. (also middle mouse to delete vertices; if you're using this instead of the alphabet keys you'll probably want to set movement to WASD instead of arrow keys.)
- slightly improved how it handles lag. (still some work to be done here.)
- fixed crashing on startup on some Macs with MacOS 10.5.
- small balance tweaks: Damage All does +2 damage to objects, Roaming Mine does +1 damage on a direct hit, vertices captured by Local Capture are invincible for a short duration.
A lot of people complaining about the large number of keys used for abilities. This really surprised me, because nobody mentioned it as a problem in playtesting, and because the keys are laid out in a really clear logical manner. I added an option ("Horizontal") to display the abilities across the bottom of the screen instead of to the right, so their positions map directly to the key positions - I find this a less convenient position for seeing when they're charged, but the option is there if anyone wants it. And now I've added an option to activate abilities with the mouse. It took quite a bit of experimentation to find a system for this that felt vaguely okay, and this is the result.. moving the mouse to select abilities didn't feel anywhere near as good (even with visual and audio feedback) as using the scroll wheel. It seems a bit inelegant to use the mouse just for buttons and scrolling, and not for the main thing that a mouse actually does (continuous movement), but I guess that's what you get when the game is discrete. The option is now there if you want it.
I doubt that this will make much difference to anyone. The game has been pretty unsuccessful, and small fixes like this aren't going to change that - I'd have to make it a completely different game, something I'd like less, something much closer to what's gone before. (Preferably a puzzle-platformer, that's how you make a successful indie game, right?)
Friday, 2 September 2011
BIGJam
Went to the Berlin Indie Game Jam last weekend, a meetup of game developers. Made four games, three of which aren't awful.
5 hour jam, theme "album cover of your choice": Resistance Revolution
3 hour jam, theme Free/Cat: Feline Feeling
2 hour jam, theme Mysterious/Enemy: Mysterious Sniper
3 hour jam, theme Delicious/Suicide: Delicious Cake (don't bother with this one)
Resistance Revolution is my favourite of these, it was based on this Muse cover:
A quite satisfactory weekend. Met lots of cool people.
5 hour jam, theme "album cover of your choice": Resistance Revolution
3 hour jam, theme Free/Cat: Feline Feeling
2 hour jam, theme Mysterious/Enemy: Mysterious Sniper
3 hour jam, theme Delicious/Suicide: Delicious Cake (don't bother with this one)
Resistance Revolution is my favourite of these, it was based on this Muse cover:
A quite satisfactory weekend. Met lots of cool people.
Friday, 10 June 2011
Vertex Dispenser
TLDR version: released a game, get it on steam.
This game has haunted me since 2005.
My first attempt at it pretty much failed. Back then it was a fairly standard RTS with a few weird new ideas mixed in. I didn't much know what I was doing, and the code got into quite a mess.
A couple of years later, I came back to it. I'd started a few other games (but not finished them), and knew better new how to go about things. I cut out the unnecessary parts of the design, trimmed it down to the core idea that was interesting, and ended up with something fantastic. And then I made it, played it quite a bit, tweaked it, relea--
No, wait. I didn't release it, it wasn't quite ready. This was early 2007.
It was a couple of weeks away from being done, but I needed to focus more on my studies, so I left it for a bit. It's been a couple of weeks away from completion ever since.
Back then, it was multiplayer-only. This wasn't ideal; although the game isn't inaccessible, it does have some skill to it, and it's easier to learn if you can take things at your own pace. (Not everyone agrees with this - some people like to learn an RTS by going straight into the multiplayer and losing until they win. This isn't for everyone. You're welcome to use this approach here, but it's maybe a bit harder when the game isn't a repeat of something you've played before.)
So I added a single player mode. It wasn't very good, so I threw it away and added another one. It's a series of levels with different goals, a "campaign", a fairly standard structure for a single-player mode of an RTS game.
Of course, this meant I needed to make AI for it, so I did. It will beat you.
One time, when I hadn't worked on the game for several months, I came back to it with a lot of new ideas for abilities. So I added them.
Some of them didn't work out very well, so I took them away.
It grew.
And then it was done. Well, almost. A couple of weeks away. I tested it with a bunch of different people, kept finding new things to fix and improve. Submitted it to the IGF - it didn't get in, but I met some amazing people who encouraged me that it was worth keeping working on it.
I got stuck, didn't work on it for a while. Friends would ask me if I'd finished it yet - no I haven't. I thought it was basically done - yes it is. But not quite.
This year, I had reason to switch to working part-time, and move to a different country.
Instantly, the game jumped back out at me.
"You're part-time, you can choose your hours, if you just spend a couple of weeks working on me full-time, I'll actually be finished."
Yeah right.
It was mostly correct - what I needed to do was work full-time on it for a little while. But those weeks were actually months,; making games is hard, and the final polishing stage is the hardest. Now I've completely lost track of whatever else I was supposed to be doing. But the game is done and it's fantastic and I'm so excited to finally get it out so others can play it. I hope you like it.
TIGSource review
tinysubversions
RockPaperShotgun Indie Forecast preview
DIYgamer interview
Steam store page
This game has haunted me since 2005.
My first attempt at it pretty much failed. Back then it was a fairly standard RTS with a few weird new ideas mixed in. I didn't much know what I was doing, and the code got into quite a mess.
A couple of years later, I came back to it. I'd started a few other games (but not finished them), and knew better new how to go about things. I cut out the unnecessary parts of the design, trimmed it down to the core idea that was interesting, and ended up with something fantastic. And then I made it, played it quite a bit, tweaked it, relea--
No, wait. I didn't release it, it wasn't quite ready. This was early 2007.
It was a couple of weeks away from being done, but I needed to focus more on my studies, so I left it for a bit. It's been a couple of weeks away from completion ever since.
Back then, it was multiplayer-only. This wasn't ideal; although the game isn't inaccessible, it does have some skill to it, and it's easier to learn if you can take things at your own pace. (Not everyone agrees with this - some people like to learn an RTS by going straight into the multiplayer and losing until they win. This isn't for everyone. You're welcome to use this approach here, but it's maybe a bit harder when the game isn't a repeat of something you've played before.)
So I added a single player mode. It wasn't very good, so I threw it away and added another one. It's a series of levels with different goals, a "campaign", a fairly standard structure for a single-player mode of an RTS game.
Of course, this meant I needed to make AI for it, so I did. It will beat you.
One time, when I hadn't worked on the game for several months, I came back to it with a lot of new ideas for abilities. So I added them.
Some of them didn't work out very well, so I took them away.
It grew.
And then it was done. Well, almost. A couple of weeks away. I tested it with a bunch of different people, kept finding new things to fix and improve. Submitted it to the IGF - it didn't get in, but I met some amazing people who encouraged me that it was worth keeping working on it.
I got stuck, didn't work on it for a while. Friends would ask me if I'd finished it yet - no I haven't. I thought it was basically done - yes it is. But not quite.
This year, I had reason to switch to working part-time, and move to a different country.
Instantly, the game jumped back out at me.
"You're part-time, you can choose your hours, if you just spend a couple of weeks working on me full-time, I'll actually be finished."
Yeah right.
It was mostly correct - what I needed to do was work full-time on it for a little while. But those weeks were actually months,; making games is hard, and the final polishing stage is the hardest. Now I've completely lost track of whatever else I was supposed to be doing. But the game is done and it's fantastic and I'm so excited to finally get it out so others can play it. I hope you like it.
TIGSource review
tinysubversions
RockPaperShotgun Indie Forecast preview
DIYgamer interview
Steam store page
Monday, 16 May 2011
Vic Davis - fiddly little decisions
Vic Davis (a.k.a. Cryptic Comet) is responsible for a couple of quite nice games: Armageddon Empires and Solium Infernum. He has a new game on the way sometime - Six Gun Saga - but apparently it's taking longer than expected to finish (I know the feeling).
These games have a very distinctive common style. Each takes an very iconic setting - post-apocalyptic wasteland, Hell, the wild west - and makes it feel quite fresh. They borrow mechanics heavily from board games, with explicit simulations of cards, dice, etc., but take advantage of the computer's capacity to handle an amount of complexity and hidden information that would be unreasonable in an actual board game. But what I want to discuss here is something a bit more obscure: they take actions that seem like a mere formality and turn them into strategic decisions by attaching a resource cost.
In Armageddon Empires, you train and recruit various army units - mutant dinosaur riders, deranged cultists, giant robot tanks - and send them out to fight for you. But before you can send them out, you have to assign them to a group! You only have a limited number of action points per turn; creating groups and moving units between them uses these up, as well as the usual stuff like ordering groups around on the battlefield and building stuff. It's sometimes frustrating - I've trained up this Lovecraftian horror but I can't send it out to devour my enemies yet because I don't have a group to assign them to; I can create a new group for it but then I don't have the actions left to send it out. But it's not unrealistic - managing an army in real life has a lot of administrative overhead, and this simulates that somewhat - and once you get used to taking it into account, it becomes a small but meaningful strategic consideration. I have some actions spare this turn - do I move my scouting party to explore a different hex, or do I create a new group ready for the units I'll be building in a few turns time?
In Solium Infernum, the resource system involves drawing randomly generated resource cards, containing elements like "ichor" and "darkness", which you then use to spend on armies/relics/etc.. The cards generally contain more than one unit of these resources, and may even contain different types, so sometimes you're forced to overpay - e.g. if you want to buy something that costs 3 hellfire, and you only have cards with 2 hellfire each, you're going to actually have to pay 4 for it. They don't give change in Hell. It makes for a really deep and interesting system, because the 'actual cost' of anything can vary from turn to turn depending on how your resources are divided up.
Overpaying isn't always a problem - most items in the game are purchased through a blind auction system, so often it's desirable to pay more than the minimum bid anyway in order to overbid your competitors.
Where this system gets fiddly - and some would say unnecessarily so - is the constraint that you can only pay with up to six resource cards. This can be frustrating: numerically I have enough resources to pay for an upgrade, but they're spread across too many cards so I can't use them. It adds an extra axis of complexity to the resources - sometimes you'd like them in smaller chunks so that you're not overpaying, but other times you want them in larger chunks so you can actually use them to pay for the bigger items. You can spend an action to combine resource cards together, but actions are very precious in this game - initially you only get 2 actions a turn, but you can increase this to a maximum of 6 at great expense. So you're forced to make choices between preparing to buy something big or taking something small - basically it sort of means expensive items cost disproportionately more because they cost an extra action as well. There's a risk to this too - if you're preparing to buy an item at auction which then someone else purchases first, you might end up with resources combined in an undesirable way. And either way, there's at least one turn where you have this big combined resource card in your vaults, where there's a risk of another player stealing it..
You can also cast magic spells on your opponents, which costs resources. At the start of the game, you are asked to rank all other players in order of who you consider the greatest threat, and it will cost less to cast spells on opponents lower on this list. You can change this ordering at a later point, but that costs resources as well, so you have to weigh whether you expect to save enough resources from the cheaper spells for it to be worth the cost of changing it.
I've seen a lot of complaints about all these mechanics I've mentioned, and fairly so - they are somewhat fiddly. But they end up generating interesting decisions, which is kind of the point of strategy games, right? This seems to be a key element of Vic's design style: to take away something that players might expect to get for free, and make them pay for it instead.
(Another example of this kind of thing I can think of: in Red Alert, you didn't get a minimap display until you'd constructed a Radar building, and then you'd lose it again if your opponent destroyed that building or cut off power to it. Brilliant.)
These games have a very distinctive common style. Each takes an very iconic setting - post-apocalyptic wasteland, Hell, the wild west - and makes it feel quite fresh. They borrow mechanics heavily from board games, with explicit simulations of cards, dice, etc., but take advantage of the computer's capacity to handle an amount of complexity and hidden information that would be unreasonable in an actual board game. But what I want to discuss here is something a bit more obscure: they take actions that seem like a mere formality and turn them into strategic decisions by attaching a resource cost.
In Armageddon Empires, you train and recruit various army units - mutant dinosaur riders, deranged cultists, giant robot tanks - and send them out to fight for you. But before you can send them out, you have to assign them to a group! You only have a limited number of action points per turn; creating groups and moving units between them uses these up, as well as the usual stuff like ordering groups around on the battlefield and building stuff. It's sometimes frustrating - I've trained up this Lovecraftian horror but I can't send it out to devour my enemies yet because I don't have a group to assign them to; I can create a new group for it but then I don't have the actions left to send it out. But it's not unrealistic - managing an army in real life has a lot of administrative overhead, and this simulates that somewhat - and once you get used to taking it into account, it becomes a small but meaningful strategic consideration. I have some actions spare this turn - do I move my scouting party to explore a different hex, or do I create a new group ready for the units I'll be building in a few turns time?
In Solium Infernum, the resource system involves drawing randomly generated resource cards, containing elements like "ichor" and "darkness", which you then use to spend on armies/relics/etc.. The cards generally contain more than one unit of these resources, and may even contain different types, so sometimes you're forced to overpay - e.g. if you want to buy something that costs 3 hellfire, and you only have cards with 2 hellfire each, you're going to actually have to pay 4 for it. They don't give change in Hell. It makes for a really deep and interesting system, because the 'actual cost' of anything can vary from turn to turn depending on how your resources are divided up.
Overpaying isn't always a problem - most items in the game are purchased through a blind auction system, so often it's desirable to pay more than the minimum bid anyway in order to overbid your competitors.
Where this system gets fiddly - and some would say unnecessarily so - is the constraint that you can only pay with up to six resource cards. This can be frustrating: numerically I have enough resources to pay for an upgrade, but they're spread across too many cards so I can't use them. It adds an extra axis of complexity to the resources - sometimes you'd like them in smaller chunks so that you're not overpaying, but other times you want them in larger chunks so you can actually use them to pay for the bigger items. You can spend an action to combine resource cards together, but actions are very precious in this game - initially you only get 2 actions a turn, but you can increase this to a maximum of 6 at great expense. So you're forced to make choices between preparing to buy something big or taking something small - basically it sort of means expensive items cost disproportionately more because they cost an extra action as well. There's a risk to this too - if you're preparing to buy an item at auction which then someone else purchases first, you might end up with resources combined in an undesirable way. And either way, there's at least one turn where you have this big combined resource card in your vaults, where there's a risk of another player stealing it..
You can also cast magic spells on your opponents, which costs resources. At the start of the game, you are asked to rank all other players in order of who you consider the greatest threat, and it will cost less to cast spells on opponents lower on this list. You can change this ordering at a later point, but that costs resources as well, so you have to weigh whether you expect to save enough resources from the cheaper spells for it to be worth the cost of changing it.
I've seen a lot of complaints about all these mechanics I've mentioned, and fairly so - they are somewhat fiddly. But they end up generating interesting decisions, which is kind of the point of strategy games, right? This seems to be a key element of Vic's design style: to take away something that players might expect to get for free, and make them pay for it instead.
(Another example of this kind of thing I can think of: in Red Alert, you didn't get a minimap display until you'd constructed a Radar building, and then you'd lose it again if your opponent destroyed that building or cut off power to it. Brilliant.)
Friday, 29 April 2011
bullshot
The term "bullshot" is sometimes used discussing videogames (apparently originating from a Penny Arcade strip); it refers to images released from an upcoming game that do not accurately represent the graphics of the game. And people say this like it's a bad thing, like they're somehow being cheated by seeing something that looks good. I want to debunk this as a meaningless complaint. Yes, it's not giving an accurate representation of what the game LOOKS LIKE, but how is that even relevant? We don't play games for what they look like; if that was all we wanted we would look at pictures or movies. We play games for the experience of playing them, for what goes on inside our heads as we play them, and a "bullshot" can be a more accurate representation of that than a direct screenshot.
Take ADOM for example.
If you've never played a roguelike game, this looks like a chaotic mess. But I see a quaint little village with a shop selling packaged meals, a few trees scattered around, and a small lake. Through playing the game, I've learnt what the symbols mean, new structures have been built inside my brain to interpret them. I still see the ascii characters, but they now mean something to me. ADOM has an intricate, detailed world, and just showing someone a screenshot doesn't communicate that, it wouldn't be a good way to sell the game to someone. If you had to come up with an image that expresses what the game is like, you wouldn't use a screenshot. You'd use a bullshot. And for many players, that might help them to grasp the game - there's a steep learning curve as you master the interface and learn what the symbols mean, and having this image of the world already in your head might help you get through this until you understand the game enough to form your own image.
This is the same with any game. When you first play an FPS, you see detailed pictures of monsters, wall textures, vegetation.. but after you've been playing for a couple of hours, you've internalised the meaning of what's going on screen. You don't see a high-polygon model of a red spiky demon thing, you see "IMP, shoots fireballs, choice: get out of the way or shoot it quick". Your brain has reduced the enemy to a symbol; you're no longer paying attention to what it looks like, because you know what it means.
So if the graphics of a game don't matter anymore once you're playing it, their purpose is purely for the first impression. This first impression is something the videogame industry pumps millions of dollars into crafting, and it's clearly something that sells games, but after the initial hit it doesn't do anything for the player (in fact, so-called "good graphics" often impair play by cluttering the display and making the symbolic meaning of game objects on-screen harder to discern). A bullshot just moves this first impression outside of the game; it gives a more vivid image of what the game objects represent than the in-game graphics can convey, and thus eases the process of building mental symbols for them.
Take ADOM for example.
If you've never played a roguelike game, this looks like a chaotic mess. But I see a quaint little village with a shop selling packaged meals, a few trees scattered around, and a small lake. Through playing the game, I've learnt what the symbols mean, new structures have been built inside my brain to interpret them. I still see the ascii characters, but they now mean something to me. ADOM has an intricate, detailed world, and just showing someone a screenshot doesn't communicate that, it wouldn't be a good way to sell the game to someone. If you had to come up with an image that expresses what the game is like, you wouldn't use a screenshot. You'd use a bullshot. And for many players, that might help them to grasp the game - there's a steep learning curve as you master the interface and learn what the symbols mean, and having this image of the world already in your head might help you get through this until you understand the game enough to form your own image.
This is the same with any game. When you first play an FPS, you see detailed pictures of monsters, wall textures, vegetation.. but after you've been playing for a couple of hours, you've internalised the meaning of what's going on screen. You don't see a high-polygon model of a red spiky demon thing, you see "IMP, shoots fireballs, choice: get out of the way or shoot it quick". Your brain has reduced the enemy to a symbol; you're no longer paying attention to what it looks like, because you know what it means.
So if the graphics of a game don't matter anymore once you're playing it, their purpose is purely for the first impression. This first impression is something the videogame industry pumps millions of dollars into crafting, and it's clearly something that sells games, but after the initial hit it doesn't do anything for the player (in fact, so-called "good graphics" often impair play by cluttering the display and making the symbolic meaning of game objects on-screen harder to discern). A bullshot just moves this first impression outside of the game; it gives a more vivid image of what the game objects represent than the in-game graphics can convey, and thus eases the process of building mental symbols for them.
Wednesday, 16 March 2011
playtest system
I've been using the following system for playtesting Vertex Dispenser. Recently I was a tester for Jason Rohrer's new game INSIDE A STAR FILLED SKY, and he was using a similar system to great effect. I thought I'd write it up because it's extremely useful; I would have benefited from implementing it sooner than I did (and I should probably use it for more of my games), so maybe this will help someone.
Basically, when someone plays my game all their input is recorded and logged to a file. Then they send me the logs, which I can play back and watch what they did in the game. I see (essentially) exactly what they saw, as though I was watching behind them as they played.
This is so ridiculously useful. Actually watching someone play is a million times better than sending them a game and getting written feedback. With written feedback there's an additional overhead from them having to explain where they had a problem, and if they've missed or misunderstood something important then they might not even know they have a problem, or might associate the problem with something completely different. If you can see them you know exactly what went wrong. Watching someone play in person is good, but it's easy to mess it up by telling them something to help them out. When someone downloads your game and plays it, they won't have you there to give hints, so recording remote playtests gives a much more accurate (and scary) depiction of what will happen when your game is released. It also enlarges your pool of possible testers, because they don't have to be geographically proximate and can do it in their own time.
(Written feedback is still useful, because you might determine from it ways that someone's mental model of the game is wrong that weren't clear from watching them play, or you might ask them why they were doing something that you didn't understand in the game. Also, suggestions from testers can be really useful; often you have to filter out stuff that conflicts with your own vision of the game, but sometimes another person will be able to come up with really excellent ideas that you couldn't think of because of your preconceptions.)
For this system to work, you need to make sure the game is completely deterministic from input. This means that updates to the game state shouldn't depend on the frame rate, and you have to be really careful with floating point numbers - they can give different results across different platforms, so it's best to stick with fixed point arithmetic if you can.. this is the hard bit. (Pseudo)random numbers are okay as long as you store the seed used with the log file. The input might be at the level of keystrokes and mouse movements, or at some higher level of game actions (i.e. "order unit X to move to position Y" for an RTS).
What else is great about this method is that once you've implemented it, several other things become trivial:
- It's useful in your own testing. If you think you glimpsed something out of place in one frame, you can just replay the log file frame by frame to check for sure.
- Replays are cool to have anyway. In an action or puzzle game, some players might like to share "look what I did", and in a strategy game some might like to look back over their games to see how they lost and can improve.
- Replays can be handy for tutorials. In Vertex Dispenser I have a couple of levels where I play a recording of myself solving a puzzle or using an ability, because playtests indicated that just using words wasn't explaining them adequately. These only took a few minutes to hack in because I already had this replay functionality to use.
- Networked multiplayer can be easier to implement (though still far from trivial). All you need to do is pass player input around the network, and advance the game simultaneously with the same input on each copy, and everyone will stay in sync (although you might want to check hashes of the game state regularly just to be sure). For some types of game it's more important to have a low response time locally than to have other players exactly in sync, so you want to do some kind of prediction instead of waiting for remote input, but a modification of this system can still work - I rewind when remote actions are received and then recompute up to the present time taking them into account.
Something Jason did but I didn't was to add to the file as they play, before input is acted upon, so that if there's a crash then the log will crash the game at the same point. I made the mistake of just saving the file at the end of each level, which means if there's a crash then a few minutes of recording are lost. Next time I'll know better.
Basically, when someone plays my game all their input is recorded and logged to a file. Then they send me the logs, which I can play back and watch what they did in the game. I see (essentially) exactly what they saw, as though I was watching behind them as they played.
This is so ridiculously useful. Actually watching someone play is a million times better than sending them a game and getting written feedback. With written feedback there's an additional overhead from them having to explain where they had a problem, and if they've missed or misunderstood something important then they might not even know they have a problem, or might associate the problem with something completely different. If you can see them you know exactly what went wrong. Watching someone play in person is good, but it's easy to mess it up by telling them something to help them out. When someone downloads your game and plays it, they won't have you there to give hints, so recording remote playtests gives a much more accurate (and scary) depiction of what will happen when your game is released. It also enlarges your pool of possible testers, because they don't have to be geographically proximate and can do it in their own time.
(Written feedback is still useful, because you might determine from it ways that someone's mental model of the game is wrong that weren't clear from watching them play, or you might ask them why they were doing something that you didn't understand in the game. Also, suggestions from testers can be really useful; often you have to filter out stuff that conflicts with your own vision of the game, but sometimes another person will be able to come up with really excellent ideas that you couldn't think of because of your preconceptions.)
For this system to work, you need to make sure the game is completely deterministic from input. This means that updates to the game state shouldn't depend on the frame rate, and you have to be really careful with floating point numbers - they can give different results across different platforms, so it's best to stick with fixed point arithmetic if you can.. this is the hard bit. (Pseudo)random numbers are okay as long as you store the seed used with the log file. The input might be at the level of keystrokes and mouse movements, or at some higher level of game actions (i.e. "order unit X to move to position Y" for an RTS).
What else is great about this method is that once you've implemented it, several other things become trivial:
- It's useful in your own testing. If you think you glimpsed something out of place in one frame, you can just replay the log file frame by frame to check for sure.
- Replays are cool to have anyway. In an action or puzzle game, some players might like to share "look what I did", and in a strategy game some might like to look back over their games to see how they lost and can improve.
- Replays can be handy for tutorials. In Vertex Dispenser I have a couple of levels where I play a recording of myself solving a puzzle or using an ability, because playtests indicated that just using words wasn't explaining them adequately. These only took a few minutes to hack in because I already had this replay functionality to use.
- Networked multiplayer can be easier to implement (though still far from trivial). All you need to do is pass player input around the network, and advance the game simultaneously with the same input on each copy, and everyone will stay in sync (although you might want to check hashes of the game state regularly just to be sure). For some types of game it's more important to have a low response time locally than to have other players exactly in sync, so you want to do some kind of prediction instead of waiting for remote input, but a modification of this system can still work - I rewind when remote actions are received and then recompute up to the present time taking them into account.
Something Jason did but I didn't was to add to the file as they play, before input is acted upon, so that if there's a crash then the log will crash the game at the same point. I made the mistake of just saving the file at the end of each level, which means if there's a crash then a few minutes of recording are lost. Next time I'll know better.
Saturday, 12 March 2011
GDC
GDC was awesome.
It's ridiculously huge. 19000 attendees, what? If there are that many people making games, how are there not a hell of a lot more games?
(Answer: most of these people aren't making their own games, they're working on other people's games, or hiring people to work on other people's games, or funding other people to make games, or distributing other people's games.. the mainstream industry is an alien place.)
So I felt a bit lost at first, until I met up with some folk I know from the internet and UK indie meetups. It helped to be involved with something as well, I think if I hadn't been speaking at EGW I'd have felt more lost and overwhelmed. (Speaking was surprisingly not overwhelming, despite being to an order of magnitude more people than I'd ever spoken in front of before. It helped that I wasn't on my own, but maybe it's easier to talk about games than mathematics too.)
I happened to have gotten a full pass for free, so I went to talks and stuff, but it would have been well worth going just to meet up with people, even to just stay at the hostel and meet people there outside of GDC! I'm used to gamemaking just being my own weird hobby that nobody else does, so being surrounded by others who do the same was an amazing experience. Some of the talks were really good, but it wouldn't have been worth me actually paying full price for them.
Michael Todd's talk about depression really spoke to where I am right now with my mathematics. I've been in a downward spiral where lack of progress leads to lack of motivation and then lack of motivation leads to lack of progress. He suggested some strategies for dealing with this (in the context of game development, but applicable outside of it): focus on highly rewarding projects, stop being a perfectionist, work on shorter projects, measure work hours, design to suit your abilities.
Brian Moriarty gave an entertaining, well-researched, thought-provoking, but mostly wrong talk defending Roger Ebert's (dull, poorly-researched, completely wrong) claim that games cannot be art.
He pointed out that to determine whether games are art we need to agree on a definition of "art". Clearly games are are art under some definitions. But after this good start he failed to define his term "sublime art"! One of the common features of his examples of "sublime art" seemed to be historic significance, but this was presumably not the intention.
He made the point that videogames are not exceptional among games; they should only be considered to be art if board games are also. This seems obvious to me, but I've come across those who think otherwise so it's worth saying. He used this to support his argument that games aren't art because some philosopher didn't include them in his enumeration of art forms, which seemed a bit weak to me.
He also claimed that nobody considered mathematics to be an art form; I do, and I know many others who do also (mostly mathematicians).
He said we can't expect big studios to produce great art, because they need to make a profit, but then made the unusual claim that the same applies to independent game developers; he is perhaps unaware of how many people are making games while financially supporting themselves (or not) by other means (or with other games). But this is irrelevant to Ebert's claim, which was that games cannot ever be art, not that nobody is motivated to make artistic games.
Other talks I enjoyed were Steph Thirion's on designing by accident and experiment, and Brenda Braithwaite's on designing games about tragedy.
Overall, an incredible week. Hopefully I'll be able to go again - this happened to be on my way back from a friend's wedding in NZ (after not having been home for two years), so there was essentially no travel cost, and then I had a speaker's pass as well. Might not work out so perfectly next time.
It's ridiculously huge. 19000 attendees, what? If there are that many people making games, how are there not a hell of a lot more games?
(Answer: most of these people aren't making their own games, they're working on other people's games, or hiring people to work on other people's games, or funding other people to make games, or distributing other people's games.. the mainstream industry is an alien place.)
So I felt a bit lost at first, until I met up with some folk I know from the internet and UK indie meetups. It helped to be involved with something as well, I think if I hadn't been speaking at EGW I'd have felt more lost and overwhelmed. (Speaking was surprisingly not overwhelming, despite being to an order of magnitude more people than I'd ever spoken in front of before. It helped that I wasn't on my own, but maybe it's easier to talk about games than mathematics too.)
I happened to have gotten a full pass for free, so I went to talks and stuff, but it would have been well worth going just to meet up with people, even to just stay at the hostel and meet people there outside of GDC! I'm used to gamemaking just being my own weird hobby that nobody else does, so being surrounded by others who do the same was an amazing experience. Some of the talks were really good, but it wouldn't have been worth me actually paying full price for them.
Michael Todd's talk about depression really spoke to where I am right now with my mathematics. I've been in a downward spiral where lack of progress leads to lack of motivation and then lack of motivation leads to lack of progress. He suggested some strategies for dealing with this (in the context of game development, but applicable outside of it): focus on highly rewarding projects, stop being a perfectionist, work on shorter projects, measure work hours, design to suit your abilities.
Brian Moriarty gave an entertaining, well-researched, thought-provoking, but mostly wrong talk defending Roger Ebert's (dull, poorly-researched, completely wrong) claim that games cannot be art.
He pointed out that to determine whether games are art we need to agree on a definition of "art". Clearly games are are art under some definitions. But after this good start he failed to define his term "sublime art"! One of the common features of his examples of "sublime art" seemed to be historic significance, but this was presumably not the intention.
He made the point that videogames are not exceptional among games; they should only be considered to be art if board games are also. This seems obvious to me, but I've come across those who think otherwise so it's worth saying. He used this to support his argument that games aren't art because some philosopher didn't include them in his enumeration of art forms, which seemed a bit weak to me.
He also claimed that nobody considered mathematics to be an art form; I do, and I know many others who do also (mostly mathematicians).
He said we can't expect big studios to produce great art, because they need to make a profit, but then made the unusual claim that the same applies to independent game developers; he is perhaps unaware of how many people are making games while financially supporting themselves (or not) by other means (or with other games). But this is irrelevant to Ebert's claim, which was that games cannot ever be art, not that nobody is motivated to make artistic games.
Other talks I enjoyed were Steph Thirion's on designing by accident and experiment, and Brenda Braithwaite's on designing games about tragedy.
Overall, an incredible week. Hopefully I'll be able to go again - this happened to be on my way back from a friend's wedding in NZ (after not having been home for two years), so there was essentially no travel cost, and then I had a speaker's pass as well. Might not work out so perfectly next time.
Friday, 25 February 2011
Experimental Gameplay
http://schedule.gdconf.com/session/12401
I'm presenting The Sense of Connectedness.
No idea how this has happened, but it's exciting.
I'm presenting The Sense of Connectedness.
No idea how this has happened, but it's exciting.
Wednesday, 23 February 2011
Starcraft 2 fail
I've been home for a little bit, so I've had the chance to play Starcraft 2 a little on my brother's computer. (I know, I'm a little late to the party - but being a bit of an itinerant at the moment I don't have a powerful desktop computer so I'm always behind on new releases; also I don't care.)
It's.. not as great as I was expecting. In several ways it's actually stepped backwards from the original. Certainly it looks pretty, the narrative is competent (one doesn't expect too much from videogame stories), and it has all the base-building and fighting and blowing things up one would expect. But the graphics are worse, units have less character, and it's missing some useful features one would expect these days, e.g. zoom. (Yes, there's a minimap, but minimaps were never an essential feature of the genre - they were a hack to get around the tech not being able to handle zooming out, and now it can.) They also left out 2/3 of the campaign (the Zerg and Protoss sections), which isn't such a big deal since they made the Terran section huge, but would have helped with learning to play the omitted races for multiplayer.
And yes, I did say the graphics are worse. This does not contradict it looking pretty. In the metric of being pleasing to look at in screenshots and videos the graphics are objectively better. But this isn't the primary purpose of graphics in a game! Compared to the original, the graphics do a worse job of communicating quickly and clearly what's going on. Colours and outlines have less contrast (in the original, unit colours were a lot more saturated than the background, which helped make them stand out), and unit types are less well distinguished. I once caused myself some trouble by mistaking a group of SCVs for a group of Reapers; they're both blocky robot things with glowy backs, but perform completely different roles in the game.
Not the end of the world, but kind of sad. And, I think, interesting to see how the goal of making detailed realistic graphics conflicts with the goal of making a game playable.
New goal: write non-negative posts about other games sometimes.
It's.. not as great as I was expecting. In several ways it's actually stepped backwards from the original. Certainly it looks pretty, the narrative is competent (one doesn't expect too much from videogame stories), and it has all the base-building and fighting and blowing things up one would expect. But the graphics are worse, units have less character, and it's missing some useful features one would expect these days, e.g. zoom. (Yes, there's a minimap, but minimaps were never an essential feature of the genre - they were a hack to get around the tech not being able to handle zooming out, and now it can.) They also left out 2/3 of the campaign (the Zerg and Protoss sections), which isn't such a big deal since they made the Terran section huge, but would have helped with learning to play the omitted races for multiplayer.
And yes, I did say the graphics are worse. This does not contradict it looking pretty. In the metric of being pleasing to look at in screenshots and videos the graphics are objectively better. But this isn't the primary purpose of graphics in a game! Compared to the original, the graphics do a worse job of communicating quickly and clearly what's going on. Colours and outlines have less contrast (in the original, unit colours were a lot more saturated than the background, which helped make them stand out), and unit types are less well distinguished. I once caused myself some trouble by mistaking a group of SCVs for a group of Reapers; they're both blocky robot things with glowy backs, but perform completely different roles in the game.
Not the end of the world, but kind of sad. And, I think, interesting to see how the goal of making detailed realistic graphics conflicts with the goal of making a game playable.
New goal: write non-negative posts about other games sometimes.
Tuesday, 22 February 2011
Exuberant Struggle
Made this for a TIGSource competition with the theme "Versus".
Exuberant Struggle (windows)
Currently it only supports exactly two players, both on the same keyboard (WASD vs. arrows). I had a vague intention to add AI and networking sometime, but they both seem unnecessary now.
It's a sort of action/strategy game. Resources pop up in the middle of the screen, players control ships moving along the edges, line up with resources to pull them towards you and collect them. Then you can spend resources to make units and fire weapons (which are chosen from random options given you).
edit: updated (21/03/2011), new win condition and stuff, see tigsource thread if you want the details. updated (26/03/2011), minor balance tweaks, hopefully not going to tweak it any furuther.
Exuberant Struggle (windows)
Currently it only supports exactly two players, both on the same keyboard (WASD vs. arrows). I had a vague intention to add AI and networking sometime, but they both seem unnecessary now.
It's a sort of action/strategy game. Resources pop up in the middle of the screen, players control ships moving along the edges, line up with resources to pull them towards you and collect them. Then you can spend resources to make units and fire weapons (which are chosen from random options given you).
edit: updated (21/03/2011), new win condition and stuff, see tigsource thread if you want the details. updated (26/03/2011), minor balance tweaks, hopefully not going to tweak it any furuther.
Friday, 14 January 2011
procrastination
I made a few white vertices..
I expect this means nothing if you haven't played the game. Vertices (the little coloured balls) give resources in the different colours, white being the best. I am powerful.
I also recorded a video of a full game. 2 vs. 2, the other players are AI.
Clearly I am procrastinating something. I don't even have the excuse of disease anymore. Still, the game is just about finished.
I expect this means nothing if you haven't played the game. Vertices (the little coloured balls) give resources in the different colours, white being the best. I am powerful.
I also recorded a video of a full game. 2 vs. 2, the other players are AI.
Clearly I am procrastinating something. I don't even have the excuse of disease anymore. Still, the game is just about finished.
Subscribe to:
Posts (Atom)