Quote Originally Posted by Xyril View Post
I don't speak for Trekkin, but I don't believe that is what he is suggesting. There's a lot of daylight between writing while coding, and going in completely blind. Having an idea of what engine you'll use and taking a bit of time to learn generally about its structure and limitations can be tremendously helpful in providing rough guidelines as to how to avoid writing in a way that would create substantial implementation issues either, but would still allow you to concentrate on scripting without adding code yourself.
Xyril's got it.

Step zero for anything like this is to get the proper tools together. That means, at bare minimum, a text editor that can output files their software can read; if they tell you not to use a word processor, there's a good reason why not, and my guess is it's a formatting issue that you really don't want to deal with for tens of thousands of words. Personally I'd use emacs or vim for something like this, but nano or gedit might be more familiar to you. You say you have multiple devices. Fine; you can learn either git or, if you really must, svn. You will want proper version control anyway and you might as well use one that works across devices.

Then, whether or not you want to actually insert your tags now, learn their syntax, paying special attention to their escape characters and how they handle things like newlines and tabs and all the other little formatting details that can absolutely destroy the engine's ability to put your story together for the judges to look at. How the engine works "in action" is completely immaterial to how it parses your work. It's good to know the ideal number of choices. It's vitally important to know what character the engine will think starts a tag, because that could well trigger a segfault if you casually use something like parentheses or quotation marks and forget to properly escape them. It only takes one to turn 100,000 words of work into a score of 0.

So no, you don't have to learn the commands before you start. You should, however, work in a way that will produce as few headaches as possible for you later. Part of that is the software I mentioned, which you can easily customize to catch any formatting errors you may accidentally commit and easily fix them. The rest is an awareness of what will trip up the engine -- and naturally you can't learn that from looking at working games because they obviously don't include any of those errors. There's all sorts of workarounds to them, but they have their own syntax, all of which is never displayed to the player. This means you cannot read it, let alone emulate it.

Basically, the more you write now, flying completely blind -- and yes, if all you've seen are working games you are flying completely blind right now -- the more your post-writing workload is going to increase exponentially as bugs propagate through the system. Debugging is already going to be a monumental task for you, both due to the sheer size of the work and because of your unfamiliarity with the kind of custom IDE that would make this easier; don't make the mountain higher by digging yourself a hole to start in.