Discussing RoE Design Constraints

Hey big (and little) ones! For today's post, I wanted to go over some of RoE's design constraints and design scope, and how quickly some decisions can get out of hand.

The #1 design constraint is Discord, more specifically the 2k character limit for messages. This severely limits the depth of a scene. Yes, technically we can break an output into multiple messages, but then one should also consider that because the game takes place in a Discord environment, a long output message already takes up the entire screen. You'll know what I mean if you've taken a look at the stat channel and seen outputs for players with wordy stat blocks.

The #2 design constraint is the fact that the game is multiplayer and being played by many folks simultaneously. This further reinforces the need to keep outputs to one message as a player should have time to read it before it starts getting bumped up.

#3 is the fact that the scope of work balloons exponentially for every accommodation we make. Do we allow flight? Now I have to write a whole set of alternative scenes. And when would flight become infeasible? The answer for this example, by the way, is no. Wings will add flavour to some scenes, but deciding early on that there is no flight helps to keep the level of work to a sane level and helps build off the macro theme of the game. Remember, the #1 reason many RPG style games fail is the failure to reign in their scope.

#4 is the lack of a gui. RoE is entirely text based and played via commands. There is no "next" button. One of my top design goals for RoE is a smooth user experience; thus, we have made the decision that all outputs, including the exploration module, are based off a single input. When a player puts in the !explore command, the entire scene will play out in one go.

When you put all of this together I'm trying to keep the "first pass" of the exploration module to a reasonable scope as to not overwhelm my developer and I. Alternative scenes can always be added in later!

Keep in mind that there are nine size tiers in the game. Yes, not all events will need nine variants as multiple tiers can be grouped together depending on context, but some events I've already written have had seven. Plus, I'm trying to keep individual scene variants to no more than two sub-variants. This means I have to pick and choose the flavour tags I want to use for each scene. For example, the event I'm working on now will have alternative text for players with a tail, because of all the flavour tags there is an obvious use case for the tail.

I'm very happy that you guys are so excited for the exploration module. But trust me, it's a real balancing act to not let my ideas get out of control. I have to reign myself in to keep the module to a reasonable scope, and then we can go back and add in event variants later!