Adam Henning

Busy Week

2011-09-07T20:04:00.001-05:00

Sorry I've been a blogsloth lately... last week was a busy one, and I was in Philly for most of it. And then, of course, there was Labor Day weekend, complete with fantasy fooball draft party.

Anyway, the long and short of it is that I haven't had as much time as I'd like to spend on game development. And what little time I have spent on it in the past week or so was mostly tied up in figuring out how to quickly and efficiently load game images and objects into and out from memory on the iPhone or iPad. I think I've got a handle on it now, but I'll still have to do some tweaking down the road. For now, I keep reminding myself that I'm not trying to come up with the perfect solution - just any solution that works well enough to rough out a game and test it - I can do all sorts of optimization later, once I know I have a product worth polishing.

So, I'm afraid I don't really have anything new to show right now. Hopefully I'll be able to carve out a little time this weekend and make some progress toward getting Isby running around in a game world.

More soon... I hope!

Gnome Animation Sketch

2011-08-23T18:19:00.016-05:00

It's not much to look at, but I made this little animation sketch last weekend (with PowerPoint, believe it or not). I did it mostly as an exercise, to get more familiar with the basics of how I'll be drawing and animating my characters (for the moment... at some point I'm going to need to get help from someone who knows what they're doing). I also made this because I'll need placeholder characters for my sample games... and this is Isby the Garden Gnome, who will be the Hero of ... wait for it... "Isby" - one of my first sample apps. It will be a basic side-scroller, which is appropriate for one of my first sample apps, since Super Mario Bros (perhaps the most classic of all classic side-scrollers) was one of the first games I ever played and loved.

So, world, meet Isby:

Anyway, I thought this would liven up my horribly boring blog a bit. Hope you like it!

I'm still working on roughing out the concepts for my first 10 samples, but I'm almost done with that. I still have quite a bit of character sketching to do before I can really start putting playable samples together, but I found a copy of Photoshop, and I'm hoping that will help.

More soon!

Picked It! ...well, mostly

2011-08-17T06:58:00.000-05:00

Well, after lots of not-so-sexy work in a spreadsheet, and brainstorming ad nauseam, I have scored about 50 app ideas. I've narrowed them down to 10 that I'm going to try to develop samples of (had a harder-than-expected time getting the number down to 10), and another 8-10 that I'm going to think about throughout the process - if possible, I'll try to work them in as I go.

It'll take me at least a week to work up some basic sketches (both of graphics, and game layout / logic), and I'll try to upload some of those sketches here, so as to break the horrific geek-monotony that has become my blog.

