Well, here I go attempting to do two things simultaneously; maintain a blog and build my first iPhone application in the process.
It seemed that simply embracing the idea of building an application was an epiphany. Having never studied C++ or Objective C or any other software code and never having designed a video game or application, it was a rather large leap in my mind to think "I want to build an application for the iPhone."
Mind you, at the time of this posting there are thousands of applications for iPhone and iTouch users. This idea isn't novel, but it is new for me. I'm uncertain how many people with my lack of experience embark on the process and I'm hoping my process will be of interest to others like me.
After embracing the ideas of building an application and blogging about my experience, it was time to do some serious, extensive research.
Apple provides open source software for iPhone developers. Their software development kit (SDK) provides developers with all types of documents, tutorials, and developer testimonials at their web site. http://developer.apple.com/iphone/
Initially, I found an excellent article "How to become an iPhone developer in eight easy steps" at http://www.guardian.co.uk/technology/gamesblog/2009/feb/10/gameculture-apple this gave me the leads to begin the process.
Once I was at Apple's SDK site, I quickly learned that one of the best articles to read BEFORE developing anything was the "iPhone Human Interface Guidelines".
Furthermore, I researched some of the best books on beginning the development process and I found "iPhone Application Development for Dummies" book received very high and favorable reviews. I've ordered the book and I am awaiting its arrival.
In the meantime, I am reading the copious materials on the Apple site, and searching video tutorials on the Web. One site offers a good tutorial at www.pragmaticstudio.com I will continue to search for more tutorials and update this blog with all the reference materials as I come across them.
The other research I have done is to begin to look through ALL the iPhone applications being offered in the Apple App Store in the genre relating to my application, which might fall under entertainment, lifestyle, health or education. Looking through these many apps helps me to understand what is currently out there and what apps may be similar to the one I'm creating. This research is daunting! There are thousands of applications, but knowledge is power and it's best to know what niche you are filling and what the competition is.
Subscribe to:
Post Comments (Atom)
I plan to follow you through this. I have a few app ideas, but when it comes to developing it I've got no knowledge of where to start. Thank you for starting this blog.
ReplyDeleteHi Kanon,
ReplyDeleteExcellent! It's my sincere hope that this blog helps you. I'll cut to some conclusions so you know what the big lessons learned are:
1. We did choose to use command buttons to control actor actions in three of our levels. I believe this to be a less effective use of the iPhone environment. I would not recommend placing command buttons within a game for iPhone for several reasons. (a) Buttons eat into the screen real estate. The size of the buttons need to be large enough to accomodate fingertips of all sizes. (b) Buttons are a bit difficult to navigate on the device. (c) iPhone uses touch and accelerometer features that do work best on the iPhone, thus buttons seem antiquated. (d) The use of the buttons did cause in one case the iTouch device to turn off because of the location of the power button on the device being where the user places her hands. While holding the device, the player can accidentally click into a black screen saver mode, thus interfering with the game play. We never considered the possibility when we made the app and it didn't show up during the testing of the game. Fortunately, it is rare.
2. It is extremely important that all PNGs be "save for web" to reduce their size. Actors and elements should be less than 100kb with backgrounds no more than 300kb.
3. DO NOT build the game on several computers. We hade five team members each building a level on their own computer believing we could migrate to one computer and stitch the game together, but that does not work. GS provides original actor ID numbers for each element individually dedicated to one project. These do not copy over into a new project. We had to REBUILD each level and import all images into a new game to stitch them together.
4. GameSalad has its quirks and acts much like a beta, so do plan to experience some delays, crashes, and frustration. It takes a while to understand the game building psychology behind the program. Whereas, the GS forums do provide fairly quick responses to questions, the forums are not organized in a concise way by topic, issue, problem or error. It's time consuming navigating the forums for answers addressing specific problems. GS does have a number of tutorials (print and video), but there is no book on the software and many issues are difficult to find answers for. Beware, some answers provided in the forums are obsolete due to GS upgrades and may no longer be relevant or accurate, but they are still listed among the entries.
5. Do test your game on a device before publishing it because the game will not necessarily work according to the computer simulator generated version. It may work perfectly on the simulator, but not on the external device during testing. Furthermore, we experienced tremendous difficulty getting our game to play on an external device. Initially, we thought it was due to the Mac OS and Xcode versions not agreeing with each other, however, after considerable time installing Snow Leopard and the latest version of Xcode we were still unable to get the game to play. As a work-around we uninstalled Xcode and reinstalled Xcode several times. Eventually, it worked, but we never understood how it corrected itself or what was truly the problem.
Hope the blog helps.
Hi Kanon,
ReplyDeleteExcellent! I sincerely hope the blog helps you. I'll post a few lessons learned so you can avoid them early. Best of luck
1. We did choose to use command buttons to control actor actions in three of our levels. I believe this to be a less effective use of the iPhone environment. I would not recommend placing command buttons within a game for iPhone for several reasons. (a) Buttons eat into the screen real estate. The size of the buttons need to be large enough to accomodate fingertips of all sizes. (b) Buttons are a bit difficult to navigate on the device. (c) iPhone uses touch and accelerometer features that do work best on the iPhone, thus buttons seem antiquated. (d) The use of the buttons did cause in one case the iTouch device to turn off because of the location of the power button on the device being where the user places her hands. While holding the device, the player can accidentally click into a black screen saver mode, thus interfering with the game play. We never considered the possibility when we made the app and it didn't show up during the testing of the game. Fortunately, it is rare.
2. It is extremely important that all PNGs be "save for web" to reduce their size. Actors and elements should be less than 100kb with backgrounds no more than 300kb.
3. DO NOT build the game on several computers. We hade five team members each building a level on their own computer believing we could migrate to one computer and stitch the game together, but that does not work. GS provides original actor ID numbers for each element individually dedicated to one project. These do not copy over into a new project. We had to REBUILD each level and import all images into a new game to stitch them together.