Opetopic

This is my first post back on the #idevblogaday roll (thanks again to Miguel for managing this!), and coincidentally today is the end of my month long pledge to donate Opetopic’s proceeds to Japan relief-related organizations.

Summary

For those who didn’t catch the beginning, back in March I came back from a SxSW excursion to the unsettling news of what was going on in Japan. I read that many indie developers were donating their proceeds for a day, or sometimes a week, to various organizations to help with the relief. I wanted to do something similar, but was in the fortunate position to go big. See, just a few months ago I decided to take a break from the indie life and get a real job (at a small tech startup, but real nonetheless). Each month my deposit from Apple is just a nice little bonus, and was a luxury I could do without.

I decided to donate all of Opetopic’s app proceeds for a full four weeks, and split the donations among three different organizations: Doctors Without Borders (50%), UNICEF (25%) and the International Red Cross (25%). Further, I made sure that the donations were never earmarked for only the Japan relief, which forces the funds to be used in the country of Japan, even though the operations may extend to other countries. And as one final move to bolster the effort, I agreed to match all donations out of my own pocket.

Renewed Interest

Four weeks is a long time to keep my interest concentrated on one thing. A really long time for me. But each day brought more news of the developments in Japan and surrounding areas. Weeks after the events we still get new videos showing the destruction of the tsunami surge, and we still do not know the long term effects of the Fukushima fallout. It kind of feels like I should just keep this going…

The Numbers

I didn’t have time to post a weekly summary last week, so this time I have two weeks worth of numbers:

Unfortunately these numbers were a little lower than our first two weeks, but $850 is nothing to sneeze at. With my matching the following donations were made:

• Doctors Without Borders (50%): $850
• UNICEF (25%): $425
• International Red Cross (25%): $425

And combining the previous two weeks of donations (week 1, week 2) we have the following breakdown of donations:

• Doctors Without Borders (50%): $1888
• UNICEF (25%): $944
• International Red Cross (25%): $944
• Total: $3776

Thanks to everyone who helped and retweeted my obsessive self-retweets.

For the Indie Devs

As a side note to the indie devs reading, this series of posts could technically serve as a “numbers post” that is so popular in the indie community. Honestly I am not a big fan of those types of discussions, but for a little more context you should know that the distribution of sales across all of my apps falls somewhere around 2:1 for IsoCards:IsoWords (all languages of IsoWords).

The 2nd week has concluded for my month long pledge to donate Opetopic’s app proceeds to Japan-related relief organizations. The numbers are very consistent with last week’s results, although slightly lower due to the fact that I accidentally counted 8 days in the first week (Sunday to Sunday).

So, we made $490, and with my matching we will be donating $980! The breakdown for my chosen organizations:

• Doctors Without Borders (50%): $490
• UNICEF (25%): $245
• International Red Cross (25%): $245

In total we have donated $2076!

We have two more weeks of this, and I will be pushing a lot harder (prepare to be annoyed if you follow me on Twitter). Also, tell anyone and everyone about this — they get a kickass game for two bucks, and some awesome organizations get a donation.

• IsoWords
• IsoWords Español
• IsoWords Français
• IsoWords Deutsche
• IsoCards

Yesterday, March 27th 2011, marked the end of the first week of my 4 week pledge to donate Opetopic’s proceeds to disaster related relief funds. Thanks to everyone that told a friend and/or retweeted my rampant self-retweets. The outcome was actually pretty good, and I will continue pushing to make all 4 weeks as good as this one. Below you will find a chart for the combined sales of my apps for March 20th to the 27th.

Note that this is after Apple’s 30% cut, so all-in-all we netted $548! And as I promised in my previous post, I have matched this to make a total donation of $1096. The final split among my 3 chosen organizations is (along with links to the donation confirmations):

• Doctors Without Borders (50%) : $548
• UNICEF (25%) : $274
• International Red Cross (25%) : $274

I don’t have a confirmation for IRC yet because my bank actually locked my account for suspected fraudulent activity! I’m sure it will be sorted out soon enough though.

