Often indie developers get caught up in following the "big boys" and trying to do as they do. With a large company, there is a lot of focus on releasing on multiple platforms, in multiple languages, on their first release, and to create a big splash. My advice is: don't do it.
Focus on one platform, make the best possible game and go from there. If you are using a third party engine that already does that for you fine, but if you have to pay extra licenses, and do a lot of extra development, you could very well be wasting your time. If you do not make enough money on your (first) target platform to support moving your game onto another platform, your game will not likely be a success anyway.
Look at Angry Birds and Plants vs Zombies, two of the most successful smart phone games of all time. Both originally only coming out for limited platforms first (just iOS for Angry Birds, PC/Mac for PvZ). Neither of these companies tackled all the platforms that they are now running on, and are likely only ported to those platforms because of the success of the original.
It is worthwhile to focus on trying to write customizable code, and wrapper classes and functions for things that you know will could be or will be swapped out. Obvious things include the graphics API wrapper classes are essential if you need to support both OpenGL and DirectX or some other graphics API. It is also worth having a default functionality for things that could be a problem (like if a platform does not support pixel shading or a limited number of textures on the gpu, make sure your game does not rely on this too heavily).
If you really want your code to be portable, port early and port often. In a larger team I have seen it work where different developers run different operating systems and graphics cards in an attempt to guarantee that most of the functionality will work with a daily build. It is often easier to catch issues as they crop up, then to hunt for hours, days or weeks for all the differences that is not making it run on the other platforms. This introduces other workflow issues, and will sometimes require those developers that broke the build to access to other machines so they can fix it. This does help guarantee that the code written is more portable, and if it works for two very different architecture chance are more likely it will run on those inbetween. The problem for indie developers is they do not usually have this luxury of multiple machines, dedicated developers and perhaps this time.
If you believe that the market has shifted and you really should be focused on another device or platform, that is different, but chances are, your first assumptions about developing for that platform or device were well founded. If your game was not a real success on your ideal device or platform, chances are not very good you will see a huge difference in success if you spend the time to port to the other platforms. This can be frustrating, but instead, focus on improving your original game first, or making your next game even better. If you want to take a lesson from the console developers, consider this: if your game is really that good, people may even buy the platform to run it :P.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
No comments:
Post a Comment