Ich halte mich im großen und ganzen an die altbewährte Top-Down Methode. Ich überlege mir zuerst den groben Aufbau, und arbeite mich dann immer tiefer ins Detail bis ich bei den einzelnen Funktionen (Call Events) mit den dazugehörigen Parametern angelangt bin.
Ich halte nichts von gigantisch langen Events, durch die ich mich nach einiger Zeit nicht mehr durchschauen kann.
Andere versuchen Events zu sparen wo es nur geht, und basteln lieber riesige Events die alles mögliche auf einmal erledigen, aber davon halte ich nichts.
Vor allem sind viele kleine abgegrenzte Module leichter wiederzuverwenden.

Kommentare verwende ich viele. Praktisch jedes Common Event hat zuerst ne kurze Beschreibung was es tut, und welche Parameter es benötigt, und wo das Ergebnis gespeichert wird. Zwischendurch verwende ich dann noch leere Kommentare als Leerzeilen, um einzelne Blöcke optisch von einander zu trennen.

Ich arbeite sehr viel mit der Funktion Variablen über andere Variablen anzusprechen, da ich mir da meistens ellenlange Forks ersparen kann. Auf der anderen Seite ist das manchmal etwas undurchsichtiger, weshalb ich auch viele Inline Kommentare setze.

SetTerrainID und SetEventID (welches ja eigentlich GETxxxID heissen müsste, verwende ich nur dann wenn ich es brauche. Da man die Events leider nur fix angeben kann beim aufrufen, bringt es mir leider selten was, mir die EventID abzuspeichern, und mit Terrain IDs arbeite ich auch nicht oft, da es bis jetzt eigentlich kaum notwendig war(ist aber sicher praktisch für ein Event, welches berechnen soll ob jetzt ein Encounter stattfinden soll oder nicht).