maydaymemer - Tumblr blog

maydaymemer · 6 days

Text

Sonic 3 (& Knuckles) 20th Anniversary

Introduction

Today marks the twenty-year anniversary of the release of the game “Sonic & Knuckles”. Given the game’s two-part nature, it was on this day twenty years ago that the general public was able to play, for the first time, the complete Sonic the Hedgehog 3 as originally intended, and in that way, today can also be considered the true anniversary of “Sonic 3”, or at the very least, what came to be called “Sonic 3 & Knuckles” In light of this fact, my good friend Christian “The Taxman” Whitehead and I have decided to take the opportunity to share some information about a project we collaborated on early this year. The video below was created by Taxman, but its contents are the product of weeks of work by the both of us:

As demonstrated by the video, Taxman and I have, as an independent proof-of-concept project, re-created a “vertical slice” of Sonic 3 (& Knuckles) using his RSDK. In brief, we have made the following aspects fully-functional:

The Title Screen

Angel Island Zone with all enemies, gimmicks, bosses, and intro/intermission sequences

All three Bonus Stages

Special Stages from both Sonic 3 and Sonic & Knuckles, including “Blue Spheres” functionality

Disclaimer

What is being shown and discussed here is purely a proof-of-concept, and was not produced in conjunction with or upon request by SEGA, nor is it in any way endorsed by SEGA. As of this writing, this is an independent project by Christian “The Taxman” Whitehead and Simon “Stealth” Thomley. The characters, scenario, graphics, sounds, music, etc from the original “Sonic the Hedgehog 3” and “Sonic & Knuckles” were not created by us and remain property of SEGA; what is being demonstrated is our own accurate reproduction of the original game(s) and potential enhancements. No claim of ownership to the original games and their content is intended, nor is this presentation meant to be taken as any indication as to whether or not SEGA ultimately intends to re-release these games or what any final product would actually be like. This is not a release, nor is it prelude to a release. Given the nature of this project, any release would require licensing/approval by SEGA. This independent presentation is being made for entertainment purposes on the anniversary of the original game’s release, and as a means of entering the significant amount of work we’ve put into it into our portfolio.

Background

Most people who know us know that we keep ourselves busy. Hobbies aside, it’s important for people in our profession to keep moving toward the next project. This leads to a lot of ideas and prototyping, so it should really come as no surprise that this happened. If you’re reading this, then you probably already know that we’ve actually developed complete remakes of both Sonic 1 and Sonic 2 with enhancements and bonus features, which were released by SEGA for Android and iOS in 2013. These follow the 2011 remake of Sonic CD, developed by Taxman and also released by SEGA for various platforms. One of the Easter Eggs present in the Sonic 2 remake was a brand new post-credits ending sequence. A lot of people seem to have gotten the impression that this was meant as some kind of “message” from me, from Taxman, from SEGA, or whoever. The truth is, though, that it’s just a nifty ending. This is an idea that I had as early as the beginnings of Sonic 1, at which point I had brought it up with Taxman, but we hadn’t settled on it for certain until the finishing touches were being put onto Sonic 2, when I implemented my concept with some additional graphics drawn by Taxman. My reasoning was pretty much - “I think that, in comparison to the other games, the ending gets pretty dull once the credits start, and it feels kind of awkward that the post-credits sequence isn’t affected by whether or not you have all of the Chaos Emeralds”, and so, I came up with an all-Chaos-Emeralds ending that was both satisfying and linked the stories of both Sonic 2 and Sonic 3 in a way that couldn’t have been conceived of at the time the original Sonic 2 was developed. This time, however, Sonic 3 and its story (and its relation to Sonic 2) were already historical fact. That having been said, though, doesn’t mean that I hadn’t been looking forward to the possibility of ultimately remaking Sonic 3 (& Knuckles) as well. On the contrary, it wasn’t long after Sonic 2 had been released that I began working on trying to arrange and convert the level data for Angel Island Zone for the RSDK. After getting a usable level with rings and other global objects, I tried out my sprite converter on some Sonic 3 sprites and ended up arranging a partial AIZ sprite sheet. After a few more additions, I sent the project to Taxman, and he became excited and started adding to it too. Before long, we had gotten into the project enough to commit to a proper proof-of-concept build.

General