It's funny, because when I started this project, I expected to need help on the coding, and to be able to take care of the graphics myself (I do, after all, have an art degree that doesn't get much exercise). Now as it turns out, I feel pretty confident that I can handle the coding (Apple makes it nearly Adam-proof, if you're willing to put in a chunk of time reading their programming guides and using their amazing, free development tools) ...but I could use some help on the sketching and graphics development.

So, uh... do you know anybody who wants to help me work up some sketches?

A slightly different approach to sample apps

2011-08-15T18:21:00.002-05:00

Now that I've waded in about ankle-deep, I'm thinking I should approach these sample apps a little differently. Instead of trying to make a bunch of simple apps that I'm hoping will be related to a future marketable app, I've decided to go ahead and do the "Pick It" work now... well, most of it.

Using the criteria that I laid out in an early post (Guide It, Part 2), I'm going to score as many ideas as I possibly can. The one addition to my earlier thoughts on this process is that I'm also going to categorize my app ideas - not just the obvious game vs utility, but within games, I'll break down whether they are action, strategy, scrollers, fixed view, physics, etc. This will help me decide how much I want to invest in any one type of game, and should help keep things straight by putting similiar ideas side-by-side.

Next I'll to choose as many as I can reasonably develop in parallel (probably around a dozen?), and treat them like one cohesive project. That way, I can compile my unknowns - many of which will apply to multiple apps - and prioritize my specific research. Also, since many of the projects will use similar objects and methods (data structures and functions), I can have several games in mind when writing them, and do a better job on modularity and portability.

The goal of the sample apps is no longer just to facilitate the Learn It process, but to end up with a suite of short samples, any one of which could be further developed into a solid, marketable application. This also fits in really well with my idea of sketching and getting feedback before mapping and drawing and commiting to a product. The downside is that it will be a little bit before I have my first testable sample app for others to check out; the upside is that I should have a nice portfolio of samples done more quickly than I would have otherwise. And more importantly, I should be well positioned to publish the best of them pretty quickly afterward.

Ok, I better get back to brainstorming and scoring. More very soon!

First Stab at a Sample App

2011-08-11T18:06:00.004-05:00

Last time I blogged, I had a pretty lame excuse for why I hadn't written anything in so long. But this time, my excuse is awesome... I've been working on my first sample app!

And it's actually been going great. I wouldn't call it a game yet, and it's lightyears away from being a presentable, publishable application, but it's something, and it works (reasonably well), and I made it.

After deciding to put the roller maze idea on hold, I thought I'd try to work up a knock-off of "Asteroids" or "Space Invaders" - you know, a space ship shooting things floating through the screen... that sort of thing. As I worked toward an asteroids game, I ended up taking a little different direction, and instead made a freeze tag game. Objects float around the screen, bumping into each other (and doing a little bit of "damage"), and you have to tap on them to freeze them. As they run into each other, they gradually turn red - if they all turn red, you lose. If you get them all frozen, you win that level, and another loads - with a few more objects, which move a little faster.

The next "Angry Birds"? No. In fact, I wouldn't even really call it a game, per se. But it makes for a good programming exercise, which is the idea. And the challenges I'm working out now should pay big dividends on future projects. As it turns out, the physics behind lots of objects colliding with each other is not easily to calculate efficiently (and the calculations need to be preformed 30 times per second for every object on the screen). In fact, most asteroids-type games skip many of the collisions by allowing the asteroids to just float through each other, and only worry about them colliding with the ship and its bullets.

I've always thought of myself as pretty good with math, but after a few days of calculations and spreadsheet models, I was only able to come up with a pretty limited physics model. Basically, it can handle circles moving in a 2D environment, but only if they all have the same "mass" - different sizes are ok, but the idea of a heavier object running into a lighter one is apparently beyond me. Also, the objects can't move too fast, or things start to look a smidge choppy. Pretty weak, I know. But for now, I'm just happy that I was able to work out a system that works well within its limited scope.

Next up, I think I'm going to plan out a few projects in parallel - partly to make sure I don't get too wrapped up on any one sample, and partly a practice for when I lay out a more significant project in the future - one that will hopefully be good enough to publish.

And I'll see if there's a way to capture video of an application so I can show you what I'm doing in the future, rather than trying to describe it.

A few late night ramblings to make up for the fact that I haven't blogged in over a week

2011-08-01T22:34:00.006-05:00

Ok, forget Zombie Farm. That was a fun little distraction, but now I'm over it.

So, the good thing about this project is that it is incredibly challenging, and I'm learning a ton of stuff about computers and programs and just generally how stuff works. Although, I do have this disturbing thought that I'm the guy trying to teach himself how internal combustion engines work 30 years after the industrial revolution was in full swing. Oh well - I didn't start this project to revolutionize the world (I'll try to do that in some future project, I promise).

For now, I'm just trying to make an iPhone / iPad app... and right now it's not going so great. Since I last blogged, I finished the iOS Game Development book (finally!) that I've referenced in earlier posts - the one I started reading at the very beginning of this project. It's a pretty bad book, full of obvious errors, and seemingly deliberate obfuscation. And based on the one other title I've read by that same publisher (Addison-Wesley), I plan to avoid picking up future books with that name on them. The Apress books I read, however, were great - if you're thinking about learning programming-related stuff, I recommend Apress books for sure. If only they had a good book specifically on game development... but I think I'm past that now.

Although poorly done, the iOS Game Development book did lay out a pretty robust game engine, and I'll be able to use a lot of that info on future projects. But for now, I think the way ahead is to bone up on Sparrow (the lightweight game engine that I'll use to try to bang out some sample apps), and, well... try to bang out some sample apps.

