The Making of Magnetix
From the start we wanted Magnetix for iPad to be simple to play but use variables to add complexity. What we ended up with was a unique and simple game in theory, but challenging in practice, where players were rewarded for perseverance and planning.
The original concept appeared one day while messing around with a real magnet. Jassa created a game which used a magnet and a bunch of metal bottle caps on a table top. Using the bottle caps, one player would set up a course which had to be navigated by pushing the square magnet along the table. The aim was to reach a designated end point without touching any of the bottle caps. As the magnet was quite powerful it would attract the bottle caps quickly, making the game rather challenging. Once the bottle caps were stuck to the magnet the course would have to be reset, the player's turn would end, and the next player would attempt it. This lead us to think that different materials with different levels of magnetism would make for cool variants, and the idea for Magnetix was born.
We wanted the gameplay of Magnetix to have a level of intensity to it. The sense of urgency to move quickly or slowly at any given point whilst knowing when to use each for maximum effect.
The core game mechanic centres around a very simple concept. Enemies are drawn towards the player once they enter the invisible magnetic field. If the enemies touch the player, the level resets. With this system in place, there were almost endless variables that could be added to it to create variety in gameplay. However after much discussion we finally settled upon; strength of magnetic pull, enemy size and moving enemies. Other variables discussed included snake-like carriages of enemies that connect to each other, enemies that move position on timers and 2 player mode. But as with any project, the latter options were put into the 'nice-to-have' category but ultimately didn't make the final cut.
Learning the ropes
Being our debut game, Magnetix was as much of a learning process for us as a passion. We created completely new workflows and gradually optimized our approach to asset creation and problem resolution.
In addition to creating a game that was manageable and feasible for the output of our company, it was also important for us to create a game that we actually wanted to make. As an independent game developer we were able to create our concept, choose the format and execute the designs ourselves without having to satisfy a third party. This freedom helped to not only streamline the development process but also maintain the passion for a project that we had created entirely ourselves.
How hard is too hard?
A major challenge with Magnetix was difficulty scaling for each of the levels. From a UX stand point it was important to get the balance between difficulty and engagement right. Also, due to the unique nature of the game, we found that players were unfamiliar with the gameplay format. This lead to observations that certain techniques for passing levels were only apparent after playing for an extended period of time. We saw this aspect of learning as a barrier to player engagement and decided that the best option was to have user tips guiding the player. Our beta testers also agreed that without the tips, the game was entirely too hard. Adversely, we were cautious not to make the game too easy as the satisfaction of passing a level would then be diminished and lead to a less rewarding experience. As a whole, perseverance was to remain a key value to enjoying Magnetix
The application of the magnetic fields was created by applying a "magnetic strength" to each of the enemies. That value, along with a field radius and a speed gave us enough variety to come up with seemingly endless level layouts. It also kept the actual game loop relatively simple thus we were able to keep gameplay performance up where we wanted it. Adding the randomly moving magnets helped to mix things up a bit as it made sure that those levels were never quite the same the next time you played them. We toyed around with the idea of enemies being able to "see" you from one edge of the screen through to the opposite edge but it made gameplay virtually impossible on the more advanced levels.
One of the greatest workflow breakthroughs that we made was during the level creation and planning stage of Magnetix. A level generator had been created using a simple Flash file that would place enemies onto the stage and output the positions of them to XML. This XML file was then baked into a compiled version of the app for use on the iPad. This process, however, was cumbersome as the level difficulty couldn't really be gauged until the app was compiled and transferred to the iPad for testing. Sometimes levels would be too hard, other times too easy. This lead to us choosing to use external XML level files that were read from the Piñata servers. After the XML was exported from the flash file it was then uploaded to the server where it was instantly read into the app on the ipad. This workflow for testing sped up the level creation process and difficulty scaling significantly as it removed the need to compile a fresh app (roughly 3 minutes each time).
As with any creative process, it is always best to dream up the most outrageous and unbelievable ideas and slowly bring them towards a middle ground within your technical constraints. A major challenge we faced was ensuring that Magnetix was playable on the iPad 1. This decision to encompass all incarnations of the iPad drove the design and lead to some of the graphical effects being somewhat reduced in complexity, however the artwork style still aimed to give depth and variety without the use of animation.
Much of the design in Magnetix centres around the use of circles. This is in relation to the fact that circular movements are, by and large, the key to success within the game itself.
Coming from a Flash development background, we decided the quickest way to get our game up and running would be to leverage the Adobe AIR sdk. This would allow us to at least get a working prototype completed so that we could start testing the concept. As it turned out in the end, the performance AIR gave us was more than enough to compile a release build.
All of the game code was written in FDT and compiled using the ADT compiler with an ANT build. About halfway through the development process the Starling framework was made publicly available. Though we floated the idea of porting everything over to the Starling framework, we realised that with the performance we were already getting out of the 3.1 sdk, along with the fact that the gameplay is relatively simple, it was going to take more time that it was worth. Working with technologies we already knew made the workflow a lot quicker (and more enjoyable!) than it would have otherwise been. The game is partially blitted in that the game components and animations are drawn from sprite sheets, but the application itself uses the display list in the traditional manner. We found that breaking the sprite sheets up into smaller, separate sheets (rather than having one big sprite sheet) helped a lot with performance. Pre-caching sheets before they were needed also helped with performance.
The real challenges in development with Magnetix came down to performance. Our initial testing was on a first generation iPad and while we were pleasantly surprised at the the results, we were absolutely blown away at the performance on later models of the device. We decided to go with the approach of "if it works well on the iPad 1, it'll be just fine everywhere else". There were a whole heap of things we tried to get the most out of iPad 1 performance but it really came down to knowing the device capabilities, and then working backwards from there. Though we can't stress enough that you can never do too much testing on the device, there is actually a lot you can test by simulating it on your development machine. Profiling is probably one of the key points here - we used the FDT profiler which was fantastic as it allowed us to quickly get an idea of the current and maximum memory usage. Once we figured our what our boundaries were, it was just a matter of working within them. At the end of the day, it's unlike flash development for any other device/platform - you just need to be a little more conscious of memory, and make sure you are extremely thorough with garbage collection.
Our decision to use Adobe AIR to build Magnetix has now given us the option to publish it to multiple devices including Android and Blackberry. Whilst it is still currently only available for the iPad, the option to target additional platforms is just a matter of writing the relevant wrapper classes (which won't take us long at all!)
In the end, the creation of Magnetix as an independent game for ipad was a hugely satisfying learning experience. Seeing a project go from concept to application in such a short period of time was fantastic. And overcoming the challenges of game development without compromising features was as rewarding as it was educational. The addition of a shiny new mFWA award also helps to keep the fire burning as we can't wait to do it all again with our next title!
We would also like to take this opportunity to send out a special thanks to Carl "Speccy" McGee for all of his hard work in the testing phase.
About the authors
Nathan Pana is a freelance digital designer specializing in UI and UX design for mobile devices. With a background in multimedia he is a jack of most trades. He has done agency circuits in Adelaide, Toronto and London.
Jassa Amir-Lang is a freelance interactive developer based in Adelaide, South Australia. Starting off with Flash 3 (not CS3, actual Macromedia Flash 3) Jassa now specialises in desktop, web and mobile application development. Jassa's global client base has given him the opportunity to work on a wide variety of interesting projects. He has also written for numerous magazines on the topics of Flash and Flex.
After numerous collaborations throughout the 2000s Jassa and Nathan joined forces to form Piñata Games and release Magnetix for ipad, their debut title.