I think Corona is a great kit for writing games in general, especially arcade games and board games. There’s no built-in support yet for tiled maps, and it looks like Cocos2D will have that built-in first. But even with that disadvantage, developing on Lua is so much more productive than developing on Objective-C that I’ll still come out ahead.

Some apps aren’t a good fit, though:

• those that extensively use the CocoaTouch UI controls. In Corona, you have to create your own buttons, text fields, etc. There’s the ui library, but it only covers a few controls.
• those that access APIs that aren’t wrapped yet by Corona. For example, access to the address book seems to be missing.

There’s the worry that Corona SDK will violate section 3.3.1. Folks from Corona gave some reassuring messages, but of course, with Apple, you can’t have absolute uncertainty. My take is that even if Apple gives Corona the boot, Corona will become Android-only, and Corona SDK is worth $99 even as an Android

I’m taking the $99 plunge. If nothing else, I think Lua will give me a refreshing break from my day-to-day Ruby and Javascript coding.

open Terminal, then Start MySQL or PostgreSQL
in a separate Terminal tab: cd Documents/projects/ ; mate .
(if applicable) in a separate Terminal tab: Start Solr or Ferret
Start Firefox
Start Evernote

That’s a lot of keystrokes and mouse actions. No wonder I end up playing games most of the time, because Age of Empires III takes just one click.

I can configure MySQL and PostgreSQL to run on startup, but that’s wasteful. That’ll slow down the machine’s startup time, and sometimes I use just MySQL, on other projects I use PostgreSQL, and on other projects I use neither but instead use MongoDB. And that will just take away one step in this 5-step process to get from cold bootup to work bliss.

Ideally, there’s a one-click work button, a sideproject1 button, a sideproject2 button, etc. Press the right button and the Mac will be transformed into a mode optimized for the work to be done: run the needed apps, close unneeded apps, play music from the “work playlist”, change the desktop background, etc.

I have decided to learn AppleScript to build those magic buttons. Here’s what I’ve come up with so far:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

#!/bin/sh
 
# From: http://stackoverflow.com/questions/1589114/opening-a-new-terminal-tab-in-osxsnow-leopard-with-the-opening-terminal-windows/1590818#1590818
# (See answer by i0n that says "courtesy of Dan Benjamin" http://twitter.com/danbenjamin)
 
# Sets up my Infinitely terminal windows
 
# 1. Run MongoDB
# 2. Run redis in a new terminal tab
# 3. cd to the project
# 4. Launch Evernote
# 5. Launch Firefox
# 6. Launch GitX
 
 
# 1. Run MongoDB in a new terminal
/usr/bin/osascript <<mongo
activate application "Terminal"
tell application "System Events"
	keystroke "t" using {command down}
end tell
tell application "Terminal"
	repeat with win in windows
		try
			if get frontmost of win is true then
				do script "cd ~; ./mongo.sh" in (selected tab of win)
			end if
		end try
	end repeat
end tell
mongo
 
# 2. Run redis in a new terminal
/usr/bin/osascript <<redis
activate application "Terminal"
tell application "System Events"
	keystroke "t" using {command down}
end tell
tell application "Terminal"
	repeat with win in windows
		try
			if get frontmost of win is true then
				do script "cd ~; ./redis.sh" in (selected tab of win)
			end if
		end try
	end repeat
end tell
redis
 
# 3. cd to the workers project
/usr/bin/osascript <<workers
activate application "Terminal"
tell application "System Events"
	keystroke "t" using {command down}
end tell
tell application "Terminal"
	repeat with win in windows
		try
			if get frontmost of win is true then
				do script "cd ~/Documents/projects/infinitely/workers; mate ." in (selected tab of win)
			end if
		end try
	end repeat
end tell
workers
 
sleep 1
# 4. Launch Evernote
open /Applications/Evernote.app
 
# 5. Launch Firefox
open /Applications/Firefox.app
 
