TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #5129: The8bitbeast's SMS Sonic the Hedgehog in 15:03.71

Console: Sega MasterSystem
Game name: Sonic the Hedgehog
Game version: USA/Europe
ROM filename: Sonic the Hedgehog (UE) [!].sms
Branch:
Emulator: Bizhawk 1.11.6
Movie length: 15:03.71
FrameCount: 54153
Re-record count: 33856
Author's real name: Jake M
Author's nickname: The8bitbeast
Submitter: The8bitbeast
Submitted at: 2016-05-31 09:15:14
Text last edited at: 2018-08-10 10:09:58
Text last edited by: The8bitbeast
Download: Download (16605 bytes)
Status: published
Click to view the actual publication
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

(Link to video)

Sonic the Hedgehog is one of Sega’s most successful mascots, appearing shortly after Alex Kidd and Opa Opa. The first Sonic game was released in 1991 for the Genesis/Megadrive titled “Sonic the Hedgehog”. Later that year, Sega released a Master System version of the same name. The Master System version is completely different from the Genesis version. Sega then released the Game Gear version which is a reworked clone of the Master System version.

Dr. Ivo Robotnik, the mad scientist, is snatching innocent animals and turning them into evil robots! Only one tough dude can put an end to the demented scientist’s fiendish scheme. It’s Sonic, the real cool hedgehog with the spiked haircut and power sneakers that give him super speed. Spin ‘til you’re dizzy, save the animals and become the super hero. Be Sonic! Be atomic!

This Tool Assisted Speedrun completes the Master System version as fast as possible, omitting the chaos emeralds.

Version Choice

The Master System and Game Gear versions have different layouts for most levels ranging from slight to fundamental changes. In addition, most of the bosses behave differently between the two versions, requiring different strategies. In general the boss fights in the Game Gear version are easier. Due to the significant differences between the two versions I think they both deserve separate publications, however, if only one run were published I would choose the Master System for the following reasons:

• The Master System has a much bigger viewport so the action is more visible throughout the run.

• The Master System version has much shorter score screens, with the Game Gear version's being 10x longer at maximum time bonus. This means that the action is broken up less in a Master System run and greatly reduces the time spent hearing the ear piercing sound of the score screen ticking down.

• In response to the Game Gear TAS, I’ve seen a lot of comments saying that a Master System TAS would be better. So there is some interest in the Master System version from the community.

• This TAS includes more thorough optimization and a new horizontal underflow glitch.

• The Master System version was released before the Game Gear version, meaning TASvideos rules would obsolete the Game Gear run by default.

Naturally, there are also advantages to the Game Gear version. It’s easier to play a copy of the Game Gear version than the Master System version due to it being included in compilation titles such as Sonic Mega Collection Plus on the PS2, Gamecube, and XBOX. Also, the US Master System version is the rarest game on the console, despite the cartridge and ROM being identical to the common PAL version.

In the first boss on the Master System version, Ivo flies just in range to be hit but it is quite difficult to do so. In the Game Gear version he flies low enough to be hit at any time, possibly to compensate for the smaller viewport. This makes the fight much more consistent for non-tool assisted speedruns on the Game Gear version.

Since rarity of a game and consistency of a speedrun doesn’t affect a TAS, these Game Gear advantages were outweighed by the Master System advantages in my version choice.

Timing Method

The timing method that I decided to use for this run was real time minus the time spent in bonus screens.

The reason that I did not optimize purely for real time is the variable length bonus screens at the end of each level. Since completing the level with lower in game time results in a larger time bonus and therefore a longer bonus screen, there are ranges of game times such that instead of finishing the level, it would be quicker in real time to wait for the smaller time bonus. For example, If the level is completed between 26.67 to 30 seconds IGT exclusive, it would be quicker in real time to wait until 30 seconds IGT to finish the level with the lower time bonus. If pure real time were used, levels where waiting was faster for real time would require little optimization and become trivially easy and potentially sloppy.

A common opinion is that only game time should be used, but this also has some issues.

