PyTFall > PyTFall: Bugs and Game balancing

Code review

<< < (6/8) > >>

Xela:

--- Quote from: rudistoned on June 28, 2013, 08:17:59 AM ---What I meant to convey with my advise is that we should package GUI code up in classes and functions, so we don't overwrite global variables with variables that look "local", when in fact they are in the global namespace. Putting GUI code in game logic classes (anything else than GUI code) is quite the opposite of what I want  ;)

--- End quote ---

One of the things I like about RenPy is screen language and how it's setup. I figured you were in favor of cleaning screens up, not recoding them in pure Python.

rudistoned:
I am in favour of cleaning the current screens up and I'm probably also in favour of using renpys screen language.


Is there any way to package screen language code into a separate namespace? Something like a subscreen or custom widget?



What I don't like is code that does something for screens in classes that contain game logic. Rule of thumb: if the class is in any of our current "classes - *.rpy" files, it should not contain GUI code. GUI code should IMHO be in the label that shows the screen, or in separate classes and functions.

Xela:

--- Quote from: rudistoned on June 28, 2013, 10:31:03 AM ---I am in favour of cleaning the current screens up and I'm probably also in favour of using renpys screen language.

Is there any way to package screen language code into a separate namespace? Something like a subscreen or custom widget?

--- End quote ---

One or the other, you can't have both, would be to convenient.


--- Quote from: rudistoned on June 28, 2013, 10:31:03 AM ---What I don't like is code that does something for screens in classes that contain game logic. Rule of thumb: if the class is in any of our current "classes - *.rpy" files, it should not contain GUI code. GUI code should IMHO be in the label that shows the screen, or in separate classes and functions.

--- End quote ---

I honestly have no problem with it.

rudistoned:

--- Code: ---            # Should not be called (ever)
            else:
                txt += "Brothel is reasonably clean and there are no clients left to serve! "

--- End code ---

This is a snippet from ServiceJob.set_task.

If the else condition should only be reached when something went wrong, why does it output ingame text instead of logging an error message?

Xela:

--- Quote from: rudistoned on June 30, 2013, 02:57:42 AM ---If the else condition should only be reached when something went wrong, why does it output ingame text instead of logging an error message?

--- End quote ---

Because it still works, but feel free to remove it completely or turn it into an Error. Things like that are in many places in the code, especially in part that I've programmed close to when the project was started (Not having any previous coding experience of any serious kind).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version