Much as I decry the trend in games of giving the player objective markers and leading them around by the nose, they can’t be expected to remember everything — especially in a complex RPG with many moving parts. Since I am intending to build a complex RPG with many moving parts, I need a place to store information about your current objectives.
Enter the Journal.
Updated My Journal
The journal is ripped straight out of Warcraft III and, honestly, I’m not ashamed. To me it’s always been the gold standard of journals — concise, but also with room for context.
Consider the long trail of text entries in Baldur’s Gate, where events are interleaved in chronological order — it might be very atmospheric and flavoursome, but it’s hell to find anything again when you’re scrolling backwards. Consider the opposite in something like Fallout: New Vegas where there is purely a list of objectives and a quest title, but no real reminder of why you’re doing the thing.
Whereas in the Warcraft III style, each quest includes both a concise list of objectives and a paragraph of context. The context paragraph gives you the personality of the entries in the Baldur’s Gate journal without losing them in the endless wall of text, but the list of objectives still tells you clearly what you need to do to progress. (Also because it’s organised by quest, quests can have punny titles.)
The only real deviation I’ve made is that I’ve dispensed with the distinction between Main and Optional quests, with all objectives being packed into a single list. This is something I’m still on the fence about — ultimately, I don’t think I’ll have enough quests per chapter to make it worth splitting them up this way, and I think it’s potentially interesting to let the player make up their own mind about what’s optional and what’s critical (notwithstanding my completist tendencies meaning that nothing is truly optional).
My own This Wreckage also had a horrendous imbalance between main and side quests, because side quests are naturally smaller and more quickly completed, so it would be silly to have a big Main Quests list with one or two entries and an overflowing Side Quests list with four times as many.
Of course, the true big deal with quests is not the relatively simple user interface for displaying them, oh no. It’s the trigger system that powers them.
I’ve always said that my desire is to build a load of systems and tools and get to the point where I don’t have to do any more programming, and can focus entirely on content. A major part of that puzzle is the ability to have things happen in the game without hand-coding all of them in C#.
Traditionally, this is where one would implement Lua or another intermediate scripting system that can operate at run-time. Not me, though. I do enough programming on the engine side as it is, and remember — I’m a man who fetishises Warcraft III‘s GUI trigger system and touched the underlying JASS code as little as possible.
Can you see where this is going yet?
So, a Trigger for me is a Unity MonoBehaviour, which has an accompanying set of TriggerConditions (which determine whether it’s allowed to execute) and TriggerActions (which perform the required work when it does execute). Unity’s GameObjects are nice containers for things so it’s a natural fit, the only awkwardness being that it means Triggers have a physical position and rotation that they don’t need (but this has long been a shortcoming of Unity for me — there’s no non-space to hold non-physical but scene-specific game state while still taking advantage of all the useful engine structures).
Since everything is a component on a GameObject, then parameters for each trigger action can be drag ‘n’ drop fields that directly reference things in the scene. There’s no confusing indirection or magic strings that can get snarled up, just straight linkages the same as how every other gameplay element is hooked up. Even better, this all takes advantage of the Unity editor’s standard serialisation and inspector interface systems. Maybe one day I’ll build a proper trigger editor window to go with my conversation editor, but that is by no means essential.
The main advantage over WC3‘s triggers is that I deeply understand the structure of my own game and can make systems dedicated to run it. Triggers that fire only once can be set up with a single checkbox, as can triggers that only respond to the player hero. Quest changes can be collapsed into a single action that updates their status and displays the relevant feedback. Cinematic Mode can activate the letterbox, deactivate the fog of war and take in a trigger for skipping all in one place.
Yes, this does mean I need to manually implement every kind of action I’ll ever need, but even if I did implement Lua I’d still have had to tie in my own API so it’s six and half a dozen really. Once I’ve made the basic set of actions, I can close Visual Studio and sit completely in the editor. I’ll turn Unity in World Editor yet!
Rao Dao Zao 