Difference between revisions of "Feature Requests"

From BattleMaster Wiki
Jump to navigation Jump to search
m (And this, folks, is why you always do show preview and don't get cocky and think you did it right the first time. :P)
Line 10: Line 10:
 
In order to make sure that your feature request has the greatest chance of being accepted, you should have the following things:
 
In order to make sure that your feature request has the greatest chance of being accepted, you should have the following things:
  
; A Name: This is something that people Pproduction by the Peasants" should be OK. In addition, when writing the subject for the discussion list add "Feature Request:" as a prefix. This should mean your subject would be "Feature Request: Widget Production by Peasants".
+
; A Name: This is something that people can use when discussing it. It should be short but descriptive. "That widget thing" probably isn't good, but "Widget production by the peasants" should be OK. In addition, when writing the subject for the discussion list add "Feature Request:" as a prefix. This should mean your subject would be "Feature Request: Widget Production by Peasants".
 
; Three-line Summary: Think of this as the executive summary. It should be enough detail to give a casual reader the basic gist of the idea, but shouldn't contain any specific mechanics.
 
; Three-line Summary: Think of this as the executive summary. It should be enough detail to give a casual reader the basic gist of the idea, but shouldn't contain any specific mechanics.
; Three Paragraphs of Detail: This is where you get the chance to describe your detail in all of its glory. You need to provide all the specific information about how your feature request works. These paragraphs are '''how'' the request works. You should fit your whole idea into three paragraphs (roughly fifteen lines of an e-mail). If you can't fit it all into that much space, then chances are that your idea is ''just too big''. Try splitting it into multiple, smaller feature requests. Try to focus on the core of the idea, and not fall victim to feature creep. You do ''not'' need every little piece of detail. Don't get bogged down by listing exact percentage chances of an event happening, or a complete list of options. The dev team is very good at coming up with a lot of twists and turns to build on an existing idea. The key is to get their attention, and convince then that '''this''' idea is worth the effort.
+
; Three Paragraphs of Detail: This is where you get the chance to describe your detail in all of its glory. You need to provide all the specific information about how your feature request works. These paragraphs are '''how''' the request works. You should fit your whole idea into three paragraphs (roughly fifteen lines of an e-mail). If you can't fit it all into that much space, then chances are that your idea is ''just too big''. Try splitting it into multiple, smaller feature requests. Try to focus on the core of the idea, and not fall victim to feature creep. You do ''not'' need every little piece of detail. Don't get bogged down by listing exact percentage chances of an event happening, or a complete list of options. The dev team is very good at coming up with a lot of twists and turns to build on an existing idea. The key is to get their attention, and convince then that ''this'' idea is worth the effort.
 
; One Paragraph of Why: What benefits(gameplay, atmosphere, or game balance etc.) does it provide? How do the benefits of this feature justify the work needed to implement it? Be sure to be honest about the feature and list both positive and negative changes to the game that would result(pros and cons). This paragraph(approximately five lines) should be the '''why''' of the feature request.
 
; One Paragraph of Why: What benefits(gameplay, atmosphere, or game balance etc.) does it provide? How do the benefits of this feature justify the work needed to implement it? Be sure to be honest about the feature and list both positive and negative changes to the game that would result(pros and cons). This paragraph(approximately five lines) should be the '''why''' of the feature request.
  

Revision as of 22:10, 4 August 2009

This is a page for serious feature requests. By "serious" we mean that the originator bothers enough about it to describe in detail what exactly he wants and why.

Submitting a Feature Request

Feature requests will be entered on the community portal by the Community Manager(CM). The CM will not create the feature requests (unless it's his own personal project), nor will he develop them beyond basic organization. All feature requests should be submitted to the Discussion List by the originator for discussion among the BattleMaster community. Once enough discussion has occurred, and the request deemed to be a good addition to the game, the Community Manager can finalize the discussion, wrap it up, and put it here on the wiki. (Note: The CM has a direct line to the developers, so he should have a good idea for the technical feasibility of any proposed request.)

Remember: The first step of requesting a new feature is to check the existing list of feature requests. Make sure that your feature isn't already on the list of accepted, in-process, or rejected feature requests. Also, check the list of frequently rejected features. These are things that simply will not get added, regardless of how many times you ask.

Requirements

In order to make sure that your feature request has the greatest chance of being accepted, you should have the following things:

A Name
This is something that people can use when discussing it. It should be short but descriptive. "That widget thing" probably isn't good, but "Widget production by the peasants" should be OK. In addition, when writing the subject for the discussion list add "Feature Request:" as a prefix. This should mean your subject would be "Feature Request: Widget Production by Peasants".
Three-line Summary
Think of this as the executive summary. It should be enough detail to give a casual reader the basic gist of the idea, but shouldn't contain any specific mechanics.
Three Paragraphs of Detail
This is where you get the chance to describe your detail in all of its glory. You need to provide all the specific information about how your feature request works. These paragraphs are how the request works. You should fit your whole idea into three paragraphs (roughly fifteen lines of an e-mail). If you can't fit it all into that much space, then chances are that your idea is just too big. Try splitting it into multiple, smaller feature requests. Try to focus on the core of the idea, and not fall victim to feature creep. You do not need every little piece of detail. Don't get bogged down by listing exact percentage chances of an event happening, or a complete list of options. The dev team is very good at coming up with a lot of twists and turns to build on an existing idea. The key is to get their attention, and convince then that this idea is worth the effort.
One Paragraph of Why
What benefits(gameplay, atmosphere, or game balance etc.) does it provide? How do the benefits of this feature justify the work needed to implement it? Be sure to be honest about the feature and list both positive and negative changes to the game that would result(pros and cons). This paragraph(approximately five lines) should be the why of the feature request.

If you can fill out all this information, then you will give the discussion list community a good bit of material to work with. You also run much less of a risk of the idea getting derailed by people trying to jam way too much (quite possibly unrelated) stuff into any individual feature. ("What do you mean we need to add ship-to-ship combat to this feature?! I only wanted to have my guild title shown in the message signature to guild members!")

Once you send a feature request to the Discussion List, don't forget to check back and make sure that your idea is not being misunderstood, or that some people have found some serious holes in it. Someone may even have some good ways to alter the idea to make it better. When you're done, roll all the various desired changed together, and post a recap of the idea. If it's acceptable to the dev team, the CM will post it here on the wiki, and a bugtracker feature request can be created.

This is the only approved way to get feature suggestions added onto the bug tracker. This will prevent the bug tracker from filling up with excessive, unacceptable feature requests, or used as a discussion forum for debating the merits of any particular request.

Current Feature Requests

Feature Requests that have been fleshed out and are waiting for approval or rejection.

Approved Feature Requests

Feature Requests Tom has approved.

Frequently Rejected

These are wishes that people have asked for many times, and Tom has decreed that they will never be granted. So don't ask about them, here, on the bugtracker, or on the discussion list. Reasons are provided by the development team as to why they are rejected.

  • Recruiting away from capital
    • This would make it much easier to fight long-distance wars, which messes with game balance in ways Tom does not want. The capital needs to be an important place, and this keeps it so.
  • Reply to all on messages
    • This would increase spam in the realm, which is a definite no-no.
  • Transfers of gold (not bonds); transfers of money not in cities; anything related to guilds/religions that turns them into banking houses
    • These would seriously upset the balance of the game, allowing long-distance wars and a number of other things Tom does not want. There's a reason for the difference between gold and bonds.
  • Changing of region types (including building or destroying cities)
    • This would utterly destroy game balance, as well as being infeasible with the way the maps work (they are static images, created painstakingly ahead of time)
  • Archery skill or archery contest in tournaments
    • Archery was not something nobles did. It does not fit the milieu
  • Forums
    • Forums are an abomination and should be cleansed from the earth
  • Anything to cater to the specific problems of MSIE users
  • Prison break option for infiltrators
    • They already have slightly better chances than others
  • Priests-as-healers
    • This is a Dungeons-and-Dragons-based concept that doesn't fit the milieu. If you want to play Dungeons and Dragons, go ahead...but this is BattleMaster
  • Newbie-only island
    • This would shut newbies away from some of the most interesting aspects of the game - the players - and would, in the end, be counterproductive. Integrating them into the general population right off is the best way for them to learn the game.
  • Non-Human races
    • They do not fit with the milieu. Yes, there is magic, there are undead, and there are monsters, but it's still (more or less) an Earth analogue, which means that everyone is human. Except for Sirion on the East Island, where you can find Elves (special dispensation due to long-standing, pre-existing RP when the human-only rule was created), but that's another story. They keep to themselves, and don't flaunt or otherwise push it on other realms.
  • Confirmation dialogs
    • Unless the action is a very drastic one, you don't need your hand held. Confirmation dialogs have also been shown in several studies to be ineffective. You just get used to them and hit the "yes, I mean it" button automatically.
  • Plagues, famines, diseases, etc.
    • Random events having significant effects on characters and realms don't make the game fun.
  • Any kind of whole-island "reset"