When someone’s already been given a mountain of advice in spite of them still being in the earliest stages of a process, I feel they probably don’t need more advice. But due to my ego, here is more advice.
Once I’ve done enough planning on paper to my satisfaction, I like to start in Inform by making a handful of the game’s rooms. Just the rooms themselves, not any of the contents or any people; the room names, their connections, my first attempt at writing their descriptions.
The reason I like to do this is it builds something I can walk around in. I’ve hardly done any work yet but I can already move around in a not-bad semblance of my ultimate envisioned world. This gets me excited when maybe twenty minutes earlier I had absolutely no game.
With some code in the bag and some real rooms in place, and the sense that the ball’s rolling, from there I play it by ear. This is just my variation on the idea suggested earlier in this topic that you keep turning your attention to whatever interests you… at least in the early stages. Later on I’d say something different. But we’re just talking about getting going here. For me, it’s a physical process in the imagined world. I build something in the gameworld, it reminds me of another object I’ve got planned that I’d now like to see next to the first one, or some object it interacts with, so I build that object next. Eventually I have to write some code for the puzzle that connects these objects. At that point, I may have a room with one functional mechanic, and again I get that cheapo thrill of seeing the next thing work.
Much further down the line, the excitement of the project becomes self-sustaining. At that point I tend to stop hopping around and start to concentrate on building entire types of things - for instance, all the people, or all the props, etc.
This, this, this. Planning helps a great deal, but I find it does wonders for morale and momentum to actually create something - anything, really - something tangible as a first step toward the rest of the project.
Personally, I prefer to work both on a “low level” (adding and refining rooms, objects, code, etc.) and “high level” (more abstract design work pertaining to the project as a whole and as a series of bigger parts) at once. The two threads add to each other: low-level code work informs the high-level design of what can and can’t be done easily; and high-level design work influences what elements go into the low-level code and how they interact.
The way I structure my I7 code is to divide it up into a hierarchy that makes sense within my brain (more general statements at the top, rooms & the objects within them towards the bottom) and label the sections with CAPITAL LETTERS for large divisions and Regular Letters for subdivisions. If I just need a simple “this is a thing in a room, this is its description,” that can all go in one paragraph; when a thing gets complicated enough its code might be split up into several paragraphs so I can more easily see where I’ve put a certain bit of it.
So my source headers tend to break down like
RULES AND JUNK
WHEN PLAY BEGINS
TO SAY DEFINITIONS
KINDS OF THING
NEW ACTIONS
Spanking the pizza
Making Julian cry
Muffination
THE PLAYER
NPCS
Robotson the robot sidekick
Sheila Francesco O'Montague
THAT BIG ROOM EVERYBODY LIKES WITH THE WINDOWS
Scenery
The windows
The ottoman
The secret drawer in the ottoman
The nutcracker hidden in the secret drawer in the ottoman
THAT OTHER ROOM PEOPLE DON'T LIKE AS MUCH
Scenery
The really terrible statue
Mycofungus
TABLES
Then inevitably I get lazy and start doing things like putting the code for new actions right next to the nouns associated with them, and then I can’t find anything and wind up with two chunks of code that conflict with each other, which breaks Soupbot’s unwinnable-state prevention features, and Ryan Veeder can’t beat the game. So don’t do that. Actually it is probably for the best if you don’t be like me in general. But that is how I organize my code.