Since this warrants a longer response, I'll be breaking it up into segments and responding to each. Note that my goal with these posts genuinely isn't to shit on MITY, they are far from the worst dev when it comes to goodwill, transparency or trying their hardest (especially the artist). I'm trying to be as neutral and fair as possible.
My main contention with "the coder" being the primary writer/programmer is that he's supposed to be THE ONLY writer/programmer. The artist coming in and writing or coding as much as 30-40% of the game speaks against him when compared with the artist. When you have Guy A who's drawing all the art, and doing potentially as much as half of the coder's programming and writing work, Guy B claiming to be burnt out raises a few eyebrows. Of course it's entirely possible that he's a different type of person who gets burnt out more quickly, but if I was in his situation, personally, I wouldn't feel like I "deserve" to complain or take time off when the other guy is essentially doing half of my work already in addition to his own.
I don't disagree with the notion of a writer's block, but... come on. I mean we're not exactly talking about Tolstoy here.
Given that the art portion of the game was finished on August 24th at the latest and 0.8.3c came out Aug 14th, that leaves us with a timespan of roughly 4 months (119 days) to account for. Consult the timeline of events posted earlier for a more detailed breakdown, but suffice to say that the physical injury accounts for a two week period around the middle of November through December 5th (during which he also worked), caring for his sick mother is something that was mentioned in the past and is likely no longer applicable (he doesn't live with his parents, and staying with them seemed to be an unusual one time event), he has no reason to worry about his finances unless he owes money to a fucking Saudi oil magnate, and the artist told him to drop the CCG minigame and avoid getting burnt out way back in August before this entire thing began. Make of that what you will.
Hence why I included the filesizes in the screenshot (to give a rough estimate of how much code is involved - we're not talking about 3MB 78,000 LOC files. In this case it's 30k lines for Book 4, of which ~15k is boilerplate, ~15k is dialogue and ~2k is actual logic), selected the only two files with minigame code (i.e., programming), trimmed out the VN segments from even those, and brought up the example of the map screen and the day/night system as the most complex elements implemented in Ren'Py script as opposed to pure Python.
The intent was basically "if he hasn't even bothered to split it beyond two files, how much code do you think that is", and to show the ratio of what people understand as "programming" to everything else. But for the sake of transparency, this is what the entirety of Book 4 looks like (or it would, if it was organized):
_boilerplate is code that's self-explanatory (b4_eq1 is an equalist, their color is black, their side image is /equalist/sidebox/equalist_1.png, etc), _images are the sprite assignments ("bfau" is the Korra blowjob scene, it has 10 stages, stage 1 is /boobjob/body_1.png, stage 2 is /boobjob/ani_3.png, stage 3 is a 6 frame looping image with a 0.2 second delay between the frames etc), neither of them are terribly relevant, it's basically metadata that you wouldn't even use for future content.
Then we're left with code (which is the code for the minigames), and dialogue (which is the actual script and flow of the story).
You don't need to concern yourself with the minigame code, because you're not working on the minigames. The match-3 coin game is a fucking black box, you don't care what it does, and you don't care how it does it. Same with the blackjack minigame from Book 2. Yeah, it uses 18 files, all of them are identical, yeah 16 of those aren't even reached by the code, and yeah, all of them have a 52 element long if/else chain with variable names like "P6s" or "krix0". None of that is relevant. It does what it's supposed to, and it increments your money once it's finished. That's ALL YOU NEED TO KNOW. You don't need to touch it, you don't need to debug it, you let it sit there alone in the corner like the unloved abomination it is, and forget about its existence like its creator has.
Which then brings us to the only thing that involves logic you need to understand, the dialogue trees. Which make up ~16,000 lines of text, of which maybe 1000-2000 involve any kind of logic at all. Everything else is literally a book.
The reason I ignored those and why I'm overly dismissive of the VN side of things, is that I don't CONSIDER Ren'Py code to be fundamentally the same as programming. Note that I'm not saying "it takes no effort" either - writing DOES take effort. It just doesn't take the same kind of effort as programming in the conventional sense does. There are no classes you have to instantiate, you don't have to write unit tests, you don't need to know how A* search works, you don't have to be cautious when implementing cryptography, you don't have to write your own parser, you don't need to understand how binary formats work, you don't need to access a database, you don't have to work with matrices, you don't need to deal with the obscure bugs and API of the system you're running on, you don't have to worry about GC pauses, you don't need to worry about memory allocation, and I could keep going on and on. Ren'Py is control flow. That is ALL IT IS.
This...
Python:
if spinner_level >=10:
$ korra_foot_quest = 2
jump air_train3
else:
tn "(i need to level up to {b}10{/b} on the spinners before i can train more with korra.)"
jump bk4_training_menuIt's a fundamentally different task that's much closer to writing and directing, and thus needs a different skillset. Same with the boilerplate code I mentioned like filename and image assignments, which make up almost as much of "the code" character-wise as the dialogue, follow a distinct formula, and could be easily offloaded to someone else with zero knowledge of the code or the script. Find the right filename, make sure it's on the right coordinates, make sure you put enough of a delay between frames that it looks the right speed, etc. They're glorified metadata files. It's busywork that you only even have to do in the first place because Ren'Py doesn't have a proper IDE or editor built around it which would handle it for you. It's the equivalent of manually renaming a hunded files in a directory. It doesn't take creativity or skill, it's not difficult, it just takes time. Christ, you could probably spend a few weeks putting together a basic graphical editor/preview tool for scenes or a PSD converter and save yourself months of effort down the line.
Yeah, and that's contention number #2. Even without the minigames and the Python side of things, EVEN amongst other VNs, Four Elements Trainer is very simple. The game doesn't HAVE an inventory system (ironically, because it might actually make things simpler). There are no complex series of interwoven choices which determine one of 17 possible outcomes with each character. The minigames don't affect your game state besides incrementing your money value or setting a flag to True. What you have are inline if/else choices with the dialogue listed right below, and scenes where the game outright fucking ASKS YOU which ending you'd like. Even as far as VN logic goes, FET's is firmly on the lower end of complexity.
Anyways, the reason I look down on VN code is because control flow isn't something you SHOULD have an issue with in the first place. It's something that's very easily visualized, and something that comes naturally to writing the story in the first place. If it becomes a problem because you didn't name your shit properly or you're deep within a nested loop of 19 elements, it's entirely a problem of your own creation. To illustrate what I mean, let's take a look at the two main components of Ren'Py code (ignoring boilerplate) - variables and control flow.
Suppose that you want to implement the Ember Island segment from Book 2 into the game.
You don't just start writing code from the get go, you do a million other things first. You decide on the idea, you talk it over with your partner, you think about what could be included, what the overall storyline would be, where it takes place in the game, and so on. You determine the scope of this update (an island in the love route, you interact with various girls, there's a crab minigame, the story involves azula warming up to you, we'll have these 13 scenes, the locations will be the beach, the house and the party you go to, the length is planned to be around five in-game days, etc).
In our mental map of the game's code, it's going to go right...
...there. So logically, it's only able to draw from or have an impact on variables here:
The only things that will be relevant to our Ember Island update are what has happened in the love route of book 2 so far, and what will happen in the love route of book 2 afterwards (which we're most likely not concerning ourselves with anyways, since we haven't even decided how the book is going to end yet). And if you were to finish the Ember Island update on your own as hired help for the project, the coder managing things would have to add a grand total of one (1) line of code to integrate it into the game: jump ember_island_start right at the end of that red section. You don't need to understand anything, and neither does the existing coder. Everything is modular and self-contained.
But why don't we make things more interesting? You start writing the story, and you reach a point as a writer where you decide that it would be a good idea to make a callback to a previous event. Let's say you're in a conversation with Azula and Mai, and there was a scene earlier in the Book 2 love route where you could choose to side with Azula or Mai respectively (which you know, because you've played the game already and/or wrote that scene yourself). You open the file that has a list of all of your variables for Book 2 (which you have, because you're not an idiot), you do a search for "azula" if you can't remember what it was called, find chosen_mai_over_azula, note that the comment above it says
Python:
#This variable is set to False if you told Azula about Mai in the shop during the second day of the love route, and True otherwise
Python:
#This variable should be between 0-10 if you didn't get along with Azula, 10-20 if she was lukewarm towards you, and a perfect score of 23 is required for the special endingWhat you DON'T DO, is start fucking reading through the previous 293,400 lines of dialogue in the game and try to figure out where that variable was defined or when it gets modified, or HOPE that you can recall it every single time you need it. Because you're not fucking insane.
TL;DR - The problem is variables. The way you solve that problem is by having one of these:
Let's take a look at problem number two. How do you comprehend this unwieldy chain of labels and quadruple-nested menu items and jumps and OH GOD
Well first off, are you working on the Azula throneroom menu? No? Is the Azula throneroom menu going to be relevant in future content? What's that, "never again"? What the FUCK ARE YOU DOING here trying to read the code of the Azula throneroom menu, then? See the minigame rule above, close the file, forget about it, and go do something useful. Assuming the Azula throneroom menu actually IS relevant though, how would you go about comprehending this mess?
You don't. You separate the logic from the scenes, and read this instead:
How do you memorize the complex relationship between jumps and how different labels link into each other?
You don't. You use one of these:
Which you have, because you're not an idiot.
This became a rambly fucking mess and I'm too lazy to edit it down, sorry. The point is that if you were to be hired on right now to work on future content for the game, then
- you ignore minigames and everything before the current book
- you don't parse fifty million lines of code, you look at a tree of intro -> book4_map -> korra_room -> korra_training_menu -> korra_blowjob, and a list of variables
- when writing a scene, you just write that standalone scene as its own thing with zero logic, code or labels, when coding minigames, you code that minigame separately as its own standalone project - i.e., you could be hired on as a writer or a programmer with ZERO knowledge of the game and have the existing guy implement your work
- the order of how things should progress and what scenes should lead to what is ALREADY DECIDED beforehand, during the planning phase of the project, by someone doing the work of a director, which a writer then works off of and a programmer ties together with logic
- understanding a call stack is the most basic component of programming, and is not even comparable to working on actual code
Last edited by a moderator:
