Coding Best Practices
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
Coding Best Practices
Hello =) (It's been a while since I last visited Lemma Forums)
I'd like to ask the coders/developers here for some advices/tips
on how you make your codes; some programming patterns you
adhere to that you find effective and time saving =)
I don't have much pretty experience on Renpy. But I can imagine
applying the best practices of other programming languages.
For starters we might (1) create a dedicated *.rpy files for
initialization, (2) seperate the codes according to chapters/scenarios,
(3) having a variable naming standard (applying prefixes), etc.
So what do you think =)? Any comment would be greatly appreciated ^-^
I'd like to ask the coders/developers here for some advices/tips
on how you make your codes; some programming patterns you
adhere to that you find effective and time saving =)
I don't have much pretty experience on Renpy. But I can imagine
applying the best practices of other programming languages.
For starters we might (1) create a dedicated *.rpy files for
initialization, (2) seperate the codes according to chapters/scenarios,
(3) having a variable naming standard (applying prefixes), etc.
So what do you think =)? Any comment would be greatly appreciated ^-^
One thing I've done in my last project is separating the starting scenes from the configuration. The same concept seems to be included in the upcoming version of Ren'Py.
Then, it all depends on your game. You could have a script file per location... or per character... or per chapter... etc... A kinetic novel would probably use the chapter idea, while dating sims would use the character idea.
I also create separated script files for any additional coding (new move functions and stuff).
Then, it all depends on your game. You could have a script file per location... or per character... or per chapter... etc... A kinetic novel would probably use the chapter idea, while dating sims would use the character idea.
I also create separated script files for any additional coding (new move functions and stuff).
-
- Eileen-Class Veteran
- Posts: 1314
- Joined: Mon Sep 19, 2005 2:15 am
- Completed: Controlled Chaos / Sum of the Parts / "that" Midna game with ZONEsama
- Projects: Sparse Series/Oddments Shop original cartoon in Pevrea; Cybernetic Duels (fighting game); Good Vibin'
- Organization: Watercolorheart Studios
- IRC Nick: BCS
- Tumblr: adminwatercolor
- Deviantart: itsmywatercolorheart
- Github: Watercolordevdev
- Skype: heartnotes
- Soundcloud: Watercollider
- itch: watercolorheart
- Location: Florida
- Contact:
Commercial games tend to split things up quite a lot. A typical RealLive game, for example, will have separate script files for each menu screen, and then separate scripts for each logical section of the story (each chapter, or each day). If there are multiple routes that can be taken, then these will generally be mixed together at first, and start being given separate files as they diverge.
Of course, other games go the other way. Classic NScripter games may have an entire massive story crammed into a single file...
Of course, other games go the other way. Classic NScripter games may have an entire massive story crammed into a single file...
-
- Miko-Class Veteran
- Posts: 576
- Joined: Fri May 07, 2004 9:40 am
- Completed: GO! Magical Boy (2006), Angelic Orbs (soundtrack)
- Projects: Cyberlin (in progress)
- Location: Finland
- Contact:
Re: Coding Best Practices
Yes, (1) and (2) is what I do. One file for the config, and one each for every chapter. The biggest advantage is that if you mess up and make an error, it's much easier to track down.yuirei wrote:(1) create a dedicated *.rpy files for initialization, (2) seperate the codes according to chapters/scenarios, (3) having a variable naming standard (applying prefixes), etc.
(3) makes sense, and should also apply to label sections. Usually I number them and use increments of 10 (e.g. Monday0010, Monday0020...)so that it's easier to add new ones in-between.
Also, I comment a lot so as not to forget things. If I have to make changes to a final version (e.g. an already released VN), I write down exactly what changes were made.
Also in the code itself of each chapter, don't hesitate to take a bit of your time to place comments or short description on the block you are working (along with spaces), because one bit of code you would want to duplicate later is easier to find with the search function.
You can also use #comment to disable a part of code for another one, it is useful if you decide to go back to the previous version.
You can also use #comment to disable a part of code for another one, it is useful if you decide to go back to the previous version.
Re: Coding Best Practices
That's what source control is for. :PAlessio wrote:If I have to make changes to a final version (e.g. an already released VN), I write down exactly what changes were made.
Seriously, that's another coding best practice: use source control. Subversion or whatever. Even if you're the only coder working on a project, it is unutterably valuable to be able to go back at any point and see all the previous versions of your code, so you can check at a glance what changes you've made recently, or even recover an old version if you decide a month later that you shouldn't have changed something.
Re: Coding Best Practices
Oh that's a good one =) however I have no idea on how to implementHaeleth wrote:That's what source control is for.Alessio wrote:If I have to make changes to a final version (e.g. an already released VN), I write down exactly what changes were made.
Seriously, that's another coding best practice: use source control. Subversion or whatever. Even if you're the only coder working on a project, it is unutterably valuable to be able to go back at any point and see all the previous versions of your code, so you can check at a glance what changes you've made recently, or even recover an old version if you decide a month later that you shouldn't have changed something.
a CVS for Renpy (do you have an idea how to do it?) I'm only aware
of using such source control using Eclipse for Java =)
I'll try to research on this one (but any comment regarding this would
be alot faster XD)
Just install Subversion, create a repository on your HD (right click, make repository), then right click in your game directory and do "check out", checking out your (empty) repository which does nothing except link the two together. Then you can just commit and update and compare and whatever else you want by right clicking on the files or the directory.
Thanks I'll try to do that =) Hmm .. I wonder if there a source controlmonele wrote:Just install Subversion, create a repository on your HD (right click, make repository), then right click in your game directory and do "check out", checking out your (empty) repository which does nothing except link the two together. Then you can just commit and update and compare and whatever else you want by right clicking on the files or the directory.
app with a friendly independent UI ^^ Getting used with Eclipse makes
me wish there is =)
-
- Miko-Class Veteran
- Posts: 576
- Joined: Fri May 07, 2004 9:40 am
- Completed: GO! Magical Boy (2006), Angelic Orbs (soundtrack)
- Projects: Cyberlin (in progress)
- Location: Finland
- Contact:
Re: Coding Best Practices
For G!MB I managed by doing source control manually (copying old script/graphics files away instead of overwriting them). Also I have a complete zipped package of every release version. I didn't need more than that for such a small project.Haeleth wrote:That's what source control is for. :PAlessio wrote:If I have to make changes to a final version (e.g. an already released VN), I write down exactly what changes were made.
Nowadays I'm using a Subversion client (TortoiseSVN) for my current project (thanks to PyTom). But one thing source control can't do for you is tell you WHY changes were made. That's why I usually add that info, too.
Re: Coding Best Practices
I'm pretty sure that all the source control software I've used, from Sourcesafe (which is next to worthless outside of solo use) through CVS (difficult to set up) to SVN (still my favourite) has had the option to leave a comment on the check-in of code... my usage pattern on my own projects - where I can get away with it - is to make only one feature change/bugfix at a time, then check those changes in with a comment saying what I did, then move on to the next fix/change.Alessio wrote:Nowadays I'm using a Subversion client (TortoiseSVN) for my current project (thanks to PyTom). But one thing source control can't do for you is tell you WHY changes were made. That's why I usually add that info, too.
Server error: user 'Jake' not found