For those who actually don’t know, the two games “Sonic the Hedgehog 3” and “Sonic & Knuckles” were spawned from a single game concept- the original vision for “Sonic the Hedgehog 3”. The planned game was so large, however, that during development, SEGA realized that they wouldn’t be able to complete the entire thing in the usual space of time, and so it was split into two parts. In fact, the game that was released as “Sonic the Hedgehog 3” was referred to as “Part 1” internally and in some promotional material, including the full version of the picture that was used for its European box art. The game’s split nature was also later referenced in promotions for Sonic the Hedgehog 4, cited as precedent for its “episodic format” The long-term plan in the case of Sonic 3, though, was to release both parts separately at first, and eventually release a “Special Edition” version that contained both parts as a single game. It was instead decided, though, that the combined game would be achieved through a gimmick introduced with the release of Part 2 - “Lock-On Technology”. In short, this was a hardware trick that allowed the game program from “Sonic & Knuckles” to read some of the level data from an attached “Sonic 3” cartridge while it ran in its own “Sonic 3 & Knuckles” mode. More can be said about the feature, but that’s best left for another time. Logically, one might expect the ultimate goal of an official remake project to be to re-create the combined game in its entirety. That’s how we saw it, and that’s how we treated this project. As such, we were looking at a humongous task, something that would take more time and effort than Sonic 1 and Sonic 2 combined. Sonic 3 (& Knuckles) went all-out with 23 full-length main-gameplay levels, each up to three times larger than those in its predecessors, and all of them packed with complex features. As the last entry in the numbered classic series, it really lived up to this status by pushing the limits of what could be accomplished with a Genesis/Mega Drive Sonic the Hedgehog game while remaining true-to-form. While better use of the 64-entry, 4-bit palette to create more-detailed graphics created the illusion of greater color depth, other graphical limitations were “broken” by greater use of DMA, the basis for SEGA’s “Blast Processing” promotion, to dynamically reload gimmick and enemy graphics to allow for smoother animation through the use of more animation frames and a VRAM “slot” system, and in addition to standard use of hardware line-scrolling to simulate extra non-overlapping “layers” of background for parallax scrolling, a more-advanced method of animating background tiles based on carefully-drawn tile frames chosen through math based on the camera position was used to simulate extra “layers” that could be overlapped. Although the latter was used once in Sonic 2’s Hill Top Zone, it was put to much greater use in Sonic 3 (& Knuckles), along with a much more complex tile animation trick that could simulate a 3D-perspective waterline extending from the foreground into the background. Aside from the tricks used to make each level more interesting visually, the levels themselves were also filled with various gimmicks and events with a wide range in degree of complexity. For a legitimate remake project, all of these things would have to be duplicated in exact detail. This is something with which we took great care in re-creating Sonic 1 and Sonic 2, and so, we’d expect no less from ourselves in the case of Sonic 3 (& Knuckles). However, in some ways, this makes the job of re-creating the game somewhat more difficult than when the game was first created from scratch, because instead of being the ones who make the decisions, design the methods, and plant Easter Eggs and other subtleties on a whim, we instead have to fully understand and accurately reproduce what was already done in a way that is virtually indistinguishable from the original. This is actually where our different methods come into play. By preference, Taxman has acted mostly on the basis of observation, carefully observing what happens at run-time and then reproducing it with his own methods. When I was brought into these projects, one of the reasons was that my understanding of Sonic the Hedgehog came from an understanding of the original assembly code itself, and experience with reading and manipulating it. This meant that I was able to take specific methods from the original code and apply them to whatever else I was doing, which in this case, was re-creating the games using the RSDK. It was especially handy when observation couldn’t readily, or at all, explain what was happening. Observation also has its merits, though, as it’s a great time-saver in straight-forward cases, and there are advantages to writing your own code without bias, such as the potential for more-easily creating cleaner and more versatile code, and guaranteeing a from-the-ground-up understanding of the method. That’s not to mention how repeated observation can expose strange exceptions. The code, too, could easily expose an obscure behavior in some cases, or at the very least, be used to easily obtain exact values. I tend to move between the two as it feels appropriate, and between the two of us, we seem to catch pretty much everything.

Main Gameplay Levels and Angel Island Zone

As mentioned and demonstrated, we have re-created Angel Island Zone in its entirety, and it serves as demonstration for standard level gameplay. This includes not only the enemies and level gimmicks, but also other special features such as intro and intermission sequences, Bonus and Special Stage integration, and level chaining. The first time any part of Sonic 3 was running on Retro Engine was when I converted Angel Island Zone Act 1 using a modified version of SonED2. I actually ended up converting the zone at least three more times, though, in various attempts to get it to work out with the RSDK in relation to tile storage space and the cutscenes. This also involved a few other hackish modifications to SonED2 to allow me to move a few tiles back and forth between data sets so that everything could be strung together cleanly. This is due to two key differences between the way Retro Engine and the original engine for Sonic 3 work - Firstly, the two are modularized in different ways. While Retro Engine works more similarly to Sonic 1 and Sonic 2 in that one full zone contains a single set of tile data, Sonic 3 breaks things down a step farther. This starts with a “page” system, where the basic 8x8 tile set and the two tile mapping steps, 16x16 and 128x128, are broken into multiple parts. For several zones, Angel Island included, each of these sets are broken down into a primary page that contains data that’s common to both act 1 and act 2, and a unique secondary page that corresponds directly with either act 1 or act 2. Furthermore, a few levels, again including Angel Island, contain extra tile and mapping data that can be loaded in place of other data that has become unnecessary in response to certain level events. In the case of Angel Island, the various sets include tiles used in the intro sequence, the main act 1 set that overwrites it, tiles loaded for the fire sequence, the main act 2 set, and tiles loaded for the pre-boss bombing sequence. Second, Sonic 3 runs from a cartridge, from which new data can be read almost immediately. Combined with a method of streaming that was implemented to spread the task of decompression over the course of several game frames and thus virtually hide the process if the streamed data is never actually required before loading is complete, this means that Sonic 3 could easily load new graphic data at any time. Retro Engine, however, runs on platforms whose storage doesn’t provide immediate access, such as a Hard drive or an SD Card. This means that there will be a noticeable loading period whenever new data has to be loaded, and thus, anything that needs to be used without there being any load time needs to be combined into a single set of data. Although the limitations for Retro Engine are less strict than was necessary on the Genesis/Mega Drive, some considerations had to be made so that it could run on a wide variety of platforms, and the restrictions that were imposed still weren’t quite enough for this massive level. For that reason, in the current build, Angel Island Zone is actually split into three parts:

The intro cutscene areas

The part of act 1 before everything is set on fire

The rest of act 1 combined with the entirety of act 2

