This term I'm taking my second game design course from Professor Mary Flanagan. This one is subtitled "Values at Play", with a focus on encoding values in gameplay.
Last year's game design class required one game per week. I'm guessing that this year will be similar. I'll post descriptions of my games here.
March 29, 2010
March 2, 2010
Aurora Thoughts
I'm making progress on Aurora. Recently I've been mostly focusing on experimenting with the UI and making the music system work (more on that later), but I'm also putting thought into the core gameplay structure. To remind you, the basic idea is that there are buildings and troops. Buildings produce troops at a constant rate. Troops can annihilate themselves against enemy troops, enemy buildings, or friendly buildings (to upgrade). Buildings can be upgraded once, doubling their production rate. It costs 100 troops to build, upgrade, or destroy a building.
In trying to create a pared-down RTS, I may have broken the genre. By removing most elements of luck and putting players on an even field, the game tends towards a stalemate. Most of the strategy involved right now involves trying to slowly-but-surely gain numerical advantage over the enemy. There are a few ways of doing this:
- Upgrade your stars before they do and have a higher production rate until they catch up.
- Let the enemy annihilate troops against your buildings, but not so many that your buildings die (so they are essentially wasted).
- Focus fire on an enemy building and gain a production advantage until they send reinforcements and recolonize it.
- Destroy an upgraded enemy building (you spend 100 destroying something that took 200 to fully build).
- Let the two enemies waste their forces against each other and build up strength from afar.
That takes too long, and it's too passive to be consistently fun. I'm led to believe that RTSs are mostly defined by the imbalances, asymmetry, and chaos they introduce. Rock-Paper-Scissors combat mechanics, asymmetric factions, and interesting maps are examples of this. I was trying to distill the RTS down to something simple, symmetric, and direct, like Chess, but the "essential" rules to which I am committed don't offer the complexity that's required to make that scenario interesting.
This leaves me with three options.
First, I can add larger, more complex, and maybe more asymmetric maps. Just the possibility of having multiple fronts of battle might be enough to solve my conundrum. I plan to try this first.
Second, I can cave in and change my basic mechanics, thereby admitting defeat in my design experiment, and make it into something different. Multiple building types, multiple troop types, flanking effects, etc. I'll add complexity until I force strategy.
Third, I can report the results of my failed experiment like a good scientist. If it's still unfun (but also still an honest attempt at an essentialized RTS), I can release it as-is and show it off in order to teach others the lessons I learned during its design. Principled and uncompromising, but maybe unsatisfying as well.
For now, I'm hoping that the first option will be enough.
February 27, 2010
Lessons of D&D
It went well. A summary of the adventure is on the campaign's blog record: Part One, Part Two, Part Three.
Of course, it could have gone better. The biggest challenge to running a long weekend game was the difficulty of improvisation in DMing. I had only certain encounters prepared (most of which turned out to be too easy), so I had to put the story on rails to a certain extent. I used the same strategy seen in Mass Effect or Dragon Age in which the player is given a few tasks and can complete them in any order (with special events happening in between).
Characters were the best and the worst part of this module. The bit characters (the alchemist, the gnome dungeon keeper) were excellent and fun to play, but the more nuanced characters couldn't be developed or revealed naturally. The players weren't interested in rambling conversation, and the to-the-point conversation could only carry so much characterization in it. My biggest problem was with my villain. It wasn't clear that he was the bad guy from the start. I was counting on my players asking certain questions and getting a big reveal, but they didn't. That's my fault, not theirs.
I also had several encounters that existed mostly to provide interesting combat. When my players decided to engage their enemies cleverly (using Bluff or something), I was often not entirely sure of what to do. I improvised decently, sometimes letting the players off and sometimes driving towards a fight, but it was a lost opportunity. I could have used these encounters to build the wider story.
I'd be interested in carrying on with this campaign, hopefully on a weekly format. I think that if I handled it a few encounters at a time, the game could go in a lot more interesting directions.
Of course, it could have gone better. The biggest challenge to running a long weekend game was the difficulty of improvisation in DMing. I had only certain encounters prepared (most of which turned out to be too easy), so I had to put the story on rails to a certain extent. I used the same strategy seen in Mass Effect or Dragon Age in which the player is given a few tasks and can complete them in any order (with special events happening in between).
Characters were the best and the worst part of this module. The bit characters (the alchemist, the gnome dungeon keeper) were excellent and fun to play, but the more nuanced characters couldn't be developed or revealed naturally. The players weren't interested in rambling conversation, and the to-the-point conversation could only carry so much characterization in it. My biggest problem was with my villain. It wasn't clear that he was the bad guy from the start. I was counting on my players asking certain questions and getting a big reveal, but they didn't. That's my fault, not theirs.
I also had several encounters that existed mostly to provide interesting combat. When my players decided to engage their enemies cleverly (using Bluff or something), I was often not entirely sure of what to do. I improvised decently, sometimes letting the players off and sometimes driving towards a fight, but it was a lost opportunity. I could have used these encounters to build the wider story.
I'd be interested in carrying on with this campaign, hopefully on a weekly format. I think that if I handled it a few encounters at a time, the game could go in a lot more interesting directions.
February 18, 2010
Dungon Master
In two days I'll be DMing my first game of Dungeons and Dragons! I've been playing 4th edition for some time, and I get one weekend to see what the other side of the screen is like.
Creating a weekend adventure has been an interesting and unique design challenge. I'm trying to create a somewhat story-centric adventure, and making sure that things make sense has been difficult. I'm also trying to figure out how to offer the feeling of freedom while keeping the total number of story branches contained (I don't have much time to revise the course of the story on-the-fly). I've already railroaded my players somewhat by requiring no mercenary or evil characters, essentially demanding that they act out of the goodness of their hearts.
Still, I'm pretty confident that it will turn out all right. I'm very much looking forward to roleplaying some of my NPCs. I think my players will appreciate the characters I've dreamt up.
Creating a weekend adventure has been an interesting and unique design challenge. I'm trying to create a somewhat story-centric adventure, and making sure that things make sense has been difficult. I'm also trying to figure out how to offer the feeling of freedom while keeping the total number of story branches contained (I don't have much time to revise the course of the story on-the-fly). I've already railroaded my players somewhat by requiring no mercenary or evil characters, essentially demanding that they act out of the goodness of their hearts.
Still, I'm pretty confident that it will turn out all right. I'm very much looking forward to roleplaying some of my NPCs. I think my players will appreciate the characters I've dreamt up.
January 1, 2010
Game Design Decision
My first game design problem of the new year is an interesting one, and a pretty typical one. It's a good example of the stuff I think about when making games, and maybe my still-incomplete thinking on the subject will be a good example of how I try to solve these problems.
In Aurora, players have one "building" (in RTS terms), which is called a Sun and which periodically spits out troops that can be used to attack or can be sacrificed to build or upgrade a Sun. There is a small, finite number of spots on which a player can build new Suns. When a Sun is upgraded, it starts to produce more valuable troops. Suns exist at some level from 1 to 5 and produce troops of corresponding strength. The strength of a troop matters during upgrading, so if an upgrade "costs 100", you need 100 level-1 troops or 20 level-5 troops (or some other combination that adds up correctly).
So here's the question: how much should it cost to upgrade a Sun to its next level? Upgrading is a very important mechanic, since it can make a Sun up to five times more useful than it starts. I'm considering three options right now. First, all upgrades could cost some static number, like 100. Second, all upgrades could cost some number times the current level of the Sun, so building a new Sun could cost 100, upgrading it the first time could cost 200, and then 300, etc. until the maximum. Third, the cost of upgrades for all suns could increase universally, so that the first upgrade on any Sun could cost 100, then the player's next upgrade (even on a different Sun) could cost 200, etc. Meanwhile, the cost of building new Suns would stay low and constant.
My thoughts on the pros and cons of each system:
1. Static Cost
The maximum rate of upgrading accelerates, quickening the pace of the game. The player can get as much advantage out of upgrading a Sun as building a new one. Since some Suns will be better defended than others, this encourages the player to upgrade the best-defended Suns rather than expand. Players will expand slower and upgrade more, and the game space will be marked by some very valuable Suns.
2. Increasing Cost
The maximum rate of upgrading is more stable. The player can get more advantage out of building a new Sun than upgrading any. If determined to upgrade, the player is encouraged to upgrade the weakest, lowest-level Suns first before making any especially strong ones. The strategic terrain is therefore more flat, but expansion is encouraged, and so conflict may be more common.
3. Universally Increasing Cost
The maximum rate of upgrading remains totally constant. The player can get much more advantage out of building a new Sun than upgrading any. Upgrading eventually becomes so expensive that attack is more advantageous than investment, since a new Sun can be built on the remains of the enemy's. Since the location of an upgrade doesn't affect its cost, the layout of high-level Suns will be varied, like option #1.
Option 1 incentivizes a lot of quick upgrading. Option 2 incentivizes expansion and then "flat" upgrading (where upgrading is spread evenly across Suns). Option 3 incentivizes quick early upgrades (maybe, depending on starting cost) and then attacks to conquer new territory. I still don't think I understand the "feel" of these different systems.
If any one player is quicker at the start of the game than others, Option 1 ensures that that player will dominate the game before combat even starts due to the accelerating growth. I dislike games in which the outcome is decided before you even meet your opponent; it becomes a simple race or test of mouse dexterity. And yet, Option 1 offers the intriguing possibility of being able to come back from behind after some well-timed upgrading investment.
I'm bothered by the prospect of a "flat" game terrain with Option 2. I like having some targets be more appealing than others since it introduces tactics like blitzing a poorly-defended but high-level Sun. Encouraging conflict is good, but this game might not need it if I'm going for a more cerebral feel.
Option 3 introduces an interesting player decision of determining when it is more advantageous to attack an enemy than continue upgrading. And after all, interesting player decisions are what this is all about. The big negative to this system is that it slows down the pace of upgrading over time, and I worry about what that might do to the game's interest curve. But, then, maybe a stable rate of production combined with an incentive to attack would make the game more exciting in its later stages.
And there are, of course, other considerations at play. Game performance would be better with a system that encourages fewer, stronger Suns and troops, like Option 1, and that option would also allow a constant cost and therefore a simpler UI.
Right now I'm leaning towards a static cost system (Option 1).
In Aurora, players have one "building" (in RTS terms), which is called a Sun and which periodically spits out troops that can be used to attack or can be sacrificed to build or upgrade a Sun. There is a small, finite number of spots on which a player can build new Suns. When a Sun is upgraded, it starts to produce more valuable troops. Suns exist at some level from 1 to 5 and produce troops of corresponding strength. The strength of a troop matters during upgrading, so if an upgrade "costs 100", you need 100 level-1 troops or 20 level-5 troops (or some other combination that adds up correctly).
So here's the question: how much should it cost to upgrade a Sun to its next level? Upgrading is a very important mechanic, since it can make a Sun up to five times more useful than it starts. I'm considering three options right now. First, all upgrades could cost some static number, like 100. Second, all upgrades could cost some number times the current level of the Sun, so building a new Sun could cost 100, upgrading it the first time could cost 200, and then 300, etc. until the maximum. Third, the cost of upgrades for all suns could increase universally, so that the first upgrade on any Sun could cost 100, then the player's next upgrade (even on a different Sun) could cost 200, etc. Meanwhile, the cost of building new Suns would stay low and constant.
My thoughts on the pros and cons of each system:
1. Static Cost
The maximum rate of upgrading accelerates, quickening the pace of the game. The player can get as much advantage out of upgrading a Sun as building a new one. Since some Suns will be better defended than others, this encourages the player to upgrade the best-defended Suns rather than expand. Players will expand slower and upgrade more, and the game space will be marked by some very valuable Suns.
2. Increasing Cost
The maximum rate of upgrading is more stable. The player can get more advantage out of building a new Sun than upgrading any. If determined to upgrade, the player is encouraged to upgrade the weakest, lowest-level Suns first before making any especially strong ones. The strategic terrain is therefore more flat, but expansion is encouraged, and so conflict may be more common.
3. Universally Increasing Cost
The maximum rate of upgrading remains totally constant. The player can get much more advantage out of building a new Sun than upgrading any. Upgrading eventually becomes so expensive that attack is more advantageous than investment, since a new Sun can be built on the remains of the enemy's. Since the location of an upgrade doesn't affect its cost, the layout of high-level Suns will be varied, like option #1.
Option 1 incentivizes a lot of quick upgrading. Option 2 incentivizes expansion and then "flat" upgrading (where upgrading is spread evenly across Suns). Option 3 incentivizes quick early upgrades (maybe, depending on starting cost) and then attacks to conquer new territory. I still don't think I understand the "feel" of these different systems.
If any one player is quicker at the start of the game than others, Option 1 ensures that that player will dominate the game before combat even starts due to the accelerating growth. I dislike games in which the outcome is decided before you even meet your opponent; it becomes a simple race or test of mouse dexterity. And yet, Option 1 offers the intriguing possibility of being able to come back from behind after some well-timed upgrading investment.
I'm bothered by the prospect of a "flat" game terrain with Option 2. I like having some targets be more appealing than others since it introduces tactics like blitzing a poorly-defended but high-level Sun. Encouraging conflict is good, but this game might not need it if I'm going for a more cerebral feel.
Option 3 introduces an interesting player decision of determining when it is more advantageous to attack an enemy than continue upgrading. And after all, interesting player decisions are what this is all about. The big negative to this system is that it slows down the pace of upgrading over time, and I worry about what that might do to the game's interest curve. But, then, maybe a stable rate of production combined with an incentive to attack would make the game more exciting in its later stages.
And there are, of course, other considerations at play. Game performance would be better with a system that encourages fewer, stronger Suns and troops, like Option 1, and that option would also allow a constant cost and therefore a simpler UI.
Right now I'm leaning towards a static cost system (Option 1).
Subscribe to:
Posts (Atom)