Ren'Py Under Your Spell [Development Thread] (Magic School Dating Simulator)

[Shady Character 1]

Okay, I think I will try to return to weekly Friday updates.
We got a lot of feedback in this past almost week. Most of it were issues that we were already aware or ready for, like "too little content", "where are the boobs?", etc. But we also had a lot of got bugs caught, and a lot of ideas how to improve things or in what direction we should move first.

So there already some changes that we did. (None of them included boobs though. Those will have to wait for now):
-Stat losses were a bit too punishing in the early game, so those got scaled bit a bit.
-The exam descriptions were expanded to give clearer picture of how you did and why. These are still placeholder events and will be expanded even more later.
-The first encounter with each girl is now guaranteed once you have enough stats for that (you still need to do the correct activity)
-New random event have been added to the "Rest" activity, which will bring a bit more value to the activity, as well as adding more flavor to each of the houses.
-The work continues on the Trial of Mind, which was actually a bit broken before, but is fixed now (about 80% done).

I guess that's it for this week, aside for the continuous work on the art. See you next Friday.​

 

[Shady Character 1]

Wow, this week flew by fast!
Unlike the previous one, I don't have much to report. Aside for almost finishing the first Trial. Only 1 door out of 19 and the event aftermath remain to be finished.
- Most of this week was spent in planning new events, looking for bugs, typos, translation and setting up pages on other websites.
- I also started working on two new girls' plotlines (Elizabeth and Ciara), those will not be added for some time though, because they still need their sprites to be done by the artist first. As well as me wanting to each girl having the same number of events when added (which is currently 3.)
- On the art side, a couple new sprites have been finished along with some progress of the BGs and in-game artworks. Hopefully those will be completed and added into the game soon.
​

 

[Shady Character 1]

And another weekly update is here. To be honest, I and acquired an new sense of appreciation for other game devs, who make games open to the public, because it is really hard to not feel you rhythm broken by players' feedback be it good or bad.
That being said, we are trying to pace ourselves going forward.

On the coding and writing side:

Most of our attention that isn't spent on planning the game events is currently focused on implementing the shop and part-time job mechanics. These two mechanics will allow you to buy items that will help you train your stats. Later the store will also be one of the places that allow you to gain access to utility spells, that will need to be learned and trained during "Practice Spells" activity, and will give you additional ways to resolve some events.

Since these three mechanics are interwoven, it takes a lot of time to plan and implement them. But you will hear and see more of them in the upcoming updates.
I will not burden you with how they look right now.

One the art side:

A sprite for Elizabeth Lewis, the prefect of Dunagall House and one of the main girls is almost complete and will be soon added to the game.

We are also continuing the work on placeholder backgrounds, so that the game will not feel so empty. As well as the introductory artworks for the 8 main girls. Artworks, as all good things, take a lot of time so the progress is pretty slow on this front.
​

 

[Shady Character 1]

Ok, time for another development update.

Developments on the coding and writing side:

Last week was a bit tough, I got my eyes opened on how may typos there were still in the game, even after several rounds of spell-checking and testing. But thanks to a couple of supportive testers I found a way to run spell-checking on MS Word without being afraid to ruin the code. In retrospect, this was so simple that I feel dumb to not doing it before. Live and learn. Anyway, with several hundreds (yes, hundreds) typos fixed, I had to also redo a lot of translation code, so that took a lot of my time this week. But at least the writing should be much smoother now.

But I did manage to find time to continue working of the "earning and spending" system in the game. Specifically by implementing the first part time job "Helping at Raven's Wing pub". This job also introduces one of the alternative dating candidates, pub's proprietor - Hope. And the introduction even also teases a "soon to arrive" main cast member - Ciara.

On the art side:

Work continues on the sprites for Elizabeth, Hope and Ciara. But there is very little new that we can show you yet. Probably something to look forward to in the next week's update.
And some new placeholder backgrounds are coming along nicely too. We will probably be able to fill most of the holes in a couple more weeks. Then it will be time to actually turning them into their final form.​

 

[malcolmalbie]

Noticed a bunch of copy/pasted code like

if prowess <= 25:
    $ prowessnew = min (100, prowess + 0.25)
elif prowess <= 75:
    $ prowessnew = min (100, prowess + 0.5)
else:
    $ prowessnew = min (100, prowess + 0.25)

that both does and doesn't take into account the currently unused {skill}_item_bonus variables.

Why not use and call functions like

