behind the scrapyard puzzle, take infinity (Patreon)

sigh.
let's try this again.
again.
because i wrote out most of this post this morning before i left,
and thought "my computer is password protected so if i put it to sleep there's no way the post draft will be deleted"
"but just in case,"
"let's copy everything in to a notepad++ file, since those persist even if the computer restarts"
i felt very clever. and secure.
naturally, i came home to find the post deleted not only from patreon, but from notepad++ as well.
apparently notepad++ saves on restarts, but does not save through windows updates.
thanks, microbama. 

sigh.

okay. so previously i talked about laying it out and how i wanted it to be different from the (now redone!!) railnet. once that's set, i had to make sure that it couldn't just be done willy-nilly. there all these trains and the correct answer is basically to just ride every single train so what makes that difficult? to answer that question, i used debris that trains could break but the player could not cross, and rocks that the player could break but grounded the trains from starting. these obstacles are basically tools for me to create a correct sequence of actions that the player has to find. in this way it becomes a puzzle rather than a playground.

so that's the conceptual piece. let's talk about the actualization of it. 

just about anything that moves in a map is probably an Event, to use RPG Maker's langauge. events are things that can Happen or Have Graphics that go in any given tile of a map. for instance, we have one event that holds the whole train's graphic, and under a certain condition the whole event can be moved around, taking the graphic with it. thus, the trains move.

the problem is that the train graphics are 2x3, or 3x2 on the other facing, and an event is only one tile. RPG Maker normally only detects collision with the single event that holds the graphic, but that means that a player could just stroll right under and through a train. we don't like this. so, there are two solutions:

• either bust that train graphic up into six events so that each space of the graphic has passability-- this would be the straightforward approach
• or create a bunch of invisible tiles that go under the other spaces left by the train that can't be stepped on despite having no graphic.

we choose the second. the first is disadvantageous because it makes moving the train graphic a clusterfuck. instead of moving one event, we have to move six. also, there's a chance if they don't all move in sync that that we could see small lines between the trains while in motion.
on the other hand, the second is advantageous because it allows us to actual skimp on some events. 

consider the buffalo:

the boxed in area is a train. the trains' graphic is stored in the bottom right tile, since event graphics always display from the bottom center (and the graphic itself is shifted 32 pixels (one tile) to the left to make sure it centers on the map properly). the other four events there are invisible blocker tiles. the sixth space, where the arrow points, should technically have an event there too. however, since there's no way a player could step there anyway, we get to skip placing one there. we could not do this if we split the graphic into six parts, or else a piece of the train would be missing. 

so we save one event. this is trival, but it adds up. at 160 events per map, the game begins to lag. it's my personal goal to keep all maps under that amount. at 190 events, the lag will be very severe on weaker computers. getting to that point is unacceptable.
because i was able to save enough events, cut some extraneous... no, extraineous parts of the puzzle, and limited hidden items, the scrapyard puzzle tops out at 169 events. for everything going on in it, that's a pretty tight squeeze, but it worked out.

in retrospect i could've saved a lot more tiles if i handled the blocker events the same way i do in E18's main puzzle-- it's much more efficient. but... well... i didn't. so i mean, i guess good that i'm still improving. so we save as many tiles as we can this way.

so we now have the train, and the player can't walk through it. in order to make it work, we have an event by the entrance of the train that pulls the player in, sets them to invisible, and then moves the train.
normally if the train moved, the screen would stay in the same place. you will notice that the screen moves with each train.
this is because the player is actually just running at an incredibly high speed as each train moves. and also they're invisible under the train. 

i'm pretty sure that is something like bethesda did... where their trains are just NPCs with train hats. it's the same kind of thing.
like this, right.

am i professional developer yet?

incidentally, when taka is with the player, we just turn him invisible and have him run under the train too.
in my headcanon, he and the player are both doing the naruto run down there.
anyway

so the train moves and reaches the end and sets a variable so that the game knows that the train is now here and not there. it updates the block events similarly.
..except the final train of the first map, the one you ride through the field of trains, is actually handled differently.

since that one can stop at three different places if the player hasn't properly cleared the path, that one doesn't use a variable to keep its position-- the blocker events are just pulled along with it step by step whenever it stops moving. it would have cost too many events to do this the same way as the other ones, since the other ones have no more than two stops. so i oped for this solution despite realizing that if someone leaves the map and comes back and sees that only that singular train resets (that is the side effect of not using variables/other events) then they might think it's a bug.

thought: i can probably pre-empt that now if i just have that specific train handled the same way as in E18. i'd have to make a variable for it, but the fix might only cost zero or one additional events.
it also might break something i'm not thinking of. 

and on the other hand having it reset to the bottom position might be more effective anyway since if the train is at the third position it can get stuck at, it barely looks like it gets enough momentum to knock the others out of the way.
not that that problem couldn't exist anyway.
so it's all double-edged, zzzz

nevertheless, that's the core part of the puzzle. 

so the first map of the scrapyard was a pain mainly because of the event limit. the second map (where you ride the train through stuff into) was a pain for a very different reason. 

essentials has this fun little quirk (please imagine me saying that as desperate-housewifey as possible) where if a graphic in an event is too big, it'll just...... follow the player around..........................
like no matter what they do the graphic gets stuck in the corner of the screen and scrolls with them forever until they move back into its range
like some kind of weird graphic-yandere.
this is because of how essentials has changed the camera angle from normal RPG Maker. in normal RPG Maker you can walk to the edge of the map. in 3rd gen Pokemon games, the player is always in the center of the camera. therefore, the map has to scroll differently. the script changing how the camera scrolls causes this bug since the event holding the graphic moves out of range, and then the anti-lag script terminates the graphic to save processing power thereby leaving a floating graphic.
it is incredibly frustrating.

retrospective: both of the map's main frustrations of this area are caused solely by essentials. many-events don't lag like that in normal RPG Maker...
thanks, marunobama.

so, scrapyard. the graphic in question that was too big was the huge trains there.
the ones that go in these places, i mean:

those long trains of cars all scoot back together so i had naively put them into one graphic so they'd be as easy as possible to handle.
i was a fool
a fool in a girl's shoes

so i shortened the trains a bit to try and fix it, but even after i did it was a little too long on the left side...
so i got cheeky,
and made it longer instead.
i eventually just put a bunch of blank space on the graphic sheet on the right side of the train.
remember before how i said the graphics display from the center? this means that even if the edge of the graphic gets stuck on the screen-- and it certainly will now, it'll just be the empty side of the graphic.
so technically... i didn't fix the issue at all.  i just kind of made it invisble.
mostly. i forget why but i couldn't do that with the trains on the right side-- i suspect because the player can walk around to the right of those and then we're in double trouble. so i just had to break those into smaller cars and handle it normally.
but i was able to do that since this map has so many fewer events, wasn't too worried.

so that was the second map.

train town and the fourth map, the bottom right connecting the gym entrance to the back of the first map, were both pretty straightforward, although i was originally going to have a train from the bottom right take the player back to the first map instead of having them walk that relatively empty stretch-- alas, that was one of the extraineous things i had to cut for event counts from the first area.

not that it makes much of a difference cuz that would've only worked once anyway but i was all set to crash this train into that side mountain xd

maybe one day.

so that's about it for notes from the scrapyard, sans some misc troubles that aren't too worth talking about.

stay tuned for next dev cycle when i procrastinate the very similar puzzle in E18's development notes for three months as well !