HTML Perverted Education [v1.3301] [April Ryan]

[~X~]

My suggestion is that ~X~ should look into locking the settings when the game is launched (or restarted) and then unlocking it after the survey is taken.

Ah ok. Setting the kinks in the surveys sets them to the point where you have already taken the hypnosis. That's probably why it's not showing up.

 

[~X~]

Will old saves work on newer version? Also im getting this weird virus notif

Malwarebytes is saying that the one on my machine is clean. Not sure what's going on there. Did you try to run that file when you got the message? Also, can you click on "more" and show me what it says?

 

[~X~]

Greetings, all! We are already working hard the next release, so I thought I’d share with you some of our plans.

The team is taking this month to focus on doing some work on the game engine. As such, the amount of visible changes will probably be less than the past two months, but these changes will make things a lot easier for us to add new content to the game in the future and will hopefully create a better play experience for you guys. This will likely start being a pattern for us, a couple of content-focused releases followed by a gameplay-focused release.

The changes:

• Inventory system changes - This is the big project for this month. Our old system doesn’t fit our use cases any more. Specifically, it doesn’t handle the different variants of items well. We’re going to try to make the variants more distinct and apply different attributes to them, which will help us make things more varied inside of item types (for example, we can start ascribing colors to specific pairs of shoes). This is really for future proofing as we want to start adding more clothing soon.
• Mall interface - We’re adding a couple new stores to the mall: a menswear store, and an accessories shop. We’ll also be adding a category of latex items to the adult store. This will mean some regrouping of items. We’ll also be adjusting what is “School appropriate” and breaking those out into their own item sets to make it a little clearer what can be worn to school. We may also add some new stores in the future like a sportswear store and a cosmetics shop.
• Fetish system rework - With the addition of the fetish survey, it made less sense to have the hypnosis sessions determine whether fetish content was unlocked. In particular, it didn’t allow for the world to be kinky around the main character, even if he didn’t actively enjoy the kink himself. The new system will allow the world around main character to be kinky after a kink is selected on the survey, while accepting a hypnosis session will cause the main character to react positively to that fetish. This should allow us to better handle players who like to play a resistant main character.
• Difficulty options and other economy fixes - Players will be allowed to select difficulty options that will determine the teacher’s starting bribe requirement and how quickly it escalates, as well as how much money is earned through chores. This will also affect the ease of winning against opponents in the arcade. We will also be looking at the cost of items in relation to money earned by the PC and how quickly the bribe escalates due to forced trips to the clinic.
• Phone UI (time dependent) - This one will really just come down to how long it takes to deal with the other four. If we have free time, we will try to finish the phone functionality in the game, though it may be a bit light on its usage immediately. It will allow PC to message with NPCs, as well as receive phone calls from them, and keep his tasks and other commitments straight with a day planner.

New content:

• The club basement - What sexy secrets hide behind the hidden door to the club basement? This will be a new area of the game designed for non-canon “what if” scenarios and will be a place to live out fantasies not available due to the restrictions of the game’s storyline. Patrons may find this place particularly interesting, but more information on that will come soon.
• Several incidental scenes - We will be adding several small scenes to the game to make the story flow a little smoother. These will be scattered throughout the game like easter eggs, so have fun hunting them down.

Plus, we will be doing the usual bug fixing and text fixes, several of which are already in the game.

We are also taking this month to do some planning and writing for future content.

Currently writing:

• Cheerleaders - Two more episodes + two side events with Ashley + one side event with your friend from the cheer squad
• Friend - Helping with teacher tasks and other scenes
• School slut route - New updates to this route to help it lead into our teacher finale

Currently planning:

• Arcade tournament - Visiting the arcade on weekends will now feature a tournament in which you can face a number of opponents for cash. Of course, if you’re having trouble winning, you can always try cheating by distracting your opponent with a little flirting.
• Teacher endings - In this final chapter, Teacher would be giving the main character specific “job training” in a number of professions. Each of these professions would have a few after-school scenes and accompanying tasks. Upon completing the “training program” laid out by teacher, the main character would be given a choice to “graduate” from the teacher’s instruction and reach an ending or continue his education with a new job training sequence. Based on our patreon poll, our first endings will be:
  • Teacher’s pet
  • Trophy wife

