Ren'Py Abandoned What a Legend! [v0.6.02] [MagicNuts]

[Mordikay]

We found another 69 issues to debug. Progress bar 178/272.

Not a patron but this line could be used at #insert any month for the past year and half year. So answer is legit.

 

[Kisama33]

 

[FreelancerFL]

No they said before november...

Yeah November 2125, At this point Haramase Simulator is gunna get an update before this game does.

 

[Melfior]

It's been 72 years...

 

[arigatogyro]

how can a renpy vn have so many bugs?

 

[Xupuzulla]

how can a renpy vn have so many bugs?

How indeed...really makes one think and wonder

 

[Oriandu]

how can a renpy vn have so many bugs?

Spaghetti code due to incompetence. Y'all are acting like Ren'Py is some magical super program that does all the work for the developers... it doesn't. No engine is that effective and if you're an unskilled programmer you can easily cause a lot of problems.

Now, do I believe that the problems are legitimate and that MagicNuts isn't a pair of grifters? No, alls I'm saying is Ren'Py can have just as many bugs as any game developed for any system. The question you should actually be asking is how does a game as simple as What A Legend! wind up with so many bugs.

 

[nitram5]

how can a renpy vn have so many bugs?

 

[moskyx]

Self-quoting me for the umpteenth time, in case these doubts about what debugging means in this game are genuine:

This is 3 lines of text in a complex scene in WaL:

    show abusmall ewide sangry
    show pov enarrow hfneu2 hbneu2 msmile bangry scrazyhair
    show rose basemessy xwings xhornsnude enarrow bangryn msmile at s_left:
        xalign -0.5 alpha 1
    $ renpy.music.set_volume(0.8, channel='sfx4')
    play sfx4 "audio/magicdemon2.ogg" fadein 0.5
    abu "WHHHHHAAAAAAATTTTTTT?!" with vpunch
    show rose eneu bupn
    show pov hfreach eclosed bup at m_left with moveinleft:
        xalign 0.3 xzoom -1.0
    show pov hfneu2 eneudown
    show abusmall at t_right with moveoutleft:
        xalign 1.5 xzoom -1.0
    show pov hfneu1 hbneu1 bsad mneu
    show abusmall at t_right with quickdissolve:
        xzoom 1.0 xalign 1.5
    show rose bsadn
    show abusmall eangry sangry
    with quickdissolve
    pov "Ah, Rose, I was worried you wouldn't come."
    show rose ewide bupn mneu
    show pov ewideb bup mcry
    show abusmall eangry
    abu "WHAT HAVE YOU DONE?!" with vpunch

And that's basically the same for every piece of dialog. That's what they call 'posing'. This coding structure you see above needs to be done for every single dialog line in the game (maybe on a different scale, but still), and then you need to replay the scene taking extra care to detect if every single one of those short orders works as intended and make actual sense. Of course, if you edit the dialog lines, all those orders need to be adjusted too, and then checked once again.

Creating a minigame or a turn-based combat system surely takes longer than 'posing' this scene, but it's usually a one-time thing and then all you'd need to do is add a 'call screen' line and maybe adjust the variables involved before that 'call' statement. There, a bug can only exist within the minigame's core, and it would be easily detected as it would crash the game altogether or make the minigame not produce the expected result (it may take several days to fix, sure, but again it would be a one-time thing and you'll then have your minigame's code all fine and dandy for every time you'd want to use it in-game again). Taking care of different variables and paths is complex too, but that's just a matter of carefully noting down every possible combination and not messing with the variables' names; again, bugs would be easily detected and way easier to fix than those in minigames. Having a myriad of those variables and paths is probably similar to what posing means for WaL in terms of complexity, except you only check those variables every once in a while, after a significant interaction, while posing is needed for every single dialog line.

Change a line of text, and you'll need to change those little commands that show the characters' expressions so that they match what's being said - miss-spell one of them or use an existing but wrong one because the right one just slipped your mind, and you'll have a bug you'll only detect when you replay the scene, and only if you're really focused on what you're doing (note that these bugs won't make Ren'py crash when you launch the game, telling you where the bug is; you must actively look for them while playing, reading the text and focusing on the sprites' eyes, hands, and mouth expressions to see if they are doing what you wanted them to do).