Which brings me to tonight. I spent about 3 hours tonight trying to get through part 1 of the iKy1e tutorial I mentioned earlier, only to find out that there are a ton of issues with integrating OpenFeint, which is sort of like a social networking extension for games on the iPhone - online leader boards, featured game-of-the-day type promotions, "friends," achievements... that sort of thing. After I finally fixed all of the errors and warnings and was able to successfully load the first part of the tutorial app onto my iPhone simulator, it opened, didn't do what it was supposed to, and then crashed. So I'm giving up on it for now. I would have dropped it sooner, except for this statement in iKy1e's tutorial:

"We had over 520,000 downloads in the first 2 days our game was promoted by Free Game of the Day. We immediately jumped to #1 in the Top Free chart and stayed there for 6 days."

So, pain in the arse? Yeah. Worth it? We'll see.

I'm going to call it a night for now. Tomorrow, I may spend a few hours trying to follow OpenFeint's directions for setting up an app with their service integrated into it. If it works, great. If not, I'm moving on for now. I've got much more fundamental things to work on at the moment, and I can always come back to promotional stuff later.

Oh yeah. I started this post with "the good thing about this project..." so I should probably finish that thought. The bad thing about this project is that sometimes it feels like work. But most things worth doing feel like work at some point along the way.

So here's hoping this is worth doing.

Zombie Farm

2011-07-20T18:24:00.003-05:00

Feeling a little burned out on all of the reading, I decided to take a break and research (read: play) some of the top-grossing apps in the app store right now. I found that over half of them are "Sims" type games - if you're not familiar with Sims, you might recognize games like Farmville, Rollercoster Tycoon, Animal Crossing, Tap Zoo, or any of a dozen other similar games. They all feature a quasi-3D birds-eye view, an arbitrary game currency (allowing for lots of in-app purchases), a game clock somehow linked to real time, a build-an-empire type of goal, and lots of cuteness. When you put it all together, you get some pretty addictive games.

And Zombie Farm is no exception - it's been sucking up a bunch of my time in the past week, but it wasn't totally wasted time. Aside from being pretty fun, it gave me some insight into the balance between user experience and monetization. The key is obviously getting users to want buy some of your game's currency (in this case, brains) without being too obnoxious about it. In other words, the game still has to be fun if played without any in-app purchases, but there also has to be some incentive for users to spend money.

Anyway, I'm definitely adding this style of game to my list of possible applications - both because it's very fun, and because it has good potential for monetization... and with that, I think it's time for me to get back to reading!

Tutorials ad infinitum

2011-07-13T17:19:00.093-05:00

As I've mentioned in some other posts, I've been reading quite a few online tutorials lately. In case you're curious, here's what I've been reading:

The View Programming Guide for iOS - views are like invisible containers that sit in the application window and display everything that the user sees
The OpenGL ES Programming Guide for iOS - as I may have mentioned before, OpenGL ES is a graphics library for making 2D and 3D animations... very powerful, and notoriously difficult to learn
The Drawing and Printing Guide for iOS - I sort of skimmed through this one
A really good OpenGL ES 2.0 tutorial by Ray Wenderlich that explains OpenGL ES from scratch

There was another site that listed OpenGL ES tutorials by platform and level of complexity that made for a helpful list (that's how I found Ray Wenderlich's stuff), but I can't seem to find my link to it... oh well. I also glanced at a few other iOS guides on view controllers (they present, manage, and swap out the various views that a user will see during the life of the application), a guide on core animation, and a few other things on OpenGL ES, but I didn't dig into any of those too much, because I didn't feel like I was really learning the stuff that would allow me to dive in and start programming.

Finally, I've recently completed a read through the Sparrow Framework (game engine) documentation - they have really good manual and tutorial pages, and I like their philosophy a lot). With that as a basis, I'm working my way through two online game tutorials that go start to finish using Sparrow:

This action game programming tutorial on maniacdev.com which touts its simplicity, and...
This four-part (and still growing) game tutorial - 1, 2, 3, 4 - posted on "the blog of a teenage programmer" called iKy1e iOS Developer, which looks to be slightly better, at first glance.

Just in case you wanted to follow along with what I'm reading.

More soon (including, hopefully, a sample app!)

Game Engines

2011-07-11T17:30:00.036-05:00

There's a funny thing about me and projects... I tend to get about half way into them before I figure out what I needed to know at the outset. Just the nature of the beast, I suppose - and this project has been no exception.