The issue with optimizing purely for game time that is most obvious from unassisted runs is the signpost at the end of the level. When hitting the signpost it will spin in the air with the height depending on how fast it was hit. Stopping movement before the signpost is quicker in real time since it shortens the spinning animation but has the potential to reach the next second of game time in some levels. In this run I have decided to stop to shorten this animation. If this wasn’t the case, it could lead to carelessness such as in the Game Gear TAS where there is enough time to stop at the end of the first level before the screen catches up, but the signpost is still hit at full speed costing unnecessary real time with no game time saved.

The less obvious issue with game time is lag. Game time doesn’t count up during lag, so optimizing for game time could completely ignore lag reduction. This would make some levels such as Bridge Zone 2 trivially easy to TAS, again leading to carelessness. Also completing Bridge Zone 1 with 0:21 game time is actually faster in real time than 0:19 which I’ll explain in the IL comments. When optimizing for game time, creating as much lag as possible in the boss fights would be used since lag doesn’t slow the boss down.

Since optimizing purely for real time leads to awkward waiting periods in levels, and optimizing purely for game time leads to potential for carelessness, my chosen solution is to time from the frame that the level fades in, until the frame that it fades out. This eliminates the issues with lag, signposts and bonus screens.

I’ve summarized each possible timing method in the following table. The game time is naturally measured in minutes:seconds.frames for which I have converted .frames to .centiseconds. I also include any levels where slowing down would lead to a faster real time due to bonus screens. Keep in mind that these are not the best possible game times since optimizing purely for game time was not my goal. Also the game time counts until fade out for the boss levels. Interestingly, the game time counts during the end cutscene, I don’t include this in the total since input has ended at this point.

Level Real Time (Fade in to fade out) Time lost to quick finish IGT (.frames) IGT (.Centiseconds)
GH1 1542 0 0:18.36 0:18.60
GH2 1704 0 0:20.59 0:20.98
GH3 3100 0 0:50.43 0:50.71
B1 1765 0 0:21.09 0:21.15
B2 7604 15 1:59.55 1:59.92
B3 1693 33 0:27.13 0:27.22
J1 2074 0 0:25.58 0:25.97
J2 2774 0 0:35.51 0:35.85
J3 1833 173 0:29.33 0:29.55
L1 2928 0 0:35.07 0:35.12
L2 829 0 0:07.58 0:07.97
L3 2861 0 0:44.53 0:44.88
ScB1 2096 63 0:27.43 0:27.72
ScB2 4089 0 0:49.34 (35.34+14.00) 0:49.57
ScB3 2702 0 0:43.13 0:43.22
SkB1 1962 0 0:25.27 0:25.45
SkB2 1319 0 0:11.55 0:11.92
SkB3 1017 (to last input) 0 0:18.37 0:18.62
End (Not in total) 0:13.39 0:13.65
Total Frames:43892 Time: 12:11.53 Frames: 284 Time: 4.733 sec 10:14.25 10:14.42

Since waiting for shorter bonus screens during this run would only save 4.733 seconds in real time, standard TAS timing, purely real time from power on, is still a very good alternative to time this run.

Tricks and Techniques

No TAS would be complete without extensive use of a RAM watch. Sonic's position is quite complicated, but velocity can be observed with a simple RAM watch. Here are some useful addresses.

X velocity (2 bytes) 0x1403
Y velocity (2 bytes) 0x1406
Game Time (3 bytes) 0x12CE
Rings 0x12AA
Lives 0x1246
Level 0x123E

Thanks to Isotarge for giving me his RAM watch which contained these addresses. His work can be found at https://github.com/Isotarge/ScriptHawk

This TAS is all about building and maintaining speed. If you can build a little more speed, that difference will be present on all following frames giving a large net improvement. The majority of tricks in this run are to do with building and maintaining more speed than intended.

Broken Speed Cap

When not in water, Sonic's X speed is capped when it exceeds 0x0300. However, the cap is only applied when Sonic is walking or jumping and the same d-pad direction is pressed. If Sonic is moving faster than the speed cap it is best to let go of all directions to preserve this speed as the cap will not be applied. Water has a speed cap of 0x0100 which can be exploited in the same way as on land. So if Sonic is entering the water at walking speed, it is best to let go of the direction input temporarily to avoid the speed cap being applied. This allows for less painful movement speed when entering water. Exploiting the cap in this way is possible in an unassisted run.

