Tips for Preventing Laggy/Slow Game?

[malakme]

So I'm new to Ren'py and game development as a whole, but I want my first project to be a relatively big one (my estimate is something like 25,000+ lines of code right now). I've heard about people having issues with larger games slowing down, so I figured I'd be proactive and ask if there's anything I can do or learn how to do to prevent that.

Like are there any coding organizational techniques I should know to help save space? Should I be using as few PNGs as possible (I've heard they take up space)? Any tips you've gathered from your own experience will help. Thanks!

[nature1996]

Generally speaking, trying not to do a 10009 thing at the same time is a good idea. Try to do them when needed. for size, trying to combine scene that are the same but in different path is a good idea I guess (also help with typo), either by using call/return rather than jump, or by having a variable keeping track of the path you are on.

But other than that, I don't think there is much more you can do as a writer, as I think this might be a problem native to python. Make sure to make new scene from time to time, and not just pile thing, be careful when using music, especially the format (same for the picture).

I'm not that knowledgeable on the subject, but I hope that these bit and pieces can help a bit.

[LateWhiteRabbit]

Most games made with newer versions of Ren'py don't actually "slow down" or "get laggy" - they only SEEM to do that, because of image or screen responsive-ness. (For lack of a better term.) Ren'py tries to run at the least demanding framerate possible depending on the situation, and generally does a pretty good job of this.

nature1996 is correct in that you don't want tons of code running simultaneously, but to make a Ren'py game SEEM fast and responsive, you need to master and be smart with Image Prediction. Rather than leave it entirely up to Ren'py to figure out what images are coming up that it needs to load into memory, you can give it a game plan to make sure things go smoothly. Basically, any screens or graphic elements that a player can call up or show at ANY TIME, need to always be 'predicted'.

This will make a big difference in how good the game feels and make things less 'laggy'.

[malakme]

Generally speaking, trying not to do a 10009 thing at the same time is a good idea. Try to do them when needed. for size, trying to combine scene that are the same but in different path is a good idea I guess (also help with typo), either by using call/return rather than jump, or by having a variable keeping track of the path you are on.

But other than that, I don't think there is much more you can do as a writer, as I think this might be a problem native to python. Make sure to make new scene from time to time, and not just pile thing, be careful when using music, especially the format (same for the picture).

I'm not that knowledgeable on the subject, but I hope that these bit and pieces can help a bit.

Ah I'm sorry for the late response, but thanks for your help! This is great advice. I'm wondering though, what do you mean by be careful with music formats?

[malakme]

Most games made with newer versions of Ren'py don't actually "slow down" or "get laggy" - they only SEEM to do that, because of image or screen responsive-ness. (For lack of a better term.) Ren'py tries to run at the least demanding framerate possible depending on the situation, and generally does a pretty good job of this.

nature1996 is correct in that you don't want tons of code running simultaneously, but to make a Ren'py game SEEM fast and responsive, you need to master and be smart with Image Prediction. Rather than leave it entirely up to Ren'py to figure out what images are coming up that it needs to load into memory, you can give it a game plan to make sure things go smoothly. Basically, any screens or graphic elements that a player can call up or show at ANY TIME, need to always be 'predicted'.

This will make a big difference in how good the game feels and make things less 'laggy'.

Thanks for your advice Rabbit, and I'm sorry for the late response! That makes a lot of sense. I've read through the link you shared and I'm still not exactly sure where predicting images should be inputted. In the area before "label start" on the script.rpy or in another file? Also would you recommend predicting everything all at he same time for a game that's roughly 25,000 lines of code?

[LateWhiteRabbit]

Thanks for your advice Rabbit, and I'm sorry for the late response! That makes a lot of sense. I've read through the link you shared and I'm still not exactly sure where predicting images should be inputted. In the area before "label start" on the script.rpy or in another file? Also would you recommend predicting everything all at he same time for a game that's roughly 25,000 lines of code?

I would NOT predict everything at the same time. That is bad if someone is trying to play your game on mobile, and Ren'Py can only use a certain amount of RAM, even on desktops. (And has a limited memory cache, as is mentioned in the article I linked.)The only elements I would recommend keeping predicted at all times are things like menus or UI elements that can be called up or interacted with at any time by the player. (Maps, inventories, character screens, etc.)

For all the rest of it you just want to tell Ren'Py to predict your images before they are needed, and then unpredict them when you know they won't come up again for a while. It is really that simple. For instance, say in your story one scene takes place at your main character's house, and the next scene always takes place at school. During the scene in the character's house, you can tell Ren'Py to start predicting all the school assets, then when your scene transitions to the school there won't be any pauses, delays or hitches, since you basically just told Ren'Py to "load" all that art in the background of the last scene.