Eager to know more about both Sonic CD and the iPhone Retro Engine and Retro Engine Development Kit (or RDSK), we fired off a series of questions. The interview is totally worth a read, but beware, it will only make you want Sonic CD and other games produced by the RDSK even more.

Eli Hodapp: How flexible is the RSDK? Is it tied to a game like Sonic or would something like Castlevania with RPG elements be possible?

Christian Whitehead: All of the actual Sonic CD logic is script driven, so the Retro Engine is more than capable of different styles of gameplay. A game like Castlevania would definitely be possible, since the engine excels at handling 2D side scrollers. Stuff like top down RPG's would be fine too, I wouldn't count it on doing something like a full on 3D racing game though!

EH: What is involved in building a game in the RDSK? Does the it somehow interpret the ROM file to generate levels and sprites automatically? Can you tell us how closely your RSDK relates to the original ROM code?

CW: Using clean reverse engineering, I've been able to extract the level layouts and sprites in a pretty automated fashion. The formats in Sonic CD (especially the PC version) were pretty easy to deduce. I haven't touched the original ROM code though… I don't have that level of understanding of Motorola 68k assembly.

EH: How much research did you do on the Sonic CD game? The physics in your demo look spot on, what was the trick behind that?

CW: Quite a lot to be honest, it owes much to my many years as a Sonic fan. If you go to http://www.sonicretro.org/ you'll see a community that's very interested in dissecting the original games. That's why the demo was made in a short time, I know Sonic inside out, and so have a very clear understanding as to how it can be recreated. It involved a lot of frame by frame analysis of the game running in an emulator to observe how the game (and all its objects) behaves in detail. I could go on and on, but y'know… trade secrets?

EH: On your site you mention putting together the Sonic CD proof of concept in a month. Does that count development of the Retro Engine and RSDK, if not, how long did those take you to do?

CW: Officially, the Retro Engine and RSDK have been in development since March 2008. However, the iPhone version of the engine actually only took a week to set up!

EH: During your month long process of porting what you have so far of Sonic CD, what was your average work day like?

CW: I'm a freelancer and a musician too, so it was sort of in between a lot of this stuff. Lot's of late nights, and giving up partying! But yeah, it certainly wasn't some insane crunch period you hear about at some of the big name studios.

EH: What is the work flow of starting a new game in the RSDK? Say you wanted to remake Gunstar Heroes, what would be involved?

CW: To create a game like Gunstar Heroes, or to literally port it? Obviously a literal port requires a degree of reverse engineering to find out how stuff like level layouts and sprites can be extracted first. But creating a new game in the style of Gunstar Heroes would just be a normal game development process. One thing I want to make very clear: The Retro Engine and RSDK are not magic, it will NOT instantly port a game for you (or toast your bread either). All it does is provide a fast and efficient 2D framework, which has features very similar to what were present in many 2D games of the 'golden' 16 and early 32 bit era along with a nice editors and powerful scripting system. It takes the hassle out of having to set up API's, you can just get down to business.

EH: What are your plans for the future with the RSDK? Has Sega been receptive to your Sonic CD demo? Ideally would you want to sell them the RSDK technology or just a perfectly ported copy of the game?

CW: Personally, I'm only marketing end product Sonic CD to SEGA, not the actual engine. I'm proud of my work and it'd be a shame to let it go and not be able to develop it further for my own future endeavors. The pitch was made to Sega about 2 weeks ago, and after an initial response, I hadn't heard back until they made that blog post. That's what made me decide to show it publicly, they asked what to port and I wanted them to see a clear answer.

EH: In 1990, John Carmack and Tom Hall built a similar demonstration based on their own game engine running the first level of Super Mario 3 titled "Dangerous Dave in Copyright Infringement." Nintendo politely refused their offers to make a Super Mario port for the PC and they went on to use that same engine for Commander Keen. Do you have any similar contingency plans if Sega gives you the cold shoulder and/or sends you a cease and desist?

CW: Gary the Porcupine anyone?… Seriously though, I do have my own game ideas that I'll be pursuing if this all folds up. I really like the iPhone as a gaming platform, so it wouldn't be the last you'd hear from me.

And there you have it! Sounds like amazing technology, and I can't wait to play a game built with it whether it's Sonic CD or some other game. Since we first posted about it, their comments have been flooded by people demanding Sonic CD. If you want to see Sega explore the Retro Engine instead of their current barely-playable emulator, let them know.

My name is Mark Andersson, and I have been working with Freeverse for over a decade. I was the Lead Programmer for Burning Monkey Puzzle Lab, Burning Monkey Casino, Wingnuts, Wingnuts 2: Raina's Revenge and Neon Tango. Most recently I've been working on games for the iPhone, and developing versions of Burning Monkey Puzzle Lab and Burning Monkey Casino.

In that effort big chunks of code came over from the original Mac versions largely unchanged, making development on the iPhone that much easier. You really can consider the iPhone platform to be like a tiny Mac, which is great for old-school Mac developers like me and the other Freeverse guys. The real effort goes into rethinking the interface for the smaller screen and the innovative control methods, and of course maximizing performance within the limitations of the hardware.

early development shot of Flick Baseball

