I chatted up Keith Shepherd of Imangi, author of Max Adventure [App Store], which has supported TV-out via the aforementioned cables for some time now, to see what he thought the iPad 2's 1080p capability means for existing titles. While he hadn't tested Max on an iPad 2 personally, he felt it likely that the newly supported resolution should be there among those presented to an application by iOS, and therefore presented as an option in his game.

And, he was right.

With an iPad 2 connected to a 1080p HDTV by way of the Apple Digital AV Adapter (the HDMI cable), I fired up Max Adventure to see how it runs on the new hardware. Max, which supported a maximum resolution of 1280x720 on all previous devices, presents the option to run at a full 1920x1080 on the iPad 2. And, when chosen, the game runs beautifully in full 1080p.

I also loaded up MajicJungle's Chopper 2 [App Store], which has supported TV-out since day one, and noted that it runs in full 1080p on the iPad 2, where it, too, was previously limited to 720p.

It's great news that existing apps like these got an automatic upgrade courtesy of Apple and Imagination Technologies.

Since I was caught up in waving around my HDMI cable, I decided to try it out on the iPhone 4 running iOS 4.3, which we already knew supports TV-out via the component and VGA cables. I loaded up Max Adventure and my HDTV lit right up, with full audio and video coming through just fine, but at a maximum resolution of 1280x720 due to limitations of the device's earlier generation graphics chipset. Still, this is great news, as HDMI delivers a nice, clean digital signal while the VGA and component cables provide analog output only (and lack audio information).

Speaking of those older cables, a quick look at Apple's website indicates that the VGA cable will also deliver 1080p video when used with the iPad 2, but that the component cable is limited to a maximum of 576p on recent devices and just 576i on older hardware.

Our earlier iPad 2 HDMI-out demo video can be seen here.

Daniel Zandelin, who is apparently a big fan of Mario Kart DS

Donut Games is the developer/publisher of well over a dozen iPhone games including fan-favorites like Rat On A Scooter XL, Comet Racer, and Cows in Space. Officially titled "Swedish Game Development Group AB," Donut Games has all of their games available in flash form on their website, where they can be played for free. With a arcade-like menu and three-star rating system for the levels in all their games, Donut Games has earned a large fanbase by consistently providing simple, quick experiences that draw players in for more, usually with a focus on increasing high scores.

I got the chance to find out a little bit more about one of the important faces behind the company, Daniel Zandelin, one of the founders of Donut Games.

Touch Arcade: What is the history of Donut Games as a company?

Daniel Zandelin: We're a small team of game enthusiasts, with roots going back to the good old days when the 8 and 16-bit gaming systems evolved. As a kid in the '80s I was quickly sucked into the intriguing gaming world of the Commodore 64, and together with my older brother, Ola, I grew an early interest of developing our own games, which lead to a bunch of quirky, buggy BASIC-games. Many years (and programming languages for that matter) later, in 2003, Ola started his own indie company to develop shareware games, and a couple of months later I quit my current job to join him.

The shareware market, which had just started to transform into the casual games market, was a blast! You could be a small team of 2-5 people and release quick, innovative downloadable games on the internet without the need for large budgets, and our titles (which we released under the Arcade Lab brand) were very well receieved.

As the casual games space and its portals grew more mature, productions grew bigger and a few certain genres got established and didn't leave much room for creativity or variety. So in 2006 we launched DonutGames.com, which started off as site for our Flash games. This project would give us our much needed room to play with new concepts and try out new ideas or whatever fun or crazy thing that popped into mind. When Apple announced the AppStore in 2008 and we started to dig deeper into the specs and SDK, we realizied this was the perfect platform for us: a device that you can carry with you anywhere you go, a store that is open for all and an excellent hardware to build your apps upon.

Comet Racer, one of our favorite creations from Donut Games

Touch Arcade: What exactly is your role within Donut Games? Could you tell us about some examples of your contributions to some of the company's games?

Daniel Zandelin: My role differs from one game to another, but my main areas of involvement are programming, sounds and last minute tweaking. The creation of a Donut game typically follows this flow: Ola, the concept master mind, brings up a new idea for a game, decides a theme to go with, and creates a mock-up of the basic artwork needed to get started. A programmer picks up the game and makes it playable, and we evaluate the result to see which elements are in place and what can be improved.

Once the basics are in, the level designers start working on the levels, and may eventually request more features from the programmer. In the last phase, I start working on the music and sounds. Once they're in, it's time for the final tweaking, which may or may not include additional visual effects, an extra mini game, and other last minute adjustments to make the game feel more solid. Simply put, Ola starts off the games, I finish them, and the whole Donut team is involved in the in-between.

Touch Arcade: What's the weirdest thing that has ever happened to you during your time with Donut Games?

Daniel Zandelin: This happens occasionally: When I'm sitting in a public place and a stranger next to me picks up an iPhone and after a few seconds I realize they just launched a Donut game. It's a weird feeling!

Rat On A Scooter XL, one of Donut Game's biggest sellers

Touch Arcade: If you had an unlimited budget to create an iPhone game, what sort of game would you make?

Daniel Zandelin: Back in the '90s, me and my brother started working on a really whacky point-and-click game for the Amiga in which players controlled a crazy kid with long greasy hair called Matthew. I don't remember all of the details of the story that we came up with for the game, but Matthew owned a tiny, aggressive poodle and had a secret band in his cellar together with his best friend who owned a shabby old Hammond organ. It would play like a “Get item A to unlock item B, use item B to find item C” sort of game, but instead of logical puzzles it would involve things like flushing yourself down the toilet to find certain items. I'm not sure everyone would appreciate a game like that for the iPhone, but if money was no issue it sure would be fun to bring this old concept to reality.

Touch Arcade: What is something that you'd personally like to do in a future game release?

Daniel Zandelin: I know that this may sound dull, but I'd like to continue with what we're currently doing. We have great fun creating these games, our model works really well for us and our fans seem to enjoy what we're doing.

Thanks Daniel. Check out Donut Games' catalog on the App Store. Daniel is username DonutGames on our forums.

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.