Sonic 3 (& Knuckles) 20th Anniversary
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:
Angel Island Zone with all enemies, gimmicks, bosses, and intro/intermission sequences
Special Stages from both Sonic 3 and Sonic & Knuckles, including âBlue Spheresâ functionality
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.
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.
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 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
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:
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.
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.
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.
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.
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!
andulkaphoto
jacobvanloon
annaxmalina
blakekathryn
turnnoffyourmind
ellievsbear