This is still somewhat similar to the original in that the original level data is split as “act 1” containing everything from the intro scenes through the fire, and “act 2” containing everything after the fire clears. They also share the method of using a special flag to determine when to display “act 1” or “act 2” on the Title Card due to the primary “act” setting controlling which section of the level is loaded. One other difference, though, is that the pre-fire area that the player is locked into just before the Fire Breath miniboss appears is actually duplicated in the “act 2” data in the RSDK version. This means that, while the original game actually uses the fire sequence to mask the loading of the “act 2” data, the RSDK version actually performs the new level load before the scene even begins, and the entire sequence takes place while technically in “act 2”. This allows the fire to come and go, and for gameplay to resume without a noticeable pause. The problem with doing this is that the load still has to occur at some point, so, it was decided that the best course of action would be to cause a “puppet scene” to occur upon entering the area, where the computer would take control of the player character and move him to a specific place, making him look upward as if he were alerted to something. This way, the load could occur between the player looking up and Fire Breath descending onto the screen, causing only a reasonable delay between the two actions and avoiding freezing the game while anything important was in motion. Angel Island is the only zone that is actually split up in a manner other than a straightforward separation between “act 1” and “act 2”, but unlike with its predecessors, all zones in Sonic 3 “chain” directly from act 1 to act 2 without a black fade; it is made to appear that act 1 and act 2 are part of the same level, and no loading has occurred. This is, of course, untrue, and the load occurs while the character is posing and the score tally is being shown. The load itself is masked by the fact that it is done in the background while animation continues, and the end of the act 1 level is duplicated at the beginning of the act 2 level. Once the load occurs, the camera and all objects are shifted so that they are at the beginning of the new level, but it appears that they’ve never moved anywhere. For this to work in our version, another difference between Retro Engine and the original game engine had to be overcome. To keep up with active level objects, the original games use what is called a “Sprite Status Table”, which was so-named and patented by Yuji Naka himself. At its most basic, the SST is an area of RAM set aside for holding the data associated with objects that are either within a certain range of the screen, or meant to stay “always active”. Objects are streamed into this region from the object layout data as the screen scrolls across the level, and so not all objects within a level are “active” all at once, and any change in the currently-referenced object layout data doesn’t immediately affect any objects that are already active within the SST. In the case of Retro Engine, however, the entire object layout is loaded all at once, but in a similar manner, not all objects are processed all of the time, which is still an important factor in performance. This does mean, though, that the loading of a new object layout, such as happens when a new level is loaded, will eradicate any existing active objects. For previous games, this wasn’t an issue since a black fade would occur and all existing objects would become irrelevant anyway, but for act-to-act transitions in Sonic 3 and the Angel Island fire cutscene, Taxman altered the engine to include a backup object area to which important objects could be stored before an act load, and from which they could be read back after loading had finished. This allows the character and all of his status, the signpost, any hidden monitors that had been exposed, and any other relevant object to be preserved, and to maintain the illusion that it’s all still part of the same level. This object backup area also became important in light of the fact that the level’s object layout state needs to be preserved when the player enters a Bonus Stage or a Special Stage in the middle of a level. The level’s objects are written to the backup area before the Bonus/Special Stage is loaded so that the primary object storage area can be used without destroying them, and they’re reloaded from the backup when the level starts if it has been flagged to do so. In the original game, this is accomplished using an engine feature that is tied heavily to the use of the SST - a “persistence table”. This table actually contains one byte for each of the objects stored in the level’s object layout, seven of whose bits are used individually or in various combinations to flag that the object is in certain states, including having been destroyed, and whose eighth bit is used to flag whether or not the object is already active within the SST. This is because objects that are not meant to be processed at any given time are removed from the SST to save space, and so their states would otherwise be lost. It is this table that is backed up upon Bonus/Special Stage entry in the original Sonic 3. One other minor point of interest regarding Angel Island Zone is that it contains one very small section that requires an exception in the global level collision code. Since Sonic 2, the main-series Sonic the Hedgehog games had started using a 2-path collision system, which involves the use of strategically-placed invisible objects that swap the player’s collision response between two sets of data. This is how loops and crossing paths are achieved, and indeed, Retro Engine uses the same method. Although this only allows for two paths to cross the same space without issue, there is an area at the bottom of the last loop before the giant tree in act 1 where three paths cross each other- up the loop, down the loop, and up onto the loop from the separate path below. Given that level collision is divided into four separate modes corresponding with the floor, the left wall, the ceiling, and the right wall, some extra code was added to the right-wall mode to allow the player to move through this area without any apparent issue. The code assumes that if the level is Angel Island Zone Act 1, any right-wall collision that will cause the player to shift to the left by more than 14 pixels must be this particular structure, and in that case, it sets a timer that is checked in the same routine. If/while that timer is non-zero, then the player’s angle value is forced to stay fixed at 270 degrees (a flat right wall) to prevent him from being moved in any direction other than up, and he is disallowed from being affected by collision that would cause him to move horizontally. This is one of the things that Taxman ended up tackling by instead placing an invisible object at that same location, which forces the character to stay at a certain X position while he is in contact with it. The greater majority of Angel Island Zone was done after most other aspects of the game were either finished or well-under-way, though I had already gotten a large start on the two bosses and the fire and bombing sequences, and Taxman sorted out the new sliding HUD feature and most Sonic 3-specific global object behaviors while I was doing some work on the Bonus Stages. The fire sequence ended up being a team effort, and the rest of the level’s features were divided between us. As with our previous remakes, we also made a few noticeable improvements. Examples in Angel Island Zone include, but aren’t limited to:

Similarly to Rexon in the Sonic 2 remake, I’ve re-done the “Monkey Dude” enemy “from scratch” to smooth out its animation without compromising its actual movement