init python:
    def increment_skill_bonus(skill, increment, skill_item_bonus):
        """Returns a skill + increment taking into account the item_bonus"""
        min_increment = increment / 4
        if skill <= 25:
            skillnew = skill + min_increment * 4
        elif skill <= 50:
            skillnew = skill + min_increment * 3 + min(min_increment, skill_item_bonus)
        elif skill <= 75:
            skillnew = skill + min_increment * 2 + skill_item_bonus
        else:
            skillnew = skill + min_increment * 1 + skill_item_bonus
        return min(100, skillnew)

    def increment_skill(skill, increment):
        """If skill is between 25 and 75 (inclusive) then skill + increment, otherwise skill + (increment / 2)"""
        # if 25 <= skill <= 75:
        #     skillnew = skill + increment
        # else:
        #     skillnew = skill + increment / 2
        skillnew = skill + (increment if 25 <= skill <= 75 else increment / 2)
        return min(100, skillnew)

$ appealnew = increment_skill_bonus(appeal, 1, appeal_item_bonus)
$ prowessnew = increment_skill(prowess, 0.5)

This way you avoid copy/paste mistakes like

if knowledge <= 25:
    $ knowledgenew = min (100, knowledge + 1)
elif knowledge <= 50:
    $ knowledgenew = min (100, (knowledge + 0.75 + (min (0.25, knowledge_item_bonus))))
elif knowledge <= 75:
    $ knowledgenew = min (100, knowledge + 0.5 + knowledge_item_bonus)
else:
    $ knowledgesnew = min (100, knowledge + 0.25 + knowledge_item_bonus)

(note the knowledgesnew on the last line)

 

[Shady Character 1]

Noticed a bunch of copy/pasted code like

if prowess <= 25:
    $ prowessnew = min (100, prowess + 0.25)
elif prowess <= 75:
    $ prowessnew = min (100, prowess + 0.5)
else:
    $ prowessnew = min (100, prowess + 0.25)

that both does and doesn't take into account the currently unused {skill}_item_bonus variables.

Why not use and call functions like

init python:
    def increment_skill_bonus(skill, increment, skill_item_bonus):
        """Returns a skill + increment taking into account the item_bonus"""
        min_increment = increment / 4
        if skill <= 25:
            skillnew = skill + min_increment * 4
        elif skill <= 50:
            skillnew = skill + min_increment * 3 + min(min_increment, skill_item_bonus)
        elif skill <= 75:
            skillnew = skill + min_increment * 2 + skill_item_bonus
        else:
            skillnew = skill + min_increment * 1 + skill_item_bonus
        return min(100, skillnew)

    def increment_skill(skill, increment):
        """If skill is between 25 and 75 (inclusive) then skill + increment, otherwise skill + (increment / 2)"""
        # if 25 <= skill <= 75:
        #     skillnew = skill + increment
        # else:
        #     skillnew = skill + increment / 2
        skillnew = skill + (increment if 25 <= skill <= 75 else increment / 2)
        return min(100, skillnew)

$ appealnew = increment_skill_bonus(appeal, 1, appeal_item_bonus)
$ prowessnew = increment_skill(prowess, 0.5)

This way you avoid copy/paste mistakes like

if knowledge <= 25:
    $ knowledgenew = min (100, knowledge + 1)
elif knowledge <= 50:
    $ knowledgenew = min (100, (knowledge + 0.75 + (min (0.25, knowledge_item_bonus))))
elif knowledge <= 75:
    $ knowledgenew = min (100, knowledge + 0.5 + knowledge_item_bonus)
else:
    $ knowledgesnew = min (100, knowledge + 0.25 + knowledge_item_bonus)

(note the knowledgesnew on the last line)

Yeah, good point. I already did a similar thing to time progression. When I initially wrote this, I did not consider that it would be repeated as much.
I am not very comfortable with "init python" too, so I try to do most things with standard ren'py stuff. But that's the issue I will need to work on. I will try your code. Thanks for the suggestion.
On the side note, I do know that people can look at the source code pretty easily, and I am totally ok with that. But it still irks me a bit for some reason =) Any tips on that?

 

[malcolmalbie]

On the side note, I do know that people can look at the source code pretty easily, and I am totally ok with that. But it still irks me a bit for some reason =) Any tips on that?