I figured out (way too recently) that the game development book I'm reading is really just laying out a game engine from scratch - and explaining it poorly along the way. I could use that game engine as a starting point in developing my own games, but it turns out there are several other game engines out there - some of them for free - that have great documentation and are much more intuitive. In particular, Sparrow seems to be a good option, and I'm reading up on that now. I'll still finish the book, but I doubt that I'll use much of it in developing my own apps.

I also figured out that I could have dug into an engine like Sparrow quite a while ago, having just learned the basics of Objective-C, but I'm glad that I spent as much time as I did on C and Objective-C, and even the basics of Cocoa Touch and general iOS development stuff. I think that the extra background will pay dividends when I get to the point where I really want to control what I'm developing.

I'm trying to be patient as I work through what I'm hoping will be the last few weeks of research before I can start producing simple apps... but I'm really eager to dig in and start making stuff. Hopefully soon!

Guide It, Part 2 (The Specifics)

2011-07-09T09:24:00.002-05:00

Alright, so I've got my big picture stuff - a published app, with lots of downloads and a little income, in under a year, that can be enjoyed casually (that is, without having to invest hours in playing it).

Now, the specifics, for the remaining steps in this project. I'm also going to use these to guide my sample apps, but to a smaller extent.

1. How to choose it - what criteria will guide the Pick It process

