Ren'Py Abandoned Princess Tower [v0.12.public.3] [Euphemismus]

[MarshmallowCasserole]

Is the in-game "help" screen useful to you? The secret sauce is dragging the mouse in order to sort of... draw back the ruler and then release to swat. It is apparent that I'm going to have to improve the UI/UX when it comes to the ruler.

View attachment 821871

Personally, I found this unhelpful. Dragging up the skirt is intuitive (drag upwards, DUH), but dragging the ruler is less so. The wording "try clicking or dragging" is not the best fit here, since clicking doesn't do anything for both tools. So "try dragging, not just clicking" seems more appropriate.

If I were to suggest a solution, just modify the tool icons by adding arrows in the direction you are expecting the drag. Also, if the dragging for the ruler isn't made for the upcoming option to measure out strength of each individual blow, then it's kinda... pointless? Drag mechanics can be replaced with a simple click for the ruler.

Spoiler: also, unrelated

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

 

[niconob92]

So far, so good.

There isn't too much content yet, but that's only to be expected given the fact that the game's development has just started. Hope to see more of it soon, looks very promising!

Personally, I found this unhelpful. Dragging up the skirt is intuitive (drag upwards, DUH), but dragging the ruler is less so. The wording "try clicking or dragging" is not the best fit here, since clicking doesn't do anything for both tools. So "try dragging, not just clicking" seems more appropriate.

If I were to suggest a solution, just modify the tool icons by adding arrows in the direction you are expecting the drag. Also, if the dragging for the ruler isn't made for the upcoming option to measure out strength of each individual blow, then it's kinda... pointless? Drag mechanics can be replaced with a simple click for the ruler.

I kinda like the fact that you have to drag your mouse to spank her with the ruller, it feels a bit more interactive than just clicking. I will admit that I had some trouble figuring out at first as well, but if the icon were to be modified as you said (or at least made it so that the first event has an arrow pointing out how to do it, like a forced tutorialor something) it could solve this easily.

 

[MarshmallowCasserole]

I kinda like the fact that you have to drag your mouse to spank her with the ruller, it feels a bit more interactive than just clicking.

I like the feeling too* but I'm always irritated when the UI/UX is misleading. It feels like it should be interactive, but it's not right now. Someone already mentioned billiard and golf games, and that's perfect analogy, because there you can vary strength of your hits and it matters. If similar mechanics are planned here, splendid, I'm all for it. If the dragging is purely decorative then I'm not so enthusiastic about it.

* well, except for the lack of smoothness and a couple of bugs. I could expand if the dev wants feedback.

 

[niconob92]

I wouldn't say no to adjusting power, that would actually make it a whole lot better to be honest.

 

[Euphemismus]

Oh! What an excellent time to start discussing how the ruler tool works! I can show you the changes I've made since last week and if you like, you can give me feedback on whether they seem better or not.

One of the important inspirations for the game were ye old adult flash games which we're big on interactivity and general touch-the-paperdoll-ness rather than pick-an-animation-from-the-dropdown-menu-ness. An element of these games was a sense of discovery about what exactly you can do and what tools can be used where.

That effect sort of needs both an amount of tools that exceeds the current two, and also that the interactions are fairly intuitive even without a help screen. The first of these will come with time, but I have clearly underestimated the difficulty of the second.

The current changes are not massive - when clicking or holding the mouse, the ruler moves just a little bit (I spoilered the explanation so that you might form an opinion before I give mine):

Spoiler

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

I also had a little bit of text pop up that said "not enough power" if the ruler is not pulled back enough - that was taken out because I kind of hated it and now I'm trying to find the sweet spot between "the player is having trouble discovering things" and "the player is being condescended to".

It is clear that the intuitive-ness of tools is something that could really use playtesting. If the Discord ever becomes more active in the future, I might put crappy early WIP versions there for any testing volunteers.


Oh! And on the subject of adjusting power - the image for an additional level of power already exists in the game files, it's just waiting for the moment when I need to use it.

 

[Euphemismus]

One of the important inspirations for the game were ye old adult flash games which we're big on interactivity and general touch-the-paperdoll-ness rather than pick-an-animation-from-the-dropdown-menu-ness. An element of these games was a sense of discovery about what exactly you can do and what tools can be used where.

