Programming is Hard

Been awhile since I updated. There's a reason for that: My actual job has been keeping me busy. And by busy I mean working the crap out of me. I've been putting in overtime hours for the last few months.

I've kept plugging away at this programming thing, and understanding how DSE works. The original intention was to use this as a precursor for a gamedev blog - so people could get updates on progress. This is difficult to do when the most I can do is poke at the coding for a couple hours at most, and compounded by my working every day of the week.

Still, not an insurmountable task. I've learned quite a lot about many things, a great many deal regarding the DSE (and just how friggin' powerful it can be!).

Speaking to others about my not-so-secret project, I describe myself as less a programmer and more of a hacker. I don't come up with a lot of code myself, mostly I appropriate from others until I get it to do what I want it to. This has mixed amounts of success, but I'm really proud of how far I've come these last few months.

When last I left off, I was dealing with syntax issues, and understanding why the code wasn't recognizing my Day variables. Given tonight's little project, I think this is a nice time to review.

So, anything that occurs during the init line is not set in stone - those are the default values set in when the game launches. Any variables changed during the course of the game should be saved as a state when Ren'Py saves the game - meaning even if Day = 0 on launching the game, it will still be Day 39 when you load your game (rigorous testing concluded this functioned properly).

After much hacking, I've accomplished not merely setting up additional time slots for events to occur, but I've also locked choices during specific days of the week, removed them from the planning menus, and also set aside an option for these things to be overridden should the need arise (say, a holiday for example). The scope of the game is pretty large, perhaps too large to be reasonably accomplished, but I'm not one to let something like that keep me from progressing.

Today's project (or the project I started a few days ago really) involved a very simple thing: How do we make sure that events play out only in a specific location, at a specific time? For reference, the events are structured like so:

    $ event("library", "act == 'library'", event.only(), priority=200)

    $ event("garden", "act == 'garden'", event.only(), priority=200)

    $ event("cemetery", "act == 'cemetery'", event.only(), priority=200)

    $ event("dojo", "act == 'dojo'", event.only(), priority=200)

    $ event("workshop", "act == 'workshop'", event.only(), priority=200)

    $ event("laboratory", "act == 'laboratory'", event.only(), priority=200)

    $ event("office", "act == 'office'", event.only(), priority=200)

These are some of the placeholders I'm using for now, but they illustrate what I'm working with. Let me break down the code for you: The first part of the string is the event that is occurring (so I have for example an event named 'office'). The second part, the 'act', tells us that this event plays out when the current act is the 'office' option from the planning menu. So when you go to the office, the office event plays out. The 'only' descriptor states that this is the only event that should play out, and any other possible options should be pushed aside regardless of whether they are eligible to play out. Lastly, we have the priority, which tells us how important this event is in relation to the others. In this case, all of my events here are set at a priority of 200, which isn't too terribly important since 100 is the recommended default.

So I set up some testing events to play out, to make sure they occurred properly.

    $ event("tzan_intro", "act == 'cemetery'", event.only(), event.once(), priority=190)

    $ event("tzan_ar01", "act == 'cemetery' and period == 'late_eve'", event.only(), event.once(), event.depends('tzan_intro'), priority=200)

Once again, let's  break down what's going here. You can see that the event "tzan_intro" has a higher priority (lower numbers are higher priority) than the normal cemetery event up above. We can also see here that it only plays once. This plays out any time you visit the cemetery, but only the first time.

It worked just fine. The second one though, that took a bit of doing. Because for some reason, it just would. Not. Trigger.

I spent the last few days pounding my head against the wall figuring out why. Was it not tracking the period name? Or was it not referring to the variable correctly? After much running in circles, I realized the error of my ways, and also learned about something very cool I could do.

The problem... was the priority of the second event. Because it is lower on the list than cemetery, which as I noted has an event.only tag, it was being disregarded every time. As soon as it was placed on a lower priority, like with the first event, it played out correctly the next time I visited the cemetery in the late evening.

This revelation however opened my mind to how powerful this events system can be. Because you see, I can have multiple events play out, in order, so long as they are not pushing one another out.

So for example, I can have the normal cemetery event play, where a player arrives at the location and gets a brief description, and then it can load the next event, where they meet a character.

Needless to say, this is a pretty powerful revelation to have, and I really look forward to the day when I can openly share more about what the game is intended to be. But for now, I have to keep playing with code until the framework is solid. And also cobble together some art assets.

But so far, I'm rather proud of the improvements I've made so far, and the amount I've learned about how DSE, and Ren'Py in general, work.