Welcome back web stalkers.  As stated in last week’s riveting post, Pixel Shift took 2 months to go from initial concept to release on Windows Phone 7 and iOS.  Dive in for the sordid details…

The Pixel Shift game prototype had support for up to 8 color puzzles, but it made games much more complex and time consuming.  I reduced the colors to 4 and avoided any colors that could be used to create offensive images.  That’s right, I stayed away from colors that could be used to replicate bodily fluids (or solids) and flesh tones.  I also realized that it was good for puzzles to have white space as a working area to ease into solving the puzzle.  There were also going to be other modes in the game, but since the main mode was strong enough, we decided to just focus on it.

Two weeks into development I had the game running on Windows Phone 7 and started getting valuable feedback from friends during play test sessions.  Tutorials got added, refined and streamlined.  The simple visuals got the most criticism from the more hardcore gamers, but the game play won them over.

Settling on the final name was an ongoing debate.  My wife and I tossed around different names but some obvious ones were already in use on various platforms.  Since you could push or pull pixels, “shift” felt like a good term to describe the game play mechanic.

As for the icon, it took 18 designs to get to the final one.  Initially the idea was to have the 4 primary game colors be represented in the icon.  But then we realized that it looked a lot like the delicious icon.  The focus then shifted to somehow represent the game board in the icon.  I looked at various iOS logos and one that stuck out was for the Huffington Post app with the large “H” on the icon.  That led to the shifted P logo and then we needed a color to help it stand out so we used the red color that was used in the game menu.

The icons were created at 57×57 pixels which is the original size for iOS.  I then used different methods to scale the icon for other platforms.  The rounded corners were changed to square corners for the WP7 version to better match the system.

Unfortunately, in my icon rendering flurry, some bad icons were exported for the iPad version.  Most people won’t notice it but if you look closely you will see some blocks that are not perfectly square.  The next update will fix this sooner or later.

Next week we look into the scary world of Android development.

Dreams of Diablo-ish danced in my head and I started on an epic journey of RPG design.  I read books, talked to wise sages roaming cyberspace and started prototyping.  But this did not go well.  I was trying to make something new.  Something different.  But again it wasn’t fun.  Frustrated, I switched to some space combat nonsense which had me tracking down ancient and out of print Star Trek games on eBay.  Mockups were made.  Designs were discussed.  And focuses shifted from tactical to arcade.  Then a spark ignited at the RPG camp, so I beamed down back to that domain.

But still, after a few more weeks, none of the prototypes screamed “awesome” (or even “mediocre”).  It was 2 months with nothing solid to show for it.  I was getting depressed to say the least.  I knew the only way to shake myself out of this slump was to spend a day dreaming about new ideas that could excite me and jump start the creative spirit.

I started the morning with Word (<pose>word!</pose>) and Fireworks open.  As a side note, Fireworks is my fave tool for mockups.  I let my mind wander and came up with 2 pretty solid concepts, with one being a pixel focused game that became Pixel Shift.

It all started with Puzzle Quest.  I think about that game a lot, stalker-a-lot.  It made a great experience by the shotgun wedding of match-3 and RPG mechanics.  But the last thing I wanted to make was yet another match-3 game.  I was thinking about the mechanic and I liked the idea of moving gems around.  Then I had the idea of forming images from the gems, such as shields and swords to trigger RPG combat actions.  The colors for the images would have to already exist in the puzzle and not fall into place.  That led to the game mechanic in Pixel Shift.  All the puzzle pieces are there, just scrambled.  And as a result, it plays like a flat Rubik’s cube, which I didn’t realize until I had to explain the game concept to a friend on the phone.

Here is a side by side comparison of the actual mockup and the final game at 50%.

I removed the mockup’s current state mini map in an early build since it was redundant.

It took 2 months to go from idea to release, but I was moving at about half speed, so it was about a months worth of full development.  I also took my time letting feedback from friends sink in and process.

Stay tuned for the gritty tech details in a future post.

Monstercraft initially only supported the normal and Retina Display resolutions of the iPhone.  When played on the iPad, you can run the small 480×320 version or have it do an automatic 2x scale which makes things blurry and loses the nice sharp detail.

[iPad screenshot after the jump]

One thing I didn’t want to do was to redo the graphics and positions for an iPad version because it would require a lot of work for the artist.  But I did want to take advantage of the sharper resolution.  So I decided on just rendering the high res iPhone 4 verison (960×640) centered on the iPad screen.  I first tested it out on the Win32 side and got it working quickly.  Once those changes were in it only took about 30 minutes to get the iOS version working and testing.  So people with iPads now get a larger sharper version of Monstercraft which makes it easier to play especially with 2 players.

This is what it looks like on the iPad:

There were a few parts of the port which I felt took too long and need to be optimized for the future.

First was the namespaces.  I stripped out namespaces for Zombie Outhouse because they were getting in the way of the actual porting but that itself was a time consuming process, so for the next game I will make sure that namespaces will be used and port smoothly to save a good chunk of time.

The next annoyance was rewriting the checkpoint saving/loading code which was a tedious process.  For the next project, I’m going to write a file I/O wrapper class to handle savings the various data types and classes.  The wrapper will then just be rewritten once from C# to C++ but all the code actually calling the wrapper should not need any modification.  This should save a lot of time.

In Zombie Outhouse, there was a data type name conflict in Win32 with Rectangle so I renamed my class to XRectangle.  For Monstercraft I used the Point class a lot and that name caused problems on iOS because it’s defined in a place you can’t get around so I had to rename it to XPoint.  A few people online looked into clean ways around it but renaming was the cleanest option at this point.