Normal acceleration when holding right is 0x0010 velocity units per frame. When not holding any direction, acceleration is -0x0010. If the speed is 0x02FF and right is pressed, speed on the next frame will be 0x030F. If right is held on the next frame, speed would be capped to 0x0300. But if right is released, speed would be reduced back down to 0x02FF. Therefore it is possible to alternate between pressing right and letting go every frame to alternate between speeds of 0x02FF and 0x030F. The average speed during this movement is 0x030E, which is greater than the speed cap of 0x0300. A side effect of this technique is a visual animation glitch which is seen throughout the run.

In practice, Sonic's velocity has increments of 0x0002, so it is possible to alternate between 0x02FE and 0x030E. This is a rarity though, since manipulating the last digit of X velocity to be E is difficult. The way to achieve this is to start climbing a hill which will lower speed, then jump off when the last digit is E. This is often not the fastest way to move since you would only be averaging speed 0x0300 leading up to the hill.

It is possible to alternate between 0x02FC and 0x030C on arbitrary terrain apart from in water. This is achieved by rolling then pressing left. The roll has acceleration -0x0004 which puts you at 0x02FC. Pressing left exits the roll but lowers speed to 0x02CC. After building back up to 0x030C the alternation process can begin. Jumping out of the roll at 0x02FC unfortunately doesn’t work. Since slowing down is needed to set up the alternation boost, it is required to boost for at least 28 frames to be worth it. This drawback along with the extra lag from boosting means that this method is not used in every possible situation. The game has a few different types of lag. One type still has the game complete the calculations for that frame and successfully render, but it doesn’t read input, rather it just copies the input from the previous frame. In levels with this kind of lag, alternation boosting is impossible since it requires different inputs on each frame.

In a run optimizing purely for game time, alternation boosting would be used in more situations since lag does not cause game time to increase.

Unbounded Roll Speed (a.k.a Roll Zipping)

When rolling on flat ground, acceleration is -0x0004. But when rolling in the air, acceleration is 0x0010. This is the same acceleration as walking, but unbounded as the speed cap is not applied when rolling. The most well-known exploitation of this is in Green Hill 1 where the level can be beaten quickly by rolling off the ramp near the start which is used in unassisted runs. This technique is used in the TAS far more than in unassisted runs, for example Jungle 1, and is the most common method used to exceed the speed cap throughout the run.

Unbounded Negative Velocity

When Sonic is rolling and the player presses the opposite direction on the d-pad, he stops rolling and the game subtracts 0x0030 from his velocity regardless of his facing direction. Since travelling left is negative velocity, subtracting from it speeds Sonic up. So when travelling left, it is possible to increase speed in that direction by 0x002C every 2 frames. This is a greater increase than the usual 0x0010 per frame. Since this process does not involve pressing left while not in a roll the speed cap is never applied. This technique is used throughout the run, but is most useful in Labyrinth 2.

Individual Level Comments

Green Hill 1

Speed cap exploit is used for the first part of act 1. I press left to stop the roll after hitting the ring box which technically slows me down. But I speed up to 0x030C before I reach the ledge meaning that I can roll off at full speed and get more speed overall for the roll. Once I reach 0x0300 speed, I jump out of the roll to avoid the deceleration from the roll. While over the speed cap, it is best to stay in the roll since rolling acceleration is -0x0004 compared to -0x0010 out of a roll.

I use the hill to line up my last velocity digit for speed cap abuse. I break the invincibility box since the boxes cause a lot of lag. Again I get out of the roll before going down the hill so that I can reach the hill at full speed and get a quicker roll. From here, roll zipping skips the rest of the level.

Green Hill 2

I start the level with a falling section. Falling from a jump is faster than walking off the ledges as expected. I ensure that I don’t hold right when in the water to avoid triggering the speed cap. I TASed the glitched route with the upwards zip, it was slightly slower than glitchless. In the glitched route, you hit the spring with the rings above it earlier than glitchless, but turning around makes it slower. Slowing down at the end of the level before the ramp saves time.

Green Hill 3

There is a lot of lag in this level making exploiting the speed cap very difficult. The lag is made worse by jumping despite jumping usually reducing lag. In the fight, you can’t hit Ivo in the first phase. My play around actually causes lag, but lag does not slow down the boss movement so it did not cost any time. A TAS optimized purely for game time would create as much lag as possible in bosses.

Bridge 1