Thanks again to everyone who supported this, and spread the word… we have 3 more weeks!

Update #1: First week’s numbers have been posted!
Update #2: Second week’s numbers have been posted!
Update #3: 3rd and 4th week’s numbers have been posted!

I just got back from a week and a half long trip to Austin for the SxSW Interactive+Music festivals. I had a mind blowing good time, but could really feel the bubble surrounding me when it came to news about the tsunami in Japan. It’s understandable, we have been working ourselves to the point of breakdown leading up to this festival and we were all there to do something great.

Now that I am back in New York I have caught up on the news and the gravity of the situation set in. I’ve already made my donations to a few organizations, as you probably have too. Remember, donate to organizations, not just the disaster relief which unfortunately earmarks money for only Japan instead of the entire relief operation, which will spread across many parts of the world for many years to come.

As I wrote in the postmortem of my indie game development career, the revenue of my apps have transitioned from being a very meager living (pre real job) to just a nice little bonus I get each month (post real job). Well, this bonus is a luxury I can certainly live without.

So, for the next month I will be donating all proceeds of my apps to relief related organizations. I will also match the proceeds from my own pocket to further bolster the effort. Since I only started a real job a few months ago I probably have to cap my matching to something, but let’s just see how things go.

I will also be splitting up the proceeds in 3 ways:

• 50% to Doctors Without Borders i.e. Médecins Sans Frontières i.e. MSF
• 25% to UNICEF
• 25% to the International Red Cross

This breakdown is influenced by the fact that Japan is a very wealthy country with a modern infrastructure. They will get back on their feet very soon. But MSF fills a need that even rich nations need when something this scale hits.

If you found this page from a friend, then hopefully they can vouch for me that I’m a good guy. I just want to help anyway I can. Each week I will post a summary of my sales and make a donation (even though Apple pays me roughly once a month).

So, if you would like to help Japan by just buying a couple of kick ass games, check mine out:

• IsoWords
• IsoWords Español
• IsoWords Français
• IsoWords Deutsche
• IsoCards

cocos2d for iPhone has a built in particle system that is flexible enough to take care of many effects needed in games, especially when the effect acts independently from the rest of the scene. This post will describe an optimization that can drastically speed up particles in your app.

CCParticleSystem

All of the core logic and computation of the particle systems takes place in the class CCParticleSystem, which inherits from CCNode (as does anything that gets drawn in cocos). However, there is no drawing code in this class. Instead, all of the drawing is done in either CCParticleSystemQuad or CCParticleSystemPoint, both of which inherit from CCParticleSystem. The former class draws a single particle using two a quad (4 vertices, 2 triangles) and the latter uses GL_POINTS. It turns out that quads are faster on armv7 architecture and points are faster on armv6, so there is a nice little macro defined in CCParticleExamples.h that allows you to target both architectures at the same time:

#if defined(__ARM_NEON__) || defined(__MAC_OS_X_VERSION_MAX_ALLOWED) || defined(TARGET_IPHONE_SIMULATOR)
#define ARCH_OPTIMAL_PARTICLE_SYSTEM CCParticleSystemQuad
#elif __arm__
#define ARCH_OPTIMAL_PARTICLE_SYSTEM CCParticleSystemPoint
#else
#error(unknown architecture)
#endif

Rendering a particle system with CCParticleSystem is actually quite efficient because its internals are pretty much straight C. However, things can get very sluggish if you use many particle systems at once, and especially bad if you allocate them on the fly as you need them. Each particle system requires its own glDrawElements call, and each allocation results in a hefty malloc.

Reusable Particles

I will describe a few small changes I made to the particle system classes that allow one to allocate a large pool of particles just once and then reuse them for every particle effect in your game (even for effects with different parameters and textures). The idea for these changes came from a post on the cocos2d forum, and in particular the work of “zombie”.

