OpenGL ES

After seeing the multitude of AppStore games which undoubtedly use OpenGL ES instead of my hacky method of what amounts to UI controls as sprites, I've decided to bite the bullet and switch to using OpenGL ES for the game.

This of course means that I will spend weeks more doing research, learning how utterly crappy the APIs are (not to mention the utter lack of thorough documentation) compared to XNA Game Studio and wishing I didn't have to put up with this just to target a popular platform. Changes to the game will be virtually non-existent if not backwards for a while. I am crossing my fingers that I'll be able to work on an XNA Game Studio project simultaneously in order to keep my spirits up.

That's right, folks. C#/Visual Studio/XNA Game Studio is so much more pleasant to work with that I'd rather work on two projects at the same time than suffer with just one for the iPhone.

Latest gameplay video, at the cost of boring dev details

If you want to skip boring details about my struggles, skip to the video at the bottom of this post.


I've at least found a good temporary solution for the landscape issues, and I've been progressing with learning Objective-C / Cocoa / UIKit / etc. but not to the point at which I can concretely delineate between each of these terms. I'm also struggling a bit but getting the hang of several things.

I finally installed a third-party mouse configuration software so that I can get more than a kindergarten level of control over my mouse sensitivity.

I'm getting the hang of the MacOS app launching model, the dock bar and how it represents running versus non-running programs, the "Finder" file browser and its quirks.

XCode is like Visual Studio lite, or perhaps "Visual Studio Gimped". I've chatted endlessly on IRC with people who gladly praise XCode over Visual Studio, but I wonder if they've used VS2005 or greater. It's just no comparison; there are redundant windows/panels everywhere, the debugger runs in a separate tiny window, though you can resize it, covering your other windows. The expression watcher is nowhere near as powerful as Visual Studio's, and Intellisense (or its equivalent) is weaker in its implementation, requiring more keystrokes for simple tasks.

Speaking of the tiny debugger window (obviously resizable), this is a common observation with MacOS. It seems the norm to be expected to manually drag windows around and place them as you need them; stretching them to just the right extents, etc. In Windows my usual mode of operation is to only do that when I'm copying files from one explorer window to another. When I'm running apps, I generally switch to the app, then maximize the window if it isn't already maximized. Windows seems to work well with users who are used to this behavior. MacOS doesn't seem to be expecting it; hence, I'll find that apps have lots of little "helper" windows that are expected to be resized to comfortable dimensions for the particular user at that particular time. This is not how I want my apps to work. Visual Studio supports this, but also a very extensive docking scheme so I can have all my windows docked where I want them instead of floating about in the ether, always getting in the way of content behind them, or else getting hidden themselves when I click somewhere else.

Again I find it ironic that so much of what makes the iPhone dominant over Windows Mobile is the same that makes Visual Studio dominant over XCode and the general Mac development situation. Of course, I am trying very hard not to bias my arguments with my existing familiarity with Visual Studio. There's still much more to learn.

Other factors which add major hurdles include simple things like the feel of the keyboard. It's no longer Ctrl-C, it's Command-C, etc., not to mention completely different dev environment hotkeys. And on my particular keyboard, the Esc and F-keys are tiny.

I finally bit the bullet and sacrificed dual-monitors on my PC in order to have a dedicated monitor with a DVI input from my Mac. I also switched placement of my keyboards/mice so that my Mac is in my primary workspace on my desk, and my PC is riding shotgun. This will encourage me to give my Mac some more love.

If you've read this far, your reward is a video of the app in its current state, run through the iPhone simulator. Long story short, I need to go through a long, painful process to enable deployment to my iPhone ever since switching Macs.

F#$king Landscape mode

I have spent the vast majority of my coding time on this project trying to get the damn iPhone to properly handle content created for a Landscape-only orientation.  I never realized how much easier life would be if I was a good boy and just kept everything in Portrait mode.

I heard rumors that the 2.2 SDK (currently 2.1) will include a fix for the landscape-mode hackery that exists now, and hopefully this will prevent me from needing to create a transform and do some sort of wild, seemingly arbitrary calculation to find the center point of my view (used in the aforementioned transform).

This really is insane.  I don't know how people say they've been able to get apps going in like 10 days.  Actually I do know why: they weren't creating apps in landscape mode.

Vacation...

I know you've all been wondering why I haven't updated in a while. There are two reasons: 1) I haven't had a Mac available for iPhone development since August 28th or so, and 2) I'm on vacation right now in Disney World, returning September 10th.

