Emil Johansen, aka AngryAnt, has been working for some time on his ‘Path’ pathfinding AI system for Unity. A remarkable piece of work, Emil has even gone so far as to make a complete video tutorial on the system, explaining its usage and how it works. A big thanks goes out to him for this amazing contribution to the Unity community, as this system is provided free – see the license on his site for more information.
Archive for April, 2009
Stumbled accross this on the web – very useful full vector based file of every part of the current iPhone interface, including the device itself. Really useful for iPhone developers who want to feature the device, or even simply to design their GUIs to fit with those of the existing operating system. The file can be downloaded and opened in Illustrator to be picked apart at your leisure, massive thanks to Mercury Interactive for providing this to the public.
http://www.mercuryintermedia.com/blog/index.php/2009/03/iphone-ui-vector-elements
This production post-mortem was donated by Jacob Williams. His game, Maze Shifter is now available from the Apple App Store on iPhone and iPod Touch. I’d like to thank Jacob for the donation of this article and wish him all the best for future development.
Maze Shifter Post Mortem
About the Game
Maze Shifter is a casual 3D maze-escape game with a few twists. It was a one-man project created for the iPhone, and at the time of writing is awaiting approval to the Apple App Store.
I chose to write this post mortem to shed a bit of light on the problems a hobbyist developer faces when making the switch to indie developer, and why starting with the iPhone was both the best and worst decision I have ever made.
What Went Wrong
Originally, I was going to divide my “What Went Right and Wrong” sections into points, and have the same number of points for each individual section. I soon realized however, that the ratio of wrong/right was way out of proportion. So I am going to talk about what went wrong first, and maybe I can balance it out toward the end… probably not.
If I could give any advice to any aspiring developer out there, it would be this:
Before you begin a project, make sure you understand the limitations of the hardware you are developing for. I thought it would be simple to finish a milestone and test it on the phone – rinse and repeat – I quickly became aware however, that the limitations of the iPhone far exceed that of any other platform I have ever worked with.
I would spend all day coding specific features or working on artwork, just to discover a few hours later when tested that it wasn’t going to work. Most mornings were spent cleaning up the mess I made the day before.
This little issue leads me to my next point. Take your dream game, reduce its scope by about 100%, and then think a little smaller. While that last sentence is mostly (read: hardly) a jest, there is also some truth to it.
On an entertainment medium like the iPhone, the goal should be to get the feel and mechanics of your game across as simply as possible. This is not a gaming device that is usually played for more than five minutes, so your gameplay needs to be either addictive or easy to pick up and play. (If you can figure out how to do both, let me know!)
With Maze Shifter, the scope of the game was far too big to begin with, and it went through quite a few iterations before I got it right. At first, it was simply another hobby project, and every day would bring a new idea or feature. Like any successful game project, however, this is not a good model to follow. After a week or so of development like this, I was forced to sit down and write out the features that should make it to release, and remove the features that were simply too complex for the game.
Another issue with Maze Shifter was the art, more specifically the textures. As the only developer on the project, I am a programmer first, and an artist second. The shapes in Maze Shifter are very simple, but I spent far too much time trying to perfect my textures. The textures themselves where simple, usually consisting of a solid color with a black outline. This texture style is very much like that of “toon shading,” and was the only way to achieve this look, as the iPhone does not support shaders.
In addition to the simple textures, I spent a number of days creating bump and normal maps for the textures, which made them stand out a bit more. As play testing commenced with my “advanced” textures, what I did not take into account was the limited memory allocated to games on the iPhone. Most of the testing for Maze Shifter was done on a second‐generation iPod Touch. This, again, was a mistake. The iPod Touch – especially the second generation, is the most powerful of all the iPhone OS devices. The increased memory usage caused by the textures was causing the game to crash unexpectedly on the device, and required a few days of tweaking (and eventually removal of all the extra texture maps) to avoid such errors going into the final build.
What Went Right
Throughout the game’s development, the one decision I made without regret was to use Unity as my development platform. The testing was quick – thanks to Unity
Remote – and building to the device was simple. In addition, many features and other aspects that had to be simplified or removed took only hours, where it would have normally taken days were I writing the application entirely through xcode. Without Unity, iPhone development would not have ever been a consideration for me. The Unity community was also one of the key reasons that Maze Shifter made it to completion. Most communities have the innate ability to act as a crutch when key parts of your code are broken, but the Unity community – more often than not – got my code back on its feet in a matter of minutes. Two community members (although there are many, many more) that were always able to lend knowledge where Neil Carter and mike_mac. Without those guys, I would still be going over broken lines of codes and bad logic.
Another strong area of Maze Shifter was its simple concept. Even in a prototype stage, the game mechanics were simple enough to provide me with a bit of freedom.
One of my biggest fears with iPhone development was that I would constantly have to change the original idea to suit the restraints imposed by the device, but most of the limitations were caused by over bloated art and bad programming – the idea itself came through intact.
This next point did not seem like something that “went right” at first, but I later realized it was for the best. When the time came to begin polishing the game for launch, I had to completely drop a feature. While I turned this idea around in my head and few hours, and finally (very reluctantly) removed the feature, I was very uneasy about where this would leave the game in regards to difficulty. This removal, however, turned out to balance the game just right. It was neither too difficult nor too easy. I learned from this experience that it never hurts to try a game with or without feature x -it may provide you with some much needed insight, or – as in my case – balance the game to a greater degree.
The last point to this brief section is one of the strongest. Maze Shifter was my first “real” project. Because of this, I decided to not have a set release date. I chose to release the game when I felt it was ready. At first, this idea seemed like a bad one, as I am one that is prone to add features at the last minute, usually breaking the core game mechanics. With this project, however, the drive to release motivated me far more than a release date. As opposed to a mentality of “I have to get this done before the end of the month, regardless of features,” I took a stance that allowed me to take a step back every couple of days and just play the game. I had a mindset of “This is how I want to feel when I play this game,” and upon achieving this, I knew it was time to polish and launch.
Conclusion
In conclusion, the points listed above were only a fraction of what I learned during this process. The best way to approach the “hobbyist to indie” transformation is to dive right in and get your hands a little dirty. Each experience will differ in many ways, but always keep in mind the reason you started this venture – to have fun. If you ever stop enjoying what you are doing, you will never be able to put your heart into it. While my game may not sell a million copies (or one, for that matter), I had a great time creating it. Each game you create is your personal Mona Lisa, some may not understand the beauty of it, but many will appreciate the dedication you exhibit. Do not misunderstand me, however, for I am in this business to also make money. He who does a job for the love of the work, however, will reap far more benefits when the labor is complete.
By Jacob Williams.
Maze Shifter : Indie Developer Post Mortem
Author: wgstone | Filed under: General, Showcase
For those of you new to Unity, you may be interested to know about the Unity feedback forum. An official resource that acts as a voting system, digg style, for Unity developers to vote for their next most wanted addition / change / fix to be included in the next release of Unity.
Whilst this is not a direct cause and effect – the UT team of course has its own roadmap (here) but this acts as more of a community based focus of attention – allowing you as a developer to see what others are hoping for in the future, and have your say too, good work UT!
In addition to the usual newgrounds and other game portals there is now a specific Unity game portal that any aspiring developer can post to. Wooglie, set up by 2 Unity developers who go by the names Leepo and Zylex, was designed to cater for Unity developers looking to get their game online and get feedback without having to email a URL around – with a modest number of games already available, hopefully this community will grow into something big for the blossoming Unity Community.
For those of you new to Unity, and especially from a Flash development background, Richard Hart from EthicalGames.Wordpress.com has some great starter video tutorials for you. Covering some basic elements step by step, at the time of writing Richard has done 7 short tutorials to get you started.
Here are some direct links to the blog posts that feature his videos -
- Lesson 1 - http://ethicalgames.wordpress.com/2009/01/14/unity-for-flash-developers-tutorial-1/
- Lesson 2 – http://ethicalgames.wordpress.com/2009/01/20/unity-for-flash-developers-tutorial-2/
- Lesson 3 – http://ethicalgames.wordpress.com/2009/01/27/unity-for-flash-developes-tutorial-3-prefabs/
- Lesson 4 – http://ethicalgames.wordpress.com/2009/02/06/unity-for-flash-developers-tutorial-4-basic-mouse-interaction/
- Lesson 5 – http://ethicalgames.wordpress.com/2009/02/16/unity-for-flash-developers-tutorial-5/
- Lesson 6 – http://ethicalgames.wordpress.com/2009/03/13/unity-for-flash-developers-tutorial-6-basic-physics/
- Lesson 7 – http://ethicalgames.wordpress.com/2009/03/26/unity-for-flash-developers-tutorial-7-basic-collision-detection/
Don’t forget that we also have our own video tutorial series over at our sister site, www.learnmesilly.com
