What are you even comparing, this isnt software development.
Definitionally, it is. Ren'Py is gussied-up Python.
Debugging in here is simply running the game and watching if each new scene is what is supposed to be and toy around with events to see if there are incompatibilities, which you can debug by simply editing the code and force to changing vairables that shouldnt be more that simple boolean logic.
That is not a well-formed statement. "Supposed to be" is vague, "incompatibilities" is hand-waving, and as for "simple boolean logic", I think you're confusing implementation details for the reality of state. It doesn't matter if you have a branch or a flag -- the impact on complexity remains. Some of the most absurd bugs I've seen have emerged from spurious gobs of boolean logic.
After the opening of the game each character quite literally works in a vacuum only interacting with one or two other main plot characters that need to be in specific places.
That's a slightly better argument. You still need to take into account all extant details that may impact the interaction, though. And the more room there is in a project -- the simpler it is -- the more these details tend to accrete. Why not? Adding them is
so simple.
Look, I understand why you feel this way. But what you're saying is an exaggerated version of what I've literally thought for every project I've been introduced to: "this time it's different. I understand the complexity here, the choices and workflow are obviously deliberately constrained. There's abstraction here that will mitigate most bugs. This time will be better."
It's never turned out that way, even in well-managed projects. I don't know why that's true, I just know that a greenfield (i.e. tightly managed) project attracts complexity the way flies are attracted to shit. If Ren'Py had been constricted, that would have been one thing. But Ren'Py is Python. It's a general purpose computing language, so the surface area for complexity is arbitrarily large.
I recall at one place of work, where we had FORTRAN code from the 1970s driving it. So we're talking heavily optimized toward numeric solutions; it was reasonably quick on systems from 1990. Today, of course, that means near-instant.
So one of the engineers decided that hey, we should add some handy extra functionality, you know, since it would be useful. He implemented that.
And sure, using that functionality would then change some of the numbers, so you had to have checks for that in the forms.
I no longer work there, but last I checked, a simple OnLostFocus in that dialog caused it to grey out for several seconds while the cascading update calls were doing their thing.
It's ridiculous, but it happens. It happens all the time.
And yet again you have here a barrage of VNs who upscale the complexity by a whole lot compared to WaL and dont take even close to the same amount of time to debug.
I think you're attacking the wrong thing, here.
The typical thing we see when Ren'Py authors begin something is that they're, well, beginners. There's little sense in assuming that a foundation written by beginners will have the restraint to support later development in a graceful fashion. We cannot assume a new developer will create a sensible, future-proof architecture. They wouldn't know how.
I'm happy you chose to nuance your statements above. I still think you're confusing what you think something should be with what it is on the ground, and using that to needlessly assume malice or incompetence.