Getting the shield at the start of this level would have been quicker with movement, but the extra lag caused by the shield outweighs the movement optimizations for my chosen timing method.

The roll zip off of the see-saw was the section with the most rerecords in the run (~3000). The difficulty comes from making the gap over the waterfall before the ring box without jumping. Rolling over that gap in the Game Gear version is easily possible in real time, but it is barely possible Tool Assisted in the Master System version. The basic strategy was to get the highest possible bounce with the most possible speed off the checkpoint. Even with enough speed, exact position and cycle determines whether or not Sonic makes it across the waterfall gap. I was able to reach the waterfall at frame 9350 with speed 0x08F8 but didn’t make it across. I then reached the waterfall at frame 9352 with the same speed and did make it across; it wasn’t possible to reach it on frame 9351. I suspect it is based on the platform position and Sonic's exact position. It was very difficult but saved a lot of time.

Bridge 1 is one of the biggest problems with game time optimization. When rolling on a falling bridge, Sonic will accelerate. Jumping over the bridge will make Sonic stay at the speed cap. At the end of Bridge 1, I could have rolled across the falling bridge. This would cause Sonic to accelerate up to 2 times the normal walking speed. Alternatively I could jump over the bridge, staying at the normal walking speed. Unfortunately, when on the bridge, approximately 50% of frames are lag frames compared to jumping over the bridge where there are about 0% lag frames. So even though rolling across the bridge gives Sonic nearly twice the speed, jumping is still faster in real time due to the heavily reduced lag.

Rolling across the bridge gets a game time of 0:19, while jumping gets a game time of 0:21. So without taking any signpost tech into account a game time of 0:21 is quicker in real time than a game time of 0:19! This is one of the main reasons that I didn’t optimize purely for game time.

Bridge 2

This level was more complicated to TAS than it might seem. Unlike boss fights, lag does slow down the autoscroller so lag reduction was vital with my chosen timing method. There appears to be a lot of random jumping and rolling, but this is all necessary to ensure no lag frames. The lag seems quite random and is difficult to control. This was one of the longest levels to TAS, but as a result I was able to complete roughly the last 2/3 of the level without a single lag frame.

This level is another example of why pure game time optimization could lead to carelessness, since there would be no need for the lag reduction.

Bridge 3

Ivo’s position is random but regardless of which side he is on, the fight takes the same amount of time. With knowledge of the random position, it is possible to get 6 hits per cycle rather than the usual 4 in unassisted runs.

Jungle 1

This level has much more roll zipping than unassisted runs. I use the bounce off the shield box to set up a large chain of roll zips. In this case, the shield lag is worth the time save from rolling speed, but I am keen to lose the shield as soon as possible. The first chain of roll zips allows me to skip waiting for the first swinging platform. During the water section, I let go of right in the water to avoid triggering the speed cap. The last roll zip requires a lot of slowing down so that Sonic actually sticks to the ramp and launches off of it rather than just falling through. The last roll zip is difficult, but certainly possible in unassisted runs. This could eliminate the current unassisted roll zip which relies on bouncing on a fish based on RNG.

I had to redo this level since I got over 50 rings the first time and would have had to go to a special stage. Luckily, eliminating rings didn’t cost any time.

Jungle 2

Most of this level is done off screen, but I have to let the screen catch up before the moving logs will load. The general strategy for optimizing this level is to be pressing the jump button as little as possible so that the screen will catch up. I also do all of my upwards travel at specific screen positions so that the camera is not focusing on a laggy area for long periods of time.

By being off screen, I am able to make a normally impossible jump onto a platform with a ring box on it. Usually you can’t jump high enough to make it on top of the box, but since Sonic is off the screen the box isn’t loaded so the jump is possible. This strategy could be used in unassisted runs.

Jungle 3

There was a potential boss skip in this level that unfortunately didn’t work out. If you jump and make it close enough to the end level capsule without landing (which triggers the boss) then the screen will lock on the capsule and the boss won’t be triggered. Unfortunately from the vine under the boss, Sonic can’t jump high/far enough to reach the grassy ending platform. I was able to jump far enough to horizontally lock the camera, which skipped the boss but I was underneath the grass which meant I fell into the water and died. If this skip is possible, it would most likely be on the Game Gear version since you can jump high/far enough to land on the grass but not far enough to reach the capsule screen lock trigger before triggering the boss.