I should mention that to achieve this properly, the spank scene (which is also the template for any other interactive h-scenes) is basically built as a small completely separate game in python+pygame, which then runs inside of Ren'py.

So I entirely understand that this kind of thing is not everyone's cup of tea, and that's cool, but this is already firmly set as a pillar of gameplay in Princess Tower. I just gotta, y'know... do it well enough that even people whose cup of tea this usually isn't can get a kick out of this particular game.

 

[Euphemismus]

* well, except for the lack of smoothness and a couple of bugs. I could expand if the dev wants feedback.

Oh I absolutely do. What do you mean by "smoothness"? How the game runs?

 

[voyeurkind]

Oh! What an excellent time to start discussing how the ruler tool works! I can show you the changes I've made since last week and if you like, you can give me feedback on whether they seem better or not.

One of the important inspirations for the game were ye old adult flash games which we're big on interactivity and general touch-the-paperdoll-ness rather than pick-an-animation-from-the-dropdown-menu-ness. An element of these games was a sense of discovery about what exactly you can do and what tools can be used where.

That effect sort of needs both an amount of tools that exceeds the current two, and also that the interactions are fairly intuitive even without a help screen. The first of these will come with time, but I have clearly underestimated the difficulty of the second.

The current changes are not massive - when clicking or holding the mouse, the ruler moves just a little bit (I spoilered the explanation so that you might form an opinion before I give mine):
View attachment 826912 View attachment 826913

Spoiler

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

I also had a little bit of text pop up that said "not enough power" if the ruler is not pulled back enough - that was taken out because I kind of hated it and now I'm trying to find the sweet spot between "the player is having trouble discovering things" and "the player is being condescended to".

It is clear that the intuitive-ness of tools is something that could really use playtesting. If the Discord ever becomes more active in the future, I might put crappy early WIP versions there for any testing volunteers.


Oh! And on the subject of adjusting power - the image for an additional level of power already exists in the game files, it's just waiting for the moment when I need to use it.

I understand where you're coming from, but...

A hand and a ruler are two very different things. To an adult pervert, using your hand to lift a hapless maiden's skirt makes all the sense in the world, and if you were using that same hand to deliver the spanking all would be well. However, not everyone is so conversant with using a ruler as an impact toy, and even for those of us who are, one expects a simple mouse click to do the job.

I think you'd be better off--and give a better experience--to have a simple screen or pop-up that reads "click and drag to use tools". From my personal experience developing software applications, it's best to assume your user base are a group of utter and complete idiots who've never seen anything like what you're presenting to them.

 

[MarshmallowCasserole]

Oh I absolutely do. What do you mean by "smoothness"? How the game runs?

Right, I see where the inspiration for the minigame comes from. So, that's the issue, flash games (at least good ones) used vector graphics which have the benefit of having more, as you call them, rulerstates than 4. Like, way more. To use an analogy, you want a gas pedal and right now you have a transmission stick. I've mucked about with your sprites, and at 10 states it starts to feel okay-ish. So, 20 should be good (needless to say I had to make it a bit more procedural, and so I broke your stuff. Ooops. But enums, really?). Oh, and your distance_power increment is 2 times bigger than it's appropriate, at least on my system. Should be 50, 100, 150 so the drag distance roughly matches the ruler sprite. Thankfully the ruler sprite is easy to modify to generate enough frames.

 

[waffel]

Right, I see where the inspiration for the minigame comes from. So, that's the issue, flash games (at least good ones) used vector graphics which have the benefit of having more, as you call them, rulerstates than 4. Like, way more. To use an analogy, you want a gas pedal and right now you have a transmission stick. I've mucked about with your sprites, and at 10 states it starts to feel okay-ish. So, 20 should be good (needless to say I had to make it a bit more procedural, and so I broke your stuff. Ooops. But enums, really?). Oh, and your distance_power increment is 2 times bigger than it's appropriate, at least on my system. Should be 50, 100, 150 so the drag distance roughly matches the ruler sprite. Thankfully the ruler sprite is easy to modify to generate enough frames.

Programming games as they ought to be programmed is an uphill battle in Python >.<

 