I once again want to thank all our fans, and especially our patreon supporters for making our work on this game possible. We hope you’ve been enjoying all the new additions to the game and look forward to the surprises we have in store for you.

~X~

 

[vimmers]

game engine

sounds like we shall start over again,again

 

[AWolfe]

sounds like we shall start over again,again

Yeah, the first two bullet points under "Changes" strongly imply that old saves won't be compatible. Again. A "roadmap" or guide to when to expect these save-breaking changes would be useful and nice.

 

[~X~]

Yeah, the first two bullet points under "Changes" strongly imply that old saves won't be compatible. Again. A "roadmap" or guide to when to expect these save-breaking changes would be useful and nice.

Unfortunately, that will probably be the case. The mall actually won't cause that much of a change, but the clothing system will be a bitch. We will try to keep the changes to the clothing system as compatable as possible, but as we'll be looking in new places for old variables, I'm not sure we can do it 100%. If we did, we'd probably have to find some way to scour your inventory when you load and convert your variants into separate items, but that's difficult to do since there's not really a page for us to land on right after a save that could handle the conversion.

The fetish changes shouldn't play havoc with much outside of the settings menu. You'd probably just find some things checked that weren't yet.

We are going to try to push the early game bully stuff out soon too (most likely june), so that we can get as much of the early game changes over and done with and start pressing forward instead of making people restart every time. Sadly, most of this
is based around the medium we're working with. Because of the way the game was built, it needs some early/mid game improvements, but because we're adding checks for variables, the game freaks out if they're not there to check. Loading old saves means it's loading the old structures, so even if we write something that creates the missing ones when the game starts, that just gets thrown out when the load happens and now variables don't exist when the game wants to use them

 

[AWolfe]

Oh, I understand fully what's involved and why it breaks saves. I'm a software developer myself (just not a game dev, at least not yet anyway).

My desire for a roadmap is so that I don't invest a lot of my time playing a version (or versions) that will then have their saves broken on a soon-to-coming release. I'd rather wait until after the structural changes to restart. With respect, I'm not a tester for this particular game (unlike for the games in my sig) so I'd rather not spend my time testing the game's latest additions. I just want to enjoy playing PE, and having to keep restarting drastically lessens my enjoyment because it wastes a lot of my time to get back to where I was. Time I can spend on other things. No offense intended.

 

[~X~]

Oh, I understand fully what's involved and why it breaks saves. I'm a software developer myself (just not a game dev, at least not yet anyway).

My desire for a roadmap is so that I don't invest a lot of my time playing a version (or versions) that will then have their saves broken on a soon-to-coming release. I'd rather wait until after the structural changes to restart. With respect, I'm not a tester for this particular game (unlike for the games in my sig) so I'd rather not spend my time testing the game's latest additions. I just want to enjoy playing PE, and having to keep restarting drastically lessens my enjoyment because it wastes a lot of my time to get back to where I was. Time I can spend on other things. No offense intended.

Perfectly understandible. We tend to have a general idea of where we want to take things next, but stuff can crop up that looks like it needs more immediate fixes. We will probably keep things in a pattern of 2 content-focused releases, 1 gameplay-focused release for a while. There's a lot on the code side that still needs to be cleaned up, but if we spend 3-6 months tinkering with gameplay, people are going to feel starved for new content. Additionally, taking a "writing break" lets us circle the wagons a bit when we're planning future content. For now, our plans for the next few months (definitely subject to change) are:

April:
Clothing, mall, fetish, and economy rework

May:
More friend (up to midgame) and cheerleader
First half of school slut (perhaps more)
Planning about arcade tournament
Planning about teacher's endings

