World Space Limitations

Everyone knows that Sonic was a platformer in his glory days.  Zooming from left to right; running through loops and corkscrews, jumping up and down collecting rings and smashing badniks at breakneck speeds. Well... maybe not so much at that speed. Sonic ranked high in platforming games up until the mid 1990s. 1998 saw him make the transition to 3D and he sort of lost his appeal ever since. It’s taken along time to grasp that the best place for Sonic in terms of level design and game play should be 2.5D; and with some areas in 3D like Sonic Colors and Unleashed. 

ADR was originally going down the path of the adventure series, primarily in 3D. This was proving quite a challenge in terms of planning levels.

The game world for any map inside the Unreal Engine is limited to 10 'Real world' square kilometres. In order to make better usage of the space we have; we had to resolve certain design limitations. Render times and world space Vs speed.

Rendering

A full 3d level has to render what is in front of the player. Occlusion is good for the most part but when there is a lot of geometry and action going on in front of the player this can cause computer slowdowns.  In the 2D perspective, anything in the distance can be very low poly. Add a post process volume to blur the distance slightly and no one would be the wiser if it was low poly or high poly intensive. Meaning: the more polygons on a single model, the more time it takes to render the screen frame by frame.

Space Vs Speed

With sonic not being the typical platform character with his speed boosting ability, running from one side of the world map to the other took approximately 3 to 4 minutes. This in game play terms isn’t quite good. He was too damn fast.

Slowing him down was an option but that also made him lack a certain degree of character.

Scaling down all in game assets and the player character was another option, but that can also cause a lot of problems on the programming side of things, like breaking something with the physics code calculations and can also defiantly confuse the rendering engine.

 From watching various Sonic: Unleashed videos it looked like the game levels encompass several miles due to the speed at which Sonic runs at. Level design had to practically move to a more orientated 2D perspective instead of 3D. Thus sort of keeping his speed, bringing rendering times down and bring ease to level designing.

In the end it was decided 2.5D took more precedence over 3D in ADR.

Development History

ADR first officially started production in March of 2006 after approximately eight months of doing background research into the Sonic franchise and asking questions via polls playing the games and browsing forums trying to piece together information for a game worthy of what the fans seem to demand.

ADR has had its fair share of difficulties. People promising to help out but then couldn’t for one reason or another and the lack of support from talented individuals being scarce to bring the game to its full potential.

The development really kicked off when Digimaks & Xaklse joined the ranks as Level designer and monitor coder respectively. Since then with a little harassment from me; Xaklse has practically single handily coded the entire Sonic game mechanics. Without Xaklse’s help, there wouldn’t have been an ADR as he was the only coder who was dedicated to the project.

The first map to be publically shown was Digimaks version of Sky sanctuary back in mid to late 2006. Later his creation of Marble Zone (which was never released) was used as a test level for certain game mechanics as they were made available to the team to check out. From that moment game play started to feel more like Sonic.

It was a while before we could run through loops and SpinDash into items. But when that finally became available, it felt we had finally started to achieve getting the feel of Sonic into the Unreal engine.

For the longest time the team suffered major blow backs in development. Levels just didn’t really feel worthy of an actual release, some mechanics proved to be difficult to code, alternatives had to be made or full abandonment of a certain in game mechanic as it just was not possible without the actual engine source code.

When the Unreal Development Kit became available (and most importantly, free to use depending on HOW you wish to use it) and after a small discussion with the team, we decided to switch to the newest Unreal game engine due to certain mechanics not working and with our new fan base having a hard time in locating a Unreal Tournament 2004 copy in stores or even having to resort to piracy in order to just play our modification. With the switch, we would have better access to next generation technology such as realistic physics, up to date code and visual effects, not to mention that ADR would become a full fan game (Unreal Tournament 2004 wouldn’t be required in order to play our game) and no longer a deemed modification.

ADRs development has changed a lot over the years. Most of it can be classified as experimental in order to capture the experience of playing a Sonic game. Testing and redoing stuff, trying to find that perfect combination, just to find where the game should really lie.