[Euphemismus]

Right, I see where the inspiration for the minigame comes from. So, that's the issue, flash games (at least good ones) used vector graphics which have the benefit of having more, as you call them, rulerstates than 4. Like, way more. To use an analogy, you want a gas pedal and right now you have a transmission stick. I've mucked about with your sprites, and at 10 states it starts to feel okay-ish. So, 20 should be good (needless to say I had to make it a bit more procedural, and so I broke your stuff. Ooops. But enums, really?). Oh, and your distance_power increment is 2 times bigger than it's appropriate, at least on my system. Should be 50, 100, 150 so the drag distance roughly matches the ruler sprite. Thankfully the ruler sprite is easy to modify to generate enough frames.

Oh, the ruler mouse movement were never intended to match the ruler sprite, nor was the plan to ever have actual proper animations in the game - I'd rather make room in the time budget for more writing and drawing (also I think that if I tried to build a flash-like tweening animation system into Renpy I would hang myself at around day 5). It is what it is. ¯\_(ツ)_/¯

I understand where you're coming from, but...

A hand and a ruler are two very different things. To an adult pervert, using your hand to lift a hapless maiden's skirt makes all the sense in the world, and if you were using that same hand to deliver the spanking all would be well. However, not everyone is so conversant with using a ruler as an impact toy, and even for those of us who are, one expects a simple mouse click to do the job.

I think you'd be better off--and give a better experience--to have a simple screen or pop-up that reads "click and drag to use tools". From my personal experience developing software applications, it's best to assume your user base are a group of utter and complete idiots who've never seen anything like what you're presenting to them.

"click and drag to use tools" as a popup has been on the table but I've been teetering between "what if I include tools that don't behave like that" and the "You ain't gonna need it"-principle. Gonna file your suggestion as a vote for "You ain't gonna need it.", thanks. Though I have to disagree on another point - while most might not know the term "impact toy", I'd argue that using a ruler for spanking is a fairly common non-fetish thing as well as a fetish thing.

Also - "To an adult pervert, using your hand to lift a hapless maiden's skirt makes all the sense in the world" is a fantastic sentence

Programming games as they ought to be programmed is an uphill battle in Python >.<

Definitely. Though I would say that using Ren'py for it's intended use case (mostly a VN with some interactable menus), it's pretty great and I would recommend it. I just had to make life a lot more difficult for myself.

 

[Euphemismus]

Version 0.3 is out!

Downloads at:

You must be registered to see the links

and Mega (

You must be registered to see the links

/

You must be registered to see the links

)
Changelog:

Comments:
- This update is all mechanical with no new story! Just as planned (and described in the little scene at the end of last update) this update adds hooks for adding new story content in the next update. in v.0.3, however, means that all of progression systems added this update don't actually have anywhere to progress - I even removed the few new lines of story I had because it would be kind of a massive cocktease to have, like, 4 new lines of dialogue in this update.
- And there's plenty I'm not exactly... happy with, regarding the look and the user experience of some of the fragments-related stuff. They're going to need another pass at some point in the future.

Content:
New:
- implemented fragments - these will be the primary methods of player progression
- quests exist now! Check them to see what your current objective is.
- Added exciting new bugs!

Changes:
- h-scenes are now ended by pressing a button, rather than automatically
- new tooltips: rewrote how they work so I CAN PUT THEM EVERYWHERE
- Some of the existing story content now makes use of quests and the new progression model and stuff