I won’t go over every single change I made as you can refer to the code for that, but I will describe the overarching idea. In order to be backwards compatible with the current system I added a boolean ivar, reuseParticles_, that determines if want to use this feature or not. When this boolean is set to YES we prevent particles from “extinguishing” in the -update: method, and instead moves them offscreen and marks them as inactive. A method was then added, named -spawnParticles:(int)n, that simply looks for n particles that are inactive and reactivates them. The point at which new particles are created is governed by the centerOfGravity ivar, so you should set this point just before calling spawnParticles.

Now all particles are drawn with a single glDrawElements call. The -draw method is also updated so that no elements are drawn if all particles are marked as inactive. This could possibly be made more efficient by using glBufferSubData to buffer only the particles that active, but I haven’t taken the time to implement it.

All of the parameters that define the particle system (gravity, color, size, etc.) are stored in each particle rather than globally as an ivar. This means that in between spawnParticles calls you can change the parameters in order to manage many different kinds of systems at once. I even added a method named -setAttributesWithDictionary that sets the system’s parameters from an NSDictionary, which would most likely be loaded from a plist and/or created by Particle Designer.

The code

These changes to the particle system classes can be found in my fork of the cocos2d project on github. I haven’t pulled the latest from the main codebase in a while, but it doesn’t look like there have been too many major changes to the particle system classes. If you are working on your own custom copy if the cocos2d library you can simply download my repository and copy over the following files:

CCParticleSystem.h and .m
CCParticleSystemQuad.m
CCParticleSystemPoint.m

The changes in these files are 100% backwards compatible with the current particle system classes. I have set up another github repository that shows exactly how to use the added features.

…was to go corporate.

Ok, not really corporate. Let me explain.

Lots of devs have written inspiring stories of quitting their day jobs to pursue the indie lifestyle. I love those stories. But, I kind of did it backwards. I got into this indie state of mind while in graduate school, so I’ve never really had a day job. I was a grad student at the math department of Stony Brook for 4 years. Working on a Ph.D. is very similar to being an independent developer. On the negative side is the frustration and self doubt knowing that your failures fall squarely on yourself. Fortunately, the positive side is a strong community of passionate people and the freedom to work on things that interest you.

It isn’t uncommon to take a break from research to explore different topics while in grad school. I spent most summers in small study groups with colleagues trying to understand areas of math and physics that were completely orthogonal to my own field. It is cathartic to work on something with no pressure tied to it, and most importantly for which you truly do not judge yourself and do not care if others judge you.

During one particularly dry period of research I decided to mess around with iPhone development. I’ve programmed for many years, so I was mostly interested in understanding the platform. A small device with GPS, accelerometer, touch screen and pressure sensitive microphone lends itself to lots of experimentation. This distraction decided to stick. The thought of working on my ideas, but this time actually making a living from it, really appealed to my academia pedigree. Eventually I decided to leave grad school and go into full time development.

Soon I realized that my indie undertaking had become exactly like my grad school undertaking. Days are filled with freedom and creativity, but also doubt and self loathing. To mix things up a little I took on some freelance iPhone work and found it to be incredibly lucrative… perhaps bubble lucrative. Mobile developers have a nice little window where the demand for developers (iPhone in particular) greatly surpasses the supply, and I took advantage of that. Shortly after my freelance work I came into contact with a small tech start up here in New York and began working full time.

It has been nice to work on products for which I only hold myself accountable up to the product itself and not its overall success. This is analogous to what I needed while in grad school, except now I’m making some money. I’ll be putting most of this money towards doing my own projects right; I will be hiring top notch artists and musicians from now on. I also now find myself more productive during the little bit of time I get to work on my own projects. My next game, Battle Nation, is even making a little progress recently.

So, while I am not advocating iDevs take up a corporate job in lieu of going indie, I am suggesting that you might want to scoop up some of this bubble money floating around. Then you can properly fund your next project.

I’ll end with an anecdote. The day I learned that I would finally have an iDevBlogADay spot, after months of waiting, was the exact day I started my real job, and now two weeks later, the day of my 2nd post, I got my first pay check. So. Many. Conflicting feelings…