Vines take advantage of real-time rotation smoothing out the animation and camera movement

Tails as player 2 has been made to keep up with Sonic during the bombing cutscene so that he doesn’t constantly fall into range of the explosions

Super Sonic actually leaves a spark trail in the intro sequence

Knuckles has an Angel Island equivalent of his Mushroom Hill Zone intro sequence from Sonic & Knuckles

Bonus Stages

Before I revealed the project to Taxman, I had also gotten a head-start on the Bonus Stages. Specifically, much of the gameplay functionality for the Slot Machine Stage and Item Machine Stage was already complete. For the purpose of clarity, I’ll say now that I refer to the one Bonus Stage that was featured in “Sonic 3 Part 1” as the “Item Machine Stage”. Unlike the “Slot Machine Stage” and “Rolling Jump Stage” from “Sonic & Knuckles”, the instruction manuals gave it no name other than “Bonus Stage”. However, text in the manuals localized for regions other than Japan has caused fans and even magazines to refer to it as the “Gumball Bonus Stage”. Personally, I’m unhappy with calling it that because I know that it isn’t a “gumball machine”, and it’s not dispensing “gumballs”. This is purely a misconception on the part of the localization team, given that one of SEGA’s localization personnel from the same era had said openly, among other things, that they were not given any source material to work with other than pictures, and were told to create names and write story/documentation/etc based on that. The Japanese manual contains no mention of “gum” at all, and indeed, refers to the objects that fall from the machine specifically as “item balls”. Furthermore, the description for the “Clear Ball” includes the phrase “a ball with nothing in it”, indicating that these are actually containers. This makes a lot more sense than giant gumballs that somehow give powerups when it’s considered that they are most likely more comparable to plastic capsules meant for use in dispensing small toys from vending machines. These machines are and were pretty common, and in at least some areas, much more prominent than gumball machines. (The above translation by Yasha is more literal than westernized to emphasize the lack of reference to “gum”. The English-version image was constructed by Liz. Click to enlarge. The original image can be found here, and Larger, more-readable images of the original Japanese are available here, here, and here) The Item Machine stage was pretty straightforward, although I did make a few slight touch-ups. For one, the item balls inside the machine were re-placed and the shine was turned into a separate, translucent sprite. Also, the handle uses smooth rotation, the spring catapult at the bottom animates completely instead of becoming pressed like a button, and the floor collapsing sound now plays when it when it’s triggered. An interesting note about the item machine is that the original game data contains two graphic frames for an “S” item ball, which may or may not have been intended to flash. The “S” ball never comes out of the machine, but if you look closely at the upper-right side of the balls sitting inside the machine, you can see one peeking out from behind the others. As for item chance, it’s kept the same as the original game by using the same item ID table, which produces the following odds:

1/16 - 1UP Ball

1/16 - Catapult Ball

2/16 - Ring Ball

2/16 - Clear Ball

4/16 - Bumper Ball

2/16 - Flame Ball

2/16 - Aqua Ball

2/16 - Thunder Ball

The Slot Machine Stage was practically handed to us, since the two primary mechanics had already been created for previous games:

The general rotating stage mechanic reuses the code from Sonic 1’s Special Stage, for which Taxman created a method of using smooth rotation on the blocks while preserving the highlights and the initial implementation, and for which I followed-up on physics and collision issues

The slot mechanic reuses the code from Sonic 2’s Casino Night Zone slot machines, which was implemented mostly by Taxman, with myself adding the payout, the odds, and some touch-ups

The mechanic of the blocks that form the wall changing color and turning into Goal blocks is based on the code for the diamond-shape blocks from Sonic 1’s Special Stage