The boss fight was the hardest one to optimize due to timing jumps off the slope. I use the ball to intentionally lose my shield at the end. This reduces a lot of lag in later stages.

Labyrinth 1

Strangely there was a 1 frame window on the slide where jumping gave a tiny speed boost. When exiting the slide, I let go of right so that the speed cap isn't applied. At the bottom of the level, it is impossible to jump over the spear when it is up at normal walking speed. But since I had just rolled, I was moving fast enough to make it through unharmed. Initially, I wanted to wait until it was down and roll zip from much higher, but Sonic couldn’t make it over the spear even when it was down.

The movement on leaving the water seems slow, but it is necessary to wait that long to jump out of the water. I wanted to find a different path near the ring box at the end, but the platforms were slightly too high to jump onto from elsewhere. I was able to roll off the ring box ledge by pressing left after the box so that I reached the ledge at full speed.

Alternation boosting doesn’t work underwater since acceleration is only 0x0004

Labyrinth 2

This level diverges from the unassisted route completely from the very beginning. The idea is to use the unbounded negative speed glitch to reach the left side of the screen fast enough that Sonic will go through it. Sonic's position underflows horizontally, zipping him to the signpost. This allows the level to be completed in 7 seconds compared to roughly a minute as in unassisted runs.

Originally I suspected that this underflow was possible if a speed of roughly -0x1080 was achieved and I was able to reach about -0x1000. I was surprised at how close this was but I couldn’t get it, so I posted about it on TASvideos Forums.

I’d like to thank Tee-N-Tee who responded with a button file which achieves the horizontal underflow. He had reached the same speed, but was able to adjust his exact position such that it was enough speed to underflow. It gave me a lot of motivation to start work on the TAS as I had given up on the underflow for the moment before Tee-N-Tee replied with the button file.

When I reached this level, I was able to use TAStudio to replicate the underflow using Tee-N-Tee’s button file as an example. I was able to save 6 frames over his original button file which brought this level down to 7 seconds game time.

Labyrinth 3

This level has some annoying movement at the start, but apart from that it is fairly straightforward. It is very risky to hit Ivo when he is in the middle since you don’t bounce very high. It is possible to get 3 hits in the middle in real time, but extremely inconsistent.

Interestingly, jumping at the earliest frame that you would hit Ivo isn’t the fastest strategy. When you hit him, you bounce off at the same speed but in the opposite direction. If you jump as early as possible, you are reaching the peak of the jump as you hit him, so you don’t get bounced down very fast. On the other hand, if you jump later, you hit him earlier in your jump and as such, get bounced down very fast. So jumping later allows you to start the next jump sooner.

Scrap Brain 1

The doors are awful! This was the hardest zone to optimize simply because of the doors. One might suspect that rolling underneath them would be faster. But even though you can technically get through earlier by rolling, it slows Sonic down. Since the doors are approached in many different fashions (Alternation boosting, normal walking, conveyor belts, falling, jumping…) and due to lag, the button input is unique for every door. Each door took 30-60 minutes to optimize.

Interestingly on conveyor belts, Sonic’s velocity is as it normally would be even though he is not necessarily moving at that speed. So careful observation is needed and a velocity RAM watch alone cannot optimize conveyor belt sections. I didn’t realize this when I first TASed the level and spent far too long on a backwards conveyor belt that I hadn’t realized slowed me down.

Scrap brain has a lot of lag so often alternation boosting cannot be used. But it has a lot of slopes where the last velocity digit of E can be achieved rather than the usual C, so sometimes very optimized alternation boosting can be used.

Scrap Brain 2

The techniques across all Scrap Brain levels are very similar. This level has a deathwarp. Usually speedrunners will take both hits required to deathwarp on the same enemy, but I lose rings much earlier in the level. Since I don’t have to wait to become vulnerable again before the deathwarp, losing the rings earlier saves about 1-2 seconds.

Scrap Brain 3 is similar to the other 2, but with many more annoying doors.

Sky Base 1

The first cannon was very hard to avoid/manipulate without slowing down too much. Luckily I was able to roll through the second cannon while it was shooting. I take a slower path up near the shield box so that I can set up a roll zip. This slower path doesn’t lose any time since I have to wait for the lightning, but taking the slower path allows me to be moving at a faster speed once the lightning subsides.