In relation to the file I/O, I need to stop relying on XNA’s automatic loading of XML data files and use a standard text or binary data format for more complex data.  Monstercraft’s XML data was minimal but it will become an issue for future games.

I took what I learned from porting Zombie Outhouse between the various platforms and created a system that would automatically scale the game to the various resolutions.  Specifically, the supported resolutions were 480×320 for original iOS, 960×640 for iOS Retina Display devices (iPhone 4 and iPod Touch 4G) and an in-between resolution of 720×480 for Windows Phone 7.  The WP7 resolution is perfectly in between the two iOS resolutions.

The native resolution for the Windows Phone 7 is 800×480 so you get black bars on the sides of the game screen.  Yes, it’s not using the full screen, but it’s the only way to keep the aspect ratio the same across all platforms.  Also, WP7 handles scaling/centering automatically so that saves some development headaches.  There was no support for the 1024×768 iPad resolution because it was a very different beast and I decided to hold off worrying about it until later.

I wrote a special container class that stored all the coordinates for various textures, screen positions, etc.  I used the lowest res as a base size (for iPhone OG resolution) and scaled everything up by 1.5x for WP7 or 2x for iPhone4 when it initialized.  It helped to space out all objects on-screen on even coordinates so it scaled smoothly for the WP7 version.

As in Zombie Outhouse, I had two sets of textures and fonts, 1x and 2x versions.  The WP7 version loads the 2x version so its graphics would remain as sharp as possible.

I am still refining this process for future games and eventually would like to figure out an automatic system for supporting the full 800×480 resolution for Windows Phone 7.

The three rows represent the head/torso, arms and legs, which give each monster specific attributes.  If you get 3 of the same monster icons, you craft a complete monster and its stats get boosted by 2x.  They also flash in red color to let you know they’re ready to kick some ass.  As your monsters infiltrate their opponent’s lab, they cause damage to it, bringing your opponent closer to their doom.  Two players can even battle it out on the same screen.

Over the next few blog posts, I’ll go into the details of developing Monstercraft and talk about its bumpy history.  For now you can check out the videos explaining its game play and demoing it running on various devices.

Gameplay Demo:

Platform Demo:

Zombie Outhouse Development Part 7: Back to the XNA Arrrr!

[Bonus points to whoever gets the title reference.  Okay, maybe not.]

Porting Zombie Outhouse to Windows Phone 7 was a fairly easy process since the game was developed using XNA and already running on the Xbox 360 & Zune HD.  But Windows Phone 7 is a new mobile platform with its own set of challenges.

The assets were the same high res assets as used on the Xbox 360 and adjusting coordinate values for the 800×480 screen was a simple but mindless process.  The Trial Mode from the Xbox 360 was added back in and the checkpoint saving/loading code was ported to XNA from the iOS version.  The code base was also updated to XNA4, with file i/o being the biggest to change.

Developing for the WP7 was very easy since the tools were great and Microsoft had great support in place with various webcasts, forums, etc that helped made the transition smooth.  I was also fortunate enough to get a WP7 developer phone to do final testing on and fix some issues that did not show up in the emulator.

I wanted to add some kind of Twitter/Facebook posting from within the game, but that isn’t possible since you can’t mix certain elements of Silverlight with XNA.  Hopefully XNA5/Silverlight5 will be able to coexist 100% in the future.  We can only dream.

I took everything I learned with the Zombie Outhouse porting and applied it to my next game, Monstercraft, which is currently available for iOS and WP7!

Zombie Outhouse Development Part 6: To the iPad and beyond!

[Just like a zombie, this blog is back from the dead.  Apologies for the neglect.  I got derailed a few times but am back on track.  There will be a flurry of posts over the next few weeks to catch up on the backlog and then we'll focus on an upcoming action rpg project.]

Soon after the iPad came out, I wanted to upgrade Zombie Outhouse to add native iPad support using the higher resolution art that was used in the Xbox 360 version.  But luckily [really?], I got sidetracked with the Cyborg Mice web comic.  A few months later, Apple announced the iPhone 4 with its high resolution Retina Display.  Believe it or not, this actually would make the porting job a much easier task.

So here is my attempt at one.  Feel free to use it on your website, etc.

While we haven’t officially announced our next game, it has been in the prototyping phase for the past few years and has been constantly evolving, devolving and mutating into completely different beasts.  Here is a peek into the development process for our upcoming game.

Without giving away any details, we finally settled on a workable game mechanic and needed to test and balance the various powers in the game.  I added a CPU vs CPU mode (just like there is in Street Fighter 4) which ran real time and most matches lasted about 5 minutes.  This was great for one-offs but for it would take far too long to properly benchmark all the various powers against each other.

I then wrote an automated testing system that ran each of the 11 different powers against each other.  When running 100 matches for each test case, there were a total of 12,100 (11 x 11 x 100) simulated matches.  How long does all this take?  About 5 minutes which is about the same time as watching one real time game play out. Freakin’ beautiful.

Here are the results from the final test:

So what do all the numbers mean?  CPU 1 is GREEN and CPU 2 is RED.  As you can see when an AI is matched up against another AI using the same power, it’s about equally represented by YELLOW.  The most powerful power is number 7 which is something I had predicted before even writing the benchmark system.

So it looks like the powers are now properly balanced and should offer a good challenge for players as they work up their way to the higher level powers.  If this benchmarking was performed real time it would have taken 10 hours to test each power against each other just ONE time and it wouldn’t have provided sufficient data for accurate testing and balancing.

The lesson to learn here is to perform accelerated automation whenever possible.