ENCODE/PLAYBACK INSTRUCTIONS: For technical reasons I will explain later, this recording will desync if you look at it funny. As such, regardless of if you are editing, playing back, or encoding the demo, you MUST have the following parameters set:
Ruffle arguments "-g gl --no-gui" and Force software rendering ENABLED.
Runtime -> Time tracking -> clock_gettime() monotonic CHECKED.
The game version used is the updated version with new 2016 Original Soundtrack hosted on Newgrounds as of writing; the SHA-256 checksum for the SWF file: 42AEC70ADAAA70B5FC9D937CF48AFCEC9C5CC0E6A36944DFE142B935498CAE62
Additionally, although I don't think this is necessarily required, this run was recorded on the following Linux system: Linux ubuntu-vm 6.2.0-32-generic #32~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 18 10:40:13 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
DESCRIPTION: This TAS was an absolute nightmare to record for one simple reason: it isn't actually a Flash game. Yes, it's a game, but it was made before the introduction of ActionScript, and therefore contains ZERO traditional code or logic whatsoever. All gameplay is implemented via hacked-together movie objects hidden offscreen which track information in lieu of real variables, etc. This means that, among other things, almost nothing in the actual game is tied to the SWF file's stated framerate, because movie functionality provisioned directly by the player can run as quickly as the system can allow without an actual game loop to hold things back. Where this becomes a problem is in the boss fights, where you can shoot your gun literally as quickly as you can click, without limits (the muzzle flash will desync, but that's purely a visual artifact)- RTA speedrunners use 5000CPS autoclickers to shred these bosses instantaneously, but I couldn't do that unless I wanted to slog through making a 5000FPS TAS recording that would probably be a gigabyte large and encode to a video a terabyte large. I ended up recording at 240FPS, which is 10x the game's 24FPS stated in metadata; this is also why the syncing is so tenuous, as the timing is extremely precise and the game is very inconsistent about when it actually throws out a new "frame" or not. While the boss fights are still way slower than the RTA autoclicker splits even at 240FPS, I save more than enough time everywhere else to beat the RTA world record by 4.49s. (I ended the timing at the last click required to deplete Cassandra's health, as per the "end at last required input" guideline. The health bar only actually depletes a frame after, but that's because of some framerate jank or whatever, nothing after frame 7601 is necessary.)
However, while the framerate may matter very little for controlling the game, that doesn't mean that time doesn't play a role. That's code for, "if you go too fast everything breaks, thanks Tom Fulp". Everything starts innocuously enough through the Alucard fight, but it all goes to hell when you reach the burning teachers' lounge. Here's a list of all of the problems I encountered:
If, from using the fire extinguisher in the lounge to reaching the first classroom you do not spend enough time waiting, then the first classroom will not transition to its normal second state where it is possible to use the goggles to see the key. Even now, I do not actually know where waiting is required or how much you need to wait for it to trigger properly, and most of the rerecords are me trying to figure this out since this is a completely novel problem (even autoclicker speedruns don't go fast enough for this to be a problem.) Ultimately, I ended up just enabling slow-motion and pissing around with it unpaused until I got from A to B in reasonably fast time without that issue triggering.
On the way back to the teachers' lounge, moving as fast as possible will result in Cyclops' ghost coming back and wasting your time with a repeat cutscene- to avoid this, I was able to delay clicking the East button by 1-2 frames and that fixes that.
If you enter the teachers' lounge too quickly, then the room will be on fire again. Wait some amount of time (not sure exactly how much), then enter and it will be fine.
While this a version thing rather than a timing issue, one oddity (and a difference between the 1999 and 2016 version of the game) is in how Alucard's fight works. Namely, you can deal damage as quickly as you click, but a cycle ends as soon as you deal a certain amount of damage to him. In the original 1999 version, the amount of damage you can deal is super low, and I almost ragequit making this TAS because I thought I was doing something wrong, but then I tried the 2016 version and I was able to 2-cycle him.
NOTES ON THE GAME ITSELF:Pico's School was absolutely revolutionary, and quite possibly qualifies as the single most important Flash game ever made for how it advanced the medium in ways completely unprecedented at the time it was released in 1999. Prior to Pico's School, Flash games really were just interactive movies; there was no state, and so it more or less amounted to 'click a button to see a funny canned scene'. Pico's School was the first Flash game with actual gameplay, and even is arguably responsible for putting Newgrounds on the map even more than even Club a Seal, Assassin, and Teletubby Fun Land. When I finished this TAS, it occurred to me that the Cassandra boss fight might pose a content issue; while the problematic graphic in question has all the fidelity of a 10-year-old's peurile classroom doodle, it's still definitely on the line. However, talking to a staff member via Discord, I was convinced that it's still worth submitting this, as even if it doesn't get accepted as a publication it can still be preserved as a submission, which I think this game deserves.
Alright, so a while back, I learned that libTAS supports variable framerate, which would be perfect for getting the time on this TAS down even lower by completely trashing the bosses without needing to record the entire rest of the movie at 5000FPS where that isn't needed. I'm not quite sure of if variable framerate is actually stable as an option, mind, and it would still require re-recording the entire movie, it would just make doing so SIGNIFICANTLY less strenuous. I'm not sure if doing this is worth it, so I'm gonna need some expert advice on if this submission really needs the extra timesave or not.
If you run it in Adobe Flash Player in PCem, set game scale to 100% while running it on some high resolution monitor, and set monitor refresh rate to 100, does it become possible to click objects every frame and affect them? If yes, that sounds like a reason to allow arbitrary framerate shenanigans for Flash, much like we allowed off-screen inputs (which this run is using I presume).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
If you run it in Adobe Flash Player in PCem, set game scale to 100% while running it on some high resolution monitor, and set monitor refresh rate to 100, does it become possible to click objects every frame and affect them? If yes, that sounds like a reason to allow arbitrary framerate shenanigans for Flash, much like we allowed off-screen inputs (which this run is using I presume).
This run isn't using offscreen inputs, or anything that could actually be considered an "unintended environment" TASing wise. Natively this game really DOES run at thousands of FPS natively, it's just that recording like that with libTAS is a logistical and technical nightmare, you have to hammer frame advance so many times. Using variable framerate effectively wouldn't actually be allowing anything new for this game from a technical standpoint, it's just a convenience of being able to run 5000FPS or whatever on demand rather than for the entire duration of the movie. Again, though, that's dependent on Variable Framerate actually working right on record, which isn't a guarantee.
Natively this game really DOES run at thousands of FPS natively
How do you know this?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Natively this game really DOES run at thousands of FPS natively
How do you know this?
Through simple observation- Pico's School autoclicker speedrunners achieve uber-fast times in boss fights that would simply be impossible if the game actually ran at only 24FPS. Because this isn't a proper ActionScript based Flash game with an actual input loop based off any kind of tickrate, gameplay functionality isn't determined by the FPS claimed by the SWF file, but by the running speed of the Flash Player itself.
EDIT: for reference, the current Autoclicker RTA WR: https://www.youtube.com/watch?v=AbeJyRXEBLI
It's running in ruffle in that video, and running it in FP at a rate higher than the game's reported value would show that it can indeed react faster (or not). Are there records using both FP and autoclicker?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
It's running in ruffle in that video, and running it in FP at a rate higher than the game's reported value would show that it can indeed react faster (or not). Are there records using both FP and autoclicker?
Currently the NG game entry uses ruffle too, but I can't check what it was using back then, because even archived copies from 2009 somehow launch it with ruffle too.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Currently the NG game entry uses ruffle too, but I can't check what it was using back then, because even archived copies from 2009 somehow launch it with ruffle too.
That's just because the Wayback Machine has Ruffle built in. Pico's School is a Flash movie made in 1999, it used flash player because flash player is the player that existed back then
Still, one 3rd party video without a ruffle splash screen is not enough to define a movie rule for all Flash submissions. An FP test on the other hand would be quite conclusive (and verifiable).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Still, one 3rd party video without a ruffle splash screen is not enough to define a movie rule for all Flash submissions. An FP test on the other hand would be quite conclusive (and verifiable).
I just recorded a video doing just that, hold on a minute while I upload it to youtube
EDIT: here it is https://youtu.be/cwhSNRWZhvw
It's not super visible because of Snipping Tool's FPS and whatnot, but I definitely killed alucard way faster than should be possible with only 12Hz clicking (the max possible at 24FPS)
EDIT EDIT: Also, for reference, skilled spam-clickers can click faster than 12CPS- and while Pico's School isn't a super competitive speedgame, I can definitely imagine some non-autoclickee videos server as proof of the game registering inputs at faster than its stated framerate
So, first of all, I want to apologize for the long time it's taken me to get to this judgement. I'll confess I was not too keen on touching this game, but that's exactly why I need to talk to you all about it, and what this means, or could mean, for TASVideos.
In case you haven't played the game before or aren't aware of it otherwise, the game is, very directly, the story of a fictional school shooting. Your character very directly commits one as they go around, and as the author points out, there's also some rather puerile graphics shown. In most cases, I would just object to all this and reject outright, but Pico's school is, as the author points out in the submission, a significant game in the history of Flash as a medium and of Newgrounds as a platform. Heck, they put Pico in Friday Night Funkin' for that very reason.
TASVideos does not punish the authors of movies for questionable content included within the movies, and we've published movies with rapid flashing lights in the past, for example. But I cannot, in good conscience, let this movie be published without a system that allows us to warn viewers of what the game is about. As such, my proposal on how to handle this movie is delaying until such a system exists.
A content warning system would require some significant retooling on the publication side of things, and I cannot guarantee it will be implemented anytime soon, but I think this is the best way to allow this movie to be published, and also a significant improvement to the site overall.
Are you, as the author, ok with a delay on this? What do our users think of this as a feature?
So, first of all, I want to apologize for the long time it's taken me to get to this judgement. I'll confess I was not too keen on touching this game, but that's exactly why I need to talk to you all about it, and what this means, or could mean, for TASVideos.
In case you haven't played the game before or aren't aware of it otherwise, the game is, very directly, the story of a fictional school shooting. Your character very directly commits one as they go around, and as the author points out, there's also some rather puerile graphics shown. In most cases, I would just object to all this and reject outright, but Pico's school is, as the author points out in the submission, a significant game in the history of Flash as a medium and of Newgrounds as a platform. Heck, they put Pico in Friday Night Funkin' for that very reason.
TASVideos does not punish the authors of movies for questionable content included within the movies, and we've published movies with rapid flashing lights in the past, for example. But I cannot, in good conscience, let this movie be published without a system that allows us to warn viewers of what the game is about. As such, my proposal on how to handle this movie is delaying until such a system exists.
A content warning system would require some significant retooling on the publication side of things, and I cannot guarantee it will be implemented anytime soon, but I think this is the best way to allow this movie to be published, and also a significant improvement to the site overall.
Are you, as the author, ok with a delay on this? What do our users think of this as a feature?
I'm fine with any delay necessary, although I do want to make a significant correction- your player isn't the one committing the school shooting, that's the antagonists. It's possible to shoot a couple of innocents for shits and giggles of course (Nene and the guy in the men's bathroom), and it's possible to kill Alucard after he surrenders, but I don't do any of that since it wastes time, and in general that's in the same category as choosing to dump Yoshi in a pit for the hell of it- player choice and all that.
I asked Ruffle devs because I suddenly remembered PC applications don't have to tie input polling to video rate at all.
feos: does Adobe Flash Player process user input at its own rate independent of the game's video rendering rate? in the tas world we're used to thinking input polling is connected to video rendering because old consoles were emulated that way, but with PC applications it doesn't look related anymore?
context: using autoclickers on pico's school to shoot at 5000fps seems to work fine in FP (but it would need to be verified in some way), so I wonder how FP actually works with this, and is it entirely on games to limit input polling rate in some way?
Dinnerbone: I haven't looked into this to give a definitive answer, but in 'modern'-ish software (like FP), input is generally given separately to graphics. You click a hundred times, and the operating system sends one hundred "click" events to the software (ie flash), and that software handles it how it wishes (either by queueing up "I've been clicked" for one big update loop, or more likely in this case, sending each click event to actionscript)
Consider a text editor, whether as native software or something written in flash (lol): you type really fast, sometimes repeat keystrokes within a very very short span of time. If input is fixed to graphics, typing becomes "lossy" - you'll randomly lose keystrokes as they happened too fast for it to realize it has them
feos: is there theoretically any reason to suspect ruffle is doing anything inaccurate if we crank up libtas to 5000fps and send inputs at that rate, and the game handles it just fine? like if the game has a slower loop for input polling, only some of our inputs would make an effect, but if it's not limited, then all inputs would go through, right?
Dinnerbone: I have no reason to suspect anything wrong here. That matches my instincts of what should happen. It would be up to the game in question to be programmed to receive such rapid events, I don't think many flash developers gave it much thought, but there'd be two general groups of games:
fixed loop games, they have a single "on frame" function that runs once per frame, and in that loop they're asking "is my mouse button down". That'd only handle input as fast as the graphics rendered.
immediate event callback games, they'd have an "on click" event and they're doing whatever ("shoot bullet") in that method. It can be called infinite times between frames.
To my knowledge, we match flash in that we'll send all the events, and what happens next is kinda up to the specific game
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I honestly don't think a new content warning thing is necessary. People can read the description, which usually says what the game is about. If they don't read the description, that's fine. They can still look up a description of the game and decide whether to watch it.
DJ Incendration
Believe in Michael Girard and every speedrunner and TASer!
I appreciate the historical meaning of this game and the technical effort put in the movie. However, I find the game itself distasteful and would not appreciate its publication. Voting no.
Joined: 10/12/2011
Posts: 6344
Location: The land down under.
This TAS has been on the bench for 8 months now, and was delayed deservedly so due to the contents of the game.
Something I wish in hindsight (at the time) that I should've brought forward before a TAS that I made was Published.
And because the author said "This TAS was an absolute nightmare to record for one simple reason: it isn't actually a Flash game".
I thought to myself, besides the fact it's a title that has school shootings, blatant racism and genitalia I should avoid verifying this claim.
And then we fast forward to today, where I thought about it some more, and having used Ruffle quite a bit I was like "is that actually the case?"
It isn't. The author made it as an excuse.
The title is shockingly very forward and easy to actually make a TAS of, when you aren't rapid firing mouse clicks to get through dialogue.
But in fairness to this opening sequence input, Technoturnovers does complete the dialogue on the same frame, albeit messy.
What I won't say is clean besides the title.
For a point and click game you made a single mistake three times. You waited for the item to be available.
The key, the night vision and putting out the fires can be done faster by just leaving the room which skips the "cutscene,".
This is something that you should've been able to check without issue. Why didn't you?
Total time, those mistakes equal up to about 2 seconds.
And 2 seconds is 480 frames. So what happened in your extended input and why is it 5240 frames longer than what I produced with extended input?
The answer is there's 3209 frames of input that shouldn't be there dropping it to 2031 frames... lightly.
You had, and I'm hoping it's had as you haven't submitted anything in the past 7 months, this issue where you wanted to turn your works around as quick as possible while leaving mistakes that could've been avoided.
Based on the version of Ruffle that you used, you made this in 2 days, and it took 8 months for someone to check your work.
That improvement I made and provided was made in much less time, due to the knowledge I have with point and click titles, but because I was using all available knowledge... and made some that you should've had.
And I'm not submitting it, mainly cause I hate this game.
I voted No, cause I didn't like watching this movie, due to the game contents.
I'm glad that the characters are now in better projects, and Tom Fulp changed their attitude.
But honestly. I don't want to have a Flash TAS such as this title next to my name.
As for this Submission? It's scrappy.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
But in fairness to this opening sequence input, Technoturnovers does complete the dialogue on the same frame, albeit messy.
What I won't say is clean besides the title.
For a point and click game you made a single mistake three times. You waited for the item to be available.
The key, the night vision and putting out the fires can be done faster by just leaving the room which skips the "cutscene,".
This is something that you should've been able to check without issue. Why didn't you?
Total time, those mistakes equal up to about 2 seconds.
And 2 seconds is 480 frames. So what happened in your extended input and why is it 5240 frames longer than what I produced with extended input?
The answer is there's 3209 frames of input that shouldn't be there dropping it to 2031 frames... lightly.
You had, and I'm hoping it's had as you haven't submitted anything in the past 7 months, this issue where you wanted to turn your works around as quick as possible while leaving mistakes that could've been avoided.
Based on the version of Ruffle that you used, you made this in 2 days, and it took 8 months for someone to check your work.
That improvement I made and provided was made in much less time, due to the knowledge I have with point and click titles, but because I was using all available knowledge... and made some that you should've had.
And I'm not submitting it, mainly cause I hate this game.
I voted No, cause I didn't like watching this movie, due to the game contents.
I'm glad that the characters are now in better projects, and Tom Fulp changed their attitude.
But honestly. I don't want to have a Flash TAS such as this title next to my name.
As for this Submission? It's scrappy.
