2055
правок
Изменения
Нет описания правки
Во время проработки дизайна, неустанно повторяйте себе: "Делать, не показывать, ни в коем случае не рассказывать".
==#10: Watch Out for Nonstandard Game Modes==
Inform 7 is filled with assumptions that each turn of your game will be more or less like any other: every turn do this, instead of going do that. The more elaborate your game becomes, however, the more likely it is that some turns will not be like every other. During conversation, say, you might want a lot of things to work differently; or during combat. A tense chase sequence or drama-filled interlude might not want to play by the same rules as the rest of the game.
It's easy, of course, to override the default assumptions for your nonstandard turns (Every turn when combat is happening, do this.) But it's not so easy to remember to go the other direction: to overrule your generic rules to not apply when they shouldn't. Whenever you introduce a unique environment, all of your existing "every turn" rules (and instead rules, and before rules, and procedural rules, and so on) will still apply. In a very large project, you may have written some of these conditions months ago and not thought about them since. Here's another case where careful planning early on can save you from obscure, hard-to-find bugs. If you've pinpointed from the beginning any unusual conditions or states, you can work that into all of your rules from day one. (Instead of smelling when the player has an undamaged nose, say "You love the smell of napalm in the morning.")
A huge portion of Blue Lacuna's bugs were related to cases where I didn't think through the ramifications of special scenes or states that were added later in development: conversation, dreams, flashbacks, visits to other worlds, pivotal events, and so on. Sometimes conditions written before I considered these states were changing variables or altering rulebooks in utterly inscrutable ways. Take the time to plan for this stuff early on, and you'll save mounds of debugging time.
Another point with special environments is to make sure you test the edge cases, such as the first and last moves the condition holds true. It's not always clear what order various rules will run in: whether a scene will begin before an "every turn" rule runs, or whether this "last every turn" rule will actually be the last every turn rule. Develop testing commands that can show you exactly what order things are happening in, and make sure sequences are playing out internally the way you expected them to.
==#11: Program Consistently==
Natural language is sloppy, but programming is exact. The more complex your project gets, the more you're programming, and the more your sloppiness will come back to haunt you. Here are a few examples of ways you can be more exact.
Name Space Issues: If you call something a "blue door" in one spot, something else a "door" in another, then in some third spot have a condition like "if the door is open", you and your game won't necessarily be in agreement over which door you mean, which can lead to very subtle and frustrating bugs. Name things verbosely if possible, and use an object's full name whenever you know there are similarly named objects elsewhere in your code.
Scenes: Because scene names often refer to characters or items that are their own objects elsewhere in your code, I've found it helpful to hyphenate scene names. That way Harry, Sally, and When-Harry-Meets-Sally will never conflict with each other. If you're already using dashed-words for something, you could try camelCase, underscored_words, Things Written In All Initial Caps or even THINGS WRITTEN IN ALL CAPS. These conventions will also help remind you at a glance what sort of thing a bit of code is dealing with.
Extensions: When writing extensions, err towards more specific names rather than less specific names. If you're creating a new "window" kind, this might lead to terribly confusing errors for authors opening custom Glulx windows, implementing Windows PCs, or adding locations called The Space Under The Window. Instead, name your kind something like "latchable window" or "decorative window" or "interior/exterior window."
Be Wary of Pronouns: You can say things like "It is open" in Inform 7 code, but take extra care that you and the game agree on what you mean by "it." Whenever you're mentioning more than one object within the same paragraph, be especially wary, and take pains to do an in-game test that verifies your code is functioning correctly.
Use One Syntax: You can say "now x is y" or "change x to y," but it's a lot easier to pick one of those and always use it. Inform 7 often allows a lot of variation in the way commands are phrased, but you'll have to remember less syntax and your code will be more readable if you pick your favorite way of phrasing each command and stick to it.
==#12: Comment Everything==
In a natural language environment, it may seem that comments are redundant. What's the point of writing them when the code is so readable, anyway?
Use comments to record your design philosophies. Explain why you're using a list instead of a table or vice versa, or why you decided to make something a rulebook rather than an activity. If something needs to be a "check" rule instead of a "before" rule, note why in a comment. If you review some piece of code you wrote months ago and think "Why on earth did I do it that way?" then you forgot to comment.
Use comments to record solutions to complex or subtle bugs. If you need to declare something in a certain place or in a certain manner, comment why. If you fixed a bug by using a phrasing other than the one you'd normally use, explain in a comment why you had to phrase it that way. That way you won't accidentally "fix" your code to something that doesn't work again.
Use comments to record concessions to extensions, to explain workarounds to problems, to cross-reference other bits of code that may be far, far away.
Writing IF is always a chore, but you will spend much less time at it if you do a little homework first. Commit to coming up with a full and detailed design before you start fiddling around with code. Develop new systems as extensions to force yourself to think through their design, and allow others to benefit from your work. Get other people involved in the testing and design as early as possible. Plan your code to be debugged and to hold up no matter how complex it gets.
If I'd had all this advice four years ago, I could have finished two or three games since 2005. Just think: we could all be playing Blue Lacuna 2: Electric Blue-ga-lue or Whom the Telling Changed With A Vengeance right now.
OK, now I really do need to be punched in the face.
[[Категория:Для разработчиков игр]]