Completion and Frustration: Day 3 of iPhone Game Programming

We spent yesterday working on two things - adding and removing objects to and from the screen "on the fly" (instead of just when the game starts up) and then beginning a project by creating classes.
The first part of this took a bit longer than I had planned for - I meant it to take about 30 minutes, and it took 60 minutes. I'm glad we spent the time on it, though, for two reasons - one, it is an important skill to have, and I wanted everybody to feel like they had a handle on it, and two, because the second part was frustrating for a lot of people, and I'm glad it didn't drag on more than it did.
The second part of the class involved making a new project, importing graphics, creating classes to represent objects on the screen, and instantiating those objects. Basically, it was the next step in the learning process - instead of just copying what I was doing on screen, the students had to remember how to do stuff, and integrate what they had learned with a bit more independence.
It's hard to do - I am always tempted to reach in and "fix" everything for them, and sometimes I do. I think it was the right thing to do, but I don't want it to sap our momentum. Unless it needs to. I've worried (based on last year) that the class could become a grueling march of concepts without much chance for the students to innovate or practice on their own. So a pause in the "instructional" part of the class seemed like a good idea.
So what's coming up? Today, I plan on doing:

• Layers
• "SneakyInputs" - joysticks and buttons
• a lesson on Spritesheets (a.k.a. Texture Atlases) by Matt
• animation of sprites
• and perhaps, in the case of the bullets, keeping a stash of bullets that are hidden when not in use.

I think we'll be using this project for a couple of days. I can see us working on collision detection, text fields and possibly particle effects!
Stuff I want to emphasize today - I hope I remember at the start of class:

• Reading and commenting on each other's blogs
• One class per type of object
• The difference between sprites and things that hold sprites

First day...

I think we got off to a good start on the first day. We had a bunch of new material, but some time to play, as well. Let's see, what did we do....

• Went over the class requirements, including the blogging requirement
• Got everybody going in XCode with the default "Hello World" app
• Added a couple of graphics to the scene
• Introduced Actions and played around with them.
• Started listening for touches

Whew! That's quite a lot, and I think the kids handled it well. We have a few folks that are a bit frustrated with semicolons, typos and matching brackets, but that seems par for the course - I think we all have been frustrated by that in most languages.

Tomorrow, I'm looking forward to creating a new class, moving around with the update: function, and some simple loops. If there's time, perhaps we can make a simple game of it....

Last minute prep for cocos2d class

I'm sitting down with a chunk of time and few distractions to actually try the examples that I am planning to teach tomorrow in my cocos2d class - the first day. As always, it is interesting to note the difference between what I know I can do and the practice of actually doing it!

Right now, I am playing around with actions, updates and touches, working through the "Your first game" tutorials in both cocos2d's official tutorial and Steffen Itterheim's book. There are things I like about both of them, and things I'd prefer to avoid, at least at first, of course. (E.g., accelerometers - many of our students will be rocking the simulator, so that's going to fall under "advanced" for this course.) I think I'll try to find a middle ground.

One tricky thing I need to do is to find a way to do an exercise for the kids so they can extend what they are doing, not just repeat what we did in class. I don't think I did a very good job of that last year, so we just did a lockstep "type in the following! Look what it did!" kind of class. For some students, that's enough to get them thinking and exploring, but I can't assume that of everybody, of course.

So those are my challenges as I head into the evening.

- Posted using BlogPress from my iPad

Texture atlases in cocos2d

I was just learning about texture atlases in cocos2d in Steffen Ittenheim's (sp?) book. They look very handy, and I can see the advances in memory, code and time efficiency. The question, though, is how to convey this to students who are new to programming? Is it worth worrying about? Do I show them the inefficient way first (as Steffen does), and then show the improved way, or do I just go straight to the "good stuff"? (presuming that a texture atlas is always the better way....) A texture atlas doesn't make as much intuitive sense as a one-file-per-sprite method.

I think that it Is a similar question to actions vs manual animations. What to teach in a limited time?

So, dear reader, what do you think?


- Posted using BlogPress from my iPad

Trying out new cocos2d book

I am giving Steffen Itterheim's new book "Learn iPhone and iPad cocos2d Game Development" a try. I can't find it in hardcover, so I bought a digital copy.

I am considering it for teaching a three week course on iOS game programming to HS students - right now, it appears to be the only book on the subject out there. (I am looking forward to Rod Strougo's book, but it isn't due until March.)

So far, the books seems like an authoritative resource, but it starts off a bit slow - there are three chapters of background information before we start writing our first real program in Chapter 4. But that program is a good one, and it might be the place to start - with the understanding that we need to take some things at face value and expect explanations later.

