A couple of weeks ago, I scheduled the release of StoryTime that went out yesterday afternoon. The latest includes a means for authors to publish their story-games, completing the story-creation arch, so to speak.
Getting this done required the usual moments of despair, grind through difficult and tedious bits, and adjustments to scope. The original plan included publishing and a review process so that I can keep an eye on what people are sharing. Ever ambitious.
Within a few days, I realized that publishing on its own was plenty of work for two weeks, so I decided to skip the review process for now. Whatever people publish will be out there instantaneously. I’d be happy if anyone tries it. Blocking my brave early adopters is not a priority. Also, I have ways to turn off specific story-games if I need to, say, if someone violates my reasonable terms of authorship.
Scope always finds a way to expand. This release was no exception. Even after deferring one of the two major features, I found plenty of ways to do more than I originally thought about. For example, I implemented a neat trick for storing code look-ups that I learned from one of the best DBAs I ever met back in the early 2000s.
I could have had a separate table for each type of code: e.g., content ratings, genre, status codes, and so on. Instead, I have just one self-referential table with separate views for each type. That standardizes the data for look-ups (code, display name, sort order) and allows me to have a single method in the API to access any type of code.
In layman’s terms, I did a little extra work now to make things simpler overall and save myself a lot of work later, assuming I continue to work on this project. These trade-offs presume future work. Otherwise, I improved the parts no one else can see for nothing.
By the last days, having a deadline saved me once again. In my growing fatigue and scramble to get things in, I was tempted more than once to fix this or that non-critical problem. I pulled myself back with a gentle reminder of my fast approaching deadline.
Here’s a summary of how I manage on-time releases:
- Plan somewhat ambitiously, expecting to adjust scope once I get into it.
- Counteract the panic that I’ll never finish by focusing on the most important next step.
- Finish that step, while considering which of the least important parts should be deferred.
- Allow myself the chance to pick up a few improvements that are in the path of what I am working on.
- Build things in a way that is backward compatible with what’s running.
- Ideally, releasing is only a matter of a quick database backup and deployment through my environments.
- Keep the release process simple.
- I release to “staging” first to find problems that don’t show up in my development environment.
- Once I have fixed all of the critical problems in staging, I click the button to promote the code to production. Takes about 2 seconds.
- Send a notice to my subscribers. Then sit back, take a deep breath, and bask in the warm feeling of accomplishment.
So there you have it. Alright, that’s enough of how the sausage is made. Go play StoryTime. Write and publish your own story-games. Then you can share your game with your friends. It’s fun. You’ll see.
Fair warning: The user experience needs some serious improvements. Start with a small story, and try not to get too frustrated. Send me feedback about it using the Contact form in the game or on this website.
In other news…
Are you a software developer? You might want to subscribe to the Insider Newsletter. I’ll be creating some training materials next. My course ideas include:
- How to Design an Online Game—from game concept to system design; good for people working on non-gaming apps, too.
- Building an Online Game—everything you need to know to build modern web-based systems.
- StoryTime Walk-through—where I share how StoryTime was designed and written.
If you are interested in any of these or have some other interests, let me know using the Contact form.