Similarly, the Slot Machine Stage in the original Sonic & Knuckles was also a reuse of old assets. In fact, even though the graphics had changed, the original sprite mapping data was re-used as-is instead of being converted to the new format that was introduced in Sonic 3, which made it necessary to also include the routine from Sonic 1 that was responsible for converting game sprite map data to the Genesis/Mega Drive hardware sprite format. For the remake, one hassle was actually the positioning of the slot machine graphics. As in the original, the graphics for the machine are displayed using the foreground tile plane. This is a problem because the stage rotation is actually achieved by rotating the angle of gravity and the visible objects around the player rather than actually rotating the entire world with a fixed gravity direction, so the position of the foreground plane doesn’t match up with the position of the on-screen object graphics. A bit of math is required to constantly move the foreground plane such that it remains visually centered with the visible center of the stage. This was complicated slightly by the fact that Retro Engine supports a range of screen aspects, and the code had to be written so that the slot would be centered properly when using each of them. I performed the original implementation of this, but when Taxman followed-up to fill in the complete stage layout, create the background effect, and add some other touch-ups, it was thrown off in some fashion, and so he ended up redoing it. As he pointed out to me, the background appears to be similar in concept to a zoetrope, where the illusion of a moving image is created by the laying-out of successive frames of animation on a band that is moved in conjunction with another surface that obscures it with the exception of small, evenly-spaced slits, through which the images can actually be seen. This is because, unlike other backgrounds that use animated tiles to create the effect of motion, each horizontal strip of the Slot Machine Stage’s background contains not repeated images, but an entire set of animation frames for the shape that resides within it. To achieve animation, the strip is scrolled so far that the next frame over is placed almost in the exact position of the previous frame, but shifted just slightly to give the illusion that not only are the shapes spinning in place, but that they are also slowly floating to the left. In this case, the “slits” that prevent the viewer from seeing any intermediate motion and breaking the illusion are simply the game’s frame rate. The Rolling Jump Stage is certainly the flashiest of the three. Many objects are either bordered by or made up entirely of constantly flashing colors, and the background is a complex combination of color tile pattern animation. To duplicate the background, I first had to disable the palette animation in the original game, and use Genecyst to take palettized screen shots in sequence. This was important because the high-color screen shots produced by other programs would not retain the original palette indexes, and therefore, would be entirely unsuitable for preserving the original palette animation. Also, I preferred this method to having to rig something to convert the original raw 4bpp 8x8 animated tile data into an 8bpp image containing 16x16 tiles suitable for importing into the RSDK. I isolated a section of the background that conformed to a 16x16 grid and contained all unique graphic tile patterns for one frame of background animation, but the section was also littered with duplicate tiles that needed to be cut out. After I had done that, I used the empty space to create a stamp to plaster over the following images to quickly trim them down as well. When I was finally left with a complete set of animation frames, I organized them onto a sheet and imported them into the RSDK project. The rest was creating the script code that would actually swap the tiles out in sequence, and duplicating the original code and data for the palette animation. The outer edges of the giant glowing spheres also use a combination of palette and tile animation, so, I handled them pretty much the same way. The code for the flippers is a slight modification of the flippers from Sonic 2’s Casino Night Zone, which were originally done by Taxman. Item ball odds for this stage follow different rules than in the Item Machine Stage. Firstly, the stage is divided vertically into sixteen sections that are each 256 pixels in height. The ID of the section is used to calculate the starting point within a larger item ID distribution table and from there, a random number from one to four is used to offset from that position and select the item type. In short, the types of items that can be obtained and how frequently each one appears depends on how high the player has progressed in the stage. Ring Balls also behave differently, with the number of rings given depending on where the item ball is vertically in the stage. It doesn’t matter where the ball was when it was first released from a glowing orb, only where it is when the player collects it. Ring values for each of the 16 item sections, starting from the lowest and progressing to the highest, are - 5, 5, 5, 10, 10, 10, 10, 20, 20, 30, 30, 35, 35, 40, 50, and 80. This is why collecting a Ring Ball at the top of the stage is frequently a guaranteed 1up.

Special Stage

The 3D effect of the globe in the original version of the Sonic 3 Special Stage is achieved primarily through the use of palette animation. The two-color checkered pattern actually uses 8 palette entries, 4 of which are set to one color and the other 4 another, which are cycled as the player moves forward or backward to create the illusion that the globe is spinning. This means that, during forward and backward motion, the globe graphic that is displayed is never changed; only the colors with which it is drawn are changed. For turning, however, there are seven additional globe frames that are swapped out in sequence, depending on the direction of the turn. The palette animation stops, and is resumed when the turn is complete. The rate at which the colors are cycled is scaled directly with the speed value that is used to control the player’s position within the stage. At the stage’s initial movement speed, one cycle occurs once for every second game frame, while at its fastest, this occurs once for every game frame. One reason that this particular cycling rate was used is that the Genesis/Mega Drive uses 4bpp graphics, meaning that any one tile is limited to a palette of 16 colors. Because the first entry in each of the four 16-color palettes is always “transparent”, only 15 actual colors may be used, so 8 is the next lowest number that’s well-suited for the math. In the Retro Engine version, the globe works pretty much the same way; it’s drawn as tiles on a background layer and uses a pattern of successive palette indexes to simulate rotation by means of palette animation. Given the wide screen aspect, however, it had to be re-created to account for areas that were previously “hidden” outside of the screen’s edges. Taxman did this using 3DS Max by first creating a 32x32 checkered grid to correspond with the size of a full Special Stage map, and then applying deformations to it until it matched the shape of the original. Once that was done, he partitioned the checker pattern and applied the different palette indexes that would allow the use of the palette cycling technique, but this time, to correspond with the enhancements that had been applied to the Special Stages in both Sonic 1 and Sonic 2, 32 palette indexes were used instead of 8. This means that, at any given time, 16 of the entries were set to one color while the other 16 were set to another, and at the stage’s default speed, the cycle would occur once for every game frame. Because of this, the and the animation appears much smoother without affecting the speed of apparent rotation, even when the player slows to a stop while switching from backward motion to forward motion. Spheres and rings in the original version are positioned using a “perspective table” of pre-calculated screen X and Y positions, which are selected based on how far the player has moved between grid spaces or, in the case of turning at a corner, how far he has turned to the left or right. Because these tables don’t include positions for spheres that would become visible in a wide-screen environment, the method of using the original table data had to be re-examined, and so Taxman created a system where the on-screen sphere positions were calculated on-the-fly based on three tables that managed three different values- Y position, curvature, and Z position. The math governing these tables and the final calculations is based on the curvature of a parabola, to cause the spheres to follow the lines that curve around the globe accurately. Overall, this system not only allows for more spheres to be positioned for visibility depending on the screen size, but technically, they are no longer limited to appearing directly at the corners of grid squares and could theoretically move around the globe in an arbitrary manner. While Taxman continued to work on the Special Stage until it was almost entirely playable, I provided information on physics and a few miscellaneous aspects of the stage that I tracked down in the original code, and also created a conversion utility to import the original stage layouts into the RSDK project. The utility also included a special case for converting the layout data used to construct the “randomized” levels of the “Blue Spheres” mode, which I then implemented in terms of the gameplay mechanics. The “Blue Spheres” game constructs its stages by reading layout data from a pool of 128 pre-drawn 16x16 patterns, and arranging them to build a single 32x32 stage. The patterns are chosen using a four-byte “magic number”, each byte of which specifies the ID number of the pattern to use for one of each of the four stage quadrants. Further, the third byte in the sequence is used to determine which of the 16 Special Stage palettes to use. When Sonic 1 is attached to Sonic & Knuckles and the full “Blue Spheres” game is active, the “magic number” is calculated based on the “level” number, and is initialized to 00010203. If, instead, a different game was placed on top of Sonic & Knuckles, a single-level version of the game is activated, and the “magic number” is calculated by reading from three different parts of the attached game’s header - The game’s name string, the game’s copyright string, and the first two bytes of the game’s ROM end address. The password that’s displayed upon successful completion of the stage not only contains data to re-calculate the same “magic number”, but also a flag that tells the full “Blue Spheres” game that the password corresponds with a level that was accessed using a different game, which causes it to switch to single-level mode. Difficulty and Perfect Bonus are managed by two other tables containing that correspond to each of the 128 pre-drawn layout patterns. The same ID value used to choose a pattern for a quadrant is also used to read values from these tables, and all four values of each type are added together to create the appropriate difficulty level and perfect ring count for the generated level. Because on-the-fly calculation of the perfect ring count at the start of the stage is unfeasible, not only are the values pre-calculated and stored in the table, but also each of the 128 patterns is drawn such that no blue spheres are ever near any of the four edges, making it impossible to generate a ring-producing sphere combo that spans across more than one quadrant and changes the perfect count. Once “Blue Spheres” mode was properly integrated, I proceeded to add the one missing mechanic - the conversion of a blue sphere combo into rings. I had done this before, but the nature of the project had allowed me to transliterate the original code rather than break it down, build a firm understanding of the method, and rebuild it. Basically, my original porting of this method was done by creating a line-for-line literal C version of the original assembly code, mostly because I was rushing to meet a deadline, and all that mattered was that the reproduced version actually worked as well as the original. This time, however, not only did I want to fully understand what I had, but I also wanted to address some issues that existed in the original method. There are actually two different versions of the original spheres-to-rings routine- the one originally written for Sonic 3, and the updated version in Sonic & Knuckles. Presumably, the updates were made in response to bugs that were exposed during the development of “Blue Spheres”. Unfortunately, because Sonic 3 had shipped with the older version of the routine, it had already gone through its QA process, and therefore, its content would have theoretically received lighter testing during the QA for Sonic & Knuckles. Because of this, the modified routine included with Sonic & Knuckles has introduced other bugs that actually affect the original Sonic 3 Special Stages