clear

There’s still no “Open iTunes and play songs in my ‘work’ playlist” section, but I’m working on it. And here’s something to make it more interesting: AppleScripting with Ruby!

This script borrowed heavily from the ideas of the people in this Stackoverflow thread.

It’s to avoid a common C coding mistake of using = instead of ==. If you use the former form, and you inadvertently use = instead of ==, the compiler will catch your mistake because you’d be trying to assign a value to a constant.

I never really needed this convention because I have always been careful with my ==’s. One of the earliest C lessons I’ve learned. Still, it’s helpful to understand why some veterans prefer one form over the other.

Attendees:
topher
rad
eumir
buddy
tin
nico

There were two new attendees, tin and nico, who promised to catch up with the previous assignments.

We discussed memory management. The following questions were raised:

When should you call release on an object?

When you’re the one who did the alloc for the object.

When should you not call release?

When you did not do the alloc for the object.

Why bother with alloc and init at all, when, for example, you can use class methods that do it for you?
For example, why use:

NSString *my_string = [[NSString alloc] initWithFormat:@"format"];


when you can instead the format below?

NSString *my_string = [NSString stringWithFormat:@"format"];


Answer: The stringWithFormat call returns an autoreleased object. On the Mac OS X desktop, there’re practically no difference. On the iPhone, you want to limit the number of objects in the autorelease pool and use alloc/init most of the time so that you can be explicit (and optimize) on when you call release.

As before, let’s try to do Week 3 in one week. That means lectures 5 (Views, Animation, OpenGL) and 6 (View Controllers), and assignment 3 (HelloPoly II). Let’s aim to view the lectures and finish the assignment by next week and have a meetup Thursday next week, February 25.

For those that are catching up and still working on previous assignments, feel free to post questions about them, both on the forum and on meetups.

It starts on Feb.15. Even if you don’t know anything about Objective-C and Cocoa, you still have some time to cram. You can actually get by with what you’ll learn from the first three chapters of this book: Beginning iPhone Development: Exploring the iPhone SDK.

See you in the class!

Er, the class is virtual, so see you in the class forum instead.

Attendees:
paul
topher
rad
johann
eumir
buddy (cakey)

We skipped discussion of assginment 1A as it was really very simple and no one had problems with it.

Assignment 1B has four sections, so we took turns in discussing our solutions. Paul discussed section 1, Topher section 2, Rad section 3 and Eumir section 4.

Topher mentioned some confusion in creating the project under XCode 3.2/Snow Leopard. The screenshot provided by the handout was for XCode 3.1/Leopard. If you’re on XCode 3.2/SL, see the screenshot below on how the New Project dialog should look like.

Everyone was excited and wanted to try a bit faster pace. Tentatively, the next meetup is on Thursday, February 11. It will cover Lectures 3-4 and assignments 2A and 2B. We’ll check our progress over the weekend, and if this pace doesn’t seem workable, people should cry chicken as early as Monday, February 8.

Lastly, the off-topic discussions were also productive. Here are the links to the tools mentioned in passing during last night’s meetup:

Topher’s framework of choice for building iPhone apps:
http://github.com/blog/389-three20-iphone-ui-goodness

Rad’s framework of choice for building iPhone games:
http://www.cocos2d-iphone.org/

Rad’s framework of choice for Flash games:
http://flixel.org/

Interesting paper prototyping tools:
http://apress.com/book/view/9781430228233
http://www.appsketchbook.com/

1. The study group will move at half the pace of the CS193P class. This means two lectures and 1-2 assignments every two weeks. There will be one meetup every week.

Week 1 starts on January 25, 2010. Everyone views the lectures and works on the assignments on her own. There will be a meetup on February 4 to discuss concepts and assignment solutions.

The mechanics are still being ironed out, but here’s what I’m envisioning:

