Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I had another thought/question.
Did you (Technickle) ever actually test if a 1P or 2P game was ultimately the fastest method?
I know this was brought up with one of your previous submissions of this game. Your response at the time was:
Technickle wrote:
I do agree with you on your point about the 2 players being more interesting than a 1 player scenario. However, I don't want to put myself in a situation where I am not aiming for a 2 player run.
For the purpose of this submission, I only want to compare to a 1 player run if that is acceptable and or allowed in this context.
Under the current site rules as I understand them (recognizing that the rules may be changing due to recent discussions about vault expansion/change): if a 2 Player run would be faster than this submission (which, based on the previous submission's discussion, it likely would be), this submission would need to receive enough positive entertainment response to be published into the moons tier as it wouldn't be eligible for vault publication due to being a sub-optimal method of completing the game.
Given that this submission is sitting at 1 total vote (which is a NO for entertainment), there doesn't seem to be much interest in this game at all. This means it has a significant uphill battle to garner the necessary feedback for moons publication.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Just a note for Technickle: You may want to consider taking a bit more time to optimize your runs.
Even before this submission, I had already noted the rapid succession of complete game runs posted to userfiles from keeping an eye on the "Updates" channel in discord. Based on the history there, you have uploaded 12 userfiles of this game since June 30 (just over 2 weeks); only one of these was labeled as a WIP, and the rest were apparently complete game runs.
From what Spike's chart shows, there are odd curiosities from version to version in how long any given stage takes, with numerous occurrences where you actually lose time to one of your own previous versions.
From an optimization standpoint, it makes zero sense that you have two instances where you lost time in Level 1 to a previous version of the TAS. It's the first stage of the game; there's frankly no excuse to lose time to a version you've already made unless you can prove that the time lost in that situation results in an even greater time save later on in the game.
This all results in your runs appearing as if you're not utilizing your own best input from previous versions as you create a new version of the TAS, but instead are redoing everything from scratch each time.
You have 11-12 uploads of seemingly complete redoes of game in barely over 2 weeks. While the total game time improves with each version, the inconsistencies and lost time suggest that you're only considering optimization from a total time perspective, and not considering optimization of individual sections/levels of the game.
Ultimately, all this makes it appear as though you're really rushing through these improvement attempts.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
4. Turn submission polls into a 0-10 scale
5. Change the poll question back to "Should this be published?" and treat poll results according to presence of external goals, which is finally a clear borderline.
Won't whether a not a movie is published still ultimately be determined by the judge (even if allowing for more flexibility based on viewer feedback from the forum/poll)?
I like your idea of condensing all 3 current polls (workbench yes/no/meh, post publication entertainment rating, and post publication tech rating) into a single rating. However, given that "Should this be Published?" doesn't really ask for a rating that fits on a variable scale; perhaps we could instead present viewers of workbench movies with a simple poll that just asks to "Rate This Movie" on the 0-10 rating scale?
Regardless of the poll question another consideration from a rating standpoint would be a 1-5 scale as that is another format many (if not most) users would be familiar with for rating things.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I firmly stand behind the idea of opening things up and attempting to remove/reduce any negative 'stigma' of the Vault.
I'm all for entertainment in TASes, and I also believe that fastest completion TASes should be just as celebrated as entertaining ones simply for the TASing achievements they are (regardless of their entertainment value).
Eliminating any degree of negative perception--that Vault publications are somehow less important to the TASing community, just because they may be less entertaining--is a worthwhile endeavor.
Edit:
Out of curiosity; how would this affect things like Board Games and Edutainment? Would these titles still be restricted from the site, or would the proposed changes also potentially open publication opportunity for these types of games?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
If this thread is meant to be a place for all TASes that are known to use uninitialized RAM regardless of whether or not they've been console verified yet,
[4257] GB Donkey Kong by DrD2k9 in 54:15.44 qualifies.
If this thread is only meant for TASes that have yet to be console verified, feel free to delete this post (or tell me to delete it).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I'm in and teaming up with NYMX.
To anyone else who joins us, be forewarned: I may have very limited time to put toward working on this contest, but they are fun enough that I don't want to completely miss out.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
Do we want to agree that getting high scores in all events means fastest completion for them?
I don't remember who's comments got me thinking along these lines, but my perspective on score based events is that they can't effectively have a "fastest completion" that doesn't also max out the score. Stopping at any point before the maximum (even if it's a new high score) is essentially acknowledging that the event can be performed to a fuller extent with a higher score and thus remains incomplete.
It can't be a fastest completion if it remains incomplete.
Consider the general concept of a high score: The whole point of high score tables/records in games is to try and improve upon whatever the current high score is. While game designers may pre-program a default high score, it can probably be safely assumed that (in most cases) the designers didn't intend for that particular high score value to be the maximum that could be achieved in-game. Especially when considering older coin-op games; the primary purpose of the high score was to drive people to keep playing (and thus keep paying) to try and best whatever the top score was. The competition created between actual people--not people and the pre-programmed score--is what drove the continued payment. This high score concept bled into games for home-based systems even though constant payments were no longer a component.
Given this concept; for a full completion run, if a TAS can be made to perform better than "simply surpassing the pre-programmed high score," it should be. Therefore, in order for a score based event to be considered complete, a maximum score should be necessary.
Accepting a score below the max but above the pre-programmed high is an arbitrary point issue. This is especially the case if the event can be sufficiently finished with a score that allows for continuing onward but remains below the high-score threshold. NES Track and Field would be a good example of this. There are scores that qualify the player to progress in the game without getting a "game over", but are still lower than the in-game "world record" high score.
If we're wanting to allow any score below the maximum to be considered for "fastest completion," then any score that the game considers good enough for progress should be allowed. This would require including games where complete failure in an event (via attempts resulting in only faults) would have to be allowed for "fastest completion" if the game allowed the player to continue beyond that point. The above mentioned Decathlon game would be in this category, it allows for complete failure of a score based event while still progressing to the end of the game. I wouldn't like the idea of accepting things that way.
Speed based events are obviously speed based and should simply be completed as rapidly as possible.
TL:DR
IMO, From a TAS perspective, a maximum score is necessary to consider a score-based event "complete" at all. Thus for a "fastest completion" run, maximum scores in score-based events are necessary to fulfill the "complete" aspect of "fastest completion."
Score based events simply don't lend themselves to being completed quickly and this will sometimes result in repetitive gameplay to achieve the max score and resulting longer total runs.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Dacicus wrote:
According to several sources, at least one version of this game was available as a PC booter, which means that it can run from a floppy without need for an operating system. IDK if JPC-RR emulates that, but it might save some of the loading time by eliminating the need for FreeDOS.
While that may save some startup time, it wouldn't affect the gameplay aspect of the run. Given that loading times aren't considered for improvements/obsoletion, the resutling time savings would be moot. Considering it'd be less than 3 seconds of time saved, even from a publication standpoint, it'd hardly be noticed.
As a comparison, consider Commodore 64 games. Games loaded from tape or disk can take multiple minutes (sometimes over 10) just to load the game. When one of those same games is on a cartridge, it will load near instantly. In that situation using the cartridge version would be nicer from a publication standpoint because it would elimiate minutes worth of loading times even though the gameplay itself is completely unchanged.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Entertainment
First let me say that this was obviously a very well planned and executed TAS, and I can appreciate the work that went into creating it. Kudos to the authors for the accomplishment.
Regarding entertaiment though: While it did hold my attention throughout (mainly just out of curiosity as to how things would be done), I wasn't really entertained by the on-screen activity itself. To me, this video was a slowish completion of the game which jumped when absolutely necessary and otherwise simply wasted time while slowly waiting for a kooopa/beetle/etc. to get into positoin so it could be used either as a springboard or a method to glitch into a clipped position.
Yes, the tech of the run is interessting, but visually watching Mario rapidly duck/change direction and shoot fireballs in sync with the music in order to kill the time necessary to wait for enemies to slowly do their thing just wasn't very entertaining to watch.
Personally, I find various other of the current SMB publications (including the basic any% speedrun) significantly more entertaining to watch than this run. Even the walkathon is a more entertaining watch to me than this run.
Acceptability for Publication
I'm torn on whether or not this run should be acceptable for publication.
From a technical achievement standpoint, I fully support that this run warrants some degree of recognition/archival.
However as mentioned above, I just didn't find it all that entertaining in comparison to the collection of other SMB runs currently published.
Why this is difficult for me is as follows:
I'm one within the community (in the admittedly minority group) who believes that most, if not all, games (including educational/board games/etc) should have some place to have their fastest completions be published--even if only for archival purposes--regardless of how entertaining they may or may not be. This obviously doesn't line up with current site protocol.
I also feel that significant technical accomplishements should similarly have a place for such archival; again regardless of entertainment value.
However, as the site currently requires runs other than 100% or Fastest Completion to meet entertainment criteria for publication, I don't support publication of this run from an entertainment perspective. It already appears that I'll be in the minority on this perspective as well. I just didn't find it visually entertaining enough to warrant publication along side all the other published SMB runs from an entertainment perspective.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I tend to ignore most April Fool's submissions, but this one intrigued me enought to actually watch.
This was very impressive!
Since I can't imagine it being accepted due to the emulator limitations and the 'cheating' required to accomplish the sync....I'm pre-nominating this for Gruefood Delight before it likely (and sadly) gets rejected.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I've run into similar issue with the Odyssey 2 core and can somewhat replicate it.
I believe this may be an issue related to savestates.
Using the Pinball ROM, I can show some images to explain a bit of what I'm encountering.
When I just load the ROM, open TAStudio and start running emulation; I get the following:
When I add input, the following occurs and I get the wall of lag:
Then after the input is in place, restarting emulation from the beginning will result in this:
Then sometimes (but not always), clicking to jump back the emulation at an earlier frame results in the big block of lag returning. In this example I clicked to jump back to frame 12:
I'm not sure if this is the same bug that Lobsterzelda is experiencing, but it sounds related.
Again, I'm guessing it's a savestate issue, but I'm not a coder to know how to investigate further. There are no error boxes/logs/reports occurring.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Dimon12321 wrote:
Is it possible to transfer regular input with TAstudio window opened? It's not that convenient when you have to use either only mouse to mark specific cells in the input grid, or only console input and then open TAstudio to perform various manipulations on it.
Check the "Recording Mode" check box, and TAStudio will record your controller/keyboard inputs.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Ok. I've completed multiple versions of the game starting with Winslinator's userfile that completes the menu stuff 21 frames earlier than this submission.
Here's where things stand:
This submission (slow-menu approach) has 8,590 frames of gameplay from the first frame of controlling the first ball until the final input.
The fastest run I could attain using the fast-menu approach, has 8,617 frames of gameplay from the first frame of controlling the first ball until the final input.
In other words, I was unable to complete the actual gameplay faster using the fast-menu approach.
However, that doesn't really matter, because (even with the earlier start) the best fast menu approach run finished 6 frames after this submission.
27 frames slower gameplay - 21 frames save in menu = 6 frame slower total run.
Interesting side note: I have a second slow-menu approach run that completes the gameplay portion in 8,612 frames. Meaning there are at least 2 methods using the slow-menu approach that yield faster gameplay portions than any fast-menu approach I could accomplish.TL:DR
While finding a way to do the menu stuff faster was interesting. The improvements aren't sustained through the entire run. The submission as it stands is the fastest known completion of the game.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Winslinator wrote:
I've actually found a potential improvement to this. I uploaded an edited movie file which shows that the menuing at the beginning could be 21 frames faster by using the second controller to squeeze in more commands. Unfortunately, it desyncs after the second throw so much of it would need to be redone.
I would volunteer to help finish it myself but I am unfamiliar with the game's mechanics, nuances, and such. Hope this comes in handy!
Very cool find. I will look into this as soon as I can. I'm going to leave this submission up for now (as it's yet to even be claimed for judging). If the improvements carry through, I'll provide an updated full completion run to userfiles.
Regarding using your menu improvements: If they don't save at least 21 frames over the course of the actual gameplay, then my run (while starting actual gameplay slightly later) would still be the faster gameplay. If I'm not mistaken, the site prefers better/faster gameplay over faster menuing when there's a slight discrepancy.
But I'll make sure to comment here later with what I can find/accomplish.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Samsara wrote:
compucat wrote:
I thought I'd finally register here (hi!) and keep an eye on this thread
So this is actually my biggest concern about the whole event.
As a whole, TASGiving felt almost entirely separated from TASvideos.
...
It's honestly worrying me how much of a growing disconnect there seems to be between TASvideos and the TASbot community, and being left in the dark like this did nothing to alleviate those worries.
Speaking as an active(ish) member of both communities:
TASGiving was almost entirely separated from TASVideos. The event was neither conceived nor planned in our forums, nor did it require any direct involvement from our site (or members of our site acting directly for our site) to be the event it was. Some TASes from our site may have been used during the event, but the licensing we use for our content allows for that. Yes, some members of both communities were involved, but that doesn't mean our site had anything to do with the event itself.
I can understand that some may have a desire for the TASing community as a whole to maintain a strong degree of cohesion. However, as with anything that grows as large as TASing has become, it's nearly guaranteed that disjointed perspectives/approaches will develop and ultimately lead to some degree of disconnection between those varying perspectives/communities.
We've arrived at this position in regards to TASing. And while TASVideos may be the largest and/or most well-known site for classic TASing and its resources, we hardly own the concept in the sense that we can make demands on other TASing communities: regardless of whether or not they've stemmed from our own. Using the phrase "being left in the dark" suggests that there is some impetus on the TASBot community to keep TASVideos 'in-the-loop' of all things that are happening there and that they have somehow failed (or intentionally kept information secret) when that information hasn't made it to our site/forums.
There are members in each community who have no desire to be involve with the other community. We cannot suggest that it is somehow wrong/improper for long-standing members of the TASBot community to not be members here. If someone actively involved in the TASBot community has no desire to create/submit TASes themselves or get involved in our forums, they have no reason to create a membership for our site regardless of how involved they may be on the TASBot side of things.
While it would be nice for someone in the TASBot community to keep TASVideos apprised of everything that's occurring in that community, it's just not feasibly possible in my opinion. I'm in both communities, and I sure don't have the time to do it. I can't keep up with everything happening in either community individually, let alone be able to concisely summarize all that's happening in one of those communities to effectively present that summary to the opposite community
Beyond the feasibility though, I don't feel that it's necessary or even overly important that the TASBot community to be expected to constantly report back to TASVideos on what's happening over there.
While they still promote classic TASing and TASVideos, the TASBot community has grown into something with a much broader view of what to do or even can be done with TASing tools compared to what TASVideos is focused on. This should be easily observable by how often the TASBot community has exhibited things which 1) cannot be submitted on TASVideos due to limitations of our site and 2) would be rejected for not meeting the rules of TASVideos if they were able to be submitted.
We cannot fault the TASBot community for growing further apart from (or perhaps someday even larger than) TASVideos simply because they have chosen to take TASing in a different direction than what our site's restrictions are for potential publications.
It is the absolutely these varying directions that the TASBot community is taking with TASinng concepts that fundamentally disjoint it from our site. That community doing anything in lines of communication to keep our community involved/aware of what they are doing is as much a courtesy as it is anything else.TLDR: I understand how it may be frustrating to some TASVideos members to not know what may be going on with the TASBot community; but we should not feel "left in the dark" when we aren't directly told everything that's happening in that community. There is no forced regulation on them to tell us anything they are doing in the first place, nor should there be. The impetus for knowing what's happening in either community is the responsibility of any individual of one community wanting to know what's going on in the other.
While there is a degree of sadness that the TASing world as a whole is becoming somewhat disjointed, we should not be surprised by this. Further, we really should be thankful that our site continues to be mentioned and promoted when the varying directions that other TAS communities follow give them the opportunity to promote our site as well as their own pursuits.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
First thought: Many PC games (at least in the 90s) were released with some form of documentation--either in the manual, or on the game's packaging itself--that provided minimum and/or recommended system specifications.
If the game being TASed included this form of minimum/recommended specs, those should be settings of the emulated system regardless of year of release.
Second Thought: While the idea of 3 major generalized settings that should cover most games definitely makes things simpler, it also goes somewhat contrary to the way things are currently with JPC-rr as the only effective method of TASing DOS.
Current/JPC-rr method: Essentially, in games where the speed of gameplay itself is affected by the CPU speed, the emulated speed is limited to speeds available at the time of the game's release. If ONLY loading times were affected by CPU speed, any emulated speed is allowed as it doesn't affect gameplay itself.
Unfortunately, this presents a dilemma with the '3 Generalized Settings' approach.
1) If the generalized setting is from somewhere in the middle of the era, latter games in that era will be emulated slower than for systems they were released.
2) If the generalized setting is from the near the end of the era, some games from early in the era may be emulated at much more rapid speeds than systems for which they were intended.
3) Either of these effectively allows for games to be played outside of the CPU speed limitations that are currently imposed on DOS runs created in JPC-rr.
Regarding #1 above, if the later year releases of a given era are allowed to be TASed with the settings of the next highest era, this again could result in the game running at significantly faster CPU speeds than intended.
Regarding #2 above, this would likely affect 80's era games more than 90's era(s), as a comparatively greater percentage of 90's era games have gameplay speed tied to real time as opposed to CPU speed.
For reference:
CPU speeds in the 80's ranged from under 10mHz up to 33mHz. Meaning speeds could be up to 3 times faster for an early released game played at end-of-era settings.
CPU speeds in the early 90's (1990-1994) ranged from around 20mHz up to 200+mHz. Meaning speeds could be up to 10 times faster for an early released game played at end-of-era settings.
CPU speeds in the late 90's (1995-1999) ranged from around 150-200mHz up to 1GHz. Resulting in speeds which could be up to 5+ times faster for an early released game played at end-of-era settings.
TLDR:The idea of 3 generalized settings sounds like it should be effective enough. However, looking at the rapidity of how quickly CPU speeds increased over the years, shows that a large discrepancy in CPU speeds still exists from the beginning to end of each of the three noted eras.
In the for what it's worth category:
I understand the desire for accuracy/authenticity of emulated systems for TASing. This desire is what has driven both previous and current discussion about PC emulation settings.
However, when it comes to TASing PC/DOS games, I feel we also need to consider that one core concept of TASing is to show superhuman ability.
Given that real humans are speedrunning some of these games on real systems with MUCH higher than intended specs or on unthrottled emulated systems; it is theoretically possible that a human could outmatch a TAS which is forced to be limited to release-date specs. (I'm actually wondering if this will be the case for King's Quest 6, which I've done some basic TAS work on--the RTA community uses an unthrottled emulator which affects movement speed at the highest in-game speed settings). If this occurs, then the TAS is only partially superhuman:
1) If the human is forced to run on native specs, then the TAS would be superhuman.
2) But if the human's unthrottled run is compared to the TAS, the TAS may no longer appear superhuman.
So considering both superhuman play and the concept of fastest completion, I personally have no problem with TASes of DOS games having no CPU speed restrictions at all. Even from the perspective of obsoletion in TASing, I'd be fine with a higher CPU speed run obsoleting a lower CPU speed run even when CPU speed affects gameplay aspects of the TAS.
For example: If the highest CPU setting that one TAS author is able to complete a game is 100mHz, and the submission is published; then another author comes along and is able to beat the same game at 300mHz speed resulting in a faster run. I feel that being able to finish the run using 300mHz speed when other's can't shows greater TASing ability than the author using 100mHz speed. Obviously this would only apply to situations where the CPU speed affects gameplay itself and loading time is disregarded.
I realize there may be many in the community who would disagree with this particular perspective, and I realize that this perspective is unlikely to result in changes to the current rules for JPC-rr or for the rules ultimately created for PCem. I offer it mainly as a way of documenting that this is a perspective that exists in the community.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Yea...I'm not sure how I missed the "4/1." I guess my eyes were just drawn to "Maximum" and I was confused why you were promoting a high golf score. Sorry for the confusion.
FWIW, my thoughts still stand otherwise.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I'd argue that for a golf game, a "Maximum" Score run would actually be the minimum attainable score.
In my opinion, the concept of "Maximum" score from a vault standpoint is essentially the idea of the best possible score performance, not necessarily the highest numerical score value. In most games, that means the highest numerically achievable score. In others games though (some racing games for example) it may mean the lowest achievable time (which may be the best score performance for that game). Given that the best score performance in the rules of golf is actually obtaining a low score, it only makes sense to aim for the minimum numerical score value.
Besides, going for a high numerical value score in golf is actually intending to play poorly, which is somewhat contrary to the superplay idea of TASing in the first place. Given, as you've already noted, that the upper limit of score is capped at 2x Par; the maximum numerical value score can be clearly defined. But given the capped value, it also becomes trivial to achieve.
While it could be argued that whoever can get to that score the fastest still offers a competitive challenge, it still requires intentionally poor play. To achieve the max numerical score; one would only have to hit the ball out of bounds or into water hazards repetitively as needed to rapidly increase the stroke count, then make sure the ball is holed on the stroke that will yield the capped score value.
On a side note, while it can be anticipated that a minimum score performance in a golf game would also yield the fastest overall time, it is theoretically possible that a slightly higher than minimal score may be performed faster. For this reason, I believe that both a fastest completion run and a "Best Score Performance" run could be published side by side in the vault if they aren't the same run.
Well....it's not a dumpster fire.
When I add input, the following occurs and I get the wall of lag:
Then after the input is in place, restarting emulation from the beginning will result in this:
Then sometimes (but not always), clicking to jump back the emulation at an earlier frame results in the big block of lag returning. In this example I clicked to jump back to frame 12:
I'm not sure if this is the same bug that Lobsterzelda is experiencing, but it sounds related.
Again, I'm guessing it's a savestate issue, but I'm not a coder to know how to investigate further. There are no error boxes/logs/reports occurring.