![]() |
![]() |
![]() |
|||||||||||||||||||||||
![]() ![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
|
In the last two parts of this series, we examined the need to be patient, and the need to prepare. Now that we’ve made it to part three, it is time to discuss what happens when we think the project is finished. "But, isn’t there a part missing?" you may ask. "After going through all the previous steps, shouldn’t we learn what to do when actually making the game?" Yes, but what can I teach you? It’s not my game you’re making, right? How to design your game is up to you. No project should follow a set formula. If you want to draw maptiles first, then so be it. If you think walkabouts are the way to go, who am I to try and stop you? There is no lesson in game design because each design is specific to the author. However, one thing that is important to understand is that your game is not finished until it’s worth playing. Hence, we move to: Lesson #5: Tie Up Loose Threads. That’s right. Every project, regardless of medium or style, needs to have its threads tied. But, what does that mean exactly? Well, just like everything else mentioned so far, this lesson is dependent on the author and the project. To tie up loose threads can either mean taking the story up to a significant event, or providing an ending to certain puzzles, or just simply finishing a town or dungeon so that the player can experience the setting the way it was intended. After all, no one wants to fight slimy creatures halfway down the castle hall before the monsters stop and the castle turns into a sea of default grass. Essentially, the game should provide definite ends for the player to adhere to. Is this suggesting that a game should always have an ending? Well, an ending certainly doesn’t hurt, but that’s not really what’s necessary. Bear in mind that just about every project that gets released is merely a demo, and no one expects a final ending when a game is just that. So, the idea is not to be so extreme that it ends like a full version (although that is perfectly acceptable and encouraged), but at least give the player a sense of joy that he or she has taken the game as far as it will go, and that there are no questions that it’s over. The thing that irritates a lot of people is spending several hours walking around a map to discover the hard way that the game was over a long time ago. I mean, who really wants to waste their time? May I see hands please? Yep, that’s what I thought. So, when you know your game is over, write in some signal that tells your players that it’s over too. People like that, and they will like you too. But, what if making an ending isn’t enough? you may question (instead of ask). What if the game requires a certain character to show up before the story can take its shape, and what if that character isn’t due to show up until much later in the game? Can the threads still be tied, or does the author have to hold back his release many more months, just so the game has some kind of satisfying ‘closure?’ Good question, but I think the answer depends on true readiness. What determines the line between patience and impatience? What tests the author’s confidence that the game is still worth playing? If there is any feeling of incompleteness then the game should wait, regardless of what characters it does or doesn’t need. Sometimes hard choices need to be made when getting creative, and those hard choices may require constant date shifting. But, what truly determines completion is up to the goals that are set from the beginning. In other words, if the goal of the demo is to have a clearly written story with a minimum of five interactive heroes, then that game is unfinished until those goals are met. If all it demands is one dungeon with a boss at the end, then that is all it really needs. The main point to remember is that the dungeon must be complete, with a full working battle system, or those five heroes need to be sustained long enough to set up the story, or else the game will not live up to its right kind of potential. What this translates into is a potentially great project that falls apart at the seams. Therefore, the goal of lesson five is to avoid unraveling at all costs, which won’t happen if lesson one is practiced. "Okay, so the game has an ending, and all the threads are tied. Can it be released now?" Sure, but do you really want it to be? Do you really want people stumbling through your bad grammar and missing wallmaps? Bear in mind no one wants to play another Magnus, so are you sure you’re ready to release it? If you think your game is ready now, then go ahead and post it somewhere, but it would be best to practice lesson six first. Lesson #6: Editors Don’t Want to Write Your Story for You. What’s that supposed to mean?" That basically says that your project should be revealed when it’s at its very best. If any given player is tempted to edit or rewrite your game, then you missed the important step of polishing up. Too often, newbies are criticized for writing Kindergarten quality grammar, and making too many blatantly ignorant mistakes. True, people who don’t know the engine are bound to miss a lot of things without even knowing it, but that’s why it’s very important to learn it before you churn it. The biggest downfall of the worst games around is that they miss simple, but painfully obvious things. Problems like vanishing wallmaps, poor continuity, and even improperly linked doors are many of the dreaded symptoms that turn a four-star game into a turkey. Who really wants to release a turkey? So, the simply stated point of lesson six is to make sure that the only flaws that come with a game are the ones that are unnoticeable. If a character is a prince in one scene, but is a 1984 station wagon in the next, and there is nothing in the story to explain this transformation, then the game isn’t ready yet. "So, now that we understand the little points that make us better game designers, what is there left to learn?" Well, there isn’t really anything else to say, but there is a question that should be asked. Lesson #7: Is This Thing Really Meant to Go Public? It may seem like a rhetorical question at this point since the whole series has been devoted to making the game more appropriate for a community release, but think about it anyway. Is this game that you have in your editor really something you want to share with the world? If it is, then why? What is so special about it that everyone must know about it? Is it something you’re proud of because it’s a statement of your versatility? Must the world know about it because it’s unlike anything people have seen before? Is your game destined to make you a legend among gamers everywhere? Or do you just want somebody to tell you what could be better about it? These questions may be awkward to most game designers, but what’s the true drive to making a release a reality? For those who just want to create, then a public release is not even a concern, right? For those who want publicity, then the set release date is the most important date of the year, right? What is it that makes you want to test the line between praise and ridicule? Or, do you have a game that you think people might enjoy for awhile, and then move on to something else the following week? These questions may not seem relevant to the heart of game design, but in truth, asking them may test your will to finish what you started. Essentially, if your goal is to win awards and be the talk of the community, then you’re less likely to finish, and more likely to be greatly disappointed. But, if your goal is just to have fun and explore a new form of statement, then the outcome could be anything. Only you can answer this question, and it’s up to you to decide what to do about your answer. Granted, players love new releases, but we love them more when there’s a true heart devoted to making them. And that brings an unofficial close to the "training ground" parts of the series. The next part will just deal with some tricks I discovered when making my game that I found to be useful. Maybe they’ll help you, or maybe they won’t, but it can’t hurt to give them a try anyway. So, until then... |
||||||||||||||||||||||||
Operation: OHR is owned and maintained by Kevin W. (Aethereal) |