June:
Early Bully
More cheerleader
Rest of school slut
Teacher's pet ending
Trophy wife ending (time permitting)

July:
Not sure. Adding acceptance system is a possibility, but we're still considering the value of this system.
Add Arcade tournament system
Guardian planning

Aug:
Midgame bully
More cheerelader
More teacher endings
Arcade tournament writing

 

[vanuyak]

but because we're adding checks for variables, the game freaks out if they're not there to check

<<if ndef $variable>>
<<set $variable to "default state">>
<</if>>

 

[~X~]

<<if ndef $variable>>
<<set $variable to "default state">>
<</if>>

I mean, that's the start. We'd just have to go through and do that to basically every variable check in the game that was affected by the change, plus figure out what default states are in the event of fail states. Some variables may have also changed in their use, so we'd have to check for a suitable value as well as if it's missing. There are more considerations than just "this isn't there, so do this."

In the instance of the inventory change, do we default to your inventory now being empty because we can't check to see if you own/are wearing something or do we just do enough to get by until we can hit a page that will convert things out for us (like sleeping or going to the bedroom, etc.)? Is losing all your progress in that regard, but not losing your place in the story still "keeping your place" in the game?

Do we pull devs off other bug fixes and coding work to make sure everything is backwards compatable?

If we're adding content that is meant to trigger at a specific place in the game (such as with cheerleading), do we try to make the game work such that it will activate that new content even though it's out of time sync? If we don't allow them and they load a save past the additions, what's the point in them loading a save in the first place since they won't see the changes?

 

[AWolfe]

Isn't there a way to check to see if the save being loaded is using the old structure, load the old data into the old structure, and then convert the data into the new structure? Up front during the save loading process. You (should) know what the old structure was (assuming you kept an intact copy of the development files for the previous, now obsolete, version), and you know what the new structure is, so an in-game conversion should be doable. Whether you want to devote the effort to not break old saves by building in such a conversion mechanism is another matter. Depends on how annoyed your paying customers get when you break their saves and how important it is to them, and you as the dev, to keep them happy. If more content regardless of the expense of save compatibility is what they want, then that tells you not to devote your resources to assuring save compatibility. But if the paying customers are willing to live with a little less new content in an upcoming release so that their saves don't get broken, then that tells you to make the effort.

 

[~X~]

Isn't there a way to check to see if the save being loaded is using the old structure, load the old data into the old structure, and then convert the data into the new structure? Up front during the save loading process. You (should) know what the old structure was (assuming you kept an intact copy of the development files for the previous, now obsolete, version), and you know what the new structure is, so an in-game conversion should be doable. Whether you want to devote the effort to not break old saves by building in such a conversion mechanism is another matter. Depends on how annoyed your paying customers get when you break their saves and how important it is to them, and you as the dev, to keep them happy. If more content regardless of the expense of save compatibility is what they want, then that tells you not to devote your resources to assuring save compatibility. But if the paying customers are willing to live with a little less new content in an upcoming release so that their saves don't get broken, then that tells you to make the effort.

I'm looking into it. There was some attempt at making things compatable in the past, or at least, the version check is there. I'm not sure the fuction is working right though.

Edit: Thanks to some old code left by april, I think I just cracked it. We'll probably have to write a conversion script when we do the inventory changes, but I just got saves from .79x to work on .81.

 

[vimmers]

~X~
you could maybe add this

You must be registered to see the links

while you update the gui anyway

 

[vanuyak]

I mean, that's the start. We'd just have to go through and do that to basically every variable check in the game that was affected by the change, plus figure out what default states are in the event of fail states. Some variables may have also changed in their use, so we'd have to check for a suitable value as well as if it's missing. There are more considerations than just "this isn't there, so do this."

In the instance of the inventory change, do we default to your inventory now being empty because we can't check to see if you own/are wearing something or do we just do enough to get by until we can hit a page that will convert things out for us (like sleeping or going to the bedroom, etc.)? Is losing all your progress in that regard, but not losing your place in the story still "keeping your place" in the game?