Because of this and other problems, such as certain patterns in certain Blue Spheres stages causing a long delay each time a blue sphere is touched, I decided that the best course of action was to plan and implement my own method from the ground up, rather than having to first understand and then fix the original. It actually took a couple of weeks and a lot of debugging to complete, but what I ended up with seems, so far, to cause fewer errors than the originals, and even account for a few more types of pattern. The method I use starts at the position of the latest freshly-created red sphere, and traces along any connected and branching paths in an attempt to find a closed pattern. Along the way, each red sphere is drawn onto an invisible background layer that is used as a map to keep track of only in-progress and valid closed patterns. For each new red sphere that is found, a test is performed for adjacent spheres, and if more than one is found, the current sphere is considered a “node” and added to the nodes list. The first adjacent sphere that was found is then made “current” and tested the same way, continuing until the path ends either in success, by meeting the origin sphere, or failure, by terminating without meeting another red sphere, or meeting a different red sphere. If the path returns to the origin sphere, all nodes currently on the list are flagged as being part of a successful path, otherwise, all spheres that had been found since the last node are removed from the sphere pattern map. In either case, testing then resumes from the last node. If all paths for the current node are unsuccessful, all spheres connecting the current and previous node are removed from the map. Regardless, once all paths for the current node have been tested, it’s removed from the list, and testing resumes with the node that preceded it, until all paths for all nodes have been tested. Once this is finished, if at least one successful path has been found, a test is performed to find at least one blue sphere in any of the eight directions surrounding the origin red sphere. For each blue sphere that is found, a test is performed using the red sphere path map to determine whether or not it is inside the closed pattern. If so, a similar tracing method is used as a sort of “flood fill” to travel along paths of adjacent blue spheres and convert them and their bordering red spheres into rings. A few setbacks and mistakes made it necessary to check the sphere trace patterns to be able to diagnose the problems. While it was still in development, the code included extra lines to write debug data to the game save file. One type of data was a position list for single and node spheres that was written as they were tested so that I could read them back and follow along while looking at the layout. The other was a tested sphere map that I could open in a hex editor for a visual representation of the pattern that the routine had followed. Aside from just minimizing the potential for bugs in the original stages, there were two other reasons that I wanted to create a better and more versatile spheres-to-rings method- First, I know that there are many people like me who are fans of level editors. There are no guarantees that if the project had taken off that we would have been able to successfully create a stable and friendly end-user editing environment for these stages, or that the concept would even be approved, but I certainly wanted to prepare for the possibility. In fact, I had even cobbled together a mini in-game editor mode using the RSDK’s scripting to test the concept, though, any release product would probably have the editor custom-coded outside of the main Retro Engine in a similar way to the interfaces for the Sonic 1 and Sonic 2 remakes. In terms of implementation, that sort of thing has been Taxman’s department. Second is a brand new mode that I would like to get approved - “Blue Spheres 2”. This is actually a concept that I came up with in 2009, when I was working on a 3DS port of the original Sonic trilogy in an attempt to get into the “Sonic Classic Collection” project, which unfortunately didn’t pan out. As mentioned earlier, I had prior experience with the Sonic 3 Special Stage, and this is why. While creating the Special Stage, I also created a map view using the bottom screen, and ultimately took it a step farther and turned it into a touch-controlled stage editor. I had hoped that both of these things could make it into a final product, but to make the editor more interesting, I came up with and implemented two new sphere types:

