So, after a very long break from writing any games, I’ve decided to try getting back into it again. As I took a look at my two old games (the only ones I’ve ever written), I realized my problem may be in not creating a proper foundation.
When one writes an essay, they might first start with some brainstorming, followed by a web, a rough draft, some changed drafts, then a final draft. Or I recently learned that in coding, there is flow-charting, followed by coding, then testing and fixing, or something like that. Is there some sort of analogous process to writing a game in Inform 7? Like maybe: start with a map, add objects, create a decision tree, etc. Or even for the “coding” process itself? For example, I remember I would start with the creation of rooms first, followed by their descriptions, then look for nouns within those descriptions with which the player would interact, etc.
I’ve tried looking it up online, but there is such a wealth of results, I’m not even sure where to start. Thanks in advance to anyone who can help me, or even just point me in the right direction!
As for myself, I know that no game is ever perfect. So I create a skeleton of the game that is complete or and has a trivial version of each ‘puzzle’. (For instance, just having you grab the treasure instead of unlocking it). So I have a complete game at all times, it just sucks at first.
Then I add in more and more, continuing to have a completely playable game. Then I test it and fix what’s wrong, and have other people test it and fix that. Then I change all the standard responses and write a walkthrough.
I don’t think there’s one correct procedure. This is a bit like asking a group of parents what is the best way to raise a child. You’ll get lots of contradictory answers, anecdotal evidence, and strong emotions. It can be interesting, even illuminating, but in the end you’ll just have to forge your own path.
That being said, I can’t resist sharing the Metaphor of the Rickety Bridge (from a book about translating poetry, among other things):
– Douglas Hofstadter, “Le Ton beau de Marot”, p367.
I second the article recommendations, as well as the notion that there might not be the one true way of doing things.
The approach of “writing the through-line first” strikes me as sensible:
“create a simple outline design of the game and implement it so that you have something you can play (even if very quickly) from a beginning to the end, and which contains the most critical turning points of the plot.”
(quoted from Emily’s article)
I think that this method can help to avoid getting bogged down in the implementation details of the first few rooms, which I am prone to do. I might spend ages on implementing scenery, thinking up synonyms, making sure the player can look in every nook and cranny; and then I’d end up feeling overwhelmed. And in the worst case, I might have to throw away a lot of work when it turned out later that the story should better develop in a different direction.
In contrast, if you already have a working outline version of the game, the motivation will probably be higher to finish the “boring” details. And you won’t have to throw a lot of work away, because now you already know what’s needed and ideally flesh out just that.
You can use the method in combination with Inform’s TEST command by incrementally adding tests as soon as you add some content, and combining the tests into a master “TEST ME”, so that you always have a version which is verifiably working and playable from start to finish.
Additional tips:
If you already know the locations which your game needs, you could map them out with Trizbort, which allows you to export the rooms to I7 code, as far as I know.
These are my personal suggestions which may not work for everyone, and with all caveats that nobody’s process is the same:
start small
think about it for a year
don’t “wing” a game
If you’ve ever written any game, you’re familiar with “scope-creep” where you keep having ideas and not saying no to any of them. Don’t plan an epic plot (or more specifically, your plot can be epic; the implementation needn’t necessarily be.) Cut content that isn’t necessary, that you don’t feel you have a handle on how to execute, or is not fun for the player. You may want to simulate macroeconomics with a trade and barter system, regionally-based imports and exports with tarrifs and fifteen different cultural currencies, but you can save yourself a lot of time by narrating “the stock market crashed and now everyone is broke…” Starting small with a relatively simple premise–look over science fair exhibits and then judge them–your ideas will fill in the plot and balloon it to a reasonable length. It’s easier to polish a dime than a ballroom floor. Let scope-creep happen in the planning stage so you can quash it down or develop it reasonably with a clear head.
The last two kind of go together: If you have a finale in mind, everything else can organically aim toward it. And less of the middle will be filler since you have “magnetic north” of your ending to orient to.
I’m not saying you have to write all the prose before you start coding - by all means make a prototype and experiments to work things out. You should know logistically and plot-wise where it starts, goes, and ends, and starting small will facilitate that. If you can make the entire game work with placeholder text, you have a solid framework to write upon and you’ll waste less time. Writing the prose is usually the easy part.
I’m horrible with making outlines. I will sometimes scribble names and notes and beats down, and then never look at them again. Most of it’s done in my head. If you’re good at making notes, you can maybe skip “think about it for a year”, but generally a good meal needs time to cook. Give your brain some time to dream up connections and situations you didn’t initially come up with. A quick and imaginative snack on-the-fly can be awesome, but an undercooked meal is not.