Schedule Update

Thanks for bearing with me. I know this has been a dry spell for Interns content, but as I’m trying to weed out a lot of the persistent bugs from the game with this rebuild, I’ve been taking it slow so in the hopes that I can minimize potential errors.

Unfortunately, there’s been a lot of trial and error, and a lot of things that just haven’t worked out. Few things more frustrating to me than spending a lot of time working on something that I end up having to throw out, and it’s happened more than a few times in the last few months. But I’ll get to that a little bit later.

Here’s an overview of where I am right now:

Trying to Have more Class

In the “making things more complicated to make the more simple” category, I’ve been working on doing more with classes.

Specifically, I was finding that I was doing some stupid things to track work events, when they start, when they end, etc. What’s in the game right now is so convoluted and disorganized (some parts are set up during the intro days, others are hidden away during Mallory’s evaluation scenes) that I can’t seem to figure out how it works at all…and I’m the one who wrote it!

At present, to handle work and free time, each day in the game used one of three schedules:

  • Morning shift
  • Evening shift
  • Free day

This has been working for quite a while, but as I’ve been writing more event sequences that give the player special jobs (like the beach party or modeling), this has begun causing problems for me; I’ve had to find ways to break out of these pre-defined schedules to get those events to work.

I think I’m on to a new potential solution, though. I mentioned in a previous post that I’ve broken each day down into a series of “blocks.” Recently, I’ve been working on creating a Python class for these time blocks, having each store variables that let me know what type of event they are (work, free, special assignment, etc.).

So, the general idea will be that the block objects themselves have a record of whether or not they’re a work shift. This would make it possible for the player to get a half-day, or a double-shift, or even work two different jobs on the same day.

To handle those time-block class objects, I’ve also created a “schedule” class. This class holds a list of the 9 time blocks and contains functions for reading, writing, and manipulating the information in those objects.

Things Don’t Go Smoothly

I was fairly proud of myself for figuring out how to make the classes work, but in the process of testing, I ran into the very problem Twi on Discord was complaining about while attempting to build the time-log system: Ren’Py’s “Rollback” feature doesn’t revert the information that the class functions change.

In my tests, I found that trying to roll back through earlier blocks of time would actually cause time to advance, instead (while entirely skipping over whatever content was rolled back).

Thus, the code that I wanted to use as the underlying structure for the whole game…just doesn’t act reliably, and would make a complete mess of things.

I’ve whipped up a quick video demonstration, so you can see what I’m talking about. Each time I scroll backward or forward, the schedule just keeps marching forward.

The game script rolls back, but the schedule’s timer keeps marching forward. Not working as intended.

Keep Moving Forward

It’s irritating and disappointing to lose time on this, but I‘m not without ideas to rectify it. Storing information in a class appears to work well enough if I’m not actually using the class itself to manipulate it, so I believe I can just move those operations to a place where Ren’Py has been more reliable about tracking and reversing changes.

So, hopefully, this is a “two steps forward, one step back” situation. It doesn’t work the way I’ve coded it currently, but it doesn’t mean it won’t work at all.

Fingers crossed!

Bonus Objective

As this build is in a state where I can’t even predict when it’ll be ready, and my “real” life looks like it might be busy in the near future, I feel like I’m going to need to come up with -something- to act as a reward for everyone who’s continued to support me.

I’ll look through what I’ve got in progress so far see what I can come up with.

(Oh, and the post image is just a tease for those who have been following what I’ve been up to on Discord.)

Update: June 20

As I thought, the fix for rollback ended up being a matter of removing the variables that controlled the passage from time from the class, and just using the class for information storage. I moved the time advance code to a basic Ren’Py label (treating it as a scene in the game) and things appear to be working fine.

So, if you were confused by the previous video, here’s a sample showing how the schedule was supposed to handle rollback:

The schedule now properly participates in rollback. Hurray!

Leave a comment

Up ↑