Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
Feature creep, creeping featurism or featuritis is the ongoing expansion or addition of new features in a product, such as in computer software. Extra features go beyond the basic function of the product and so can result in software bloat and over-complication rather than simple design.
In the context of game design, the term would apply to being overly-amibitious with features you want to add, the complexity of certain mechanics, etc.
Pokémon is a relatively simple game, but when it comes to ROM hacks there are no limits to what you can add. My question is, how much is too much? Do you think any hack so far has reached the point of having too many features? Any tips for budding hackers who might fall prey to this pitfall?
When it comes to engine hacks, I also believe in "the more, the merrier". To me, that's what ROM hacking is all about--bending the original engine to your will.
This is kind of a general game design idea, but I think it applies here.
I love the idea of people adding their own features and making the game their own, and I think the biggest wonder of hacking is just that- it turns the Pokemon games into an engine for basically anything you can think up. With all the resources and tools around, the games have basically become a game engine in a similar sense to, say, RPG Maker or...well, that'd probably be the best example.
But I do feel like there is a point where you can actually do too much. A quote I read a while ago is something that chimes in my head whenever I'm conceptually designing a game, and that's, "A game for everyone is a game for no one". This can mean a lot of things, but here I'd use it to say that if you add too much to a game without any idea of how to focus it or make it accessible in its versatility, you end up making a game that's harder for people to get into or, going the other way, you with an idea that's incredibly difficult to develop for.
The latter is something that we all see pretty often in the Beginner's Lounge. The biggest example, of course, is making a hack with every region. The appeal of such a hack is obvious, but they're just nice words. Oftentimes this is an idea that's boasted without any real thought as to how much work that would be. Returning to the former idea, and probably the bigger issue I see with such an idea in my eyes, the creators rarely consider how exactly they would make having every region fun. Sure, it's cool, but it doesn't support and existing Pokemon formula, nor does it meld well with its various systems. As a result, to actually make a game that is compelling and fun that includes every region, you would need to conceptually redesign Pokemon from the ground up to fit that idea. After all, I can guarantee that, even if you were to tweak a few systems to make it so that you could have one consistent party or several parties among regions, no one would finish it because Pokemon wasn't designed for such a venture.
And I'm not saying people can't go crazy with ideas. The brainstorming phase is so fun because you have so much freedom in what you can do. Seriously, go crazy with it. Have fun. Just know that more =/= better. You should try to visualize your hack as a sum of its various parts rather than a package of many different things and consider how said parts influence the sum, otherwise you can create a disjointed experience that will not only be more work for you, but also less enjoyable for the player.
I think feature creep is a problem for hackers in the context of "Well, I want to do all these things, but they're all aside from and would take early dev time away from my main plot," and then they develop the side features at the expense of plot progress, which I categorize as more important. Self-contained side features can be dummied out and added in last, in my opinion. They always seem to come out better as "post-final release DLC" (if you will) because there's infinite time (no pressure to rush/skimp to move onto the next Gym or plot point) and with all of the hacker's attention and worry focused on those side features, I feel.
I would ideally skip over areas with big, complicated features that I don't yet know how to do (or know exactly how to do but would be a severe time consumption to implement) in favor of making progress on the plot. If you were making a hack that was basically HeartGold and SoulSilver (in this example, HGSS are not canon games; this is your original idea), you might skip planned extras like the Bug-Catching Contest, the Pokethlon, the Johto Safari Zone, the Battle Frontier, etc. to get the main game plot and main areas developed and finished first. Then, after the game is playable and "complete", you would head back and flesh out side features.
I think that, in our current environment, big "features" and side areas are given more thought and dev time than the actual plot and areas themselves (y'know, the two things that player's will spend 80% of their time with), and it shows. You could put a GBC emulator in your game to play old minigames in the Game Corner (make it happen god-tier hackers), but none of that will matter to me if your maps are horrendous, the story is all over the place, and the game is otherwise unplayable. Battle engine updates, minigames, complicated cutscenes, self-contained side areas, etc. can all be skipped until the groundwork of the plot and essential areas have been made, in my opinion. My motto is that if it's not main plot essential, it's dummied-out (space is made for it) until I'm ready to go back to it. I think that this is also a symptom of our "betas are major releases" or "betas as DLC chapters" mentality. You don't need to shove literally everything that will ever be in the areas that are within the scope of your beta into those areas right away. Leave things out, for Arceus' sake. Leave a ton of things out if they're not vital to main plot progress. It'll save you so much time to not have to redo your awful early stuff or to reimplement things the way you wanted originally and not the way you had to hobble it together for your arbitrary beta deadline.
You can make a hack with the most full and engaging content in history, but if you focus too much on all the side-things that you want to pack into your hack, your progress will be so slow that it will probably be a demoralizing grind. One-man hack teams don't have the luxury of having the "feature guy" and the "game engine girl" and the "plot person" to split up the work between. Big chunks, in my opinion, are better than snail's pace baby steps.
Battle engine updates, minigames, complicated cutscenes, self-contained side areas, etc. can all be skipped until the groundwork of the plot and essential areas have been made, in my opinion. My motto is that if it's not main plot essential, it's dummied-out (space is made for it) until I'm ready to go back to it.
Many valid points you've got here. Then again, I have to disagree on the fact that hackers should work on the time-consuming, somewhat "non-important" features in general after everything else is done.
If you think about "normal" hacking process of editing a pokemon game without creating anything "new", the following is what you practically do:
1) Map a new area (should be fun up to some point)
2) Put some events there and make the events function like normal people you can talk to, or as trainers. No challenge in doing this either unless you have just begun hacking and are not comfortable with editing events.
3) Edit wild pokemon in the area (another thing you can do with ease)
4) Test whether the area you made works (okay, this should be fun! In case the hacker doesn't get any kind of satisfaction from creating something playable and new, (s)he shouldn't be doing pokemon hacking in the first place.)
But if you think about making a large game with dozens of areas like this: "how long can you stand doing this?". I'd say that one of main reasons why people quit working on their hacks is that progress in making it is so boring. And repeating that 4-step process (above) over and over again will become boring at some point.
To keep yourself entertained and interested in continuing your hack, you continuosly have to plan out: "What kind of features to introduce in this new area I'm making (, or possibly in a town after that) so that I'm actually excited to get to work on them?". Sure, it's sometimes time-consuming to complete the new features, but those are the things that keeps the hacker eager to continue working on the hack, and besides, with the features, the hack will also stand out from the rest.
I have personally had breaks (even pretty long ones) from DE too, but during the breaks, every now and then I notice myself thinking that "It would be so cool getting to work on "that specific" feature introduced when you get to a certain point later in the game.". I "can't" get to work on this feature yet since from the beginning, I have been creating areas one after another to the point that I shouldn't have to return into editing them (unless the player isn't supposed to revisit that area to do some specific quest or such in case I would create the functionality for that quest then). So that's one motivator for me to keep going forward. And when you've got plenty of these motivators, there will always be something exciting to look forward to. :)
Many valid points you've got here. Then again, I have to disagree on the fact that hackers should work on the time-consuming, somewhat "non-important" features in general after everything else is done.
If you think about "normal" hacking process of editing a pokemon game without creating anything "new", the following is what you practically do:
1) Map a new area (should be fun up to some point)
2) Put some events there and make the events function like normal people you can talk to, or as trainers. No challenge in doing this either unless you have just begun hacking and are not comfortable with editing events.
3) Edit wild pokemon in the area (another thing you can do with ease)
4) Test whether the area you made works (okay, this should be fun! In case the hacker doesn't get any kind of satisfaction from creating something playable and new, (s)he shouldn't be doing pokemon hacking in the first place.)
But if you think about making a large game with dozens of areas like this: "how long can you stand doing this?". I'd say that one of main reasons why people quit working on their hacks is that progress in making it is so boring. And repeating that 4-step process (above) over and over again will become boring at some point.
To keep yourself entertained and interested in continuing your hack, you continuosly have to plan out: "What kind of features to introduce in this new area I'm making (, or possibly in a town after that) so that I'm actually excited to get to work on them?". Sure, it's sometimes time-consuming to complete the new features, but those are the things that keeps the hacker eager to continue working on the hack, and besides, with the features, the hack will also stand out from the rest.
I have personally had breaks (even pretty long ones) from DE too, but during the breaks, every now and then I notice myself thinking that "It would be so cool getting to work on "that specific" feature introduced when you get to a certain point later in the game.". I "can't" get to work on this feature yet since from the beginning, I have been creating areas one after another to the point that I shouldn't have to return into editing them (unless the player isn't supposed to revisit that area to do some specific quest or such in case I would create the functionality for that quest then). So that's one motivator for me to keep going forward. And when you've got plenty of these motivators, there will always be something exciting to look forward to. :)
I got twelve notifications from this! Was quite excited to open up PC and see what you had to say!
I think the exception to my rule (which you're right to point out, as it's a big one) is when you come to a point where you go, "Gee, I have no concept for this next area/my ideas are not fleshed out well enough for this next area/I'm just not feeeeling this yet," which becomes a natural roadblock in the 4-step process that you mentioned and frees the hacker up to go back and work on features (or improve existing plot "infrastructure" with skipped flavor text that may reference things that were not thought up when the area was first conceived) while the brainstorming is done and the ideas solidify . If you don't leave some things to go back to, then this time is mostly wasted when it comes to "real" tangible progress. Much of the time, for me anyway, this time is filled by playtesting what I have and improving existing plot flow and dialogue, while finding numerous oversights to fix. Playing what I've done puts me in the mindset of the player and gives me a perspective on what the player might find interesting to see next, or what the player might find homogeneous or boring and gives me a notable boost in ideas. "Hey," I go, "The player hasn't seen a place with this geological feature yet. Is this feasible with my region setup?" Or, "I want to do a route with this! And maybe manmade features and a bunch of elevation changes and places where the player can walk under a bunch of higher-leveled terrain to keep things fresh and interesting!" And some of that awareness is gained from playtesting and being a player.
Or, you could just skip that area entirely and give yourself a warp past it for your playtesting purposes. I have a huge city that I've skipped because, while it is important to the plot, holds a late Gym, and is a place that the player will revisit a few times, I feel confident enough in my story planning that I know that I can get the rest of the game down while keeping the plot elements in that city a little more unfocused at this stage, as they are sort of a self-contained mini-pocket of its own overall arc. I am just not yet ready to come up with tiles and map that large of an area well enough that I won't have to scrap large portions of it and start again. I've got a ton of plans and rough sketches of the city (so it's not like I'm avoiding some gaping hole in my game, everything but the finer details are pretty solidly planned out), but I'm not satisfied enough with visual and layout parts to finalize the city with the multiple day effort it will take to map it (and put in all of its surrounding and supporting infrastructure) into the ROM. Skipping areas that you know that you aren't going to get right the first or second time until you're ready for them is just being time efficient. ...But this only works if you're confident enough with your region's setup and your plot, which leads into another thing:
These natural roadblocks are oftentimes a result of inadequate planning, where the hacker didn't flesh out their region enough in the brainstorming stages and then goes, "Now what?" That's a whole 'nother can of worms (which I'm almost certain that you and I will agree on) about how important and how deep the planning stage needs to be before anything huge is done in the ROM. I'd argue that the early planning stages are the most important thing that a hacker will spend his or her time on, as flaws in this stage are stalls and overall quality drops in later stages. The worst planning at best creates a noticeable hodgepodge effect on the final product, while at the worst makes the plot and areas seem completely disjointed and separate from each other. Bad planning creates fly-over content that the player never returns to and doesn't remember, a plot that is happening independently and regardless of everything else around it that seems disconnected from itself (or worse, lightly "sprinkled on top" of everything else), and areas that are orphaned by the plot, completely uninspired, and/or so wildly different from adjacent areas that they break the suspension of disbelief. And it's super easy to not realize that you haven't planned enough, which is another reason why I think saving big feature implementations for later is important. It gives the hacker the breathing room to flesh things out more and see where things are going to need help because of the "always moving the plot forward" approach to development that leaves these issues looming always just barely beyond the horizon. A meticulous, methodical, slow-paced approach of designing out and putting in literally everything that an area will need at once gives the hacker ample opportunity to paint themselves into a corner and force themselves to redo work later. Losing the forest for the trees isn't good when you still need to navigate to the other end of the it. Only when you've charted the forest and you won't get lost or turned around can you afford to focus on the trees.
EDIT: I just want to point out one point you made that perfectly illustrates my problem with the "betas are DLC chapters" format that we seem to have going (emphasis added):
Sure, it's sometimes time-consuming to complete the new features, but those are the things that keeps the hacker eager to continue working on the hack, and besides, with the features, the hack will also stand out from the rest.
Well, yeah, unique features definitely will make one hack stand out from the crowd but an early beta doesn't have to include those features for the final product to have them. The community is seeing each hack as a book. They get the prologue (normally an alpha or early early beta demo), and then get the main chapters added on in beta patches. They're like content patches in MMOs: the players don't get the entirety of the story for making an account, new stuff is added on top of the old. But therein lies the issue. The hackers seem to treat their prologue and early chapters as if once they release them, the ink has dried and it'll be too much to go back and change some words or add pages or cut paragraphs that aren't working. Hacks aren't like the big MMOs, who have finished content that they're patching on top of. We have a mentality that if the beta isn't bursting with "stuff", and mostly complete up until that chapter's end, then it's a bad release.
The reality is, each hack isn't a book, and shouldn't be expected to be. New patches shouldn't be viewed as add-on episodic continuations of the last beta. Each hack is more a collection of loose pages that can be messed around with and whose words can be changed, rearranged, and removed whenever. But hackers are hesitant to develop this way, because they risk the perception that they release sloppy, "unfinished betas." Well, duh. Of course the beta's unfinished. It's a beta. What it encompasses will be finished in the final release. Deal with it. Oh, your saves are broken? Sorry for making my hack better, I'll limit my creativity and the quality of the hack to appease you.
The beta is not the product. You are not presenting your work to a board of directors so that you can get the green light for more money. You don't need to put impressive and time-consuming window dressing on betas just for the sake of having them in early, especially at the expense of more pressing content. You have infinite time to get this done. Until you save the ROM file for the very last time, your fans are playtesters who you don't pay, who don't pay you, and should not be specifically catered to in the "how I functionally make progress" department. You really have no obligation to them at all. The final is the product; that is the ultimate goal that is being worked toward. If a beta is lacking the typical "finish" that our community expects, then oh well. That is of course assuming that the hack will be good in the first place, which most will not be. You don't need a beta to tell that.
If you're hacking to make a great game, then this should be on the forefront of your mind when you release stuff. You don't need to use betas to keep up the hype train or the interest or whatever, because you're not selling anything. Use betas for what they are used for, which is obtaining feedback on whatever you have so far. If you're hacking for the fans and community prestige, you're an idiot and need to reevaluate your priorities (this is a small Pokemon forum, come on). You'll likely get a higher return on investment doing almost anything else if you crave recognition.
(I'm using "you" generally, I'm not personally directing this at you, miksy91. Keep up the great work on DE! Can't wait to play it!)
You have very good points here, and the end of it "If you're hacking for the fans and community prestige, you're an idiot and need to reevaluate your priorities" also made me thinking whether I hack for the fans or not. I guess I hack for both my own fun, and the fans and thus I want to work on new features whenever I get the chance. And it's true that it would be wiser not to implement big features when "you have the chance" if you haven't planned them out throughly, or cannot implement them yet. As for myself, I have implemented quite a lot of stuff that I've had to modify afterwards and thus, use time inefficiently. However, I mostly haven't had the need to redo "simple stuff" because they in general don't serve for any real purpose in terms of development of the storyline. Hence inefficient time usage comes with having to re-write possibly somewhat complicated scripts, or maybe other stuff that I either didn't have an idea how to implement properly when I made them. These kind of events/functionalities (if talking about straight coding) were kind of important to implement somehow at the time because they worked as learning process in creating something more complicated in the future. If I personally view the events in DE, it's easy to notice that the farther you get in the game, the more complicated events and functionalities (in terms of coding them) are introduced. And of course the earlier parts of the game have gone through some changes later on as well - mostly because of me having the knowledge to improve the stuff that I created when I didn't have as much understanding as now.
Generally, it's possible to go with the plan you talk about here, but if you're not really talented with what you're doing, you will probably end up implementing most of the stuff in a "too simple" way and even then, wanting to re-write lots of stuff when you understand how you can implement them better.
This kind of learning viewpoint actually came into my mind while I was thinking, what to reply you back. I hadn't really thought about it before (or if I had, that was probably a long time ago).
P.S
These natural roadblocks are oftentimes a result of inadequate planning, where the hacker didn't flesh out their region enough in the brainstorming stages and then goes, "Now what?" That's a whole 'nother can of worms (which I'm almost certain that you and I will agree on) about how important and how deep the planning stage needs to be before anything huge is done in the ROM. I'd argue that the early planning stages are the most important thing that a hacker will spend his or her time on, as flaws in this stage are stalls and overall quality drops in later stages.
And I did just that. I hadn't thought clearly, what the hack will be like when I started. But I'm not sure I could have planned out the story well at that time either as I didn't know, how to implement several storyline-based events I know how to implement now. I simply had ideas of different kinds of events that might take place in the game and some general ideas behind the development of the story. But that's that.
And this pretty much sums out how much is required for making a good hack (or a game). You would need to have lots of programming background already when you start planning out the story. If you don't, you don't have the knowledge behind, what you will be able to implement in the future, and thus, what kind of turning points the story may have.
If you're storyline is centered on collecting 8 gym badges, battling an evil team and becoming the champion, not much planning is required in the beginning (although it could surely make the hack turn out better in the end!). But if you're going for a "non-Pokemonish" story, you will end up having problems with it. Mine has become a bit cliche too although it may not feel like it in current release yet.
Also, sorry if it feels like I was lazy replying to your points since you really had a lot to say. And it was interesting reading all that :)
But already reading your message and writing this post here took me over an hour, literally. The thing why it took so long is that it's not enough to figure out what to say, but you also need to put it in words in a language foreign to you.