My current project for Freeverse is an original, ground-up, iPhone game and the next title in the Flick Sports series: Flick Baseball. So when you're not bowling or fishing you will be able to enjoy America's favorite pastime in your pocket! (Hmmm… that didn't come out quite right)… In this post I hope to give you some behind-the-scenes peeks at the game during development and touch on some hopefully interesting aspects of the process.

Scope of Gameplay

The first design challenge in Flick Baseball was trying to determine the right mix of game depth and complexity while keeping intuitive mechanics and "pick-up and play" appeal. It's a tough problem, as baseball is a very intricate sport and that's part of its appeal. We think we've charted a course that gives the player the maximum freedom in choosing how they prefer to play, but I'm sure we'll be tweaking and making adjustments well into the testing phase.

Flick Baseball will begin with the ability to pick a pre-made team or to customize the names of the players, edit their stats and even design their uniforms. You can then choose to play a single game against any other team, play an entire season, or just skip the hard work of the regular season and enter the post-season race with your team in the wild card slot. If you go through the regular season you'll be able to speed things up by skipping any games you feel like and letting the computer simulate the outcome.

We needed player-controlled batting, of course, but we also wanted to include pitching with some control over the pitch types. Your players will also have some individual statistics which may make them more able to get a hit or a home run, and we wanted to keep an element of strategic use of your lineup to try to get the best outcome possible. For example, if your pitcher gets up to bat you are likely not going to swing for the fences and instead may want to try a sacrifice bunt instead — especially, if you have a runner on base and an out to spare.

What we did not want to do is include the ability to control absolutely every aspect of the game, which would slowg down the action and sacrifice fun for realism. So, stealing bases, controlling base running and dictating the movement and action of the fielders was dropped. With only touch controls and limited screen real estate, keeping out clutter and unnecessary complexity is a top priority.

While I played a few baseball games, including some really awful ones (yes, Ninja Baseball Bat Man, I'm looking at you), I wanted to avoid playing every game available out there because I did not want to subconsciously copy from them. Also, their input methods were universally very different from what the iPhone offers and implementing D-pads and virtual buttons on the device screen was not an option we wanted to explore.

Prototyping

During initial prototyping, I worked on the basic setup and engine and used 3D animation built for Moto Chaser and Flick Bowling. I started out by implementing batting practice to get a feel for animation, timing and ball simulation.

The Sequencer

We decided early on that we wanted as many CPU cycles as possible dedicated to graphics and sound processing. So, we are not going to take all nine fielders and give them each complex artificial software brains so they can work intelligently as a team. Instead, we realized that you can figure out a set of possible realistic outcomes when a hit occurs. For example, one of these could be a line drive that goes over the shortstop's head but drops down before the left fielder can get it, and results in all base runners advancing a single base. Others are even simpler, such as foul balls and home runs.

So with a large enough set of these outcomes you would be able to put together a realistic game. You will be able to pitch or bat and your inputs will determine the possible set of outcomes, but once the computer figures out how the play will proceed, a sequence of actions will take place that has been predetermined to some extent. However, there is still a real time simulation of the ball motion and the fielder actions. So it's not a movie clip like in Dragon Slayer.

The way this works is that there is a sequencer that can be issued commands. These can be stacked up and then the sequencer will go through them and take the appropriate action, which is really delegating the command to the various independent controllers for the ball, the fielders, the runners and the camera.

So the sequence for an easy grounder to the shortstop who throws the ball to first to get an out might consist of:

1. Set the initial velocity and angle of the ball to go towards the shortstop but roll along the ground.
2. Tell the short stop to move to intercept the ball and stop it when it gets to him.
3. Tell the first baseman to start moving towards first base.
4. Wait until the short stop has the ball.
5. Tell the short stop to throw the ball to first base.
6. Set the velocity of the ball so that it arrives at catching height at first base.
7. Tell the first baseman to catch the ball.
8. Wait until the first baseman catches the ball to report the outcome and end the play.

Within this framework I ended up adding other niceties, such as being able to set a delay to wait before the next command is processed, as well as telling fielders not directly involved in a play to rotate to face the ball. If the command is not a time delay or waiting for a fielder, they are processed and removed from the queue during the same animation frame.

I have also been implementing a number of camera commands, such as moving the camera to another location, either instantly to simulate a cut to another camera or gradually as if the camera were on a giant moving boom. There are also commands to point the camera at any fielder or base or follow the ball and change the field of view to simulate zooming.

This can get complicated quickly if you want to be able to control everything, but the most important part is to make sure that things from the camera point of view look good and you can see the action.

In order to perform the simulation of the sequences in a controlled environment, I am working on the various controller objects using g++ in Unix and staying away from Xcode for the time being. I need to make sure the outcomes are working properly before trying to debug other aspects of the game on the device. So, for now I am simulating the game frame by frame and outputting visualizing objects in POV-Ray files. I am moving the camera around as it would be on the real device so I can get a sense for how things might look and how the timing is working.

In the following movie example, using little monoliths for the players, the batter hits the ball towards the shortstop, who fields the grounder, lobs the ball to the second baseman who then turns and quickly throws it to first base for a double play. There are about 30 sequencer commands right now to implement this sequence, although there are few extra ones to simulate a pitch right now. About a third are dedicated to camera movements and timing.

The red boxes are the inactive fielders, while green indicates fielders that are doing something, either moving, waiting for the ball, or just facing the ball in the case of the third baseman for example. The yellow boxes are the active runners.

That's it for this edition, but feel free to ask questions and comment about anything you like. I'll also be on the TouchArcade forums (username hellosh) so you can reach me there too.