Red, White, and Blue

The final title for my web game, slated for an oct 31st beta. Three parties, three colors: red, white, and blue. I decided to pull back on the plot in an effort to stay out of politics, we don't need half-assed political dialogue in a budget web game prototype (v2?).

The next piece of tech I would like the exploit is Silverlight's Polling Duplex support. Similar to the "AJAX Push" or "HTTP server push", this technique, coined Comet by the web community, allows one to emulate packet "Pushing" in the browser, without having to face the hurdles of socket programming, policy files, and blocked ports. I'm pretty excited about it's capabilities and it's ease of implementation with WCF and Silverlight. Although it won't be enough for any serious real-time multiplayer communication, it'll be "good enough" for most scenarios, especially those found in a turn-based world.

As a side note, does anyone have a problem with dandruff dirtying up their keyboard?

XNA Game Studio Coding Jam, Fall '08

I recently signed up to attend an event for developers and artists which allowed them to collaborate on an almost-released build of XNA Game Studio 3.0 and build a game in a short amount of time. When I signed up, I was under the impression that this event took place on a Saturday and lasted all day long. It wasn't until last Friday afternoon that I got an Outlook Calendar reminder which corrected this false assumption, informing me that in fact it was an all-weekend event.

Reluctantly, especially given the time and energy I've been devoting to iPhone development recently, I bit the bullet and told myself that this was an opportunity that I didn't want to pass up.

The event consisted of an Iron Chef-style "five ingredients" challenge (also similar to gamedev.net's "elements" programming contests), in which we picked from randomly generated lists of game elements from which we derived a game concept. We quickly formed into groups, each containing (thank the Lord) an artist, and tried to pick the most appealing set. The elements we chose were Doom, Clock, Robot, Pirate, and Defense. Our game: Doom Clock Robot Pirate Defense.

As an aside, it's funny what goes on in my head when I have to choose team members in a short amount of time. Ultimately I'm looking for enthusiastic, motivated, skillful people who are also mellow (i.e. no Prima Donnas). Obviously it's impossible to gauge this in such a short amount of time, but I was fortunate with my group.

We ironed out the basic details of the gameplay Friday evening, and began our implementation bright and early Saturday morning. (Seriously, it still amazes me that I was able to show up on time at 9am on a Saturday.) Much to my great concern, we opted against using source control, and instead agreed to use a memory stick as our repository. Yikes. In retrospect, I bet I could have created an actual SVN repository on that thing. It wouldn't have been perfect, but it would have likely eliminated many headaches.

It quickly became apparent that our lack of source control was a very bad idea. Nearly all of our changes involved multiple shared files, and the process of merging was very manual, and very confusing. We essentially had four different versions of the code floating around at any given time, and it became difficult to tell whose changes were the newest. Instead of merging to the USB stick, team members would often just copy the changed versions of their files to a separate folder on the stick, making it nearly impossible for me to tell when a line from the USB stick's code was newer or older than what the programmer had copied to the new folder. Suffice it to say, it was a big mess, and I'll write it off as a reminder of why source control is so crucial.

Our artist, Chris, was hard at work from the very start. I regularly glanced over at his drawings and wished I had that ability. I also envied his lack of need for any sort of source control solution. We'd call out when we needed art assets, and I was tempted to ask for something completely ridiculous just for the fun of it, but I restrained myself. I really like the opportunity to work with an artist on a project for several reasons. First of all, I'm much more inspired to work on a project when I have visual gratification at regular intervals. I may be able to create intriguing gameplay without an artist, but I don't really believe it until I see it. As soon as I see appealing illustrations and animations, that's when I first start to feel the real potential of my project. Second, it's a great experience to discover the processes needed for a functioning content pipeline. What format should my images be in? What size? Should each frame of an animation be a separate image or a large composite image? What if the composite image isn't a square; will the texture importer complain? Questions I may not have even considered are suddenly an important part of the process, and this experience makes future projects go much more smoothly.

After a couple full (but not overly burdensome) days of coding, we ended up with a fairly playable prototype. It contained several types of enemies with AI, three different types of towers, several levels, a controllable player, collision avoidance, a snazzy menu system, support for the Xbox 360, and even same-box multiplayer. I added all the code to a repository which I shared with the team, and I've even seen significant updates from one of the developers in the past couple days. I am tempted/eager to clean up the code, since ours was inevitably very messy and arbitrary, and just enough to "get the job done." I am almost as much a Code Nazi as I am a Grammar Nazi. (Although seriously, I don't think that avoiding "u" in place of "you" and knowing the difference between "your" and "you're" qualifies me as a Grammar Nazi; that just means I have at least a third-grade education.) I just think there's something inherently selfish about writing bad code if you're on a multi-person team, but I'll save that soapbox rant for later.

More Mac/iPhone development updates

I have several posts in one of my other blogs that are applicable to this one, so I suppose I will fix one of them up and post it here, so as not to appear M.I.A. The following is a follow-up to some landscape-mode issues I've been having with iPhone development; specifically, if I apply a transform to a root level screen in my app, any child screens added 1) will not have that transform applied in the iPhone simulator, as I would expect, but 2) *will* have that transform applied on the actual device:


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.

Update: The lack of multi-monitors with my PC is getting annoying, but I bought a new keyboard for my Mac, realizing that PC keyboards usually work just fine. This has been so great for my sanity and has filled me with some extra spirit that was lacking the past few days.