Green Sphere - Touch once to convert to a blue sphere. Can not be converted to rings with a sphere combo without first being turned blue. Must be eliminated to complete stage

Pink Sphere - Touch to be transported to another random pink sphere somewhere in the stage

Having been given another opportunity, I implemented these spheres in the Retro Engine version of the Special Stage as well in the hope that the new mode would be approved with or without an editor. So far, only throw-away test stages have been created with them, but the intent was to create another 16x16 pattern pool to use in creating another full Blue Spheres type game.

Other Notes

As stated previously, we treated the remaking of “Sonic the hedgehog 3” and “Sonic & Knuckles” as a single remake project. Given that fact, we also toyed with the concept of providing various play modes based on the original plans for the game and what actually ended up happening in terms of the original release(s), which are currently accessible through the Level Select: Many people know that we added several features to the Sonic 1 and Sonic 2 remakes and have wondered what could possibly be done to Sonic 3. Well, we aren’t without our ideas. In addition to those that were mentioned in relation to the Special Stage and Blue Spheres, we’re also very interested in the possibility of expanding the two-player mode zones into full-sized, fully-featured, single-act zones. Other possible features hail from previous releases, such as online competition, Time Attack, and Boss Attack. The current version also retains the randomized item box mode, accessible from Level Select, which also affects item balls in the Bonus Stages.

The Future

To respond to the biggest question that I assume is on many people’s minds, the future of this project is uncertain. Three important facts that were already mentioned are that this project was created independently of SEGA and is in no way affiliated with them, that any release whatsoever would have to be licensed and approved by SEGA, and that this game is massive; what we have here is already the product of months of work, and that’s time that wasn’t spent directly working to make a living. Enough of this project has been completed to prove a point. The only way that it can be continued is with both legal and financial backing from SEGA.

Conclusion

Sonic 3 (& Knuckles) is a great game, and it was fun to partially re-create. Although we can’t share more than this for now, we hope you had fun watching the videos and reading about the project and the game in general. Now, go give the original another playthrough!

264 notes · View notes

maydaymemer · 1 month

Text

Hitman WoA Lore - How many Elusive Targets ARE there?

With the recent announcement of a brand new Celebrity ET coming to Hitman in spring, I was thinking about which number of Elusive Target this is. It used to be simple, the initial 26 in Hitman 2016 were all unique missions which didnt repeat gameplay from eachother other than using the same pool of six maps. Then Hitman 2 throw a big wrench into all that with its reactivations and reworkings, where I remember there being minor controversy over how to number each ET. Some people would number the new Hitman 2 ETs 1-7, and all the reactivations their own numbering, but then there was the question of counting Undying Returns as separate from Undying and then is Deceivers part of the reactivation numbering or the main ET numbering

It seems that people now with the WoA era dont really number anything anymore, people gave up counting anything unless theyre just counting how many ETs were made for the map pools individually, and if they do they count EVERYTHING as one big number even down to the “Year 2”, “Year 3”, etc. reactivations. Which gets crazy when you see numbers claiming there’s 61 ETs in H3/WoA. Thats crazy and highly inaccurate so i’m going to count every ET and give a canonical number for this new one dependent on each and every methodology you will want to count it with. I will do this in a form of a set of questions you may have:

1. How many ET missions have IO made?

This is the simplest metric. If IO just rerelease an old ET they made it doesnt count as a unique mission but if they some sort of modification to it like a new briefing or cosmetic change or smushing two ETs together not only will I count the original but I will also count the modification as well

So with Hitman 1’s missions we have the initial 26 consisting of 9 in Paris, 6 in Sapienza, 4 in Marrakesh, 3 in Bangkok and 2 in Colorado and another 2 in Hokkaido. Then we add on the Deceivers from H2, where they combine the Congressman and Guru from Sapienza into one mission with a new briefing and new backstories for both characters, to give us 27 on the H1 maps and 7 in Sapienza

With H2’s missions we have to tackle the Undying: technically, and I mean technically, there’s three versions of the Undying: The Undying, The Undying Returns and The Undying Returns (2024). However the 2024 reissue doesnt modify the briefing and its only difference from the Undying and Returns versions is a different thumbnail and a new unlock which could have just happened with either version of the mission anyway. It uses the Undying Returns briefing and Mark Faba’s look from Undying Returns so it’s just a reactivation of Undying Returns. However Undying Returns will count as a different mission in this numbering because it has a new briefing and in the mission itself Mark Faba has an eyepatch from the events of The Undying. No gameplay differences, unlike The Deceivers which is more difficult because you have to kill two targets in one go, but IO would consider this new work so it will count as two missions:

Which gives us 1 mission in Hawkes Bay, 2 in Miami, 1 in Colombia, 1 in Whittleton and 2 in Sgail totaling 7 ETs in H2 and 34 so far

H3 gives us 1 in Dubai, 2 in Dartmoor, 2 in Berlin, 1 in Chongqing and 2 in Mendoza with 8 ETs in its maps. Giving us 42 ETs so far

So by this metric the next ET will be the 43rd Elusive Target mission IO have made

2. How many gameplay-unique missions are there?

