Lemma Soft Forums

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 ^-^

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).

Yes, my coding practices are as follows:

1) Copy
2) Paste

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...

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.

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.
(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.

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.

That's what source control is for. :P

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.

BCS wrote:Yes, my coding practices are as follows:

1) Copy
2) Paste

Some people actually recommend that in order to
minimize typo errors =)

However, there is an obvious disadvantage when
using that.

(4) I guess what you're trying to say is to have "templates"
for blocks of Renpy codes

Haeleth wrote:

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.

That's what source control is for.

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.

Oh that's a good one =) however I have no idea on how to implement
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.

monele 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.

Thanks I'll try to do that =) Hmm .. I wonder if there a source control
app with a friendly independent UI ^^ Getting used with Eclipse makes
me wish there is =)

Haeleth wrote:

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.

That's what source control is for. :P

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.

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.

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.

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.