There is an interesting point I've found in this chapter of Itterheim - on page 76, he explains why you shouldn't use actions to move a player's sprite if you are going to be making frame-by-frame adjustments: they won't work. By the time the computer is ready to animate the first step in the action, you are telling to quit that action and start another one. So nothing happens. This makes a lot of sense. However, as a teacher, I wonder: why teach actions first then?

Still, it's a good resource so far. I don't know whether we can get hardcopies in time for the class, which starts Jan. 3, but maybe we can get by with the electronic version.

Uploaded (October 1)

Ooops! This should have been posted on October 1...


It's been a few whirlwind weeks as I put on the final touches - a new "hint" sound effect, a non-proprietary explosion sound for the end, the statistics page, pop-up instructions, fixed graphics on the menu, an updated instructions screen. But last Saturday, I deemed version 1.0 complete.

And that's when frustration really started to kick in. Every step in Apple's App Store submission process is (presumably) reasonable, but it takes a lot of time and internet searching to work through it all.

My first problem was my own fault- when I originally set up my developer account, I used my work address, because I was just planning to teach the program in class. For a personal project (for pay), however, I needed the legal address to be my own. This took an email to request the change. 48 hours later, I got a response requiring me to fax my driver's license in to prove I was who I said I was. (As I said, it's all reasonable; I'm glad they did.) Then it took another 48 hours for that change to go through.

So today I approved the Apple contract, set up my business officers (all of them are just as good looking as the chief programmer), told them where to send the money, and gave them my tax info.

After that, I went to another section of the site to register my application for the App Store. This required setting a price, a description, screenshots, etc. All stuff I was expecting.

So then they told me to "upload your binary." Right. Where is this binary?!.

I remembered that I hadn't yet built the program as a "release" product - just as a "debug" product. So, I switched it over and hit build and run. And all the old settings bugs I'd had to hunt down months ago had to be done again. Ok. Still can't find the binary file.

I hunt around online. After many false leads with people on the Internet telling me to edit the internal files of my project with a text editor - a bad idea, IMHO- I found instructions to "build and archive." Great! But where's the binary file?

A little more poking around, and I discovered online that the build and archive command sends its result to the Organizer window, where there is also a "send to app store" button. After a few false starts where I realized that I had the program set for both iPod and iPad, I got it set to go. (My app is just for the iPad, at least for now.) But when I tried to send it in, I got a message saying that my provisioning profile didn't match up.

So I sent quite a while looking for what that meant. Finally, I found (in yet another part of Apple's website), a page that indicated that I needed a different profile to submit the apps than the one I was using to test them. A little more trial and error, and I got it to upload!

So now my little app is officially uploaded and "waiting for review." There's nothing to do for it now but to wait... In hindsight, there was a lot of this I could have done earlier; I didn't have to wait to finish my program to get started. Still, I am flush with the glow of victory!

But I still don't know where that binary file is.

- Posted using BlogPress from my iPad

Starting cocos2d

I had a terrific time at the #VTM_iPhone (Voices That Matter) conference in October - one of the best things I got from it (besides great contacts) was a chance to see cocos2d in action. I'd heard of cocos2d, of course, but I hadn't connected with it yet. It looks like exactly what I need.

For what, you ask? Well, I have two needs: 1) I want to write my next game, and I'd like to work in the 2d world this time, instead of fighting with OpenGL. And 2) I've got a 13-day class on writing iPhone games (two 70 minute periods a day) that I am teaching in January. To programming neophytes, and a couple of experienced kids. Actually, I am co-teaching it with one of my older students.

So I need something with a quick entry point and lots of flexibility. Cocos2d looks to be just that. We can get stuff up on the screen and moving on the first day, and perhaps interacting by that afternoon! And with hooks for animations, sprite sheets and tile maps, we can focus on ideas of game design, rather than some of the mechanics of writing all that code.

The one weak point, as I see it, at the moment is documentation. There's some, and it's growing, but at the moment, it is still a bit lean.
Here are some resources I've found:

• The official Programming Guide at Cocos2d-iphone.org.
• Ray Wenderlich's excellent blog, which includes some good cocos2d resources.
• Here are two books:
• This book by Steffen Itterheim, which has scary fruit on the front, looks promising - it comes out in a month.
• This book by Rod Strougo, the presenter at VTM, also looks terrific. Sadly, it does not come out until March, which is a couple of months after my class ends.

Still, I'm looking forward to trying Cocos2d and will share what I learn here.


- Posted using BlogPress from my iPad