Do we pull devs off other bug fixes and coding work to make sure everything is backwards compatable?

If we're adding content that is meant to trigger at a specific place in the game (such as with cheerleading), do we try to make the game work such that it will activate that new content even though it's out of time sync? If we don't allow them and they load a save past the additions, what's the point in them loading a save in the first place since they won't see the changes?

Yeah, I was just being a smartass. I've taken a look at the game's code before and it's not how I'd have written it. Not the worst I've seen but not exactly elegant.

 

[~X~]

Yeah, I was just being a smartass. I've taken a look at the game's code before and it's not how I'd have written it. Not the worst I've seen but not exactly elegant.

Yeah. I'm about the fourth person to inherit this 60k line codebase. So, I'm not surpised it looks like the vomit on Eminem's sweater. Especially since the people writing (myself included at times) are often more interested in adding new features than making sure the code is well maintained.

 

[Proto Persona]

Yeah, I was just being a smartass. I've taken a look at the game's code before and it's not how I'd have written it. Not the worst I've seen but not exactly elegant.

Yeah. I'm about the fourth person to inherit this 60k line codebase. So, I'm not surpised it looks like the vomit on Eminem's sweater. Especially since the people writing (myself included at times) are often more interested in adding new features than making sure the code is well maintained.

Ah, the spaghetti code delima. Do you add features the users are requesting by tacking them on to the rickety framework, or do you repair the foundations while leaving the users complaining about lack of updates?

 

[AWolfe]

If you're smart you fix the foundation. Otherwise you risk creating avoidable problems, and pissing off your users more than a delay would have. People are funny that way. They want it NOW, but they also want it to work correctly. You're more likely to lose stars on a review for instability than for delaying an update or two.

 

[~X~]

If you're smart you fix the foundation. Otherwise you risk creating avoidable problems, and pissing off your users more than a delay would have. People are funny that way. They want it NOW, but they also want it to work correctly. You're more likely to lose stars on a review for instability than for delaying an update or two.

Part of our problem was users had already spent months waiting on what was supposed to be a refactor that never happened. So, we needed to push new content out the door to restore good faith. This inventory improvement is a refactor that we vastly need for upcoming content additions. Additionally, one of the coders I am looking to bring on seems to have an eye for such things, and while I'm sure we'll keep him plenty busy with new features, I do look forward to giving him some time to just go through and fix shit.

 

[AWolfe]

Yep. I am so glad that you've taken over this game! It's now in professional hands, and moving along nicely. Kudos.

I find it interesting that you feel that PE needs to have its inventory system restructured. I've used PE in my comments on other HTML games (such as TSGE) as an example of a game with a good system. And now you're going to raise the bar.

 

[~X~]

Yep. I am so glad that you've taken over this game! It's now in professional hands, and moving along nicely. Kudos.

I find it interesting that you feel that PE needs to have its inventory system restructured. I've used PE in my comments on other HTML games (such as TSGE) as an example of a game with a good system. And now you're going to raise the bar.

The version April built was pretty solid, but it was defintiely designed around the idea that there would only be one of an item. Basically, each of our item variants was just a single item in a list of numbers. That meant every variant needed to have all the features of it's "parent item." The only way we could differentiate between items was based in their location in the list of variants. Basically, any variant 0-x was school safe and variants y z and q were reserved for items owned by guardian, teacher, and therapist. The question we eventually butted up against was "what if we want to have more than one attribute split across variants?" We'd basically have to make our ordering more and more complicated until it finally broke. Far easier to just create objects for each variant, link it to a parent item, and use that parent item to inherit any missing attributes in the variant. That way, every item we have is actually distinct.

We are still doing some splits for things that should probably be kept as one "item," but in this case the driving question is "do these need to be distinct to deliver information to the player?" rather than "do these need to be distinct because their attributes are different from this other thing?"

Edit: As a bit of a spoiler:

Spoiler: Patreon plans

You don't have permission to view the spoiler content. Log in or register now.