Bugfixes:
- fixed bug where occasionally in the spank scene, animated notifications would get stuck
- meddling with Renpy transitions (they're tricksy)

Internal/Back-end:
- moved a bunch of initialization stuff from raw python to renpy script, as a step towards inter-version save compatibility
- some minor changes to how stats and changes to stats are called in the .rpy script files and how they are displayed to the player
- punishment and arousal bars now have a max value that can be changed, this will be important for progression in the future

 

[Hey you there boy]

View attachment 836659

Version 0.3 is out!

Downloads at:

You must be registered to see the links

and Mega (Win/Linux / Mac)
Changelog:

Comments:
- This update is all mechanical with no new story! Just as planned (and described in the little scene at the end of last update) this update adds hooks for adding new story content in the next update. in v.0.3, however, means that all of progression systems added this update don't actually have anywhere to progress - I even removed the few new lines of story I had because it would be kind of a massive cocktease to have, like, 4 new lines of dialogue in this update.
- And there's plenty I'm not exactly... happy with, regarding the look and the user experience of some of the fragments-related stuff. They're going to need another pass at some point in the future.

Content:
New:
- implemented fragments - these will be the primary methods of player progression
- quests exist now! Check them to see what your current objective is.
- Added exciting new bugs!

Changes:
- h-scenes are now ended by pressing a button, rather than automatically
- new tooltips: rewrote how they work so I CAN PUT THEM EVERYWHERE
- Some of the existing story content now makes use of quests and the new progression model and stuff

Bugfixes:
- fixed bug where occasionally in the spank scene, animated notifications would get stuck
- meddling with Renpy transitions (they're tricksy)

Internal/Back-end:
- moved a bunch of initialization stuff from raw python to renpy script, as a step towards inter-version save compatibility
- some minor changes to how stats and changes to stats are called in the .rpy script files and how they are displayed to the player
- punishment and arousal bars now have a max value that can be changed, this will be important for progression in the future

Gonna check out those exiting new bugs right now!

 

[Ipigskickass]

snip

poggers

 

[Kellan]

That neck looks massive..

 

[IdarksoulsI]

Could be interesting. Following.

 

[1zaza1]

Very promising start. Checks a lot of boxes for me and the writing is funny too.

 

[The Doctor (not a doctor)]

Good fucking christ you absolutely nailed the trainer-game premise and vibe.

Enormous potential was this one, and it hits certain notes that really appeal to the genre, Ari's design is well thought out clearly.
You got me on board bro, keep up the good work!

 

[agregen]

Programming games as they ought to be programmed is an uphill battle in Python >.<

You're kinda suggesting there's exactly one correct way of writing code – and that is simply not true. There's multiple approaches, and those used in something like C# for projects with a large developing staff are decidedly less fit to a single-dev project written in a dynamic language than a number of others.

Incidentally, I can't think of a single reason why having more than four visible states would require vector graphics at all; in fact, I happen to have needed to implement a vertical percentage bar of sorts in a RenPy game at one point, and that particular part was achieved quite easily using a single Crop displayable within the screen definition. You just need to, yanno, have that stuff in your logic. (And if what they were talking about was transition animation, I believe that kinda thing is just as easily available in the form of transforms… though I can't recall if I ever tried to use it specifically to animate crop resize, I don't think I ever had a use for it.)

 

[waffel]

You're kinda suggesting there's exactly one correct way of writing code – and that is simply not true. There's multiple approaches, and those used in something like C# for projects with a large developing staff are decidedly less fit to a single-dev project written in a dynamic language than a number of others.

Incidentally, I can't think of a single reason why having more than four visible states would require vector graphics at all; in fact, I happen to have needed to implement a vertical percentage bar of sorts in a RenPy game at one point, and that particular part was achieved quite easily using a single Crop displayable within the screen definition. You just need to, yanno, have that stuff in your logic. (And if what they were talking about was transition animation, I believe that kinda thing is just as easily available in the form of transforms… though I can't recall if I ever tried to use it specifically to animate crop resize, I don't think I ever had a use for it.)

What I mean is games are ought to be programmed procedurally in a data oriented programming manner, so you are able to optimize for the CPU cache flow when you need to do so. Python is locked very tightly to OOP which greatly reduces the amount performance you are able to squish out of it, because it's polluting not only the data cache, but also the instruction cache. A game like Lab Rats 2 is a shining example of this, there's nothing in that game that couldn't be handled by one CPU core with a maximum frame latency of 20ms, but he's throwing cores at the problem and we still see frame latencies well above 300ms, often several seconds which are equivalent to eons in CPU time. The reason is that he is not allowed to program in a way that minimizes cache misses, and that is very important in game programming. It's irrelevant for VNs, but very important for real actual games. C# has the option to program this way, but just makes it very tedious for you to do so, python not so much. Dynamic languages doesn't make it easier to program games, they just make it a lot harder to squish out the performance you need when you need it.