Your saying because an oval (programming language) can be constrained into a circle (scripting language). Circles are therefore Ovals. This logic is flawed! We would not have defined circles differently and call circles circles, which are not a type of oval, if circles were ovals. The limitations of a scripting language are a defining characteristic of scripting languages. A program interpreting a script and converting it into its own language then compiling it, does not make it any less script. Even after translation and compiling it would still reflect all the limitations of the scripting language to start with.
Yes they are all languages that can be translated between, but the defining characteristics of the languages is what determines what can be expressed in them, and therefore weather we call them a scripting language or a programming language. To say there all one is misrepresenting some/all of them, which only leads to confusion about eachs properties and characteristics. Which is why renpy script, is not python, nor can be treated as such. It is based on/similar to so we can draw parallels and inference, but to say one is the other is not a good idea.
This doesn’t apply, what determines where you go in the program is not call or jump(the vehicals) but rather the preceding logic(the driver), and while call has a predetermined context return point(auto pilot back to where it started), jump does not, but this characteristic of jump in no way means it cannot be use in a cyclic nature or mean you cannot create the similar flow patterns. Under the assumption the creator of the game has the same good understanding of how each works, there is no reason the preceding logic determining where the story goes that the player then gives the inputs to that result in the individualized out come cannot use jump instead of call to get to that part of the script(story). Jump only adds the flexibility to go anywhere at the end(up to the writer to again write out that preceding logic) rather than only back to where you were. Will the overall architecture of the game be slightly different for each? Yes, because each can do something the other can’t. However they both at their base switch context of where you are in the script. The preceding logic written determine if is cyclical or not not call or jump.
The school uniform is merely anime fluff for those who like the aesthetic, the planned main character is a college student and of-age, the uniform is just there to try on for weebs and to lament being fatter since graduating. No underage characters will make any appearances.
I desperately wanted to learn to make call/return formula lol. I have struggled HARD to figure out loops, so if you can explain loops basic structure to me I will be indebted. That’s been my failed goal so far.
Admittedly, I dislike the kidnap and pre-arranged dates in other life sim games, no offense to the devs that do those. I want MOST things to be player choice, with story events cropping up primarily through time passing and weight gain stages.
Thank you, I WILL be stealing this code.
I am quite dumb, so I understood about 50% of the code and 50% of what you said after it, so I will probably ask you for help multiple times. Also, apologies for not directly responding to you until now about this post - this thread has grown wildly large very quickly, which I appreciate! Its nice to get so much help and nice to have a big thread for people trying to learn renpy!
So, I have a custom map screen I was planning to use to let the player decide what to do, rather than a typically ren’py script menu.
I cannot think of any good way to use call and return though with this. I can have a place in the script with some sort of infinite loop that does nothing. Then the map buttons can jump to location based sections of the script, then jump back to some sort of time advance and garbage collection script section then jump to the infinite loop style holding pattern again to wait for the player to browse their custom menus…
But is there a way to do what I’ve just described using call and return instead?
It may take some reorganization of your script as to whats in each label however all of your labels for the most part would need to be designed to be used with call(mixing call and jump is where you get into trouble, while it is safe to call out of a jumped to label its not safe to jump out of a called label). You would then use the call screen action to call one of your main actions labels. I would also add you can have multiple screen actions for a screen element, by putting them in a list, so you can hide your map and call the action with one button and click
label infinitloop:
while True:
show screen screenmap #some one clicking on it would either call action1 or action2
label action1:
#doing stuff
call subaction2
#doing morediffernt things
call subaction3
#finsihing up
call cleanup
call timeadvace
return
label actoin2:
#doing stuff
call subaction
#doing morediffernt things
call subaction2
#finsihing up
call cleanup
call timeadvace
return
label subaction:
#doing things not specific to an main action
return
label subaction2:
#doing things not specific to an main action
return
label subaction3:
#doing things not specific to an main action
return
label cleanup:
#doing things to cleanup
return
label timeadvance:
#doing things to advace the time
return
I would end with unless you have a problem your trying to solve that needs call its not worth the effort to change how you context switch, unless you expect to need call.
The custom menus are already coded and the buttons trigger 3or4 actions because they have to do things like show the close menu button or swap between the map and stats screen, etc.
All the custom menus use no jump’s and just use calls. But I am considering making them use jumps instead of calls because it might make the base script simpler. Although your example seems to make sense, too.
The while True: Wouldn’t need anything inside it though as there’s a menu overlay custom screen with all the buttons to navigate to places like the map. The custom map also blocks the main script with modal True.
I cannot seem to upload gifs to the forum, but I can get embedded deviantart gifs to play.
This is the early prototype on how the menu would look/work, the map already has some prototypes for how mouse hover would highlight/etc. Not shown here because I was trying to get the gif to be a small enough size to forum embed.
I haven’t had time to reply in detail, but in short - yes you can.
Is this a separate question, or are you both working on the same game?
There’s a logical problem with giving the player access to a map/navigation screen at any point they choose from a menu bar. During an interaction with an NPC if it’s not playing out how they like they could pick the map and just GTF somewhere else, so to make sure that doesn’t happen a lot of the time you are going to have to have the map disabled/inactive. While you could work around this by having a global map enabled flag, it’s honestly going to be easier to make the map a callable screen when the script reaches the appropriate points.
There’s another, deeper, problem too. Displayed screens (such as your typical stat screen) run off the underlying event dispatch system and are quasi-asynchronous. Called screens (of which menu and say are types) run off the scripted steps, and effectively “block” until the event dispatch sends them an appropriate interaction making them appear synchronous. It’s complicated, but running story script off events can get things tied in knots.
My project is 100% unrelated to this thread and to muffintopmanor1’s game. I just thought of a question based on zdeerzzz’s comments.
There’s already a global flag for the map button I named freedom. The custom menus like the map are callable screens. It seemed like it would be okay to allow the player to view the stats screen during an event, but the map screen is blocked. Although rather than blocking the map screen, I could also just force shut the overlay. The buttons on the overlay only function when it is visible, if it is shut then clicking those regions doesn’t work.
I was thinking the game flow would be similar to thicker treat. But I actually didn’t copy the code from thicker treat I wrote it, quite possibly ineptly, myself.
Although come to think of it, thicker treat, wholehog, weightinggame, etc, all have a weird nebulous phase in the script where they wait for the player to use a custom interface to choose what to do. Rather than using the normal default menu. I guess I liked that feature. Tramps by comparison though always uses the renpy menu system, which I didn’t find as engaging. But I can see how it would prevent a myriad of potential bugs/pitfalls a custom screen can cause. I brought this up here I guess, because well, I’d like custom menu navigation. I’ve coded the custom menus, but I’m worried about those unforseen pitfalls in my future.
Really though, making the map something that the script calls, rather than being something the player has free access to would be fine, it wouldn’t really change much. At least it wouldn’t change the code for the map screen itself much, it would of course change the code for the script a lot.
#
# Navigation.
# E&OE.
#
# Allow PC to choose a new location.
#
label navigate:
# Default to staying put.
#
$ newLoc = pcLoc
# If self voicing use spoken navigation menu,
# otherwise use navigation screen.
# Both just change newLoc.
#
if _preferences.self_voicing:
call .navMenu
else
call screen navScr
# Did they pick somewhere new?
#
if newLoc != pcLoc:
# Describe how they get from pcLoc to newLoc.
# ...
# Put the PC at the new location.
$ pcLoc = newLoc
return
# Present a list of places to go.
#
label .navMenu:
menu:
"{alt}Menu. {/alt}Where should I go?"
"Beach" if pcLoc != 'beach':
$ newLoc = 'beach'
"Gym" if pcLoc != 'gym':
$ newLoc = 'gym'
"Home" if pcLoc != 'home':
$ newLoc = 'home'
"Pub" if pcLoc != 'pub':
$ newLoc = 'pub'
"Stay here":
pass
return
# Ugly AF navigation screen.
# Replace with pretty map with markers and mouseover hot spots and put
# in its own rpy file.
#
screen navScr:
vbox:
button:
text "Beach"
action SetVariable('newLoc', 'beach')
button:
text "Gym"
action SetVariable('newLoc', 'gym')
button:
text "Home"
action SetVariable('newLoc', 'home')
button:
text "Pub"
action SetVariable('newLoc', 'pub')
It has both a traditional RenPy menu and a custom screen that do exactly the same thing. Obviously you get to make the custom screen as fancy as you like (I haven’t to keep the example short). If self-voicing is on then it uses the menu style as it is accessible, but otherwise uses the fancy screen.
And a way to trigger it from a very rough player home:
#
# The player characters's home.
# E&OE.
#
label home:
# Allow the player to choose what to do next in their home.
#
label .choice:
menu:
"What shall I do at home?"
"Bathroom":
pass # Shower?
"Bedroom":
pass # Sleep?
"Kitchen":
pass # Food?
"Outside":
call .leaveHome
return
# Leave home and go elsewhere.
#
label .leaveHome:
"You put on your shoes and head outside."
call navigate
return
By changing the pcLoc and returning to the main loop it will now call the new location’s .choice label - effectively moving the PC there.
From experience with other GUI systems where there’s multithreading I must admit I get cautious about relying on inactive buttons to prevent users interacting with things when event/update race conditions are possible. I’m pretty sure this can’t happen in RenPy (locking up the “working” thread always seems to kill the event handling - but I don’t know for sure) but I’d be double checking that freedom flag in the map screen itself.
Don’t get me wrong - I like those custom map-like menus too. Tramp hasn’t had any kind of “prettification” pass at all! Some things are in-place - like the custom choice screen for the menu (as in food menu, not renpy menu). I’ve some ideas around the navigation I’d like to try, but it’s all secondary to the story stuff at the moment. But the experimentation I have done has shown that non-called screens (ie. running off event-dispatch system) with side-effects are problematic. The docs aren’t messing about when they state Screens must not cause side effects that are visible from outside the screen. Wierd stuff can happen.