There's a number of ways you can go about it, most common is editing options.rpy and changing build.classify('game/**.rpy', 'archive') to build.classify('game/**.rpy', None), which prevents the plaintext scripts from being included in the .rpa files leaving only the compiled .rpyc files. Note that there's ways to decompile the compiled scripts so this isn't a foolproof solution, but does remove any comments you have left in the code.

If you want to go further, you can edit the python scripts in RenPy's renpy folder, with RPYC2_HEADER in script.py being a common one changed to throw off decompilers (though again, not foolproof). Be warned that any changes made will need to be shared among any team members working on the code.

 

[Shady Character 1]

There's a number of ways you can go about it, most common is editing options.rpy and changing build.classify('game/**.rpy', 'archive') to build.classify('game/**.rpy', None), which prevents the plaintext scripts from being included in the .rpa files leaving only the compiled .rpyc files. Note that there's ways to decompile the compiled scripts so this isn't a foolproof solution, but does remove any comments you have left in the code.

If you want to go further, you can edit the python scripts in RenPy's renpy folder, with RPYC2_HEADER in script.py being a common one changed to throw off decompilers (though again, not foolproof). Be warned that any changes made will need to be shared among any team members working on the code.

Oh, no, as I said, I am ok with sharing the code. People who wanted to would decrypt it anyway. It was more of a joke about overcoming "stage fright", so to speak.

 

[Shady Character 1]

It is Friday again, lets do an update on what happened last week.

Lately, I’ve decided to slow down the writing process a bit to allow Shady Two to catch up with the artwork. My new goal is to create one random event and one "girl-event" per week. The "girl-events" will build up to a major update featuring Elizabeth and Ciara, along with a new event for every girl already in the game. This approach may change in the future, but it seems like a good strategy for now.

In terms of coding, I focused on optimizing the code last week. Much of the initial code was written with a different structure in mind, leading to numerous redundancies. I’m now working through the code to reduce these inefficiencies, already cutting out hundreds of lines. This not only improves game performance but also minimizes potential future mistakes – a win-win situation.
Almost immediately after that, it was generously pointed out to me that there is still a lot of ground to cover. Yay!


On the art side, Elizabeth's sprites required more effort than we anticipated. Different hand positions combined with multiple clothing layers resulted in a lot of tedious work with image layers. Despite the challenges, we learned a lot and have completed the base for Elizabeth’s sprite. Now that the foundation is set, expanding on it will be much easier.

However, before we dive into more work on Elizabeth, we have a lot to do with Hope and Ciara. (Here’s a sneak peek of Hope, by the way.)

Additionally, we’ve been working on artworks for new events, like this one for the broom racing event.

On that pantieful note,
Until the next update!​

 

[Shady Character 1]

Another devblog update time!
I both did and did not conform to the plan I set for myself last week. I did write two events, but both of those were random ones. Though I did also rework one of the new Aisling event per Shady Two's suggestion, so that kinda counts, no? But in any case, if I will manage to do two girl events this week, I will still get to the required total. But getting to start writing Ciara's events turned out a bit more difficult than I expected. Some girl's just don't want to be written it seems. I had the same issue with Lily too, but she turned out great so far. So, I hope Ciara will be the same in the end.
I also made some more optimizations to the code. I have no idea if those milliseconds saved parsing will ever be noticeable, but I hope this will all be worth it in the end.


Shady Two was fighting with Aisling's eyes all this time. Aisling's face was most possibly the most redrawn thing in the game so far, by far. Even setting her full-artwork aside, which was its own can of worms. But the struggle seem to have come to an end. So along with some more backgrounds and hopefully some more full artworks, there will be a bunch of new facial expressions for Aisling coming with the next update. Here's a sneak peek of that.
​

 

[malcolmalbie]

I have no idea if those milliseconds saved parsing will ever be noticeable, but I hope this will all be worth it in the end.

Half the time the optimisations make it so you can read it and bugfix a lot easier.
The other half is because you learned about this cool new thing Python can do and you want to use it everywhere

 

[Shady Character 1]

Half the time the optimisations make it so you can read it and bugfix a lot easier.
The other half is because you learned about this cool new thing Python can do and you want to use it everywhere

Yeah, pretty much nothing like the feeling you get when you understand that you can do something with 10 lines of code instead of 500

 

[Shady Character 1]

Aaaaaand, it's time for another devblog!
I have managed to keep this up longer than I though to be completely honest. These last few blog entries were a bit too dry if you ask me, so I will try to do some more in-depth development topics in the next one.
But for now, here are some news.
News on the Coding and Writing Side: I did manage to follow my goal and write two Ciara events last week, so that brings us a bit closer to the next big update, which should include 4 new events for Ciara and Elizabeth and 1 new event for each of the four girls already present. I do need to get close and personal with the "earning and spending" part of the gameplay, but it will probably have to wait a couple more weeks, since I am waiting for the art assets from Shady Character Two.
Speaking of which,
On the Art Side: Last week did bring us a couple new sprites, as well as some progress on more artworks and backgrounds. But the most noteworthy fruit of last weeks labours is definitely the finished sprite of Rosie, the White Ghost. She only has one event in the game so far, but looking at this sprite, I definitely want to make more room for her appearances.


With that, until next week!​

 

[Shady Character 1]

This time, I wanted to talk more about how the development itself is going, rather than just the specific things we have done. You know, I bet no one ever thinks about how much of your work on the game is actually dedicated to promoting it rather than making it. Most of last week I spent my time on that aspect of game development. I'm going to be honest with you all: I'm not really suited for these kinds of activities, so the last few days have been a true emotional rollercoaster for me. From the anxiety pits of putting out promotions for everyone to see, to the highs of seeing most people react positively, and then the dopamine withdrawal the next day =D

So, yeah, if you ever plan on developing your game, be prepared for someone to take on the task of interacting with the outside world. Newsflash, right? Anywho, even with all the emotional turbulence, I did manage to finish the Trial of Mind event, so the demo will not end as abruptly now. I even managed to get some good suggestions from our intrepid testers, who dare to play the game in its current state. It turned out to be a more or less productive development week.

Shady Two was able to make some headway in the art department too. First of all, work continues on the introductory images for the 8 main girls. Shady Character Two just cannot seem to focus on one artwork at a time, so progress is slow. But hopefully, there will be a burst of artworks later. For now, here's how Lily is coming along.

Also, some work has been done on finalizing one of the other recurring characters that you may see during your adventures at Tír na nÓg: a young (by Greater Fae standards) fairy queen who has yet to have a name. We are thinking of also making her our mascot/spokeswoman character. Look at her go—strike that—sit.
​

 

[Shady Character 1]

I skipped dome updates here, because, honestly, I am not sure is anyone is following me here. But I do feel like this one is kinda worth sharing. Also, I do keep posting these regularly on other platforms.


A LOT was done during this past week. First of all, let's get the the small stuff out of the way. I did some major optimizations to the code. Currently, the calendar system is by fast the most cumbersome and over-engineered in the game (it had more than 6000 lines of code which dwarfed every other singular module in the game). Thankfully due to a sudden epiphany I came up with a way to cut that down by almost 40%. Yay! It is still the biggest single block of code in the game, but it is much smaller now, almost seems manageable.
Before:

After:

Honestly, I think it should be at least 10 times smaller still, and I bet you that if any half-decent coder will take a single look at it, they will immediately come up with a much more elegant solution. Let's hope I'll get there someday.

Second on my "important accomplishments" list. We ironed out the interface for the android version of the game. I did not have a chance to test it properly, but is seems to be pretty stable from what I did test, and we are happy to present it to the public. There was so much demand for it.
Now to the part that I actually consider the most important. Shady Two worked tirelessly to make the store interface for the game. We only started the implementation, but it is a major step for the game, since this announces the addition of the last major mechanic to the game. After this, we only need to add the inventory interface, and that's basically it. There are still some more minor mechanics that will come up here and there, like unique spells, gallery, possibly a small card collecting mechanic, but those don't require so much work, and don't have such a big impact on the game. Now we can give much more focus to actually expanding the events.


Beside that, Shady Two only managed to barely start working on more actual artworks for the game, but it is still something. Our next goals in art department are finishing the sprites for Ciara, and artworks for or Fairy Queen (name still in progress, but we are leaning towards Maeve) and Gwen's training event.
​

 

[NaweGR]

You mentioned in one of your recent posts about needing to have a team member dedicated to interacting with the community. Are you finding that you are getting most of your interaction on here? Or are you getting more interest/traction on some of the Reddit subreddits, or...?

 

[Shady Character 1]

You mentioned in one of your recent posts about needing to have a team member dedicated to interacting with the community. Are you finding that you are getting most of your interaction on here? Or are you getting more interest/traction on some of the Reddit subreddits, or...?

It really depends honestly. F95Zone was really only active on the first couple updates. So now I get much more engagement on Reddit. But Reddit can be a hit and miss too, since some promos get a lot of traction, while other - just get nothing. The thing I mentioned was not just interacting with community that was already formed (which is very important too, of course), but also actual promotion which now takes almost as much of my time as writing and programming. Looking for places to promote, preparing the materials, and most of all actually posting something not knowing what the reception will be.
But going back to your original answer again, I cannot really say what platforms get more interest. Because, for example, we got a lot (comparatively) of attention on itch.io recently, but it didn't translate into any community activity, just a lot of silent followers

 

[malcolmalbie]

Looking at calendar.rpy, I see what you're talking about. I see a bunch of sections like

    if day == 3 and themonth == 12:
        imagebutton:
            xpos default_calendar_xpos+offset_calendar_xpos*1
            ypos default_calendar_ypos+offset_calendar_ypos*1
            xalign 0.5
            idle "calendar/calendar_button_chosen.png"
            hover "calendar/calendar_button_hover.png"
            action NullAction()
            tooltip December3
    else:
        imagebutton:
            xpos default_calendar_xpos+offset_calendar_xpos*1
            ypos default_calendar_ypos+offset_calendar_ypos*1
            xalign 0.5
            idle "calendar/calendar_button.png"
            hover "calendar/calendar_button_hover.png"
            action NullAction()
            tooltip December3

that only differ in the tooltip. What if you made a function that took the day, month and tooltip variables in as arguments and made the button?

You could possibly have another function that generates the calendar page.

 

[Shady Character 1]

Looking at calendar.rpy, I see what you're talking about. I see a bunch of sections like

    if day == 3 and themonth == 12:
        imagebutton:
            xpos default_calendar_xpos+offset_calendar_xpos*1
            ypos default_calendar_ypos+offset_calendar_ypos*1
            xalign 0.5
            idle "calendar/calendar_button_chosen.png"
            hover "calendar/calendar_button_hover.png"
            action NullAction()
            tooltip December3
    else:
        imagebutton:
            xpos default_calendar_xpos+offset_calendar_xpos*1
            ypos default_calendar_ypos+offset_calendar_ypos*1
            xalign 0.5
            idle "calendar/calendar_button.png"
            hover "calendar/calendar_button_hover.png"
            action NullAction()
            tooltip December3

that only differ in the tooltip. What if you made a function that took the day, month and tooltip variables in as arguments and made the button?

You could possibly have another function that generates the calendar page.

Yeah, you are looking at the public build that's the old code that I optimized to look like this

    imagebutton:
        xpos default_calendar_xpos+offset_calendar_xpos*4
        ypos default_calendar_ypos+offset_calendar_ypos*3
        xalign 0.5
        if day == 24 and themonth == 1:
            idle "calendar/calendar_button_chosen.png"
        else:
            idle "calendar/calendar_button.png"
        hover "calendar/calendar_button_hover.png"
        action NullAction()
        tooltip January24

Just one block per day now. I have now idea how to make it shorter than that, not yet so far. Also my issue is usually not logical, but just not knowing what the code can and cannot do. I learn as I go, so I can only really optimize if I encounter a new way to express the logic when I encountered another issue, and then I go "aaah, I can probably update my old code with this"

 

[Shady Character 1]

Looking at calendar.rpy, I see what you're talking about. I see a bunch of sections like

    if day == 3 and themonth == 12:
        imagebutton:
            xpos default_calendar_xpos+offset_calendar_xpos*1
            ypos default_calendar_ypos+offset_calendar_ypos*1
            xalign 0.5
            idle "calendar/calendar_button_chosen.png"
            hover "calendar/calendar_button_hover.png"
            action NullAction()
            tooltip December3
    else:
        imagebutton:
            xpos default_calendar_xpos+offset_calendar_xpos*1
            ypos default_calendar_ypos+offset_calendar_ypos*1
            xalign 0.5
            idle "calendar/calendar_button.png"
            hover "calendar/calendar_button_hover.png"
            action NullAction()
            tooltip December3

that only differ in the tooltip. What if you made a function that took the day, month and tooltip variables in as arguments and made the button?

You could possibly have another function that generates the calendar page.

Oh, wait I see what you are saying... The main difference is actually the position of the buttons not the tooltip. So I will still have to manually put: day, month, xpos and ypos into the function. It would definitely save me a few lines of code, but will not make it much less cumbersome to work, because I will still have the same number of blocks, just that the blocks will be slightly smaller.