News 2020-05-20

Where have you been Roman, we haven’t heard from you for a few days! What’s with the silence? Well, I’ve been battling depression with SCIENCE! or something. Maybe it was technology. I don’t know.

Anyway. Let’s talk candidly about where we’re at and the challenges of making a game.

To make a game like Doctor Amana requires three very different jobs with three very different skill sets.

1. Writer – You have to build a story and tie it together and make it worth reading. I do this in Scrivener because it has excellent tools for tracking notes, characters, and assembling different parts of your story in different sequences to test the “flow” of the read.

2. Artwork – You have make pretty visuals to enhance the story and bring to life all the characters and scenarios you worked so hard to develop in the writing process. I use Daz at the moment because the models are ready made, it’s quick to implement, and it’s become a bit of a standard.

3. Coding – You have to turn all that into a playable product. In a game like mine, this means coding the art, the story, and tracking hundreds of variables to mark the difference choices a player makes and ensures that the story unfolds in predefined sequence.

Each one of these can be a full time task and as a lone developer trying to tackle all of these alone for a game as ambitious as Doctor Amana has been daunting. When all this started I was just a writer, and slowly I’ve been spread out to handle all three of these tasks simultaneously.

One of my biggest reoccurring challenges is evolving script. I write in Scrivener, I export to Renpy, As I make the art, sometimes the script changes or the dialogue morphs a bit while because the ideas continue to flow. Then before I know it, my Scrivener files and my actual game are out of sync. The next time I sit to write, I have to jump back and forth between renpy and scrivener to make sure things work and make sense.

But in renpy, my script has now been poisoned with lines and lines of code that interrupt the flow of the read (which is why I don’t write exclusively in renpy). This turns the task of writing the next scene into a challenge as I jump back and forth between three or and four files to make sure things make sense and flow together. Often those files don’t agree with each other and I write hoping it’ll make sense on the back end.

I have over the last year sought help with art and coding from other parties with mixed success, but never to the degree of personal preference I have for the project. It’s hard working with artists remotely because the communication is so limited and you can’t give real time feedback during development, making the process of outsourcing almost as time consuming and laborious as doing it yourself.

I finally reached a point where I think I have to throw in the towel and say, “I’m going to be doing this alone for a long, long time.” And at first, this realization was a bit dejecting. But I’m not a defeatist and with a bourbon in my hand, I sat down and focused on the real problem .

“How can a single developer create a quality game with a complex narrative by himself, and maintain a regular update schedule that doesn’t span months at a time?”

At this point I want to add that professionally, my background is in business analytics and data science. I’ve made a better than average living for years selling process improvements and last week I decided I needed to start hardcore applying that experience to this project.

I realized the solution to my problem is the same solution I’ve sold to many companies over the years: Computer Automation.

But where to implement it? Obviously I can’t automate the writing because it requires too much creative input. The same goes for the artwork. But then I thought about the coding.

Coding the Doctor Amana game requires many, many lines of code. For example, when there is a choice to make in the game, you typically have an image, the choice, a few lines of following dialogue, another image, and some code that records your choice.

So at times, 1 Choice + 1 Line of Dialogue + 2 Images = 18 Lines of Image Definitions + 5 Lines of Script

One choice plus a line of dialogue and two images can often take up to 20 lines of code all said and done.

Could I trim this by making a simpler game? Of course I could. I could trim it down to four lines easy, but in doing so would lose some of that dynamism that your choices have and reduce the game to a more simple, linear narrative. But I don’t want to do that. I like the complexity introduced in my choice system and I couldn’t dream of giving it up.

So if I wanted to reduce my workload, I needed to apply some automation to my coding. And if I went about it smart and did it right, I could cut out a complete third of my workload. I’ve automated tasks for years, but I’ve never automated coding and I didn’t know how much of a challenge that would be.

But as I looked over the code I began to see all the places where method calls arise and in the way my definitions are set up and the patterns were very clear. I already had patterns I used to reference my images and name my files. Much of the information I’d need to automate the coding was already embedded in the short hand I used for file names.

Well it turns out that all you need to automate the coding process is a strong understanding of string manipulation, which I already had. Once I realized that,  all that was left was to develop a bit of a shorthand for more variable things like choices that could be isolated in the script and turned into meaningful code. Seemed simple enough.

Alright, well, I had an idea for a potential solution, all that was left was to sit down and build it, and then pray it worked. Guess what, it fucking did.

In only 150 lines of code I now have a renpy generator that will take my raw .txt output from Scrivener and convert it to a usable renpy file that I can plug straight into the game.

It takes the Windows 1252 encoding from Scrivener, converts it to UTF8, fixes indentations, adds the python code for the menu choices, formats the menu choices and adds the python code for the scene variables.

But what saves the most time is that it takes a simple notation, and generates a sequence of image names following my existing convention and places them in the code. It then takes these references and in a separate file writes all my layeredimage code, complete with paths and variants for different game modes that it generates using the file name of the renpy script file.

Image definition files can consist of 300+ lines of code that I have type manually or copy and paste and make changes to the individual lines. And each scene needs one of these files. Manually typing, and copy and pasting can and have sometimes lead to errors in the code that I later have to go back and fix.

This file is now automatically generated using a file name, and a list of images. And the list of images it needs is also generated automatically. It’s a massive time saver not just in time spent coding, but in time spent debugging images.

Basically, it turns the first image (a single txt file), into the second and third images (1 Renpy Script File and 1 Renpy Image Definitions File) in the blink of an eye. The only one I had to touch was the .txt file. The rest was created automatically on export.

What’s it all mean?

It means that 95% of the coding job is handled automatically. I don’t have to do it anymore! And when I make changes to certain implementations, I just tweak my code generator and in seconds the entire script is updated with the new implementation.

No more jumping between files. As I make art, if the script changes, I can just change it in Scrivener, export, convert and in a fraction of a second it’s done. My core script is now always up to date and editing of the story can be done exclusively in Scrivener. The problem with files being out of sync between Scrivener and the game is eliminated and the story is no longer a fragmented mess.

Best of all, when I sit to work on the game, my time is split between writing an art. No more coding. The way I like it!

No doubt there will be some tweaking and adjustment required to fine tune the operation. But already I’m seeing time saved in the encoding of images into the game. And not having to sit and do the tedious code work is a real morale booster.

I know this post got a little windy, but I wanted to paint a complete picture for you. Not just so that you’d understand my silence these last couple of weeks, but so that you’d understand just what a victory this is for the project. Now, onwards!

I’ll have some more art and news coming soon. I figure that’s probably about enough for one day.

Salute mates! And thank you for your support!