United StatesThe only other consideration for this journal entry is considering what the developer's intention was for the journal entry. While I'm not aware of any statements by the developers on the topic, we can make an educated guess based on the information we have. The journal entry's description when not completed references collecting all 12 balloons, the journal entry's description when completed mentions collecting a "beret", and the patch notes for the Nov 17 update says "Red Beret greatly enhanced". The only changes related to hats in the Nov 17 update (that I'm aware of) is the addition of the triple-balloon hat behind the 12-balloon door. With all this in mind, I believe that the "beret" referenced in the journal entry's description is supposed to refer to the triple-balloon hat, and the journal entry is supposed to be triggered by collecting that hat. This makes since, as the same update that added the hat also broke the journal entry, suggesting they attempted to switch the trigger to the hat and messed up. This means that an alternate category ruling could be to require collecting the triple-balloon hat to match the developer intent for the journal entry. However, the rest of the run takes the journal entries as they're implemented, not as they're intended (eg. the sequence break for the "Master Twig" journal entry), so it doesn't make as much sense to handle this journal entry this way. Collecting the triple-hat balloon would be required by a 100% category (along side collecting all the batteries and shells and/or shop items), and a subcategory for All Journal Entries could be created requiring the collection of the triple-balloon hat if there's interest from runners. However, until someone does the work to define, route, and run these categories, there's no need to create the category leaderboards for these.
~ ~ ~
That's the breakdown of why these two journal entries are excluded from the All Journal Entries category. If you have any questions about this, feel free to ask me. Otherwise, good luck running the new category.
The new leaderboard category All Journal Entries for this game has the following line in the category rules:
The journal entries "Mystical Treasure" and "Go to tram station" are not required.
Considering the purpose of the category is to complete all the in-game achievements / journal entries, it's not immediately obvious why it would exclude these journal entries. The purpose of this forum post is to provide a comprehensive explanation for why the category is setup this way.
Short Answer: The journal entries "Mystical Treasure" and "Go to tram station" are affected by game bugs that would make their inclusion in the category problematic.
To explain the issues with these journal entries, I need to break down each entry separately.
~ Go to tram station ~
This is the comparatively easier journal entry to explain. When the trigger for this journal entry works, it's triggered by walking in front of the tram in Coastal Plain (around where Miss Tricket is). The problem is that this entry doesn't always trigger when it is supposed to. Specifically, whether the trigger for this journal entry works depends on which option is selected on the main menu. If the player selects "Start Journey" to start a new game, the trigger for the journal entry won't work, but if the player selects "Continue" to load a save, then the trigger will work. This means that completing this journal entry requires quitting the game and relaunching it at some point in the run.
This all means that the journal entry is technically completable if the runner quits the game and restarts it at some point during the run, but it was still decided not to require it. An important factor in this decision was considering how exactly the run would change if it was required. Notably, the journal entry "Take the tram" effectively assumes the completion of "Go to tram station", as the former requires talking to Miss Tricket inside the trigger for the latter. With that in mind, the only change that requiring "Go to tram station" would make to the route is to require the runner to relaunch the game. In the interest of making the category simpler to run, it was decided not to require the journal entry.
~ Mystical Treasure ~
This journal entry is more complicated to explain because its behavior changed with a game update on November 17, 2022. In the current game patch, this journal entry is simply incompletable. There are multiple threads (in both english and chinese) on the game's Steam discussion board asking about the bug, so it's seems to be a common problem with the game. Prior to that update, the journal entry was actually completable. There is a trigger area inside the vault (not present in the latest patch) that causes the backpack to say "Nyan! It's a battery!" and triggers the completion of the journal entry. This dialog trigger spans the space between the 9-balloon and 12-balloon door, so approaching either battery in the vault is sufficient to trigger the journal entry in these game versions.
Originally, the options being considered were to either create a (sub)category split depending on the game version (requiring the journal entry for game versions where it's collectable) or define the category to require opening the 9-balloon door to create a degree of requirement parity between game versions. However, it was discovered that, for the game versions where the journal entry is completable, it's possible to get the entry by simply standing in front of the 12-balloon door without having to open it (YouTube video). With this in mind, it became clear that the only difference between a run requiring the journal entry (in game versions where it's completable) and not requiring it is a small diversion taking just few second, which isn't worth creating a (sub)category split over. Similarly, the removal of the dialog trigger in the latest patch means there's no similar event to check for on the latest patch, preventing a simple category rule to create run parity that way. As such, it was decided to simply ignore this journal entry entirely, as excluding it doesn't significantly impact the category.
cont.
I've been discussing the rules and definition of the "Glitchless" category with ripWSB in the OSC discord. I want to quickly summarize here what we talked about, and bring up the ideas for category clarifications and changes we mentioned in there.
The conversation started when we figured out a way of approaching Pilgrim's Peak from the north, and ripWSB mentioned that it could allow for skipping the crown quest in Glitchless. I mentioned that I feel like allowing runs to skip the cable car and crown quests is against the spirit of the category, and wondered if it should be against the category rules. The rules simply say that "glitches are not allowed", which doesn't really clarify what is and isn't allowed. I also realized that ripWSB already submitted a Glitchless run that skipped the cable car quest, which would be affected by whether skipping these quests is allowed or not.
My take on this is that "talking with Grandma in a location before she's moved to that location" qualifies as a glitch. Grandma's behavior is actually pretty straightforward. If the crown quest has been completed, she will be in Pilgrim's Peak (disabled if the player has already talked to her there). If the crown quest has not completed, but the cable car quest has, then she will be in Turtle Rock. Lastly, if neither quest has been completed, she will be in the starting area. If we define talking to grandma somewhere she isn't a glitch, then Glitchless would require completing the cable car quest before the turtle rock cutscene and completing the crown quest before the pilgrim's peak cutscene.
There's also a case to be made that Glitchless should allow this kind of sequence breaking, and instead a new category should be made for not sequence breaking. Based on our current game knowledge, it seems like the glitches that this kind of Glitchless category would ban are super jumps, clipping through walls, and OoB upwarps. A new category could be made then to cover runs that don't use sequence breaks. Personally, I prefer making category rules based on what runners must do rather than what runners cannot do. In this way, the new category would be defined something like "you must do the cable car quest, second grandma conversation, crown quest, and third grandma conversation, in that order." Whether this new category allows glitches would also need to be figured out, as allowing the OoB upwarp glitch would likely affect the route.
Also, with a free demo of the game being available on Steam, it might be nice to add a few demo categories, such as Demo Any% and Demo Glitchless. It is possible to reach the credits in the demo with exploits, but that run isn't really distinct enough from regular Any% to warrant a category. I already performed a run of Demo Any%, so if that category is made, there will be at least one run on there.
The way I've usually seen PC vs Console runs split up on other leaderboards is to made them subcategories of the main categories. So instead of PC being a main category, with Any%, Glitchless, etc. be subcategories on that, you'd instead just have the one Any%, Glitchless, etc and each of those categories would each have a Switch and PC subcategory. It makes it easier to find PC runs, especially since PC Any% won't be relegated to a "miscellaneous" category. (Personally, I think PC should get priority over Switch, but I only say that because I use the PC version. I do think PC runs should be at least equal to the Switch runs, and not hidden under misc categories, though.)
Found a way to clip out of bounds and up-warp to the top of the Stronghold side of the canyon (tested on PC v1.2.3), and a way to jump from there to the other side of the canyon. Unfortunately, you can't just skip the second Grandma conversation, so you do need to backtrack there and talk to her before going back to the Stronghold side.
That being said, this means that a Low% run can now complete the game with zero items. Instead of repairing the bridge, you just perform the clip (again) to up-warp to the other side.
I was in a discussion today with the leaderboard moderator for Melatonin today, and ended up left with an interesting question. There are two categories for that game that are relevant here: All Levels and All Stars and Rings. The first category is just Any% with the requirement to also complete all the levels, and the second category is like All Levels, but also requires completing the "hard mode" variants of each level (in addition to the normal mode), and get the highest (non-perfect) score in all of them.
The discussion was about what would be between them. You could make a category that needs all stars, which excludes the hard modes, or make a category to also do all the hard modes, but not necessarily get the highest score in them. Right now, there's nobody pining to run those categories, but the discussion was over how to handle it if they do get run. The moderator was saying to just make them additional categories (most likely misc. categories), but I had another thought.
In my view, separating categories by the scores you get doesn't make much sense as, assuming perfect skill at the game, it doesn't take longer to get a better score. An all stars run could trivially obsolete a normal all levels run. My idea, then, was to use a variable to indicate the score the run got, and let users filter by that. The problem I see is handling run obsolescence. An all stars run could obsolete an all levels run, but an all levels run that doesn't get all the stars can't obsolete an all stars run. From what I can tell, variables can only be set such that all values obsolete each other or none do, so they can't be used for this ordered relationship.
Is there a way to do this with variables? If not, is there a better way to handle this kind of relationship between runs? Would adding this functionality to variables as a feature to the site be helpful for other games' leaderboards? Additionally, for filtering by these "ordered" variables, it would be nice to have an easy way to say "filter by this value or better" instead of having to select all the values individually to get that.
So I went through all the levels with an emulator and looked at the game's total enemies count during the score screen. There's a decent chance that I made a mistake somewhere here, but this should all be accurate.
Mission 1: 31 Enemies Mission 2: 35 Enemies Mission 3: 27 Enemies Mission 4: 33 Enemies Mission 5: 21 Enemies Mission 6: 52 Enemies Mission 7: 70 Enemies Mission 8: 71 Enemies Mission 9: 9 Enemies
Just to note, what counts as an enemy seems to be kind of weird. The helicopter at the end of the first mission, as well as every boss I checked, do count as an enemy. However, the infinitely respawning enemies at the end of Mission 4 do NOT count.
While I was at it, I also collected all the par times for each mission. These are visible in-game, so this isn't new information, but I figured I'd aggregate it here for future reference.
Mission 1: 300 Seconds Mission 2: 360 Seconds Mission 3: 510 Seconds Mission 4: 540 Seconds Mission 5: 300 Seconds Mission 6: 630 Seconds Mission 7: 690 Seconds Mission 8: 960 Seconds Mission 9: 180 Seconds
EDIT: This was all done on Normal difficulty, though my basic testing suggests this shouldn't change for Hard difficulty.
I posted a message about this in the OSC Discord, but I'll reiterate and expand upon it here for easier access.
The game essentially calculates a percentage value (from 0% to 100%, other than time) for each of the five categories, then multiplies each by 250 to get a score value, other than Dispatched, which is multiplied by 2000 (and time, which works differently). The percentage (other than the Bond bonus) is calculated by dividing two numbers to get a ratio, multiplying by 100, and rounding down. This can be described as the function Percent(Num, Den) = floor(Num * 100 / Den). There are some quirks with how the division is calculated, which I'll mention at the end, but for any case you're likely to run into, this is how it works.
The Bond bonus percentage is the simplest. If ANY emblem is collected, then this is 100%. Otherwise, it's 0%. If there's any possibility of collecting more than one emblem in a level, then there is no benefit to collecting more than one. The number of emblems collected is stored as a 16-bit value at 0x0200073C.
The Dispatched \ Subdued percentage is calculated by keeping a tally of both the number of enemies loaded and enemies taken out, and calculating Percent(Enemies_Disp, Enemies_Total). These counts are stored as 16-bit values, with the dispatched count at 0x02000740 and the total count at 0x02000742. The total count appears to be updated with each map load, so in theory it might be possible to influence this number if a significant sequence break is found. However, for the time being, we can treat this as a constant value for each level. I'll add another message here once I get totals for each mission.
The Accuracy percentage is calculated by keeping a tally of both the number of shots the player has made and how many shots hit something important, and calculating Percent(Shots_Hit, Shots_Fired). It doesn't appear that they have to hit an enemy specifically, as shooting the window in the first mission still counts as a hit. It is not clear at this point how the game counts shots that hit multiple enemies (if possible), but there is a check to make sure the percentage doesn't go above 100%. These counts are stored as 32-bit values, with the hits count at 0x02000734 and the shots count at 0x02000730.
The Health percentage is calculated by taking the number of health chunks still lit up (from 0 to 8 ), and calculating Percent(Health + 1, 9). This only takes into account the health that you complete the level with, so collecting a full armor right at the end of the level is enough to get full points for this category. The health value is stored as a 16-bit value at 0x0200074A.
Time is more complicated to compute, and is also rather strange because the score is not linear with respect to the time taken. The game takes the time taken, rounded down to the nearest whole second, and the par time for the mission, and calculates Percent(Par_Time, Time_Taken). Note that having the actual time taken as the denominator means that the score has an inverse relationship to the time score. From here, the game multiplies the percentage by 1000, and then checks the resulting value X. If X ≥ 125,000, then the time score is set to 25,000. If X < 50,000, then the time score is set to -100,000. Otherwise (if 50,000 ≤ X < 125,000), the time score is X - 100,000. This has the effect that taking exactly twice the par time results in a time score of -50,000, but taking exactly one second longer results in a time score of -100,000. I suspect that this was a mistake in the code, due to the -100,000 matching the subtracted value in the middle case. If we assume that it was meant to be -50,000 instead, then we can rewrite this equation as being 1000 * clamp(Percent(Par_Time, Time_Taken) - 100, -50, 25). The time taken is stored as a 32-bit value of the count of vertical interupts (i.e. 1/60th seconds) at 0x02000738. The level's par time in seconds is stored as a 16-bit value at 0x02000748, which in turn comes from an array of 16-bit values starting at 0x0801EE74 (stored in mission order). Here's a desmos graph of the resulting time score using the first mission's par time: https://www.desmos.com/calculator/jyi4vyumug
The final score is taken by adding together all five component scores, resulting in a score between -100,000 and 300,000 inclusive. For all of the missions, Bronze requires 190,000 points, Silver requires 245,000 points, and Gold requires 270,000 points. This is pretty much all there is to the scoring system.
Now, here's some information about how the game performs division. The GBA's CPU lacks any instructions to perform division, so it has to use some tricks to make it work. Starting at 0x08021400, there is an array of 16,384 32-bit values, where the X indexed value (starting at X=0) is equal to 2^32 / X (The exceptions being at X=0, X=1, and X=2, which are all equal to 2^31 - 1). Using this array I'll call DivTable, the game performs division by calculating Div(Num, Den) = floor((Num * DivTable[Den]) / 2^32) (with the floor of the division by a power of two in these equations being implemented using a bit shift). There are a few special cases to this, though. The first special case is that it short circuits if Den < 2, which means that Div(Num, 0) = Div(Num, 1) = Num. This has some interesting effects, most notably that never firing a weapon counts as 0% Accuracy. The next special case is when Den = 2, where it simply performs a bit shift to perform the division. This is because the value for DivTable[2] isn't accurate (nor is there a valid signed value it could use). The last case is when DivTable[Den] doesn't exist, which happens when Den ≥ 16,384. When this happens, the game approximates the value using Div(Num, Den) = Div(floor(Num / 2), floor(Den / 2)). This could produce some interesting rounding issues if it ever comes up, but it would have to be a pretty exceptional case for it to come up at all.
EDIT: Also, using Hard difficulty appears to add a flat 10,000 points to your score. The bonus is added before the ranking (bronze, silver, gold) is determined, so you need slightly less for bronze on hard mode.
EDIT 2: Coming back to this game, and spending more time reverse-engineering this, I realized there's a type of edge case that should also be mentioned. You see, DivTable[X] isn't quite 2^32 / X, but instead is floor(2^32 / X). This adds an additional rounding step to the division which can result in incorrect values in some edge cases. While these edge cases are unlikely to come up in practice, it's worth keeping in mind that the percentage that the game shows can be rounded down by more than a whole percent in a worst-case scenario.
BTW superjack126:
The full-game categories have now been added. I also see that you're in the Discord, but haven't accepted the rules, so you can't see the chat rooms. If you want to participate in the server, you need to click the checkmark underneath the rules in the rules channel.
You got to bringing this up before I could. I see you're in the Discord (but not in #general because you haven't accepted the rules? I didn't setup the server, so I'm not 100% how it works). I planned on bringing up the issue of a full-game run in there at some point. I'm working on a Livesplit plugin that works similarly to my IL tool because I like autosplitters, and the autosplitter might help define how timing should work (eg. real-time vs sum of track times). Once that's at a relatively-stable point, I will bring up the topic in general to get feedback on how the category should work. Currently the biggest question I have about making the category is whether to have the run use the RACE or SPDRUN mode (basically what catalina said).
So to anybody wondering about this: Adding a full-game category is planned. Come join the Discord to follow and provide input.
The (current) decision is to allow online runs in empty lobbies. This was decided after talking to the developer and taking a brief look at the decompilation of the game's C# code and determining that the logic for physics and the race timer occur locally (enough) in online play to not be significantly different from offline play. It's still recommended that you play offline when specifically grinding for times to avoid people hopping in and invalidating the run, but runs won't be rejected simply for being played online.
To get ahead of the debate, I'm making this thread here to discuss the game-wide rule that all runs must be made in the "Offline" mode. My rationale for this rule was that the instability of adding an internet connection could influence the results of the game. However, I can understand this being a contentious rule, as most people will play online the majority of the time (especially if they're playing it casually).
Put your thoughts and opinions on this rule in this thread. I'll look over the arguments and try to make a decision that will make most of the community happy.
I've also created a strawpoll over the options as I see it. If you have an opinion on this, please respond to the poll (in addition to any comments you make here), so I can see what the general opinion is. https://www.strawpoll.me/20687530
I think I already know the answer, but I figure it's doesn't hurt to ask and see if there is any sort of protocol in place.
I am the moderator on the leaderboard for Empathy: Path of Whispers. The game's name is very often shortened to Empathy, to the point where that's what it's still referred to on Twitch. (That comes in large part due to the subtitle being added very close to launch, and the GiantBomb database not being updated until I asked them to myself.) I would want to use speedrun.com/Empathy for the game, but that is currently taken by a user by that name. The account appears, to me at least, to be inactive/abandoned. The info page says they were last online 3 years ago (close to the age of the account) with 0 posts or runs.
I know that currently, with my game having no runners other than me, there's not going to be any sort of special case for me, so I'm wondering if there is a protocol for this kind of thing. Is there an "abandoned account" system? This isn't a huge issue for me, as I did recently change the permalink to one I am relatively happy with (as apposed to the old one, which was the game's full name), and if it were, I could always message the user on their linked accounts to see if they'd willingly change their permalink. I'm just curious if there's rules or systems already in place about this.
I have a game request currently pending for a game I want to get a speedrunning community started for. In the section for "Additional notes by the user", I made a speculation/observation about part of the game. Today, the developer made a comment that very much confirmed my speculation. I was wondering if I could (or should) update my request to include this specific quote to better clarify the submission.