1. The study group will move at the same pace as the CS193P class. This means two one-hour lectures a week, and one assignment a week.
2. Each participant will view the lecture videos on her own
3. Each participant will work on the assignments on her own
4. There will be an optional once-a-week meet-up to work on assignments together. Everyone still work on the assignment solution individually – the assignments have been designed that way – but the meet-up is an opportunity to have a high-bandwidth discussion on difficult concepts.
5. There will be once-a-week meet-ups to “submit” assignments and discuss solutions.

The meet-ups will from 8pm to 9pm and will be held in the Ortigas office of Sagada Solutions.

If you’re interested in joining the group, please join this Google group.

A new class has just started, and the material has been updated for iPhone OS 3.0. Videos of the lectures are available for free in iTunesU one week after the actual class.

Watching the videos (of the 2009 class) and working on the assignments has been the best iPhone programming exercise I’ve done so far. Highly recommended.

Follow the class here: http://www.stanford.edu/class/cs193p/cgi-bin/drupal/

Recently I decided to join the Get Rich By Selling an iPhone Game bandwagon. I had several things going against me. First, I’m starting from scratch when it comes to Objective-C and Cocoa. Second, this is completely unrelated to my current work, so I will not be able to port any know-how I gain from work into this new endeavor. Lastly, I still have to maintain my full-time job, and my family obligations, so this will at best get 5-10 hours a week of attention.

After several months of pursuing this inconsistently, my efforts have paid off and I finally am at point where my confidence in building an iPhone game is at about the same level as my confidence in building a web site on Ruby on Rails (my full-time job). I haven’t released a game yet, but I think I’m finally over the steep part of the learning curve.

If you’re planning to embark on a similar journey, here’s some advice:

1. Enroll on an iPhone programming course

I didn’t, but if one was available locally when I was learning, I would have seriously considered it. What I discovered during my learning process was that spending just one to two hours per session (the most I can spare in a day, given my full-time job and family obligations) for learning a completely new language and framework was very unproductive. I got stuck on most of those sessions, then I spent a considerable portion of the next session retracing my steps and figuring out where I stopped during the previous session. I made the most progress when I took a leave for several days from the my full-time job to concentrate on my studies.

Here are the bootcamps I recommend:

• Big Nerd Ranch
• Mobile Orchard

Alternatively, you can follow the Stanford CS193P iPhone Application Development class. Video transcripts of the lectures are freely available in iTunesU. The assignments are great, IMHO even better than the iPhone books. I’ve been looking for the Objective-C equivalent of the K&R book, and the lectures and the assignments come closest to it.

2. Go through these books, in order

• Introduction to Cocoa Application Tutorial
• Cocoa Fundamentals Guide
• Beginning iPhone 3 Development, 2nd Edition
• The Objective-C Programming Language
• Coding Guidelines for Cocoa
• iPhone Human Interface Guidelines
• iPhone Developer’s CookBook: Building Applications with the iPhone 3.0 SDK 2nd Edition

If you follow the Stanford CS193P class, you will find these books very useful. The Apple reference docs are your, well, references. The Beginning iPhone book and the Developer’s Cookbook will be helpful if you find some concepts aren’t adequately explained in the lectures or in the reference materials.

3. Get an actual iPhone or at least an iPod Touch

Theoretically it’s possible to build and release an app by just using the simulator, but it’s not recommended. Here’s why:

• You cannot test multi-touch and the accelerometer using the simulator
• You need to be an actual iPhone OS user to be able to understand the UI expectations of your users. You need to actually use an iPhone or an iPod to be able to appreciate much of what’s written in iPhone Human Interface Guidelines
• Apps, especially games, will be much slower on an actual device than on the simulator. You need to verify that your app won’t be sluggish on an actual device

4. Start with a framework

I recommend the cocos2d-iphone framework and the chipmunk physics engine. Both are free and are supported by a healthy community. They may not be the best, but they’re accessible and are enough to get you started.

5. Lastly, always remember to have fun!

That’s what this is all about, right?