I'm having an awesome time but it'll be really nice to be home and back to my geeky endeavors.

iPhone development delayed, Xbox development proceeding

So my Dell notebook was supposed to be repaired by an on-site technician, but they failed to fix the problem and now I've got to send my laptop in for repairs, and I won't get it back until several days from now, at which time I'll be on vacation.

I have been considering purchasing a cheap Mac mini to use as my dev machine in order to avoid the issue of having to borrow my girlfriend's MacBook and also to give myself more screen real-estate.  So far I'm holding off, and instead will just focus on the XNA GS version of the game until I can get my Dell back (and swap with the gf).

One issue I'll have to solve with the Xbox version of the game is how to support different video resolutions in the easiest way possible without sacrificing quality for hi-def players.

Another bit of art.

Here is another small bit of art:



I also created the game logo tonight, but we're not quite ready to reveal the name of the game just yet, so I'll save the art and show it to you one day in the not-too-distant future.

Exclusive Game Teaser Video!

Since I won't be needing to take my Dell laptop in for repairs until Tuesday, I've weaseled some more quality time out of my Mac dev environment for the weekend. Still, I'm trying to convince Dave to do a XNA Game Studio version of our game, or barring that, a different (simple) game for that platform.

As I work out the kinks and frustrations with iPhone SDK development with the help of my trusty l33t gaggle of cybergeeks on IRC, the experience gradually becomes more tolerable. If I ever need a break from the stresses of programming, I just open up my XNA Game Studio project and enjoy the pleasures of programming.

And here's another teaser of our game, complete with more information than I should probably reveal:

iPhone development temporarily on hold -- with a good excuse!

I love my Dell XPS m1330 laptop, but ever since I've had it it's had an intermittent problem in which the screen goes blank for no apparent reason.  I tolerated it for a long time, but finally called Dell tech support a few weeks ago since my warranty ends in September and I want to make sure I get a hardware replacement if needed.

Well, naturally Dell did what they could to avoid the hardware replacement option, exhausting every software and firmware option they could think of, but finally I insisted that I get a hardware replacement since my warranty is almost expired. 

