April 2017 Progress Report: Project Cranberry Jam

It has been several months since I last gave any indication as to where we stand for Project Cranberry Jam. This is unacceptable so here goes.

All of the character and background artwork has been completed, though not all of the assets have been converted just yet. Being a one man operation in a lot of respects slows some of that progress down. (Not to mention the attending hardware/OS failures that initially delayed progress, combined with a rather troublesome bug... ugh.)

In what time I've been able to find, work has been slowly progressing on getting the scenes into the engine so that work in other areas can finally begin. The scenes for the demo itself are about 60% completed at this point - the scenes required for Week 3 are about 30% finished by now. A number of them are fairly short, so that shouldn't be too difficult to deal with, provided I have the time.

UI design still hasn't been touched. Again, one man operation, UI work will come after I get the scenes taken care of. Also, no audio has been completed yet - though work has commenced on some of the music. If the stars align, this is something that can be taken care of within another month or so.

There's still a good amount of editing which needs to be done as well. For now, my focus is on getting the scripts into the engine, so that they can be more easily adjusted - I'll have to go through them all again anyways when it comes time to put in the audio.

So as it stands, we're at about 50% completion for the demo, I feel. Getting the scenes all put in is the biggest part of the game - it's the core of the experience, really. Once those are all finished, the demo can be considered about 75% complete - the rest is getting in the audio, fixing any other weird bugs that might pop up, and finishing the UI (and assembling some credits? That's probably important for a full release!).

All told, still a lot of work to be done, and while it's not where I hoped it would be by now, having all of the artwork finished is a huge step forward.

This has been your not-regularly-scheduled break in silence. Back to work.

Jan 8 2017 - Displaying images sanely

I think one of the most difficult challenges I face with not having a strong programming background is not knowing exactly how syntax is set up for different languages.

Case in point: Renpy. You would think flipping an image is a simple thing. Spoiler alert: It is. But figuring out how the heck the engine expects you to do it with the spaghetti documentation that exists is kind of a nightmare in my experience.

I have a picture, and I want to be able to display it facing left or right. This isn't a difficult thing to ask. But there are a lot of ways to do this, some of which are more trouble than others. It's possible to declare the image transforms upon initialization, but when you could potentially be flipping thousands of images, you need a much better solution. Same with exporting duplicates of every image that could be flipped and hoping you remember the naming conventions.

It's a nightmare, and while it might work for a one-off instance, it DOESN'T work for my project at all (or most projects, I'd wager).

Fortunately, there's a much easier solution, one that isn't covered in ANY of the documentation at all.

I present to you the xzoom command.

    scene black

    "This here is just a test scene meant to play around."

    "We're going to play around with some images right now."

    show tzania happy at right:

          xzoom -1.0

 The gist here is pretty simple: By declaring a show command with a colon, you can apply transformations such as scale, zoom, rotate, whatever. It does NOT work like the following:

                 show tzania happy at right with xflip

Despite the fact that the documentation seems to indicate this should work. (It doesn't because it has no idea what xflip is. Or xzoom. Or a lot of other things for that matter.)

So lessons learned once again, and if you ever need to flip an image in renpy quickly, this is how you do it. (You can also use yzoom -1.0, that works just as well but with the other axis.)

I'm sure I'll figure out other ways I can use this to my advantage in the future.

Dec 13 2016 Devlog: Cracking the code

Tonight I'm going back to the usual tone I've set lately, and delve into some of the programming issues I've been wrestling with. It comes with a surprising revelation: I'm actually sort of okay at this thing it seems.

I still feel like a hack when assembling things, but tonight was one of those nights where I made a plan, followed it through, then came up with a better way to do it immediately after. So I'm going to be talking about that.

How do you make a game?

Today I'm going to take a break from what I've been writing about lately to talk about new lessons I've learned as an indie game developer (and why it feels weird to call myself that). While I won't be talking about programming issues (at least not directly), I'm going to instead discuss some of the other lessons I've learned the last couple of months.

So hopefully someone out there finds this useful. I need a break from the usual thing anyways.

Ren'Py, the DSE, and How Events Work

So, I have mentioned in the past that programming is hard.

What a surprise, right?

Well, today's bit of weirdness comes from the way the DSE framework in Ren'Py handles events, the way it processes those events, and the way that it determines when to execute an event.

So here was my issue: When setting up the core events for my game, I came across a truly strange interaction where the game began to execute a specific event, despite the fact that it was in neither the correct location, nor the correct time, or even the correct day within the game.

My first instinct was that maybe it was a typo. I was visiting the laboratory, but for some reason one of the character's generic events was playing out that occurred in the library! So maybe I'd just made a spelling error in the event.

Turns out it wasn't so simple. Or rather, it was simple, but not in the way I had expected.

After turning it over and over, I finally managed to hammer down what was going on, and in the process learned something about how it processes variables.

See, here's what the event code looked like:  

$ event("cyn_base_library", "act == 'library', tod == '3', dow == '3'", event.only(), priority=175)

$ event("cyn_base_library", "act == 'library', tod == '1', dow == '1'", event.only(), priority=175)

$ event("cyn_base_library", "act == 'library', tod == '1', dow == '7'", event.only(), priority=175)

$ event("cyn_base_garden", "act == 'garden', tod == '3', dow == '2', day >= '5', cyn_rel >= '1'", event.only(), priority=175)

$ event("cyn_base_garden", "act == 'garden', tod == '3', dow == '6', cyn_rel >= '1'", event.only(), priority=175)

$ event("cyn_base_lab", "act == 'laboratory', tod == '4', dow == '4', cyn_rel >= '1'", event.only(), priority=175)

Turns out, what I was doing was totally wrong, because none of those conditions was actually causing the event to play. What I should have typed was this:

$ event("cyn_base_library", "act == 'library' and tod == '3' and dow == '3'", event.only(), priority=175)
$ event("cyn_base_library", "act == 'library' and tod == '1' and dow == '1'", event.only(), priority=175)
$ event("cyn_base_library", "act == 'library' and tod == '1' and dow == '7'", event.only(), priority=175)
$ event("cyn_base_garden", "act == 'garden' and tod == '3' and dow == '2' and day >= '5' and cyn_rel >= '1'", event.only(), priority=175)
$ event("cyn_base_garden", "act == 'garden' and tod == '3' and dow == '6' and cyn_rel >= '1'", event.only(), priority=175)
$ event("cyn_base_lab", "act == 'laboratory' and tod == '4' and dow == '4' and cyn_rel >= '1'", event.only(), priority=175)

Instead of triggering the events when all of the conditions were met, it seemed more than happy to select the events based on their priority, totally ignoring the variable block.

All because I didn't use the word 'and' to separate my variables.

Hopefully someone finds this useful someday. In the meantime, it's back to the grind with me. There's so much work left to do, but this seemed like one of those major things that was really just a minor thing. Really though, I felt proud when I figured it out on my own, and without needing to consult the Internet for help.

**EDIT**

I AM AN IDIOT AND YOU SHOULD IGNORE THAT STUFF ABOVE BECAUSE IT'S STILL WRONG.

So after spending almost literally my entire night, here's the way the code blocks should really look:

    

$ event("cyn_base_library", "act == 'library'", event.only(), "tod == 3", "dow == 3", priority=175)
$ event("cyn_base_library", "act == 'library'", event.only(), "tod == 1", "dow == 1", priority=175)
$ event("cyn_base_library", "act == 'library'", event.only(), "tod == 1", "dow == 7", priority=175)
$ event("cyn_base_garden", "act == 'garden'", event.only(), "tod == 3", "dow == 2", "day >= 5", "cyn_rel >= 1", priority=175)
$ event("cyn_base_garden", "act == 'garden'", event.only(), "tod == 3", "dow == 6", "cyn_rel >= 1", priority=175)
$ event("cyn_base_lab", "act == 'laboratory'", event.only(), "tod == 4", "dow == 4", "cyn_rel >= 1", priority=175)

You will note that the variables have been moved outside of the second block. It's because the 'and' statement may or may not work. But it probably won't, so don't use it in that context.

LESSONS CONTINUE TO BE LEARNED!

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.

Lessons learned: Syntax is everything

I may have mentioned this before, but I am not a very good programmer.

Back in high school, I learned the basics of HTML. Straight HTML, mind you. I could make some of the ugliest damned webpages you ever saw, all with the glory of friggin' Notepad. It taught me the basics of program logic, but beyond that I can't say I ever learned any useful programming skills.

That said, I am capable of sort of reading code. So transitioning to Python and learning the rules the hard way (ie: jumping right in with both feet) has been interesting to say the least. *laughs* I've made some real progress.

Ren'Py utilizes Python scripting, but it seems to have its own rules and shortcuts, which make things easier for guys like me who haven't bothered to learn programming via proper channels. What I do is much less programming, and much more like hacking things apart and trying to stitch it together into some sort of Frankenstein's Monster in the hopes that it works (it's aliiiiiiiive!).

Tonight I set some fairly simple goals for myself:

- Set up the class system, and create placeholders for all of the classes

- Ensure that only Attend Class shows up on the appropriate days

- Check to see that the correct class is being executed on a given day and time period

Needless to say, it provided me with a few challenges right off the bat. Chief of all: How do we determine when classes become available?

Because of the structure of the game, it is necessary to differentiate between morning and afternoon classes, as well as to differentiate 'Monday' classes from the rest of the week. This creates ten courses, all of which have their own set skill increases associated with them. Furthermore, if I feel the need to create actual events that take place during these classes, I need to find a way to have them all execute in the correct order.

The first idea that came to mind was to use the day counter that comes packaged into the DSE code. It looked a little something like this;

init python:

    register_stat("Strength", "strength", 10, 100)

    register_stat("Intelligence", "intelligence", 10, 100)

    register_stat("Charisma", "charisma", 50, 100)

        dp_period("Morning", "morning_act")
        if (day == 1 or day == 8):
            dp_choice("Attend Class1", "class01")
        if day == 2:
            dp_choice("Attend Class2", "class03")
        if day == 3:
            dp_choice("Attend Class3", "class05")
        if day == 4:
            dp_choice("Attend Class4", "class07")
        if day == 5:
            dp_choice("Attend Class5", "class09")
        if (day == 6 or day == 7):
            dp_choice("Something Else", "class05")
   
    # This is an example of an event that should only show up under special circumstances
    ###dp_choice("Fly to the Moon", "fly", show="strength >= 100 and intelligence >= 100")
        dp_period("Afternoon", "afternoon_act")
        dp_choice("Study", "study")
        dp_choice("Hang Out", "hang")
        dp_period("Evening", "evening_act")
        dp_choice("Exercise", "exercise")
        dp_choice("Play Games", "play")
   
        dp_period ("Late Eve", "late_act")
        dp_choice ("Twiddle Thumbs", "twiddle")
        dp_choice ("Stare at ceiling", "stare")

It makes perfect sense, except that when you try to run it, it throws an exception: "day not defined".

What gives? Day is clearly defined - it says so right down below in the start code! This was the first major lesson of the day - Day is not defined in the intro block, and you cannot define it in the init code because every time you load the game, it would force the day to become 0 - regardless of what the actual day was. This provides a problem, because you only want the day to become 0 at the start of the game! How do we get around this?

It took some finagling, but I found that placing the day planner code after the day code is initialized gets around this. Now the game properly only provides the correct option depending on what day number it is. Which led to the next problem: While the correct option was showing up, for some reason none of the events were playing out properly! The day progressed, and the correct placeholder for the class was showing up (proving that the correct buttons with the correct commands were being displayed). But for some reason, the execution of the day planner was skipping over my placeholders.

Eventually, I found the source, and it lay in the event planner's code.

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

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

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

The problem lay in the act. The correct event (Class 01 for example) was being called. But instead of executing the correct event, it was attempting to jump to 'Class'. My mistake was in thinking that act meant a classification of an action - instead, that's the part of the code that tells it 'jump to this event name' (or 'when this action is called, jump to this event', I haven't figured out which yet). So essentially, I wound up breaking it completely by accident, but it wound up fixing itself once I corrected the error. So now the correct classes show up on the correct days I tell it, and the correct placeholder activates.

Unfortunately, this has presented a new problem that I didn't anticipate until I sat down to write my progress for the night: While the code works in execution, loading a saved game during the start of the day (when you would decide what to do for the day), everything breaks.

Why does this happen? Because when you load the game fresh and jump right into a save, the start-of-day code has already executed, meaning none of the day planner options have initialized, because they were not defined when the game loaded. Using the "roll back" option to step back to just before the day initializes causes the code to execute properly, but you should not be required to step back the first time you load your game because it hasn't figured out what Morning is.

I haven't found a solution for this yet, but hopefully tomorrow I can figure it out (if I don't manage it tonight before I go to bed).

So while I've hit my goals for the evening, I'm still left with one puzzle that I may leave for tomorrow.