Feasibility - how much time and money it will probably take to complete (yeah, there's gonna be some serious guessing involved here).
Marketability - how much demand there seems to be for this type of app in the App Store.
Originality - how many other apps are doing something similiar already.
Simplicity - not to be confused with feasibility, here I mean ease of use, not ease of production.
Monetizability (not actually a word) - how easily and naturally ads and in-app purchases can be integrated.
Modularity - the ability to easily produce added features or levels once the framework is in place (I know this has an inherent bias toward games, but this seems to be a staple of most successful apps, and also goes toward the user's ability to use the app casually and frequently).
iPhonality - not satisfied at having made up "Monetizability" (which upon further research, may actually be a word), I'm using this last criterion to measure how well the application can take advantage of the unique iPhone (and iPad / iPod Touch) features, and how well it will embrace the format.
When the time comes, I'll lay out all this stuff into a very geeky decision-making matrix, and weight and score each of my app options.

2. How to organize it - what principles and conventions will determine layout during the Sketch It, Map It, and Code It processes

Work from general to specific. This is something I've learned that seems to apply to all projects - from making art to planning an Army operation - get the big picture first, and then start working toward the details.
Get feedback on the sketches (which will involve not only the general visual layout, but the flow of the user experience, and the rough structure of the code as well) before moving on to Map It (specific visual layout, and precise coding structure with skeleton comments).
Get the project completely organized and commented (with placeholders for future code) before writing any actual code - make sure all of the logic and structure is in place before getting bogged down in coding.
Break down the required code into modular chunks (and get help on those chunks if needed!)
Make the entire project maintainable, expandable, and localize-able (there I go again) as much as possible... in other words, make thorough, clear comments, and set up all of the user-interface words for easy translation into other languages once the project is complete.

3. How to theme it - what design elements will guide the Draw It and Hear It processes

Must be smooth. Everything about the iPhone is smooth, and all of the best apps are - not just visually, but in terms of interface and sound as well. The only caveat here is that some apps lend themselves to a sketchy look (sometimes stick figures or a retro, pixelly look are right for an app), but even in those cases, there needs to be a certain intentional cohesiveness - gestalt, if you will.
Cute and trendy are big bonuses - while not strictly a necessity, many of the best apps have distinctly cute characters, or at least a cool and quirky appearance.
Sound should be optional (the app should still be good without it), and (when used), should add the the user experience in a positive way - even sounds that indicate something bad happening should be pleasant, and never grating or irritating (this may be partly my personal bias speaking here, but even if it's subconscious in most people, I think that annoying sounds are always detrimental).

I realize that I'm ruling out music and other sound-based apps here, and I'm ok with that. If I have a eureka moment and want to make a sound-based app, I'll come back and amend this.

Must be simple & scalable - has to look good on the relatively small iPhone screen, but also on the iPad
This might be a smidge out of place here, but the visual layout should allow space somewhere during the user experience for non-intrusive ads, that seem to fit as naturally as possible into the app (and while I'm on the subject, one of the in-app purchase options will be to remove the ads, so the space reserved for ads should have a natural use when the ads are gone as well).

At some point, I'll come back and fill in details on the last two items (below). In the meantime, the reading goes on! I've made great progress toward understanding (enough of) OpenGL ES, and I think I have a better idea of how I'm going to proceed now. I'm going to finish the game development book (even though it's pretty badly written) because it gives a good example of a game engine, and then I'm going to move on.

More soon on:

4. How to refine it - guidelines for successful completion of Test It and Tweak It
5. How to present it - what communication methods and techniques will be used to Tell-all-about-It throughout the process. (Hey! I've already started that one!)

Guide It, Part 1 (The Big Picture)

2011-07-07T17:30:00.002-05:00

While I'm finishing up some reading, and trying to get my sample apps going, I'm going to begin working through the next few overall steps in my project - specifically, Guide It and then probably Pick It shortly after that. Guide It is going to be a little bit involved, because I want to work out some guidelines, not just for choosing the right app(s) to develop, but for getting the big picture right, and staying on track through all the steps of the project. So, let's Guide It:

First, the big picture stuff. I need a purpose (some goals), and a scope (some boundaries) to what I'm going to try to accomplish with this project.

As far as goals go, I know I want to publish an application to the App Store, and I want it to be good enough for people to want to download it. I'd also like it to be capable of generating some income, but I'm hesitant to make it a paid app, since it's my first attempt (if I had to choose between users and income, I'd rather have lots of users and little income, rather than a few users who are willing to pay). With that in mind, I'm going to go for a free app that has in-app purchases and advertisements (but not obnoxious, intrusive ads). That works out well, since more than half of the highest-grossing apps in the app store follow that model. Also, since the majority of the most popular apps (both by downloads and by revenue) are games, I'm probably going to go with a game of some sort, but I don't want to limit myself to games. If I come up with a great utility app, that would be fine too - but browsing through the App Store, it seems like that market is pretty well saturated. Those basic goals are almost certainly achievable, so to make things interesting I'm also going to set a more distant goal (call it a hope if you want) to make it into the App Store's "Top 100" free apps list.

As for boundaries, I don't want to spend more than a year on development (4-6 months would be nice). If it's looking like I'm in over my head, I'm either going to scale back my plans a bit, or come up with a way to network and outsource, so that I can keep this project to a reasonable length. To that end, I'm not going to try to make a hyper-realistic 3-D game that would try to compete with commercial game developers with big budgets and lots of experienced programmers. Instead (assuming it ends up being a game), I'm going to stick with something more like the games I grew up on - classic Nintendo 2-D "scrollers" like Mario Bros and Zelda... but probably not as involved as Zelda. Speaking of involved, I also don't want to make an app - game or otherwise - that requires a ton of time and attention on the part of the user. iPhone apps seem to do best that are casual, fun, easy to start using, and keep the user coming back frequently (rather than spending hours at a time in, the way many role-playing games do). Finally, by way of boundaries, I'm not going to do something that's already been done - a variation on a theme is ok, as long as it brings something new to the table, but not just a re-hashing of something that's already out there.

So, to sum up, I think I've got the following so far:

I want to publish an app to the App Store, that gets a good number of downloads (hows that for specific?), and is capable of generating some income; and for bonus points, one that makes the "Top 100" free apps list. Also, I want to keep the project under a year (and for bonus points, under 6 months), and for the app to be something that users can pick up and enjoy for a few minutes at a time (or longer if they want), and I want to bring something new to the App Store, even if it's just a variation on a existing theme.

Well, it's not quite concise enough for a mantra, but that should keep me more or less on track. Next up, the specifics... how I'm going to approach each of the steps in the project and (hopefully) not get lost along the way.

More soon!

Slogging through more reading

2011-07-05T17:13:00.027-05:00

The reading goes on, but it feels like slow going. I've read about 110 pages of graphics-related programming guides (pre-requisite reading for the OpenGL ES reading that I really need to do), and I don't feel like I know much more than I did before.

Now I'm slogging through the OpenGL ES programming guide (about 90 pages worth), and I feel a little bit like I did when I started this project... I understand a good bit of what I'm reading, but I know that some of it is just bouncing off of my brain without anywhere to dig in and take root. Frustrating.

But so it goes. I'm going to try to get through this guide and then go back to the game-programming book, and see if I can understand a little more than before. Even if I can just absorb enough to know which parts of the sample code I can use as-is, and which parts need to be tweaked in order to do what I want, that will be good enough for now. I can fine-tune, or build my dream app from the ground up later.

Alright, I better get back to it. I'll post another update in a few more days.

Roller Ball Maze Hits A Speedbump

2011-07-03T09:02:00.002-05:00

Well, I've spent some time sketching out the idea of my roller ball maze game, and I've got a pretty good outline so far. I've also finished getting my developer account set up so that I can run test apps on my iPhone, or another iOS devices, so that's pretty cool.

What's not as cool is that I have a few distinct unknowns in my game sketch, and I think I may need several days (maybe even a few weeks?) to research them. Phooey! Well, the first one won't be too difficult to work out, but the second one is probably going to require me to read a tutorial or two before I can move on.

Basically, my first problem involves loading the data model underlying the maze. Everything that the user sees is just cosmetics - it needs the actual data to be held and calculated in a structure that controls everything - including what the user sees and feels like they're interacting with. I know of a few ways to build and load this data model, but they're pretty time- and memory- intensive, and I just know there's a much easier way to do it out there. I was going to put this off and just take the long way around for now, until I ran into the second problem...

I've been planning on writing this first app using a 2-D animating model call "Quartz" which is one of two more-or-less built-in animating systems in the iOS frameworks. (Frameworks, by the way, are basically collections of pre-programmed functionality that one can import into a project and then use that functionality with minimal work.) The other major option is a 3-D animating model call OpenGL ES (an open-source graphical library for embedded systems like the iPhone... yeah, I know - blah, blah blah, right?)

The point is that I wasn't planning on learning OpenGL ES yet, because it's a bit more difficult (and also much more powerful than what I need right now). What I've found out, however, is that Quartz really isn't going to do what I need in the long run (it would barely cut the mustard for my sample apps, as it turns out), so it's in my best interest to go ahead and learn OpenGL ES now. Not the end of the world - this is what the practice apps are for, to work out the kinks before I start a major project - but still a bit of a bummer.

So for now, I'm going to keep driving on with my reading - an OpenGL ES tutorial from the apple developer documentation, and the game programming book with the gray cover mentioned below. In the meantime, I'm still going to work on sketching out my sample apps - maybe several of them - while I keep putting together the puzzle on how exactly I will implement them.

Selecting Some Simple Sample Apps

2011-07-01T20:43:00.001-05:00

Too bad "Apps" doesn't start with an S... I think I would have gotten a "Yatzee" for that.

Well, after some brainstorming, I came up with 31 simple app ideas (some better than others), and scored them in a spreadsheet against my 5 criteria. I weighted feasibility much higher than the others, because I'm just trying to get a few apps under my belt, even if no one would ever want to spend more than 2 minutes using them. Once I've accomplished that, then I'll try to make a really marketable app.

When it was all said and done, my spreadsheet helped me to narrow my list down to about 10, and I'm going to pick my favorites from among those and try to start making them. I kicked around the idea of working on a few simultaneously, as there will be some common elements, but I've decided instead to go one at a time. This way, the things I learn on one can be applied to the next right from the get-go (it's much easier to make adjustments in the design phase than later on).

I think that my first few attempts are probably going to be (in roughly this order):

A roller-ball maze game
A whack-a-mole type game where you pop bubbles that float aroud, and avoid bees
A basic math game or a financial calculator (or maybe both separately)
A better picture-cropping utility (which should be part of iPhone's Photos app already)
Some kind of Space Invaders or Centipede (think 80's era games) knock-off
A plinko-type game, where you dodge and catch items at the bottom

Can't be sure that I'll do all of those, or do them in that order (and there are a few others that I may end up doing instead), but I'm definitely going ot start with the roller-ball maze.

I should have a big jump on making this one, since I've seen quite a bit of related sample code, so hopefully I can knock it out pretty quickly. Even with such a simple concept and a lot of help getting started though, I'm pretty sure that writing this app is going to be a bit like navigating Paris after taking one semester of French.

But I've gotta start somewhere, so roller ball maze, here I come!

Learn It, Phase 2 (Simple Sample Apps)

2011-06-29T18:00:00.003-05:00

Well, I finally finished up Beginning iPhone 4 Development, and I think I'm going to revisit the iOS Game Programming book that I abandoned a few months ago, but in the meantime, I'm going to forge on.

For phase 2 of this Learn It step, I'll be going through the motions with some practice apps - from Guide It all the way through to Send It (if it's good enough) and Tell It (which I'm doing right now). This should give me some experience to apply to larger projects, and will help me to refine my plan a bit.

If you haven't noticed by now, I'm documenting my plans and progress right here on this blog, and intend to do so throughout the project... not only is this as good a place as any to work out plans and track progress, but I'm hoping it will eventually work toward my Tell It step, by generating at least a small amount of followership and buzz for when I finally publish.

Having thought it over, I've decided to make a stab at 5 or more "practice" apps, and below are the guiding principles for choosing them. I'm also going to spend some time writing down the guiding principles for the reaminder of this entire project - and that will have some bearing on my sample apps - but I'm not going to wrapped around that just yet.

Must be simple and feasible - ideally, these are apps that I'll be able to develop in a few weeks each; of course, I may come back to this later and, realizing that I'm not nearly as smart as I thought, change this to a few months each, but I don't want to get hung up on this step if I can help it.
Must have at least one aspect or feature that is marketable, or directly related to a marketable app that I could write in the future - in other words, I want to learn at least one thing on each app that will make me better at writing apps.
Must bring something new to the table - even if it's only a small improvement on an existing app idea, I'd like to do something unique with each app, not just re-hash what's already been done.
Must embrace the iPhone / iPad format - this will definitely carry over to the larger project to come, and is less important on the practice apps, but I want to make sure that even these simple samples have the look and feel of fairly well-polished iOS application.
Finally, when taken as a whole, my sample apps must hit each of the high points that I expect to use once I move on to making something really marketable; I'll have to make some assumptions here, since I don't know exactly what I'll end up pursuing yet, but I've got a pretty good idea that it's likely to be a game with an immersive environment, a catchy appearance (i.e., cute characters), a smooth interface, and motion-detection, to name a few obvious items.

I'm going to give myself some leeway on #4, not wanting to get bogged down (trying to polish a turd, so to speak), and I'm definitely not going to get too wrapped around #5, because I want this project to develop on it's own terms, without me pre-supposing so much that I miss a really good idea or (perhaps worse) take the wrong approach to a good idea.

So with that, I'm going to spend the evening brainstorming some app ideas that are simple, marketable, unique, iPhone-y, and applicable to a bigger future project. Hopefully I can come up with 10-20 ideas, and pick the best 5, based on those criteria... oh, and reading - I'll be spending the evening doing that, too.

Learn It - What I've Been Up To

2011-06-26T09:13:00.112-05:00

As I mentioned in my previous post, I've been in the "Learn It" part of my project for several months now. I think I have a few more months to go before I can really dig in to developing (although I'm hoping to start some simple "sample" apps in the next few weeks). But in the meantime, I thought I'd post some details on what I've been up to, and what's just ahead.

I've fleshed out my project plan a bit since my last post (even then, I had a little more than just my notepad sketch, but most of it was in my head). Specifically, I've broken down this Learn It step into three phases:

General Research (lots of reading - that's where I am now)
Simple Sample Apps (this will happen concurrently with the next few project steps, and hopefully soon)
Specific Research (as needed throughout most of the remaining project)

My general research began back in December or January, I think - can't remember for sure - with some pretty misguided efforts to learn the fundamentals of iOS (the operating system for iPhone / iPad / iPod Touch). I spent many hours reading "Getting Started" documents in Apple's online iOS Developer Library - a truly awesome resource, completely free for anyone who wants to study it, and full of excellent articles and guides.

The only problem with the iOS Developer resources was that they were way over my head. I mean, I could understand the general principles, but without any understanding of the underlying programming languages, I really didn't have any way to apply what I was learning. I even read through the primer on Objective-C (the language that iOS apps are written in), but without first understanding the plain old C programming language, I wasn't understanding or retaining nearly as much as I had hoped.

Undeterred by my floundering, and confident that I could pick up what I needed along the way, I bought a book on iOS game development, hoping that I could just sort of muscle through. In retrospect, I'd have done better to take a different path (and save a few wasted months), but the thing about unknowns is that you don't know about them. So I charged on, aware that I was stabbing in the dark somewhat, but determined to make the most of it.

I got about half way through the book, and although I was able to keep up with the exercises well enough, I could just tell that I wasn't really grasping the information like I needed to. It turns out that the author wasn't kidding when he stated right up front that I needed to understand Objective-C before I could understand the material in the book. I was hoping that my little bit of knowledge from the Objective-C primer would be enough... Samsonite, I was way off.

So, I bought another book, this one on the Objective-C programming language, and accepted that I'd have to put off my game development plans for another month or so.

And guess what... I couldn't really follow that one either. I mean, I thought I was following it well enough at the time - although I had a lot of questions along the way - and where it didn't really click, I just chalked it up to my lacking knowledge of the C programming language (which Objective-C is built on).

Turns out, it was partly that, but also partly that the book was poorly written - something I would have been able to figure out quickly if I had taken the time to learn C first. Not knowing what I know now, however, I finished the Objective-C book and went back to the game development book. And guess what... it still wasn't all that clear. Somewhat discouraged, I knew that I had to start over, and learn the basics (and find books by a different publisher).

Finally, I made a good move, and bought "Learn C on the Mac" by Dave Mark. For the first time, things started clicking. Reading this book was one of the best learning experiences I've had - in case anyone out there is thinking about learning how to write iPhone apps, and knows absolutely nothing... this is the place to start.

It took me several weeks, but I finished the book, and was even able to do the exercises and understand everything that I was doing. When I went back to the Objective-C book that I had read previously, I finally knew enough to realize that it was poorly written, and quickly picked up the sequel to the book I had just finished.

Learn Objective-C on the Mac by Mark Dalrymple was even better than Learn C, and I worked through it in a few weeks. It probably helped that I had done all of that previous reading about Objective-C before I really understood what I was trying to learn.

About 5 months into my project (well, I had to take about a month off when work got really busy, so more like 4 months in), I was finally ready to start learning about actual iPhone development. Wanting to stay with the publisher of the previous 2 books, I picked up Beginning iPhone 4 Development by Dave Mark, which I'm currently about 90% of the way through. This last one has taken me quite awhile, as it's abut 3 times longer than either of the previous two.

So, that brings us up to the present. With a little luck, I'll finish this book today, and be ready to move on to phase 2 (sample apps) this coming week.

That will be an important step, because I'm going to treat it like a microcosm of the whole project, working through the various steps almost like reconnaissance for the larger project to come. We'll see if my steps remain more or less intact, or if making the sample apps causes me to rethink my approach.

In the next few days, I'll try to post some more details on phase 2, along with some of my rough ideas for sample apps - my plan is to choose 3-5 apps to work on (either simultaneously or not), and if possible, get them all the way to the point where they could be submitted to the App Store (if any of them are good enough).

At the very least, though, I'm hoping to get them onto several devices (iPhones, iPads, etc) for testing, and to get more comfortable with the whole process of development, testing, and possibly even publication.

So wish me luck, and check back soon for more updates!

New Project

2011-06-08T05:45:00.000-05:00

I've started a new project.

Those who know me well know the translation of that: I've found something that really fascinates me - keeps me up at night, and wakes me up in the morning just thinking about it - and I'm going to throw myself into it semi-obsessively (some would question the "semi-" part of that statement), until I feel like I have accomplished whatever there is to accomplish... or until I lose interest, which could take years in this case.

But before this project can bear any fruit, there's a lot of work to do. I've been reading for the past few months, and I have at least another month or two of general research before I can do much else; but in the meantime, I've decided to dust off the old blog. I think it'll be helpful as my little quest develops.

So, for now (in the name of dusting off the blog) I'm going to do what I should have been doing all along, and marry up my twitter feed with this blog - over the next few weeks, I'll be transitioning my tweets from the past two years over to here (after all, I started this blog to have a record of my only life, right?)

Once I'm caught up there, I'll start posting updates on my project, and hopefully capture this journey well. For the next few weeks, though, this is all I'm going to post on the project itself - I've sketched out my plan...

I'm going to publish an iPhone app:

(and with a little luck, it just might be awesome!)

2010-06-23T10:41:00.001-05:00

Turns out General Stanley McChrystal is an idiot. If you haven't already heard the news, Google his resignation.