I tried to do a damage boost to climb the section at the end quicker, but unfortunately it was slightly slower.

Sky Base 2

The cannons are random so this level is annoying in an unassisted run. The skip is possible in an unassisted run.

Sky Base 3

I considered getting the shield in Sky Base 1 to use in this boss fight. This would speed it up a bit, but the shield caused about 160 frames of extra lag in Sky Base 1 alone. The extra lag easily outweighs the time save in the boss fight, even without considering lag in Sky Base 2.

When you hit the glass in the fight, you are ejected at -0x0300 velocity regardless of your speed or position when hitting the glass. The glitch to get inside the glass is used in unassisted runs. I was able to get 8 hits in before stopping for the laser. Then I was barely able to get the next 2 in before the laser fired again, this was achieved by carefully lining up my position to get hit back slightly less. Getting the 9th and 10th hits in and remaining inside the glass was the key to speeding up the boss fight. This definitely confirmed that the shield wouldn’t have been worth it.

Played on Bizhawk 1.11.6 using TAStudio.


Fog: Gotta go judge this!

Fog: Dropping this one, going to let someone else take it.

Samsara: Gotta judge fa- *walks off the left side of the screen and comes back with a verdict*

Samsara: I had a good long think about this one. My two primary concerns were as follows:

1. The SMS and GG runs needed to be compared in order to judge how different they are to each other in terms of publication. 2. The realtime/IGT hybrid is vague and doesn't take to the obsoletion chain well

I'll start with point 1, because it's easier to dissect. The8bitbeast's post detailing the differences between the two leads me to believe that they are different enough to warrant publication, if only due to some of the grander level differences and small things that change how the levels look when TASed. On further inspection, the two runs end up looking quite different in the changed levels because of that. So I would say that both runs have reason to be published alongside each other.

Point 2 is a tough one to think about. I'll start by bringing up a piece of mmbossman's judgement on a submission for the GG version of this game: "I am also slightly confused by the goal choice regarding fastest time and ignores bonus effects. If the author were to aim for the best in-game timer, he should not have stopped prior to the end of the level to prevent the signpost from spinning. However, if he's aiming for real-time, this can easily be improved in Bridge 2 due to horrible management of lag, which makes that level look particularly bad."

This run doesn't fully aim for in-game time by managing lag and preventing the signpost spinning, but it also doesn't fully aim for realtime by carefully optimizing levels as if it were an IGT-based run, completing them as fast as possible much like an IGT run and not intentionally wasting time to lessen the length of the score screens.

So this leads to an interesting quandary: Optimizing for IGT involves intentionally creating as much lag as possible to slow down the timer, which in my opinion would wreck the pacing and entertainment of the run in much the same way that any other insane IGT strategy would. Think of a Metroid game where pausing/unpausing frame-perfect doesn't allow the timer to run in certain cases. It's an exaggerated analogy, yes, but it fits the situation well. On top of that, this is not a Genesis Sonic game. It's not very fast, the action doesn't flow as well even when TASed, and the process of intentional lag creation for IGT means intentionally sloppy-looking play.

However, optimizing for realtime is something we can never really accept in a Sonic TAS, because some levels will inevitably turn into awkward playarounds while waiting for the timer to tick past a certain point in order to save some time on score screens. To my knowledge, we have no published Sonic TASes that aim for realtime, and I doubt any Sonic TASers would ever consider running the game that way.

But then we have this run, which strikes a nice balance between the two timing methods. It's a quick-paced run that doesn't use weird, cheap tactics to save frames one way or the other. You get all the benefits of a run that's optimized to be as fast as possible, much like an IGT run, without some of the long waits involved, much like a realtime run. It's the best of both worlds, and they mix very well and make the run far more entertaining and watchable than either of the extremees would be. So naturally, I've come to the conclusion that FOR THIS SPECIFIC SONIC THE HEDGEHOG VIDEO GAME ON THE SEGA MASTER SYSTEM HOME VIDEO GAME ENTERTAINMENT SYSTEM, we can accept this timing method.

And with that, I can accept this run to Moons to be published alongside the Game Gear version. Phew.

fsvgm777: Processing.


Similar submissions (by title and categories where applicable):