Also, let's say you remake a scene because it didn't flow as you wanted: now you may need to change some bits of previous or subsequent dialogues to match the new scene (that's a continuity bug in itself), and maybe you don't remember how many scenes or convos are actually affected, only finding new bits that need to be changed too (new continuity bugs) when you test the game later on - again, at the risk of creating some 'posing' bugs in the process. Considering they've been going back and forth with several scenes they initially created a year or so ago, in an update that is said to have 1/2 more words than the largest one so far (66k compared to 44k), it's only natural they keep finding new things to fix - and they'll find/create many more as they keep fixing them.

 

[aaronlancaster]

You guys are still waiting for Christmas?

 

[Kisama33]

You guys are still waiting for Christmas?

No, I'm waiting for the end of September (even if i'm not going to play it again until it's officially complete/abandoned).

 

[stalinsvempire]

show rose ewide bupn mneu
show pov ewideb bup mcry
show abusmall eangry

Can't possibly make much sense from variables like these. abusmall looks like 'abysmal', lol. I wouldn't be surprised if these are even in hispanic though. It's only their problem that the code is so bulky. The dialogs in the code itself and no functions to, let's say, return a set of poses. They just call that show function constantly. You're right, this is painful to maintain and to fix.
Judging by the structure I guess that's how they teach to use RenPy in those YT tutorials. If you actually going to learn programming first, then giving a distinctive name to a variable is like the first thing you'll learn. I guess they just skipped it altogether and started with the most basic functionality that RenPy could provide.
Well, it's their funeral.

 

[Kisama33]

Can't possibly make much sense from variables like these. abusmall looks like 'abysmal', lol. I wouldn't be surprised if these are even in hispanic though.

If what you mean is that those words are related to hispanic I almost for sure can say that they are not, some of them only require you to remove the first letter to figure out the "word" others definitive need some steps more.

show rose (e)wide (b)up[n] mneu = Menu?
show pov (e)wide(b) (b)up (m)cry
show (abu)small (e)angry

EDIT: Actually "Abu Small" may be that demon (Abu Gabu) in Rose's quest from when he gets small.

 

[moskyx]

I guess e means eyes, b means eyeBrow, m means mouth. Wide and up are pretty self- explanatory, neu probably means neutral, and so on.

Can't possibly make much sense from variables like these. abusmall looks like 'abysmal', lol. I wouldn't be surprised if these are even in hispanic though. It's only their problem that the code is so bulky. The dialogs in the code itself and no functions to, let's say, return a set of poses. They just call that show function constantly. You're right, this is painful to maintain and to fix.
Judging by the structure I guess that's how they teach to use RenPy in those YT tutorials. If you actually going to learn programming first, then giving a distinctive name to a variable is like the first thing you'll learn. I guess they just skipped it altogether and started with the most basic functionality that RenPy could provide.
Well, it's their funeral.

Those are actually layered images that compose the full pic we see, which I wouldn't call 'the most basic functionality that RenPy could provide' (it's not rocket science either and many games use it, but still). And that's just the way you code that in RenPy, using the show statement: what you called 'variables' are actually the preset poses devs defined somewhere else in the scripts (after creating the art for them), and they are calling them here the way they are suppossed to. I guess the names are (or were, five years ago) distinctive enough for devs, but I agree they could be more clear.

Dialogs are always in the middle of the code in every RenPy game, but this code is particularly complex due to those layered images (take into account that there are 3 characters on this particular scene), and the game is designed so those poses change after every dialog line or action. It's their problem the code is so bulky, sure, but that's just how they chose to make this game more than four years ago, and also a big part of its success because it almost looks like a fully animated game. I don't think most of complainers are really aware of this game's actual complexity.

 

[mathluccas]

Nice! In the last 4 days 6 bugs were fixed and 5 new bugs popped up. I see that hip surgery is still hindering his progress.

 

[Knight]

These guys are obviously stalling for time but for real complex code that is actually true. I write code for a living and fixing mistakes is like finding the error in a long math equation, because programing relies on the all the previous steps in a chain to be correct if one part is wrong then everything down the chain is affected; it's actually more like "fix one error, find 100 more".

That being said renpy game structure is VERY forgiving of such errors due to most events being single variable control, most events in renpy are effectively boolean statements, there is very little logic that has to be fixed (which is the most frustrating part of debugging) and most errors are self contained.

It was intentionally designed that way for simplicity sake, which is why so many people use it.

 

[SDDA]

Nice! In the last 4 days 6 bugs were fixed and 5 new bugs popped up. I see that hip surgery is still hindering his progress.

Yeah the whole development is a joke, pretty much made up numbers to fake progression... i know debugging takes time, but not 6 months to a year, especially when its not even the first release but their 7th... This was a great and promising game one time, but something went wrong during these past years and the devs got too comfortable and lost passion. Bummer.

 

[fusibile87]

Nice! In the last 4 days 6 bugs were fixed and 5 new bugs popped up. I see that hip surgery is still hindering his progress.

A proof that this is just a scam. Their progress bars always go up in a steady way, while if their excuses were true, we should see periods of inactivity and periods of huge activity.
We'll have the definitive proofs in september. They said that thanks to school, they'll have more time to spend crunching on the game. We will see. I bet the progress is still gonna increase by 1 bug every report.

 

[George213]

They are earn much for 2 years without update. Game is great but very slow update.

 

[mathluccas]

Is it one of their excuses for delay?

Yeah, supposedly the dev had a hip surgery, iirc it was around january or february 2023. And yes, it is often brought up as one of the reasons the update is taking so long.