Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
Precedent regarding not using level select codes from the Movie Rules before they were simplified:
No skipping to the end with a password
The point is to demonstrate how quickly a game could be beaten if the player had superhuman abilities; skipping major sections of it with a password defeats the purpose.
Granted, humans can use level select passwords/cheat codes...so does TASing with these options simply show superhuman ability of using those options?
Personally, I don't think intended level select methods should be allowed in most cases (this one included), but ultimately the staff/judges will have to make a decision on this one. Now if a glitch were abused to skip the levels, that's a different situation.
For what it's worth: this run, as presented, looks pretty decent at a cursory glance and is relatively entertaining. If the judge/staff decide the level skip is acceptable, I don't readily see any other reason to reject this submission.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
feos wrote:
But we can still have guidelines on what is most likely a videogame, and what is most likely not. For example, a videogame requires repeated player input to advance. It also has some kind of gameplay, usually posing a challenge, a way to lose and to win. What else?
Just a brief comment on winning/losing: some games (a number of adventure games, for example) cannot actually be lost, aside from the player just giving up because they can't figure out how to win.
That said, the vast majority of applications qualifying as "games" would still retain some sort of win condition (assuming one accepts our site's derived win conditions for looping games).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
Firstly, I want to say that I've been waiting for a full TAS of this game for a while now, and had even considered attacking it myself.
Review:
Syncs on FCEUX 2.2.3 (yea I should probably upgrade this sometime soon).
Desyncs on BizHawk when converted to .bk2 - Even when adjusting the first few inputs to get the first stage starting correctly, desync occurs by the end of the first stage.
I'd be concerned that trying to fuly re-sync this for bizhawk may be a major challenge with RNG manipulation.
Full transparency, I did not watch the entire run at normal speed, I watched it completely at turbo-speed. From what I saw, the run looks pretty solid overall.
Regarding optimization: Since the game limits the collapse of buildings to one-at-a-time, optimization is effectively going to be limited to getting the first building falling as fast as possible, then attacking the remainign buildings to be ready to collapse by the time the first (or previous) is done collapsing. A cursory viewing seems to demonstrate that this is accomplished on most, if not all, levels.
For anyone familiar with casual play of this game, it will be immediately noticalble how little damage is taken. This aspect of the TAS alone makes it superhuman.
The only improvement I can imagine would be finding a stage where it may be possible to get a different building collapsing earlier. Unfortunately, I anticipate that this would affect RNG and require full redo of everything beyond that stage. If I have time before a judge ultimately decides on this submission, I may look into going through stage-by-stage and seeing if I can get differnt buildings toppling earlier, but I'm pretty limited on time right now.
One other possiblity for improving the run might be adding the 2nd player. Normally speaking, a 2nd player wouldn't speed anything up in regards to toppling buildings due to the on-at-a-time building collapse rule. However, if there are stages where Player 2 can get a building toppling faster than Player 1 can due to proximity of the building to the right hand side of the screen, it would yield a faster overall TAS. This would obviously require a complete redo of the game using 2 players. OR, if it would be acceptable, use the "join a game in-progress" feature to use this run as a base and join the 2nd player in just before the first stage where the first right hand building collapse would be faster. Personnally, I think just starting with 2 players would be the better/more impressive option.
I may do a more in-depth review of optimization of 1st builidings later on if I'm able. I may also consider doing a 2-player run myself someday.
I would have made a temp enocde if I could have gotten a bizhawk sync, but I couldn't. And I always seem to get crappy audio when dumping temp encodes from FCEUX, and I don't have time to troubleshoot that right now.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
feos wrote:
I wonder if there are other icon options, something more default (but no less important).
What about a D-pad or joystick? They're pretty standard for most video games (with some exceptions like PC mouse/keyboard), as being able to actually control one's video game is pretty important.
Added benefit of not being associated with any one particular game/series.
We'd then have:
A D-Pad for standard goals
A music box for alternate (artsy) goals
A star for the special runs as they already signify
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
andypanther wrote:
Would it really be too much to ask if we required these types of submissions to work with nothing more than the unmodified game,...
If the primary purpose of these types of runs were to be submissions on the site, then that would be a restriction worth considering (though we already allow runs of ROM hacks, which are essentially modified games). It would also make sense to require full adherence to the current site rules, IF the primary intent was submission.
But, while this run has now been submitted, the primary purpose of its creation wasn't to submit to tasvideos.org.
It was first and foremost created to be presented live as a form of entertainment, art, and TAS showcase.
The perspectives against having these kind of runs allowable on the site seem, to me, to center around the issue of treating them as if they were any other typical submission that was created for the primary purpose of being submitted to the site.
We must realize that these aren't typical submissions. They shouldn't be judged via the typical judging process. Nor should they get a typical publication as with the main runs on our site. But none of this means that we can't/shouldn't somehow acknowledge these runs and the awareness/promotion they provide to the TASing community. They need a place somewhere on our site.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
TASBot showcases at various live events has been a major, if not the biggest (YouTube itself may be bigger), contributing factor of exposure for both 1) the hobby of TASing and 2) our site to the general public as well as to other speedrunning communities.
I find it absurd that one of our greatest exposures has been effectively prevented from having some aspect of inclusion on the site directly.
I, myself, would likely have never gotten into TASing without having seen dwangoAC and TASBot promoting both the hobby and the site.
Can such showcases exist within our current publication model? Obviously, no. The reasons have already been well explained. And I agree in that they shouldn't be housed simply mixed in amongst the normal movies/publications on the site.
But this doesn't mean we can't create a special space for these showcases (gruefood delight is not adequate). If we do create a special part of the site to house such runs/events, it could/should be CLEARLY noted on that page that these runs don't follow normal site rules and aren't judged as normal submissions are. That note should further include that these runs inclusion on the site is due to the awareness that such runs bring to the TASing community as a whole and to the extents of what TASing is capable of accomplishing.
These showcases are TASes. They are Tool Assisted Superplays. Even when human interaction is also required, the results still require TAS inputs.
Are they speedruns? Not always. Are they superplays? Typically. Do they promote TASing as a hobby? ABSOLUTELY! And they often promote our site directly.
At bare minimum, i feel we should have a highlighted wiki page that at least links to the videos of the original runs/events.
As a response to the idea that our site is solely for hosting entertaining TASes and world record TASes: if this is truly the case, then we should eliminate things like player profiles, player points, or anything else that's not strictly necessary to host entertaining TASes and world records. These live TASing showcases are no less valuable than player profiles. On the contrary, they are arguably more valuable to the site as a whole than player profiles or player points.
Adding these showcases (with the appropriate notes mentioned above) doesn't take away from the site's goals of hosting input files for world records and entertaining TASes, nor does it lessen the value of those goals and the accomplishments of the movies that we publish through our normal publication methods.
Having these showcases wouldn't suddenly make our site NOT the site that houses TASing records and entertaining TASes, nor would they suddenly become the major purpose for visiting our site.
Adding these showcases does, however, allow our site to officially recognize the promotion these TASes provide for our hobby.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
Just posting to voice my support of accepting board games to Standard.
I've never liked the claim that a board game on a console/pc isn't considered a "real" video game effectively because it began its existence (or is also available) in a non-video format. It's a game being played on a video screen that uses inputs in the same ways as nearly all other video games. That alone makes it a video game in my opinion. They can also be TASed like any other game, and they often have potential for optimization (i.e. through RNG manipulation as mentioned in posts above).
Another consideration: many puzzle games (like Boxxle), that are already accepted, could easily be converted to physical materials and played on a board on a tabletop as a board game. Would those have been unacceptable if the board game version had existed first?
The one caveat i would add regarding potentially accepting board games, is that competitive board games should require at least one computer/ai opponent to be acceptable in Standard.
TASes of competitive board games that only use "human" players should need to meet community consensus for acceptance to Moons/Alternatives. Otherwise Playground could be considered as a possible landing spot before outright rejection.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
To avoid two-word names we could just pluralize and use
Standards
Alternates (or Alternatives)
Then in judgements the language "Accepted to Standards" or "Accepted to Alternates/Alternatives" could be used.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
As NYMX mentioned, I had been discussing with him that I was under the impression that exhausing all difficulty increases was no longer strictly required for looping games, so long as new content was not being introduced as the method of increasing the difficulty (i.e. speed increase as the only difficulty increase). I would have sworn that I remember seeing a disucssion about this somewhere, but for the life of me, I can't find it now. I had also mentioned that I was under the impression (again from that discussion that I can't find at the moment), that longer runs which showcased more of the harder dififculty loops would be preferred over shorter runs of fewer loops when such runs came under consideration for obsoletion. But I was still under the impression that a singular loop of a game would be sufficient if no new content were introduced thereafter. I had also shared with Spikestuff that this was my understanding of site policy for loopign games.
Here is the rule as it's currently are written:
If there's no clear ending, end after all unique content (enemies, level layouts, game mechanics, etc.) is exhausted.
-Alternately, after completing all unique content, you may end when the in-game difficulty (enemy speed, AI, etc.) stops increasing.
The way I read this; the first line states that exhausting unique content is the minimial end point for looping games. The second line allows for (but does not require) continuing farther onward through all difficulty increases.
These are the basis for my understanding of the policy on looping games, and also the reasons I believe that one loop may be sufficient for a game like this one.
FWIW, I will be performing a formal review of this run as-is. I'll update this post with that review once I complete that review.REVIEW:
I was able to sync the run.
Optimization looks solid; I wasn't easily able to find any improvements.
Completely theoretical improvements:
1) Forest Stage - IF the vine swings could be better manipulated, this stage may be improvable.
2) River Stage - There are two types of crocodiles (standard and rogue). Multiple standard crocs can be on-screen at one time with their spawns being separated by 64 frames on a count-down timer stored at RAM address 0x64. Only one rogue croc will be on-screen at any one time. Having a rogue croc on-screen prevents standard ones from spawning even if the timer hits zero. So IF it were possible prevent rogue crocs from spawing and yield only groups of standard crocs, it would be possible to clear the necessary 14 crocodiles faster. I was not able to readily deduce how the game determines when to spawn a rogue instead of standard. (I tried using trace-logger to no avail).
3) Boulder Field - There are a couple large boulders that Winslinator ducks underneath instead of jumping over. Ducking stops horizontal leftward movement slightly delaying progress. While it is possible to jump over the first of these two large boulders (pressing UP while jumping in this stage increases Dashly's jump height slightly) and maintain forward momentum, I was not able to jump the second without manually delaying movement anyway. So waiting to duck for this second large boulder effectively eliminated the savings made by high-jumping the first. I didn't dig in to see if the boulder sequence is predetermined or if it's RNG, but IIRC it is RNG based in other ports of the game. So IF it's also RNG based in this version, it may be possible to manipulate boulders in such a way that could yield a sequence where no ducking was necessary; this would save a few frames.
Thoughts on difficulty:
1) The game's manual allows for staring on two different difficulties; this run uses the harder. The manual also mentions that the difficulty increases in subsequent loops after rescuing Lady P, but does not specifically describe HOW the difficulty increases.
2) In other ports, a monkey is added to the Forest stage. The monkey climbs on vines and can knock Dashly off a vine, thus making that stage more difficult. This port does not contain the monkey.
3) The gators do increase speed on the loop immediately following this run, but their speed doesn't seem to increase further with subsequent loops. (The loop number is stored in RAM address 0x0B, and selecting the harder difficulty at the start simply increases this from 0 to 1, effectively making this run's starting loop what would normally be the second loop if starting on easiest difficulty).
4) In the Boulder stage, the boulders do seem to bounce slightly different heights when poking different values into the adress that holds the Loop #, but this is mitigated by holding UP on the jumps. The sequence of boulders was otherwise unchanged, and thus is either pre-programmed or based on RNG values from earlier in the game.
5) I did not note any differences in the Cannibal stage regardless of what values I was poking into the Loop # address.
SO....thoughts on difficulty while also considering my comments above this review: I believe 1 loop of this game is sufficient to satisfy the rule requirement of exhausting new content. That being said, it would require only one more loop of play to also exhaust difficulty increases of this otherwise never-ending game (the loop counter resets to 0 after 255). Therefore, while I feel this submission is acceptable as-is, I'd strongly encourage Winslinator to revisit this run and complete the 2nd loop so as to also exhaust difficulty increases.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
For now, I only have a comment on number 3:
I don't think we should accept SRAM that isn't obtainable through normal/TAS play (i.e. via hex editing in max stats that wouldn't be obtainable otherwise).
While I understand the argument (and potential time benefit to the author) of being able to manually create an SRAM file that would be possible to achieve through normal play, I personally feel that we should still restrict SRAM anchored movies to provide verification movies.
I realize this may require more work from the author's position, but it would simplify judging. If a judge has the verification movie inputs, it's more readily determinable that the utilized SRAM is legitimate. If, however, verification inputs are not provided/unknown, the judge would then be tasked with first verifying the legitimacy of the SRAM before consideration of the submission in question could even begin.
Much like Samsara, I tend to lean toward a wider acceptance of runs for publication, but there does have to be a line somewhere.
Hypothetical example; if i hex edit a savegame file for a DOS game to provide an longer than legitimately achievable invulnerability time, I could breeze through a game much faster than without that ability.
So if i provide a run that has that savegame situation without any verification inputs, the judge would first have to determine if that ability is achievable normally before they can even start judging the run submitted.
Even if someone provides a manually created SRAM while claiming it's indeed possible to yield that save information via real play, it still falls to the judge to verify that claim if there is no verification movie.
TL:DR In my opinion, SRAM should only be accepted with verification movies provided that create said SRAM state. The impetus for proving legit SRAM should be on the author, not on the judges.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
As noted in the submission text, I've already had a chance to review this run and could not find any improvements in routing or optimization. Movment controls are rather limited and many platforming actions that are common in modern games are not an option here: i.e. jumping to/from ladders, jumping across screen borders, changing direction/speed mid-jump.
In the run, there are a few frame perfect movements/jumps that would be rather difficult for a human, but I won't say impossible for a human. The run uses death to save time; and when death warping, NYMX does a good job of utilizing death by falling off the screen as opposed to falling onto a platform. Falling from the screen results in less time required to regain control with the next life compared to dying by a fall onto a platform.
Frankly, this is an impressive game from the standpoint of it being a game that was published in a magazine and meant to be typed into the C64 by the reader themselves. It's a solid run, and appears acceptable to me.
The ROM/disk image used in this run is a disk image containing the programs from Compute! Gazette magazine Issue 79 (January 1990). Interesting side note on that particular issue: there is an article on Neural Networks, Artificial Intelligence, and the future of computing.
EDIT: For anyone interested, here's the pages of the magazine with the game's code. (Sorry about the big images, but I figured it'd be harder to read if I shurnk them any.)
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
feos wrote:
Being restricted to replay files would result in hacking around this restriction by providing dummy files, but we'd also have to do something about movie length to make it present some actual info about the duration of the event in question. That sounds even more hacky.
(emphasis mine)
Regarding length of run: If a dummy movie file is going to be present anyway, we could make it from all blank inputs that was as many frames long as needed to show the appropriate time frame.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
I support finding a way to do this. I find the idea of a separate publication type/area of site (as described in the "future" section of Samsara's post) to be an ideal goal.
We need to find a way to officially recognize/publish these showcase runs that otherwise can't be processed through our standard judging process due to the need for extra hardware or external data only possible at such a live event.
In my opinion, TASing, at its core, is effectively answering the question, "What can be done in/to this game with a sequence of perfectly timed button presses?" While we typically answer this question along the lines of "beating games really fast, often in entertaining ways," these showcases are simply offering different answers to that same question.
Unfortunately, some of these showcases use unscripted data from an outside source (live chat, or even human input like Savestate's in the SGDQ 2022 example), which isn't information we can "verify" in an input file. HOWEVER, the results that are seen on the screen at the event are still the result of button presses processed through the controller ports.
These runs stand therefore as valid answers (albeit very complex ones) to the question of "What can be done in/to this game with a sequence of perfectly timed button presses?". We need to officially celebrate them by some means of inclusion on the site (beyond gruefood).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
To put my opinion as concisely as possible:
I like the idea of allowing in-game codes into standard if they ADD to gameplay, but not if they take away from gameplay.
I think external codes should always be limited to Moons, with one hypothetical exception:
In the event that there is a game out there (or will be in the future) that has a programming bug present which prevents a normal win condition from being achieved; I'm fine with an external code being used to bypass the bug and allow succesful completion the game. I think that only this one situation should be eligible for standard. Ideally, the external code here would only allow bypassing the bug and not enable other features that allow for skipping other gameplay.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
feos wrote:
I feel if we call the branch label "minimum jumps" it would be neater and more informative at the same time, while still being accurate. Sorry it took me so long to raise this question, but what does everyone think?
Objectively, "Minimum A Presses" and "Minimum Jumps" are not guaranteed to always be equivalent (though they may be in this case, I haven't looked that closely at the input to confirm).
Further, a "Minimum A Frames" run could be another potential variant between two runs with otherwise equal number of A button presses. Or, in theory, it may be possible to have a run with a greater total number of A button presses yet presenting a lower total number of frames with A being pressed.
My opinion on this submission/publicaiton: I agree that "Minimum Jumps" is more readily understandable as what to expect when watching this run.
As this run currently is BOTH the known "Minimum A Presses" and "Minimum Jumps", either branch name would be valid. I'm going to make an assumption (because I'm too lazy to go count A frames) that this submission also likely qualifies as "Minimum A Frames."
If someone someday manages to make an acceptable TAS where at least one of the 3 minimums is present, but not all 3; we may need to consider rebranching as appropriate.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
MESHUGGAH wrote:
Also I had no idea that an A2600 TAS can sync on both NTSC and PAL ROM.
This may not be the case for all games, but it does work with this one. The frames are just longer in PAL mode. I've run into something similar before; I think it was with a C64 game (EDIT: If I remember correctly, it was Monty on the Run for C64. Movement synced, but RNG didn't.). It would be interesting to try this on other games as well.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
In reviewing this run, I was able to implement some movement improvements scattered through the run.
Stage 1 (16 Frames Saved): Started moving earlier and managed to get the 10th hit on the skeleton a bit earlier to move to stage two.
Stage 2 (0 Frames Saved): Different attack pattern to avoid the axe. Otherwise no frames difference.
Stage 3 (14 Frames Saved): Better movement (more diagonals) to exit the maze faster.
Stage 4 (45 Frames Saved): Better movement (more diagonals) to exit the maze faster.
Stage 5 (2 Frames Lost): Unfortunately I lost two frames here and can't figure out why. Even just copying the original requires adding two frames. The player character must move up to y-position=15 while touching the freed boy to end the game.
Total improvement = 73 Frames
Here is an updated .bk2.And a temp encode.
https://youtu.be/kZIQXhatvHo
Once I have coauthorship/editing rights on the submission, I'll change the main encode to this one.
Here's a side-by-side GIF comparison of the run before and after improvements.
I also discovered a minor ROM issue. Checking the ROM used for this run using goodtools yields "Ghost Manor (1983) (Xonox) [o1].a26" The [o1] indicates that the ROM is an overdump ROM. For those who may not know, overdump ROMs have extra unused data beyond the actual game data in the ROM file itself. This extra data is meaningless and doesn't impact the game in any way.
Unfortunately, goodtools does not have a [!] marked ROM for this game indicating a known proper dump of the game. There is a ROM in the goodtools database that's not labeled with any notations "Ghost Manor (1983) (Xonox).a26" but this ROM only seems to contain the first stage of the game (it resets to the beginning once the spears are collected).
There is a PAL version that has the [!] known good dump indicator; interestingly the inputs from this run sync perfectly on the PAL version but the overall play is slower due to the framerate differences.
Due to these issues with the ROM, I think the overdump version is likely the best to use for this game, as it allows a full game NTSC run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
I think it's great you took the idea to the next level by showing off as many animations as possible while doing it in actual gameplay from standard starting positions.
Too bad there's no way to show all animations in a single standard game.
While this may not be publishable in Standard; if it doesn't qualify for Moon class, I think it falls solidly in line with the Playground.
For the judge: On the note of playground... would my original run linked in this submission now also qualify for Playground?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
A few ideas:
"Unacceptable"
"Currently unacceptable"
"Unpublishable"
"Unpublished"
"Currently Unpublished"
"Withheld"
"Currently denied"
"Denied" (though without "Currently" it's not much different than rejected.)
"Vetoed"
"Suppressed" (i kinda like this one. It may be suppressed now, but could come back in the future)
"Inadmissable"
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
Well done!
Throwing out a personal opinion here:
IfWhen this is accepted, I feel it should be accepted alongside the current run as a different branch (as opposed to obsoleting the current run), because the bat presence/manipulation introduces significantly different gameplay possibilities which yield a completely new approach the run that is simply unavailable at the easiest difficulty. The differences result in completely different routes and item use. If this is done, the current publication would likely need its publication ammended to include "easy difficulty" or something similar as its branch.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
While it would still be my personal preference, if doing so would create a greater problem, then the alphabetizing doesn't need changed.
I only suggested it in the first place due to that method being the standardized way for alpabetizing titles in English (which, while others languages are present, is our site's primary language).
The exact order of the lists isn't critical either way; because, as was already mentioned, we also have search functions to find things.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2070)
Joined: 8/21/2016
Posts: 1012
Location: US
When it comes to the listing of games in our system, all games that start with the word "The" are currently placed in the "T" section of alphabetical lists. For example, in the NES tab of the Games page, there are currently 48 entries that start with the word "The." These are all in the "T" section.
I think we should we consider renaming these game entries by having "The" moved to the end of the game entry (i.e. changing The Goonies into Goonies, The) so that these games show up in the alphabetical list based on the first main word in the title instead of the word "The"? This is a standard way of alphabetizing titles in various other areas of life--one example being bibliographic notation.
Using The Goonies as an example, instead of being listed after The Flintstones: The Surprise at Dinosaur Peak!, making this change would instead move it to being after Golgo 13: Top Secret Episode.
Here is an example of such alphabatizing using NES games from Wikipedia.
EDIT: If there's a way to have the games alphabatized the way I'm describing, but still displayed with "The" at the beginning of the name, that would also be fine. I just feel the alphabitizing needs to happen on the next word instead of "The."
I also discovered a minor ROM issue. Checking the ROM used for this run using goodtools yields "Ghost Manor (1983) (Xonox) [o1].a26" The [o1] indicates that the ROM is an overdump ROM. For those who may not know, overdump ROMs have extra unused data beyond the actual game data in the ROM file itself. This extra data is meaningless and doesn't impact the game in any way.
Unfortunately, goodtools does not have a [!] marked ROM for this game indicating a known proper dump of the game. There is a ROM in the goodtools database that's not labeled with any notations "Ghost Manor (1983) (Xonox).a26" but this ROM only seems to contain the first stage of the game (it resets to the beginning once the spears are collected).
There is a PAL version that has the [!] known good dump indicator; interestingly the inputs from this run sync perfectly on the PAL version but the overall play is slower due to the framerate differences.
Due to these issues with the ROM, I think the overdump version is likely the best to use for this game, as it allows a full game NTSC run.