Galactic Fire FREE – Advertising networks on Windows Phone 7

[cross-posted from my blog!]

While researching ad networks on Windows Phone 7 for Galactic Fire FREE, it became clear that ad network support for Windows Phone 7 is a bit fragmented depending on which tech stack an application is written in. Silverlight-based applications have several options for ad networks, and XNA-based applications have… well, fewer options.

The first (and last!) ad network I implemented was PubCenter advertisements. During evaluation of PubCenter, I was unhappy with the format of the ads being served (480×80 banners for a full-screen ad?), the relevance of ads (trucker jobs in England? srs?), and the fact that the portal doesn’t support WebKit-based browsers.

I also evaluated AdMob, which seemed to be an incredibly clear winner. Unfortunately, AdMob didn’t have support XNA titles, so I was out of luck there.

An interesting ad exchange network that did have support for XNA was AdDuplex, in which developers exchange advertisements in their game for advertisements in your game. The monetization model is different in that there is no indirect ad revenue. A developer in the program show 10 ads for someone else in their game, and the developer’s game is shown 8 times in someone else’s game. I’ve seen this recommended a number of times, and may yet experiment with this model, but direct sales of a non-established brand appear to be pretty abysmal, and this model drives only direct sales.

PubCenter, being a Microsoft ad network, had client binaries for WP7 XNA titles and had a monetization strategy that was more in-line with my goals. In the end, the advertisements seen in-game come from PubCenter.

Advertisements

Project in Review, Part 3: 2D or not 2D?

[cross-posted from my blog here!]

This is a continuation of a multi-part blog series focusing on the development of Archimedean Assault. Go read part 1 and part 2. It’s good!

Once the scope of our game was reasonably well defined, we set forth like good little game jammers and started hammering out code, 2D art assets and music.

Not far into this process, we realized the multiplicative nature our scope had on our art assets. A robot. Alright, he has to walk around and shoot. But, also, he has to transform! A transforming robot. Okay, that doubles the number of art assets for our robot’s actions. We need assets for both versions of the robot. And, we also need a transition animation going from one form to another. Okay, fine. A free-roaming game world in which the player can move 8 directions.

So, we need at least number of actions * number of forms * number of directions (x * 32 for those keeping score at home!) frames for any given action, and that’s before we get into animation. That means, if we want the robot to fire a gun and have muzzle flash, we need to get the muzzle flash from each direction in each form. When we start talking about animation and number of frames per animation, hand-drawn art assets quickly balloon out of control.

That’s before we start talking about the environment assets in which the game will actually take place.

Being the newbs that we are, we don’t have a dedicated pixel artist. We’ve got nguyenn1, who is by my estimation, about 10% of a dedicated artist. It takes us a few weekends to discover that we wrote a check for art assets that our group couldn’t cash. At least, not within a reasonable timeframe, and not within a reasonable quality.

We mitigated our dependency on pixel art by borrowing heavily from anywhere we could. danc’s sprite sheets on Lost Garden quickly became an invaluable asset that we leaned on.

Of course, this restricts us to assets that fit into the kind of game we’re trying to build, and art decisions became something to the effect of “Well, what’ve we got that kind of works?” That strategy doesn’t work when you have very specific demands, like “floating citadel” or “a robot that transforms from 8 different angles.”

After realizing that there was no way we’d effectively deliver on our artistic demands, I started looking at alternatives. 3D models are readily accessible at comparably low costs from sites like TurboSquid. After several months, the art assets for the player weren’t yet complete, and environmental art assets were still quirky and buggy. But, we could buy a 3D model that matched up pretty well with our vision for $5.

If $5 can save months of artist time, it certainly seems like money well spent. However, working with 3D assets requires time elsewhere. It requires non-trivial developer time and ramp-up time on tools and techniques across the team. Once I have a $5 model for the player, then what? The landscape of 3D modeling software isn’t terribly friendly (importers for fixed content, exporters to proprietary formats that either didn’t support our content pipeline or munged content beyond recognition, rigging models and animating them in-game…), and animation seems to be a mess across the board.

So, $5 doesn’t seem to save us time, but does distribute the load across the team a bit more evenly. But, how can we be sure that we aren’t wasting our time chasing something because we think it’s fun?

Project in Review, Part 1: Archimedean Assault

[Crossposted from my blog. See the original here.]

As nguyenn1 alluded to, we’ve been working on a game (!). What started as a weekend long GameJam entry into October’s LudumDare competition is… well, still going. We’re clearly over every imaginable budget at this point, so let’s take some time to look back and see what went well and what could have gone better. But, before that, let’s set some context!

Archimedean Assault is a single-player, arcade-inspired shooter featuring a transforming protagonist. Development efforts were borne out of a love for games and a coinciding LudumDare competition.

The player pilots a Gundam-style mech that can switch between a maneuverable aerial form and a heavy-hitting ground assault tank. While airborne, the player has exceptional maneuverability through a constant speed bonus and afterburners for an extra boost. In contrast, the player’s ground form is a slow-moving, armored behemoth with much more firepower. Expert players will strike a balance between air superiority and ground assault modes to destroy opposing forces and complete objectives scattered through a free-roaming game world.

In retrospect, I’m not sure how any sane individual could read that last paragraph and say, “Hey, we can totally hammer that out in a weekend!” Yet, we had about a half a dozen people on-board with the idea that we could.

Stay tuned for the gory technical details!