The Text Messaging System - Fail Fast

Writing this post feels a little like walking into your boss's office, ready to explain why your metrics this month weren't as high as expected. In my last dev post I talked about a texting system I was just finishing up, with the next step being to convert existing events over to it, and then move on to bigger and better things. In the intervening week I have successfully scrapped and redesigned the whole system, resulting in something that is less impressive at first glance, but much more game-design friendly. I may not have gotten any useful code out of my first attempt, but at least I can get this dev post about what went wrong, why it went wrong, and why it's important to fail fast and fail often!

First, let's cover what I had circa last week. The text messaging system was suppose to mirror the natural way a phone works - you open it up, check new messages, and respond to ones you want. Internally each "message" you received was actually a trigger for a jump to a Ren'py label, meaning I could present dialogue, choices, and images exactly as normal. Future versions were (and still are) going to add a much more phone-like UI, but the functionality was what I was focusing on. There was some extra detail for tracking who's number you knew, your chat history with them, and other things like that.

That all sounds fine, so why scrap it? The problem comes when I started to convert existing events to actually use this new system. I found that events fell solidly into three categories:
1) The event required no feedback - Your girlfriend sends you some nudes, Jennifer texts you and wishes you a good day, that sort of thing. These would fit into the system without any issues, but were also the least interesting because they had no interaction.
2) The event is the lead in for a larger in-person event - An employee summons you to the lab to check something, Someone texts you to let you know they're coming over, ect. This causes problems because you might not check your messages right away. Each event would have to decide what happens if you, for example, wait until the next day to check a text telling you about a business opportunity, or if you receive a text from a girl who you are now standing right in front of. That was a lot of added complexity and work for the to accidently miss interesting content.
3) The event has you initiating contact with the girl. These aren't events that happen to you, they are events that you can trigger yourself. These didn't mesh at all with the system, and require a proactive way to send texts rather than just receive/respond to them.

I thought about it for a little bit and decided most of that should just be scrapped. Class 1 and 2 events were better handled just like they are now, but with the addition of a phone specific UI. Class 3 events would require the ability to trigger actions, just like you can while talking to a girl. This was much easier to add to a system that treated your phone as a message log rather than a place events might be triggered from.

Flash forward to tonight and the new system is in place. Class 1 and 2 events now grab focus, just like normal, but with the addition of specially stylized text and conversation history specific to your interactions with that girl. Eventually (perhaps as soon as this prototyping week) this history log will be used with a new say screen to display a proper phone messaging log, with old messages trailing up and off screen. Class 3 interactions will be handled by a new "text her" option you have with any girl who's phone number you know. For now that will mimic a small talk discussion, but I will be expanding it soon.

Losing a week of work isn't the best for my moral, but it's a good reminder of the saying "You shouldn't hold onto a mistake just because you spent a long time making it." The initial design I had meshed poorly with existing events and the flow of the game in general, and trying to morph existing events to work with it would have taken way more time than it would have justified. On the other hand, seeing how it didn't work let me lay out my current design and address all of those problems. 

This goose chase ate up a bunch of time I was planning to use for new internet based content, so that will end up being a lot lighter in v0.37.0 than I had planned. The update will still include a big chunk of new content for Jennifer's office storyline. I hope this post gives you some insight into the design of LR2 and let's you learn from my mistakes!