The newest spinwheel design is working surprisingly well. All the fancy math with angles and tangents wasn't completely necessary; the wheel is working adequately with just radii for Inside, Outside and Lock. I did need to tweak the state machine with some intermediate states to avoid getting stuck in certain transitions. The key breakthrough was a diagram I call Quadrant-Chaos, with a lookup table representing Clockwise or Counter-clockwise rotation. A few threshold checks make it function adequately for the prototype.
Occasionally the spinwheel will fail to lock, or skip a state. This implies the angles and tangents approach might still be the final solution in the implemented Construction project. However, the spinwheel is certainly at a solid prototype level of functionality, so the technical risk is mitigated.
It's really fun to play with the spinwheel, and see it updating images and text fields on the screen. Also, I'm really quite pleased with Javascript as an untyped, interpreted RAD language. It's quite excellent for prototyping.
Monday, October 31, 2011
Friday, October 28, 2011
Mongoose for local web serving.
One of the hassles of my prototype development has been serving the web pages. iPad Safari is very picky about simply mounting Windows shared folders. I was stuck publishing my HTML and JavaScript/CSS to my personal website, then viewing it on my iPad. It was a clunky process that added several extra steps when I was debugging code.
I described this problem over on the Fear the Boot forums and immediately got a great answer. Runester of "Postcards from the Dungeon" fame recommended Mongoose as a solution. Mongoose is a free Google open source project. It provides a very lightweight web server. You just fire up the mongoose-3.0.exe executable in the directory you want to share, and it is immediately published on your local WiFi network as http://localhost:8080 or http://ip_address:8080. Mongoose also provides single-click start/stop service, so it's extremely handy. I can now hammer code on my laptop, hit refresh on my iPad, and instantly see my code updates.
I had already planned on buying an Apple Airport for my secure home network and streaming stereo solution. I wouldn't want to run a web server from my laptop while it's connected to the Internet, but since I already have a separate WiFi router for that, I'll just leave my Airport detached as a purely local loop.
I described this problem over on the Fear the Boot forums and immediately got a great answer. Runester of "Postcards from the Dungeon" fame recommended Mongoose as a solution. Mongoose is a free Google open source project. It provides a very lightweight web server. You just fire up the mongoose-3.0.exe executable in the directory you want to share, and it is immediately published on your local WiFi network as http://localhost:8080 or http://ip_address:8080. Mongoose also provides single-click start/stop service, so it's extremely handy. I can now hammer code on my laptop, hit refresh on my iPad, and instantly see my code updates.
I had already planned on buying an Apple Airport for my secure home network and streaming stereo solution. I wouldn't want to run a web server from my laptop while it's connected to the Internet, but since I already have a separate WiFi router for that, I'll just leave my Airport detached as a purely local loop.
Thursday, October 27, 2011
Anthracite Elaboration Timeline
Short and sweet.
| E1: 5 ed | Oct 31 - Nov 4 |
| E2: 10-15 ed | Nov 7 - Nov 11 (14) |
| E3: 15 ed | Nov 14 (21) - Nov 20 (27) |
Tuesday, October 25, 2011
Anthracite Elaboration Plan
Okay, so here's the Elaboration Iteration Plan for Anthracite.
For non-techies, I'm using the Rational Unified Process from IBM. An "iteration" is a project plan increment that encompasses requirements, design, code and test. Every phase is composed of several iterations, each with specific goals. I just finished the Inception phase, which is a concept phase that focuses on business case, customer identification and technical feature analysis. Now I'm starting Elaboration. The purpose of Elaboration is to address your biggest business and technical risks by constructing a prototype software architecture.
My biggest risks are that: 1. it's tough to engage artists and writers without a product demo, because they are constantly approached by dreamers, and 2. I am a novice at Internet marketing and have very few industry contacts to create a real sales channel.
You'll note that I don't consider technology a risk at this point. The Anthracite platform technology is fairly straightforward software, so I believe any reasonably competent software engineer can drive it through to completion. Time and cost are more meaningful risks, but the only way to understand those risks better is to implement the prototype.
I originally came up with over a dozen Elaboration iterations, but then I realized that it's completely unnecessary to implement the entire product as a JavaScript/CSS prototype. I need just enough to show potential partners that the concept is real, and that I have the technical chops to implement the rest of the product plan as an iPad app. I've already constructed 60% of the use case model, which expresses (at a generic level) how the customer and system interact. The next step is converting these into sequence diagrams, or use case realizations, which show how the modules in the system interact to actually perform the use cases.
UCRs are a big step towards actual code. In my opinion they are also the toughest part of Elaboration. It's easy to lose the forest for the trees, and start inventing cool new features in the use cases, or start trying to create a finalized product architecture in the design diagrams. The former is a temptation for visionaries, who thrive on creating cool new concepts, and perhaps not so much on actually producing completed products. The latter is a big temptation for code monkeys, because you start thinking that you can avoid any rework and refactoring if you just get the design 'perfected' in Elaboration. Both are huge mistakes. All you end up doing is stretching out the phase, which actually increases your overall project risk. You've got to stay laser focused on eliminating (or quantifying) your biggest project risks by driving through to actual functioning prototype code. Many stakeholders will readily agree with high-level use case descriptions, only to have a strong negative reaction when they're actually seeing the product prototype. And you're always going to do code rework in Construction. It's much more important to get aligned that you're building the right system (business case, use cases) and that you've got a solid high-level design for that system (sequence diagrams, analysis objects, large architectural blocks, mechanisms).
Elaboration is about running through the minefield, stepping on as many mines as possible, so you know where most of them are before you commit the bulk of your development budget in Construction. Your prototype doesn't need to be pretty, full-featured or bug-free, but it absolutely, positively must address your biggest technical and business risks.
And having written that, I need to seriously consider how I'm going to address the marketing risk, because the prototype only addresses the partnership risk. :| Good thing I wrote this all out. I'll put some target dates on these goals in a subsequent post, after I do a little more analysis.
Elaboration Goal: To implement a JavaScript/CSS prototype for iPad demos and YouTube videos.
E1: Layout and Spinwheel
E2: Character Templates and Objects
E3: Basic Effects Resolution and Simple Battle
===== YouTube Video #1 =====
For non-techies, I'm using the Rational Unified Process from IBM. An "iteration" is a project plan increment that encompasses requirements, design, code and test. Every phase is composed of several iterations, each with specific goals. I just finished the Inception phase, which is a concept phase that focuses on business case, customer identification and technical feature analysis. Now I'm starting Elaboration. The purpose of Elaboration is to address your biggest business and technical risks by constructing a prototype software architecture.
My biggest risks are that: 1. it's tough to engage artists and writers without a product demo, because they are constantly approached by dreamers, and 2. I am a novice at Internet marketing and have very few industry contacts to create a real sales channel.
You'll note that I don't consider technology a risk at this point. The Anthracite platform technology is fairly straightforward software, so I believe any reasonably competent software engineer can drive it through to completion. Time and cost are more meaningful risks, but the only way to understand those risks better is to implement the prototype.
I originally came up with over a dozen Elaboration iterations, but then I realized that it's completely unnecessary to implement the entire product as a JavaScript/CSS prototype. I need just enough to show potential partners that the concept is real, and that I have the technical chops to implement the rest of the product plan as an iPad app. I've already constructed 60% of the use case model, which expresses (at a generic level) how the customer and system interact. The next step is converting these into sequence diagrams, or use case realizations, which show how the modules in the system interact to actually perform the use cases.
UCRs are a big step towards actual code. In my opinion they are also the toughest part of Elaboration. It's easy to lose the forest for the trees, and start inventing cool new features in the use cases, or start trying to create a finalized product architecture in the design diagrams. The former is a temptation for visionaries, who thrive on creating cool new concepts, and perhaps not so much on actually producing completed products. The latter is a big temptation for code monkeys, because you start thinking that you can avoid any rework and refactoring if you just get the design 'perfected' in Elaboration. Both are huge mistakes. All you end up doing is stretching out the phase, which actually increases your overall project risk. You've got to stay laser focused on eliminating (or quantifying) your biggest project risks by driving through to actual functioning prototype code. Many stakeholders will readily agree with high-level use case descriptions, only to have a strong negative reaction when they're actually seeing the product prototype. And you're always going to do code rework in Construction. It's much more important to get aligned that you're building the right system (business case, use cases) and that you've got a solid high-level design for that system (sequence diagrams, analysis objects, large architectural blocks, mechanisms).
Elaboration is about running through the minefield, stepping on as many mines as possible, so you know where most of them are before you commit the bulk of your development budget in Construction. Your prototype doesn't need to be pretty, full-featured or bug-free, but it absolutely, positively must address your biggest technical and business risks.
And having written that, I need to seriously consider how I'm going to address the marketing risk, because the prototype only addresses the partnership risk. :| Good thing I wrote this all out. I'll put some target dates on these goals in a subsequent post, after I do a little more analysis.
Elaboration Goal: To implement a JavaScript/CSS prototype for iPad demos and YouTube videos.
E1: Layout and Spinwheel
- Produce HTML and CSS sheet layout.
- Create a working spinwheel with radial x-y functionality.
- Manipulating the spinwheel according to use case changes text boxes.
E2: Character Templates and Objects
- Create object containers for Character (PC + NPC).
- Modify E1 prototype for single character, spinwheel selects Effect + Target.
- Establish EBTs getters, setters and aggregators.
E3: Basic Effects Resolution and Simple Battle
- Implement the following:
- Random Success
- Append Static Effect
- Post-round Static Effect check (defeat check)
- Available Effect
- 2 EBTs: Attack, Health
- NPCs get 1 Available Effect (no equip), direct assigned EBTs.
- Any successful Available Effect causes -1 Health
- PCs get 4 effects to showcase selection
- At end of round, victory check is made with Health - Static Effects
===== YouTube Video #1 =====
Monday, October 24, 2011
Anthracite Elaboration Phase (Start)
At this point, I'm going to call the Anthracite Inception Phase complete. Basically the biggest risks were unknown market size and lack of content partnerships. I've decided that Anthracite will be a labor of love and a vehicle for updating my mobile technical skills, so market size isn't very relevant anymore.
I got a great critique of my content partnership strategy (which had some surprisingly large holes), and I've identified some very inexpensive sources of art to get the platform started. Part of the business case feedback was that artists and content partners get dozens of royalty-only offers from grand dreamers. In order to set myself apart, I need to be able to show them something beyond concept documents.
The feature list has undergone some refinement. The biggest new feature is user-created adventures. I'll be publishing the XML specification for dialog, cutscenes and battles. Gamemaster capability is something that's missing from existing mobile RPG platforms. Customers will be able to use the images, equipment and effects from any purchased product. I need to do some more careful consideration about an adventure builder tool, because that adds serious scope to the project. The initial feature release for custom adventures might be for Notepad Warriors only.
I find it promising that Michael Ham (mindtakerr @ Fear the Boot) is doing an app with branching stories. Several writers have already expressed interest. It will benefit Anthracite if the story-tree skill base gets built up among Booters.
The Elaboration Phase goal is to produce a working JavaScript/CSS prototype for iPad demos and YouTube videos. The use case realizations should be valid for JavaScript, Java and Objective-C. Also, I need to develop at least a basic level of marketing capability: Twitter, landing site, podcast contacts, keyword searches.
I got a great critique of my content partnership strategy (which had some surprisingly large holes), and I've identified some very inexpensive sources of art to get the platform started. Part of the business case feedback was that artists and content partners get dozens of royalty-only offers from grand dreamers. In order to set myself apart, I need to be able to show them something beyond concept documents.
The feature list has undergone some refinement. The biggest new feature is user-created adventures. I'll be publishing the XML specification for dialog, cutscenes and battles. Gamemaster capability is something that's missing from existing mobile RPG platforms. Customers will be able to use the images, equipment and effects from any purchased product. I need to do some more careful consideration about an adventure builder tool, because that adds serious scope to the project. The initial feature release for custom adventures might be for Notepad Warriors only.
I find it promising that Michael Ham (mindtakerr @ Fear the Boot) is doing an app with branching stories. Several writers have already expressed interest. It will benefit Anthracite if the story-tree skill base gets built up among Booters.
The Elaboration Phase goal is to produce a working JavaScript/CSS prototype for iPad demos and YouTube videos. The use case realizations should be valid for JavaScript, Java and Objective-C. Also, I need to develop at least a basic level of marketing capability: Twitter, landing site, podcast contacts, keyword searches.
Tuesday, October 11, 2011
Technical issues in vRPGs.
There are several technical aspects that frustrate me when playing video game RPGs. I'll separate them into three categories: poor quality, needless limitations and poor usability engineering.
Poor quality.
I'm a software and ASIC engineer. Believe me, I know that bugs happen. They're almost unavoidable in some philosophical sense. But when you release an enterprise level product--and App Store games are precisely that--your customers are correct to assume a certain level of quality. I'm seeing fewer bugs and crashes over time, which says a lot about the power of the Xcode development suite and the stability of various platforms like Unity. But it's still frustrating to see a good game concept get ruined by glaring bugs.
Module and feature testing are probably the most boring process in engineering. The code base is largely done, and now you're just trying to break it in various ways. There is a huge temptation to see this step as a big inconvenience, and just release the product as-is. This is a huge mistake. Any app with bugs is going to get beaten down in the App Store ratings. In fact, because users who delete the product tend to rate it first, your first batch of feedback might be overwhelmingly negative. Take the time to do it right! Testing iterations will take up to 50% of your entire development budget, but you should be testing all the time. I am a huge believer in smoke tests prior to check-ins (I can't tell you how much I hate broken builds), and I admire Test Before Code as a design technique. Even if you only write the test descriptions prior to designing the module, it helps to keep you focused on scenarios other than Sunny Day (a.k.a. Nothing Goes Wrong). Negative testing with bad inputs is a great way to locate code that isn't handling exceptions well. And face it, sooner or later you're going to throw an object on the trash heap before its time, and send something a bad pointer. It's way better to see "Failure: ActiveEffect "Hammer Smash" undefined in target "Thor", than to have your app crash and burn. Even if you release bugs, at least your users will be able to provide meaningful field failure data, especially on infrequently occurring bugs that are a pain to reproduce in the lab.
Needless limitations & poor usability engineering.
A lot of needless limitations come from clunky game ports, but not all. Why do I only get two save slots in some games? Why do I need to push menu buttons twice to confirm? Why is my inventory only eight items? Why are there arrow keys to scroll up and down on my touchscreen? Why are the text fields in this game positively microscopic? Why is the selection area so tiny and sensitive? Why is there no Cancel button?
Why, oh why, OH WHY is there a bolt-on directional pad in your menu driven game?!?
Look, if you're going to the expense of porting and marketing a mobile video game, please take advantage of each system's control scheme and toolkits. The iOS SDK provides a ton of iPhone optimized controls. I get that some toolkits are cross-platform, but even so, you can properly architect a separation in your Model View Controller to accept different input types on different platforms. There is no reason to make Nintendo DS gamers endure a mismatched control scheme because you released on Android first.
TL;DR: If you're going to release an app, please test it as if hundreds of people will try it and immediately uncover all the bugs. And design the UI, menus and persistence mechanisms to match the target platform. Don't create pointless limitations.
Poor quality.
I'm a software and ASIC engineer. Believe me, I know that bugs happen. They're almost unavoidable in some philosophical sense. But when you release an enterprise level product--and App Store games are precisely that--your customers are correct to assume a certain level of quality. I'm seeing fewer bugs and crashes over time, which says a lot about the power of the Xcode development suite and the stability of various platforms like Unity. But it's still frustrating to see a good game concept get ruined by glaring bugs.
Module and feature testing are probably the most boring process in engineering. The code base is largely done, and now you're just trying to break it in various ways. There is a huge temptation to see this step as a big inconvenience, and just release the product as-is. This is a huge mistake. Any app with bugs is going to get beaten down in the App Store ratings. In fact, because users who delete the product tend to rate it first, your first batch of feedback might be overwhelmingly negative. Take the time to do it right! Testing iterations will take up to 50% of your entire development budget, but you should be testing all the time. I am a huge believer in smoke tests prior to check-ins (I can't tell you how much I hate broken builds), and I admire Test Before Code as a design technique. Even if you only write the test descriptions prior to designing the module, it helps to keep you focused on scenarios other than Sunny Day (a.k.a. Nothing Goes Wrong). Negative testing with bad inputs is a great way to locate code that isn't handling exceptions well. And face it, sooner or later you're going to throw an object on the trash heap before its time, and send something a bad pointer. It's way better to see "Failure: ActiveEffect "Hammer Smash" undefined in target "Thor", than to have your app crash and burn. Even if you release bugs, at least your users will be able to provide meaningful field failure data, especially on infrequently occurring bugs that are a pain to reproduce in the lab.
Needless limitations & poor usability engineering.
A lot of needless limitations come from clunky game ports, but not all. Why do I only get two save slots in some games? Why do I need to push menu buttons twice to confirm? Why is my inventory only eight items? Why are there arrow keys to scroll up and down on my touchscreen? Why are the text fields in this game positively microscopic? Why is the selection area so tiny and sensitive? Why is there no Cancel button?
Why, oh why, OH WHY is there a bolt-on directional pad in your menu driven game?!?
Look, if you're going to the expense of porting and marketing a mobile video game, please take advantage of each system's control scheme and toolkits. The iOS SDK provides a ton of iPhone optimized controls. I get that some toolkits are cross-platform, but even so, you can properly architect a separation in your Model View Controller to accept different input types on different platforms. There is no reason to make Nintendo DS gamers endure a mismatched control scheme because you released on Android first.
TL;DR: If you're going to release an app, please test it as if hundreds of people will try it and immediately uncover all the bugs. And design the UI, menus and persistence mechanisms to match the target platform. Don't create pointless limitations.
Sunday, October 9, 2011
Why design a new vRPG?
I've been sketching out the design of a mobile video game. The concept keeps evolving, but I wanted to outline the basics. The purpose of my game design posts is twofold: to keep me accountable to some sort of schedule (or at least, to keep making steady progress), and to get gamer feedback on my concept.
I've been running a customized RUP lifecycle, and I'm starting to push through several use case realizations. For non-techs, that means I've got an idea for what the game software does, and now I'm beginning to architect a system that answers how it will perform its function. Since this is my first game design post, I thought I'd summarize why the software does what it does. Let me put it this way...
I keep playing Dragon Warrior over and over again.
Dragon Warrior was an 8-bit NES game released in 1986, when I was 10. It borrowed heavily from Dungeons & Dragons, the most famous tabletop roleplaying game ever produced. At the time, Dragon Warrior was a mind-blowing experience. You roamed a world between towns, fighting monsters, learning magic, buying items, leveling up and going on quests. Along with Final Fantasy I and the Legend of Zelda, it truly defined an entirely new category of video games that stood apart from arcade games like Mario Brothers and Donkey Kong.
Twenty-five years later, roleplaying games haven't changed much. Games remain very formulaic--gather 50 Wolf Pelts and 20 Iron Pebbles, bring them to the Smith, and he will give you a Wolf Belt +3. Despite a map implying freedom to explore, most games rely on grinding to occupy 99% of the player's time. Enough gold allows you to buy better equipment, and enough XP makes you more powerful, allowing you to defeat increasingly difficult bad guys. The story is a rigid linear progression through plot points, occasionally punctuated with huge boss battles. Stories have become so predictable that Game Informer published this handy RPG flowchart. And the only way to enjoy each game is exactly the way the developer coded it--no experimentation, no exploration, no customization.
Certainly there are games that break this mold, but they are few and far between, especially on handheld devices like iPads and Android phones.
Here is the RPG that I really want to play:
All story, all the time.
No grinding, no hovering, no gold farming, no quests to "kill 50 Purple Slimes in the Purple Cave", no waiting for rare item drops. Every battle I fight is relevant to the main story arc. Nothing is ever filler.
Meaningful story choices.
No more rigid and linear Main Quest, and then completely superflouous Side Quests. That isn't flexibility. I want multiple choices to navigate the story, and for those choices to have different consequences and different challenges. I'm fine if different choices result in accomplishing the same larger story goal, but I do not want those choices to be the same. Or worse, I do not want to be presented with one "good" choice and 1+ obviously sub-optimal choices.
Real character development, not just items and levels as a proxy for development.
When faced with major choices, the characters in novels will change. Those altered beliefs and traits will affect who they are within the story. The emotional and narrative aspects of characters are a lot more interesting than what's in their backpack. Also, it strikes me as somewhat ludicrous that all characters ascend to a god-like state of power, where they can deal 1000x more damage than at the story's beginning, and can generally do ridiculous things like destroy tanks with a single sword hit.
Challenging battles.
Fighting 200 brief, one-sided battles is not the same as fighting 5 balanced battles against skilled opponents. This goes quintuple in games where you can simply buy more points via healing potions. Fighting real battles is a satisfying gaming experience. My enemies should be smart and durable. I should be required to think to defeat them. If battles are so predictable that there's a single technique for a guaranteed win, your game design has completely failed at challenge. Multiplying that by 200 battles for every quest simply changes the game into an endurance match against repetitive boredom.
Permission to experiment.
Dear Mr. Developer: I paid you my dollar. If I decide that my character build sucks, I should have the right to change it, as much as I want, whenever I want. If I want to trade my Rusty Dagger for an IceFire Axe +87, you have no right to stop me. Maybe I don't care if your carefully balanced battles will take 10 seconds to defeat. If I think it's fun to destroy an entire Lizardman raiding party in a single blast of freezing incineration, that's my choice. I bought your game to have fun. I define fun, not you. I'm not going to tell you what to do with my dollar, so you don't get to tell me what to do with your game. From this point forward, if I think it's fun to give myself different equipment, or different abilities, or simply restore all my health in the middle of a battle because I'm pissed that I'm losing, I'm going to do it. If I decide that the consequences of this particular decision stink, I'm going to rewind the adventure to my last conversation and choose a different path. If I want to see what a Skreg Assassin can do with Venomous Spineblades, or decide I'd rather play a Master Invoker wielding a Mithril Runehammer, kindly stay the hell out of my way. Oh, and here's another hint. Making it impossible to explore all the options in a single playthrough does not automatically give your game replay value. It just forces me to play a game that's 90% the same to experience a new 10%. And if your items and rewards are random, I might never get the things that I wanted the most, and that totally sucks. You get to dictate the rules, the story, the art... everything in this game. Well, as a player, I deserve some extra control over how I experience your game. Maybe I won't choose to experience your creation exactly the way you intended, but ya know what? Get over yourself. I'm not a Neanderthal art-hater, and you ain't Da Vinci.
Permission to CREATE.
Dear Mr. Developer: Hi, it's me again. I had fun playing your game. It was like a Choose Your Own Adventure book crossed with all sorts of tough RPG battles. I liked the part where my Thief could sneak around and sabotage the elven fortress instead of forcing a frontal assault. But here's the thing--I'm tired of waiting for your updates. I mean, I'm only moderately invested in your story as it stands. The main character is kind of a downer, and I'd really like to strangle the uppity chick in the chainmail bikini. To be completely honest, I'd much rather make up my own characters and adventures using your game, and then share them with my friends. It gets back to that whole "paid you my dollar" thing. I should be able to write whatever stories I want, shouldn't I? I mean, maybe we want to play the Lizardmen for a change. You obviously aren't going to write that adventure, but that's a lousy reason to stop me from doing it. To which I might add, that's a lousy reason to stop me from doing it with my game. That I purchased from you. So it's mine. If you provide new content later, I'll consider buying it, but let's be crystal clear--if I buy it, I get to use it however I want.
This concludes my philosophical reasons for building a new game. In my next blog post, I'll talk about technical and structural problems that drive me nuts in games. And then finally, I'll describe the game that I actually intend to build.
I've been running a customized RUP lifecycle, and I'm starting to push through several use case realizations. For non-techs, that means I've got an idea for what the game software does, and now I'm beginning to architect a system that answers how it will perform its function. Since this is my first game design post, I thought I'd summarize why the software does what it does. Let me put it this way...
I keep playing Dragon Warrior over and over again.
Dragon Warrior was an 8-bit NES game released in 1986, when I was 10. It borrowed heavily from Dungeons & Dragons, the most famous tabletop roleplaying game ever produced. At the time, Dragon Warrior was a mind-blowing experience. You roamed a world between towns, fighting monsters, learning magic, buying items, leveling up and going on quests. Along with Final Fantasy I and the Legend of Zelda, it truly defined an entirely new category of video games that stood apart from arcade games like Mario Brothers and Donkey Kong.
Twenty-five years later, roleplaying games haven't changed much. Games remain very formulaic--gather 50 Wolf Pelts and 20 Iron Pebbles, bring them to the Smith, and he will give you a Wolf Belt +3. Despite a map implying freedom to explore, most games rely on grinding to occupy 99% of the player's time. Enough gold allows you to buy better equipment, and enough XP makes you more powerful, allowing you to defeat increasingly difficult bad guys. The story is a rigid linear progression through plot points, occasionally punctuated with huge boss battles. Stories have become so predictable that Game Informer published this handy RPG flowchart. And the only way to enjoy each game is exactly the way the developer coded it--no experimentation, no exploration, no customization.
Certainly there are games that break this mold, but they are few and far between, especially on handheld devices like iPads and Android phones.
Here is the RPG that I really want to play:
All story, all the time.
No grinding, no hovering, no gold farming, no quests to "kill 50 Purple Slimes in the Purple Cave", no waiting for rare item drops. Every battle I fight is relevant to the main story arc. Nothing is ever filler.
Meaningful story choices.
No more rigid and linear Main Quest, and then completely superflouous Side Quests. That isn't flexibility. I want multiple choices to navigate the story, and for those choices to have different consequences and different challenges. I'm fine if different choices result in accomplishing the same larger story goal, but I do not want those choices to be the same. Or worse, I do not want to be presented with one "good" choice and 1+ obviously sub-optimal choices.
Real character development, not just items and levels as a proxy for development.
When faced with major choices, the characters in novels will change. Those altered beliefs and traits will affect who they are within the story. The emotional and narrative aspects of characters are a lot more interesting than what's in their backpack. Also, it strikes me as somewhat ludicrous that all characters ascend to a god-like state of power, where they can deal 1000x more damage than at the story's beginning, and can generally do ridiculous things like destroy tanks with a single sword hit.
Challenging battles.
Fighting 200 brief, one-sided battles is not the same as fighting 5 balanced battles against skilled opponents. This goes quintuple in games where you can simply buy more points via healing potions. Fighting real battles is a satisfying gaming experience. My enemies should be smart and durable. I should be required to think to defeat them. If battles are so predictable that there's a single technique for a guaranteed win, your game design has completely failed at challenge. Multiplying that by 200 battles for every quest simply changes the game into an endurance match against repetitive boredom.
Permission to experiment.
Dear Mr. Developer: I paid you my dollar. If I decide that my character build sucks, I should have the right to change it, as much as I want, whenever I want. If I want to trade my Rusty Dagger for an IceFire Axe +87, you have no right to stop me. Maybe I don't care if your carefully balanced battles will take 10 seconds to defeat. If I think it's fun to destroy an entire Lizardman raiding party in a single blast of freezing incineration, that's my choice. I bought your game to have fun. I define fun, not you. I'm not going to tell you what to do with my dollar, so you don't get to tell me what to do with your game. From this point forward, if I think it's fun to give myself different equipment, or different abilities, or simply restore all my health in the middle of a battle because I'm pissed that I'm losing, I'm going to do it. If I decide that the consequences of this particular decision stink, I'm going to rewind the adventure to my last conversation and choose a different path. If I want to see what a Skreg Assassin can do with Venomous Spineblades, or decide I'd rather play a Master Invoker wielding a Mithril Runehammer, kindly stay the hell out of my way. Oh, and here's another hint. Making it impossible to explore all the options in a single playthrough does not automatically give your game replay value. It just forces me to play a game that's 90% the same to experience a new 10%. And if your items and rewards are random, I might never get the things that I wanted the most, and that totally sucks. You get to dictate the rules, the story, the art... everything in this game. Well, as a player, I deserve some extra control over how I experience your game. Maybe I won't choose to experience your creation exactly the way you intended, but ya know what? Get over yourself. I'm not a Neanderthal art-hater, and you ain't Da Vinci.
Permission to CREATE.
Dear Mr. Developer: Hi, it's me again. I had fun playing your game. It was like a Choose Your Own Adventure book crossed with all sorts of tough RPG battles. I liked the part where my Thief could sneak around and sabotage the elven fortress instead of forcing a frontal assault. But here's the thing--I'm tired of waiting for your updates. I mean, I'm only moderately invested in your story as it stands. The main character is kind of a downer, and I'd really like to strangle the uppity chick in the chainmail bikini. To be completely honest, I'd much rather make up my own characters and adventures using your game, and then share them with my friends. It gets back to that whole "paid you my dollar" thing. I should be able to write whatever stories I want, shouldn't I? I mean, maybe we want to play the Lizardmen for a change. You obviously aren't going to write that adventure, but that's a lousy reason to stop me from doing it. To which I might add, that's a lousy reason to stop me from doing it with my game. That I purchased from you. So it's mine. If you provide new content later, I'll consider buying it, but let's be crystal clear--if I buy it, I get to use it however I want.
This concludes my philosophical reasons for building a new game. In my next blog post, I'll talk about technical and structural problems that drive me nuts in games. And then finally, I'll describe the game that I actually intend to build.
Subscribe to:
Posts (Atom)