But this is a super boring number to conclude from this because no one in their right mind would count The Undying Returns as a unique experience from The Undying, barring the obvious fact of Hitman’s gameplay that you could choose to play one version differently from the other but anything you do in one is transferable to the other as nothing about Faba’s routine and dialogue, the cosmetics of the map or the placement and routes of NPCs is any different. So now we have to count how many missions have IO really made

So we start again with our initial 26 but we leave out the Deceivers. The Guru and Congressman are counted separately because they were made separately. The total of H1 remains 26

Then we take H2 and subtract the Undying returns, giving H2 6 ETs and in total we now have 32 so far

H3 remains at 8 so now we have 40 ETs that IO have given us across all three games from 2016 onwards

So this newest ET will be the 41st unique Elusive Target mission made from scratch by IO. I think this is probably the most official, crowd-pleasing number we could conclude with, but I want to get wackier so join me in the next few questions as we get super nerdy on the numbering

3. How many unique, playable ET missions are in Hitman: World of Assassination?

This is probably the purest number we can distill it down to, because it’s a question of if you were to boot up WoA and every ET was somehow activated all at once how many unique missions would you be able to play? This is probably the most useful number for casual fans wanting to play everything

So we take our initial 26 and cut it down to 24. The reason why we do this not only are we now counting the Guru and Congressman as one mission, because with the Deceivers you can only ever play them together in the WoA launcher, but also the Gary Busey ET was never made available in H2 or H3/WoA. So counting them as separate would be ridiculous because that’s not the format theyre ever experienced in anymore and theres no inside-the-game evidence they ever were apart other than inference from them never interacting which requires a knowledge of their route. So this gives us 9 Paris ETs, 4 Sapienza ETs, 4 Marrakesh ETs, 3 Bangkok ETs, 2 Colorado ETs and 2 Hokkaido ETs for a total of 24. Fun fact I initially forgot to count the Blackmailer in Paris and only realized it when my math in this segment was out of wack. So I initially underestimated how many ETs were in Paris, not only is it double what Sapienza currently has but it’s a little bit over that

Then adding 6 to that 24 we get 30 and the ever unchanging H3 number brings up to 38 in total

So in conclusion the next ET will be the 39th unique playable mission you can tackle in vanilla WoA, on a good day

4. How many canonical ET missions are there?

Now this is the big question because while we can debate how ETs can be canon, it’s no doubt that with their lore bleeding into the main game and vice versa with Mark Faba namedropping future Berlin targets only to get namedropped himself by Vidal as a previous target of Diana and 47, as well as the ICA Data Core showing a whole slew of ETs on 47’s file whether we like it or not ETs are canon. But then that begs the question of how many of these ETs are part of this canon?

Well first we take our initial 26 and cut it down to 25, as the canon version of the Congressman and Guru is the Deceivers. However what we then do is add it back up to 26 because now we have to talk about The Brothers. The Brothers was a cut ET mission where you were to kill two of the brothers of prior Sapienza target Silvio Caruso, in Marrakesh. This was never released except for content leaks that were later made as mods but their names were included in the ICA file on 47 in the Chongqing mission so in the lore 47 canonically killed Caruso’s brothers sometime during all this mess

Then we have to include The Undying Returns as a canonical separate contract from the original, whether he killed Faba or not, because the unique briefing means he was given this contract which he fulfilled and then had to be given a new contract to kill him again. With this it brings us back up to 7 for H2 and 33 so far

Then with the immovable 8 in H3 we bring ourselves up to 41 in total so far in terms of canonical, separate contracts 47 has taken on, elusively that is

Which makes this next ET the 42nd canonical elusive target contract 47 has taken on

5. So how many people has he killed?* (*In the ET format)

This one’s the most interesting question because this isnt a question of how many contracts 47 was given or how many missions you can play, but instead a pure kill count. Because some ETs arent merely one and done, theres a few multi target missions. So just for fun lets count out how many guys you kill in these ETs

In H1: Paris has all 1-target missions, so we count that as 9 again. Whether we count the Deceivers or not doesnt matter, we’re just counting how many people die in Sapienza and that’s 6. Marrakesh has 4, but counting the brothers let’s bump it up to 6. Bangkok gives us our first two target mission: The Ex-Dictator and his wife, which gives us 4 kills in Thailand. Colorado has 2 again but The Surgeons in Hokkaido brings its kill count up to 3. So all in all we have 30 kills on the H1 maps

Then with H2 we have no two target missions but remember Undying counts a second time, whether Faba died and came back or a body double died in his place this is a confirmed kill. Giving us 7 total kills in H2 and 37 so far

H3 gives us another two target mission, this time in Dartmoor. So 1 kill in Dubai, 3 in Dartmoor, 2 in Berlin, 1 in Chongqing and 2 in Mendoza for 9 for H3 and 46 total people killed in the Elusive Target missions

So, assuming this next mission will also be one target as usual, the next ET will be the magic number itself: the 47th person our Agent 47 has killed in an Elusive Target mission. That’s a whole lot of killing

6. But what about [BLANK]?

Now we could go about this all day if we broaden the standards of what an Elusive Target is. It’s well known that IO reuse and rework unreleased Elusive Target missions into other formats. For example the Patient Zero campaign and the initial two Special Assignments in Mumbai and Colombia were made from ETs they had lying around. There’s also more unreleased ETs with no canonical ties one way or another, but there’s also some other cut content that seems like cut ETs but in reality they mightve just been beta tests

But I think this list is the one that answers all the questions of the ET numbering that actually matter. The rest is too niche even for me

#hitman #hitman 3 #hitman world of assassination #world of assassination #agent 47 #47

4 notes · View notes