What does this have to do with anything?  Well, as I mentioned in my last post, I've been borrowing my girlfriend's MacBook for iPhone development, but what I didn't mention was that she's been borrowing my Dell in return (she's so sweet).  Since I need to take my Dell in for service, I need to give her back the MacBook for now.  It's a blessing in disguise because it gives me the opportunity to plug away on the XNA Game Studio version of our game, which I can develop much more rapidly.  Now I just have to send Dave a new request for art assets.

Oh, and I should have the Dell fixed by Tuesday, so I should have the MacBook back either that day or the next.

All that fancy Dev talk have you down?

If Mike depressed you with his last post, then I hope the latest shot from the intro will cheer you up!



If that didn't work, then might I suggest perscription drugs?

Microsoft development, I will never forsake you

Warning: The following post was originally posted to a development blog of mine, and is thus heavy on the programming jargon and ranting.  Feel free to ignore for your sanity's sake.

For the past few weeks I've found myself jumping from one shiny project to the next.  I was enticed into trying game development using Silverlight, which I still regard as an exciting technology with lots of potential, but my heart just isn't in it.  If I targetted that platform, I'd be doing so out of pragmatism instead of passion; that is, I know there's a potential market there, but I wouldn't enjoy the work.

My latest flavor-of-the-month project has been game development with the iPhone SDK, whose Kool-Aid I drank in one giant gulp.  The iPhone is amazing.  The interface is slick and intuitive; the app store is exciting and full of great (and not-so-great) apps with a promising revenue model for independent developers, and the development platform is... utter shit.  Without breaking the NDA (I hope), let me just say that just about everything about the iPhone development story is inferior to what Microsoft has to offer.  I don't claim to be an expert after only about a week of experience (albeit with many hours put in), but here are some gripes so far:

1. First, there's the fact that you have to use MacOS to develop for the iPhone.  In my case, I'm borrowing my girlfriend's MacBook.  I would very much prefer to utilize my dual widescreen LCD monitors, but I realize that this complaint is circumstantial.  I'm sure that a savvy Mac user could navigate the MacOS with ease, but it's a struggle for me.  It would be nice if there were a Windows option somehow.

2. Second, I have to use XCode, Apple's free IDE.  I will be fair; for a free IDE, it's packed with decent features, and I can't really compare it to Visual Studio Express (another free IDE) given that the latter benefits from the features of the full versions of Visual Studio.  But it's still a giant step backwards.  The syntax highlighting is overly subtle, the code completion guesses at what you're trying to type but doesn't pop up a list of options (at least not automatically).  I've yet to see a list of method overloads appear; you're at the mercy of your memory and the greatly-inferior-to-MSDN documentation, which lists all of an object's methods/properties in one long list.  There doesn't appear to be any sort of refactoring capability, though I can probably blame the language (which I'll get to soon enough).  The solution explorer equivalent is strikingly un-Apple-like, showing redundant information while lacking important information at a glance.  I've run into bugs in which error and warning markers in the code don't disappear even after you fix the errors. (I even deleted the offending code entirely and rebuilt with no luck). 

3. Objective-C.  Oh my god.  Could Apple have picked a more obscure language?  Why not just stick to C or C++?  The syntax in objective C is unnecessarily arbitrary, with objects calling methods (or more specifically, "sending messages to call a method") of the syntax:

[object methodName]

(including the brackets.)  You can even (and are encouraged to) nest these calls, for optimal confusion:

[object1 methodName:[object2 getSomething:[object3:getSomethingElse]]]

My favorite (sarcasm, in case it wasn't obvious) detail about methods is the parameter passing.  You see, a method signature is defined not by its return type, name, and parameters, but rather just its return type and parameters.  Read that again: Return type and parameters.  Something missing?  That's right, there's NO METHOD NAME.  Or more specifically, the method name IS the parameter list!  So, a hypothetical method to open a file read-only might be:

[FileObject openFile:@"myfile.txt" readOnly:YES]

Or an even better example:

[MySpatialObject setPositionX:100 andY:120]

That's right, I can't have a method called "SetPosition".  Instead, the method is technically called: "setPositionX:andY".  Of course nobody would use the word "and" in a real-world parameter name, right?  GUESS AGAIN, it's encouraged!  Method names are supposed to read like prose.  I am a strong advocate of longer method/parameter names for the sake of readability and avoiding obscurity, but there are much better solutions to this problem than this.

And just as an extra kick in the nads, the standard coding conventions fly in the face of everything that modern, civilized software developers have evolved toward (e.g. curly braces on separate lines for the love of God, curly braces surrounding one-line if statements, non-cryptic class/variable names, etc.)

Oh, did I mention that this language isn't strongly typed?  Enjoy.

4. Interface Builder.  Fine, this relates to XCode, but it's bad enough to deserve its own category.  This is the GUI tool that creates...well, GUIs.  Hell, even Apple devs don't seem to like it.  It's again another ironic example of Apple's dev tools flying in the face of Apple's typical design philosophies.  This tool is completely unintuitive to use as opposed to Visual Studio's designers, involving all sorts of GUI elements that can be connected with lines as a way to graphically "wire up" events and relationships.  So much of what you'd expect (i.e. you click on a control in the visual designer and immediately see a context menu with this control's attributes and event wiring) just doesn't exist.  You have to dig through options to even see these things, and even when you find them, their function is not obvious.  Can the people who designed the iPhone interface please help out designing this tool as well?

---

There is much more to write about the iPhone dev woes but I'll save that for another post.  In general, if you want to know what the iPhone dev environment is like, use an iPhone for a week.  Then use a Windows Mobile phone the next week.  The extra pain you'll feel the second week is analogous to the pain you'll feel switching from the standard Visual Studio/C# environment to the iPhone's.  But at least in Windows Mobile's defense, it does have extra features it's trying to pack in.

 

After working on iPhone development/learning for a few hours today, I worked a bit on my XNA Game Studio project.  It was an almost orgasmic experience.  It felt like the feeling you get right after stepping off a treadmill after a long run.  Suddenly you feel like superman, almost gliding along the floor effortlessly when you walk.

Well look at that...

It's not final UI by any stretch, but here's a bit more of a clue as to what we're working on:



Stay tuned!

A day like any other day...

Storyboards...

I'm not sure if I should leak these yet, but since they don't really reveal gameplay, I think I'm okay...



These are really rough storyboards for the intro movie. I'll be working on real versions over the next few days, as Mikey remains "under the hood," trying to get things running.

I blurred the name (in the last panel), since we're not quite ready to reveal that just yet...

We're back!

After a much-longer-than-expected break, Mikey and I are back and working on a new project. "Attacker" was a great learning experience, but we're focused on something new right now. We'll have updates very soon, but for now, here's our new logo!