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.

]]>https://gisenberg.wordpress.com/2012/04/08/galactic-fire-free-advertising-networks-on-windows-phone-7/feed/1gisenbergGalactic Fire – Leaderboards, analytics and more for Windows Phone 7 gameshttps://gisenberg.wordpress.com/2012/03/27/galactic-fire-leaderboards-analytics-and-more-for-windows-phone-7-game/
https://gisenberg.wordpress.com/2012/03/27/galactic-fire-leaderboards-analytics-and-more-for-windows-phone-7-game/#commentsTue, 27 Mar 2012 22:41:57 +0000http://gisenberg.wordpress.com/?p=54Continue reading →]]>Throughout casual play testing, one of the recurring feature requests for Galactic Fire (now available on the Windows Phone 7 Marketplace!) was leaderboards. Initially, one could only compete with themselves for a high score on the local device and, while appealing, it doesn’t necessarily capture the same competitive edge as seeing how one ranked world-wide. Leaderboards sounded like fun, and folks wanted to see how they compared to other players in the office.

Being overzealously protective of my spare time, I dismissed the idea of leaderboards. The game was more or less feature complete, was already for sale in the WP7 Marketplace, and I didn’t want to build or maintain a leaderboard service. Even once it was built, I’d have to cover hosting costs, troubleshoot uptime and availability issues, and it sounded like a bunch of problems I ultimately didn’t have time for.

One of the key differentiating features between Galactic Fire and its free/trial counterparts ended up being work that I didn’t have to do at all, and that’s largely thanks to a service called Mogade. Mogade advertises “free solutions for casual game developers“, and one of the free solutions happens to be leaderboard support with corresponding Windows Phone 7 client source and binaries.

As far as I can tell, Mogade is a small handful of folks learning and building services for an area that they are passionate about, and monetization is currently on the back burner. From the Mogade FAQ:

Why build mogade? Why make it for free? Why open source it? Ultimately, we believe in gaming, and we believing in the casual gaming revolution brought about by new devices. We grew up on video games and we want to do our little part to make sure others get the same benefit. It currently costs roughly $100/month to run mogade on redundant hardware. It’s a manageable expense.

I ended up using the free Mogade-hosted leaderboard service, but if the idea of someone else hosting your app’s functionality makes you uncomfortable, then you have the option of forking the Mogade source on Github and hosting it on your own servers.

In addition to leaderboard support, I took advantage of some other Mogade-provided features to add some basic instrumentation to track game launches and unique users. This has the net effect of tracking downloads, unique users and game launches in a way that is far more immediate than the App Hub tools. In fact, I could see the build with instrumentation going through certification as the number of unique users spiked in advance of the game’s marketplace launch.

Mogade offers great functionality at a cost that I can’t argue with. For indie developers and small studios, it’s hard not to recommend taking a look.

]]>https://gisenberg.wordpress.com/2012/03/27/galactic-fire-leaderboards-analytics-and-more-for-windows-phone-7-game/feed/1gisenbergGalactic Fire FREE now on the Windows Phone 7 Marketplace!https://gisenberg.wordpress.com/2012/03/27/galactic-fire-free-windows-phone-7-app-marketplace/
https://gisenberg.wordpress.com/2012/03/27/galactic-fire-free-windows-phone-7-app-marketplace/#respondTue, 27 Mar 2012 15:41:58 +0000http://gisenberg.wordpress.com/?p=48Galactic Fire FREE is now available on the Windows Phone 7 Marketplace! Galactic Fire FREE is an ad-supported version of the full Galactic Fire game.

Galactic Fire FREE, now on Windows Phone 7 Marketplace!

]]>https://gisenberg.wordpress.com/2012/03/27/galactic-fire-free-windows-phone-7-app-marketplace/feed/0gisenbergGalactic Fire FREEGalactic Fire v1.5 update now live!https://gisenberg.wordpress.com/2012/03/24/galactic-fire-v1-5-update-now-live/
https://gisenberg.wordpress.com/2012/03/24/galactic-fire-v1-5-update-now-live/#commentsSat, 24 Mar 2012 08:50:13 +0000http://gisenberg.wordpress.com/?p=36Continue reading →]]>Galactic Fire v1.5 is now live on the Windows Phone 7 App Marketplace, and includes the following updates!

Leaderboards! Owners of the game will now be able to participate in global leader boards for overall score.

Fancy art! The app icon and splash screen have received a major overhaul.

Game duration has been increased, from 90 seconds to 180 seconds.

Game difficulty has been tweaked, and death should no longer reset difficulty.

Fancy score and multiplier modifiers now show on enemy death and gem pickup, respectively.

Minor UI tweaks.

Additionally, Galactic Fire now has an ad-supported trial, and Galactic Fire FREE has been submitted to the WP7 app marketplace! The trial and free versions are ad supported and lack leaderboard support, but are otherwise identical to the full version of the game!

Tell your friends and rate the game! It’s actually quite fun!

]]>https://gisenberg.wordpress.com/2012/03/24/galactic-fire-v1-5-update-now-live/feed/3gisenbergImageGalactic Fire v1.3 update now live!https://gisenberg.wordpress.com/2012/03/11/galactic-fire-v1-3-update-now-live/
https://gisenberg.wordpress.com/2012/03/11/galactic-fire-v1-3-update-now-live/#respondSun, 11 Mar 2012 05:20:39 +0000http://gisenberg.wordpress.com/?p=31Continue reading →]]>Galactic Fire v1.3 is now live in the WP7 App Marketplace! This update includes the following tweaks and fixes:

Pulled the camera back a bit, allowing more time for players to react to bullets.

Application should now prevent phone screen locks.

]]>https://gisenberg.wordpress.com/2012/03/11/galactic-fire-v1-3-update-now-live/feed/0gisenbergGalactic Fire – What It Took to Ship a Gamehttps://gisenberg.wordpress.com/2012/02/15/galactic-fire-what-it-took-to-ship-a-game/
https://gisenberg.wordpress.com/2012/02/15/galactic-fire-what-it-took-to-ship-a-game/#commentsWed, 15 Feb 2012 09:29:19 +0000http://gisenberg.wordpress.com/?p=19Continue reading →]]>EDIT: Galactic Fire is now available in the WP7 App Marketplace!

This week, I hit a major milestone by submitting Galactic Fire, my first complete game, to the Windows Phone 7 App Marketplace. Soon, Galactic Fire will be available world-wide and had a remarkable budget of $0 with one guy working on it part-time.

This feat follows no fewer than a dozen incomplete or otherwise failed part-time projects spanning a variety of platforms and technologies over a 5-year span of time, so it seems a good time to reflect on the techniques that differentiated Galactic Fire from the graveyard of software that didn’t ever ship. This is the list of things that personally helped me ship.

1. Learn One Thing At A Time.

Many of my projects started out with a mixed focus. I wanted to learn a ton of stuff, and I wanted to learn it all at the same time. It wasn’t enough to make a game that was fun! No, whatever project of the moment also had to use software stacks and languages that I would also learn along the way.

For me, botching this rule looked an awful lot like, “Let’s start a new game! New C++ project! Let’s throw Boost in there. And work luabind in there. And maybe some Win32/DirectX stuff! Or OpenGL! Or LibSDL! It’ll be cross-platform and it’ll be great!” To set context, I’ve been working in .NET/C# land for the overwhelming majority of my professional career. I haven’t worked with any of those technologies in a professional capacity, but games have to use that stuff, right?

Yeah, no. I stuck with stuff I was already familiar with (C#, XNA). The net effect of using familiar technology was bounding my problem domain; instead of learning the nuances of another language, I instead spent a lot of time focusing on the stuff I really, really needed to know, but didn’t know I needed at the time. For example, writing code designed to work in a polling system (game loop!) rather than the familiar eventing model, collision detection, physics, and a butt-ton of linear algebra and trigonometry. Oh, and tuning a game to be fun is certainly a non-trivial investment of time.

This allowed the things that I needed to know to surface more quickly, and had me spending more time on game mechanics and polish than, say, implementing my own content pipeline. There’s no denying that there are amazing learning experiences to be had working in an unbounded problem domain, but actually finishing something in that environment was an impossibility for me.

A non-trivial number of projects were killed because art and sound seemed so integral to actually finishing a legit game development project. These kinds of projects all kind of started the same way: “Oh, I know! How about an old-school RPG? Set in the future! With lasers, and stuff! We’ll need a robot, and it’ll need a rifle, and it’ll probably need to transform and look super rad from 9 different angles!”

Those projects never got off the ground because I was hung up on art. Before getting into the tools available for alleviating the art problem, it’s super important to drive home the point that I could have gottenthe entire goddamn thingdone with placeholder assets. I wasn’t creating a fun game with gripping narrative from start to finish because I didn’t have a robot when floating cubes or white squares would have sufficed. Ididn’t need art and there was a shit-ton of work to be done elsewhere. Art was never in the way of finishing something great. It was an easy and convenient excuse to get hung up on and prevent myself from getting back to the hard problems that were waiting with the real work.

The very first iterations of Galactic Fire were about a red cube flying through a cornflower blue screen, shooting red cubes at other angry red cubes. It was pretty sweet.

If I really needed something a bit more custom, I would have still rolled a game using these as placeholder assets and then handed off the sprite sheets to a professional. If all went well, moving from prototype art to final art should just a matter of replacing assets.

Also, particle effects really, really legitimize an operation. I very clearly remember the day when enemies stopped simply disappearing on death and started exploding. Seriously worth the time investment.

If you’ve got Apple hardware sitting around, Garage Band in either iOS or OSX flavors has something you can use.

For Galactic Fire, I had some sfxr sounds and authored my own background music track, but ended up cutting it before release. By the end of the project, I had become so sick of the same sounds that I absolutely required a change. By the end, I ended up using a combination of out-of-box Garage Band sounds and a drum machine, using a closed high-hat for laser fire and a kick pedal for explosions.

3. Cut Scope.

I learned that game mechanics aren’t free. I mean that in a big way. Developing a feature isn’t the biggest part of what needs to be done to complete it. Take my plight to heart, and consider that even the smallest feature has to be communicated to the player in some way that doesn’t introduce cognitive dissonance.

Consider the following trivial game mechanics:

How do we let a player know that an enemy bullet is, in fact, a hostile projectile and not a power-up? Do we pulse the bullet, making it bright red and obviously visible? Are the color schemes for power-ups and enemies substantially different? Once the code has been written for a bullet, these questions have to be answered.

If the player can shield on demand, but the shield has a cool down, how do we communicate the cool down when the player shields too soon? How do we show how long a shield lasts?

If the player can place a turret at a cost, how do we communicate the final placement of the turret and what constitutes valid versus invalid placement areas? How do we show the firing range of a turret? If it costs money, how does the player get money? How do they know how much it costs, and what happens if they don’t have enough money? If it can be sold, how? If it can be upgraded, how?

Every game mechanic requires a tremendous amount of deliberation and polish to prevent it from appearing as random noise to a player, and the great games that stick in your mind made this work look easy. Polishing a game mechanic to the point that a player will enjoy takes an order of magnitude more investment than the implementation of the feature itself.

While working on Galactic Fire, I added a ton of features that were heavily influenced by friends, other games, or whatever was going on that way. Tower defense mechanics, ship upgrades, bosses, weapon power ups, shields, invulnerability. You name it, it was in scope. Without any intervention, I’d never stop introducing new features that I felt provided the differentiation in the market that my game needed.

In shipping Galactic Fire, I cut scope by about an order of magnitude. All the stuff that was half-baked and required substantially more investment before making sense to players was shelved. Gone, or saved for a rainy day, a sequel, another game, or whatever. They exist now only in old YouTube videos highlighting features that seemed super important at the time.

Throughout development and play testing of Galactic Fire, I had a small handful of core gameplay mechanics that were consistently fun to everyone that play tested. Flying the ship around was fun, and seeing a large number of enemies blow up was fun. These were the tenets that I stuck to when cutting all the other features.

I started with dual-stick controls on the Xbox 360, then gravitated towards accelerometer input on the phone with an auto-aiming cannon. I removed tower-defense mechanics, and just spawned in a bunch of brain-dead AI that chased the player. And the game was just as much fun (arguably more so!) as it was when I had piles and piles of unfinished feature work.

4. Don’t Make Frameworks.

While writing the game, I didn’t know what I needed, but still felt compelled to make a framework that handled everything I might ever need for this game and the next. At one point, I even scrapped every single line of code to rewrite everything based on my lessons learned.

It was a dumb idea, I wouldn’t advise it. First priority is make a game and roll with the punches. Don’t make a library; get things done in whatever way you see fit and tally up lessons for the next project. Arriving at this conclusion came largely from looking through older open source games (Quake 3, Abuse!). I learned that you don’t need a message queuing infrastructure to display tutorial messages when “char* tutorialMessage;” can accomplish the same goddamn thing in the hands of a sufficiently motivated hacker.

Grokking these four lessons was the single biggest difference between my failed projects and shipping Galactic Fire. The game isn’t perfect and it isn’t what I envisioned at the start, but it’s done and I can hand the game to a broad audience of people who will start having fun with it right away. If you’ve got a backlog of failed game projects, these principles might help.

-g

]]>https://gisenberg.wordpress.com/2012/02/15/galactic-fire-what-it-took-to-ship-a-game/feed/3gisenbergProject in Review, Part 3: 2D or not 2D?https://gisenberg.wordpress.com/2011/03/02/2d-or-not-2d/
https://gisenberg.wordpress.com/2011/03/02/2d-or-not-2d/#commentsWed, 02 Mar 2011 05:08:09 +0000http://gisenberg.wordpress.com/2011/03/02/2d-or-not-2d/Continue reading →]]>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 of animation for any given action. 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. Before we start talking about animation and number of frames per animation, we can see that 2D 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?

]]>https://gisenberg.wordpress.com/2011/03/02/2d-or-not-2d/feed/1gisenbergProject in Review, Part 2: Archimedean Assaulthttps://gisenberg.wordpress.com/2011/01/25/project-in-review-part-2-archimedean-assault-2/
https://gisenberg.wordpress.com/2011/01/25/project-in-review-part-2-archimedean-assault-2/#commentsTue, 25 Jan 2011 03:33:53 +0000http://gisenberg.wordpress.com/?p=8Continue reading →]]>In this episode, we’ll focus on the team makeup going into the development of the currently-stalled Archimedean Assault. For a general overview of the project, go read Part 1 in this series.

I mentioned we had about a half a dozen people that thought this was a great idea for some reason. For a hobbyist, “Hey, who else wants to go get stuff done this weekend?” project, we ended up with an all-star cast of game development awesome.

The Game Designer

nguyenn1 leveraged some awesome connections from a local Soul Calibur Game Night and roped in an honest-to-goodness, gainfully employed game designer from a local game studio.

This was awesome, and we were quickly shaping up to be a legit operation (!!!).

Having a designer on-board for the first time, one thing we quickly learned was that an hour of game designer time could quickly translate to hundreds of hours of development time.

Even though we settled on a general design early on in the project, gameplay evolved as soon as people got their hands on something playable. Evolving design meant more requirements during development, which equated to more time producing art/audio assets and development.

On the plus side, having a game designer allowed others to focus on their work. I could fire up a build of the game, enthusiastically shout “This isn’t fun! Who cares, not my job!” and then toss it over the wall like a good and/or bad engineer is prone to do. Being able to lean on the game designer was certainly handy for maintaining focus in the face of a game that wasn’t immediately fun.

Of course, in order to be able to toss it over the wall, we had to expose a bunch of levers to allow the game designer to tweak core gameplay mechanics. Keep in mind that we started with the game jam format, which roughly translates to producing code that only looks like it works by Sunday.

Letting the designer muck with game mechanics is a data-driven concept, and the game jam schedule is on the opposite end of that particular spectrum. That got us in a bind where virtually everything was hard coded and needed to… not be.

Exposing gameplay mechanics for the game designer ended up taking just as long as the original game jam schedule. Whoops.

Lesson learned. All roads lead to data-driven content. Got it.

]]>https://gisenberg.wordpress.com/2011/01/25/project-in-review-part-2-archimedean-assault-2/feed/3gisenbergProject in Review, Part 1: Archimedean Assaulthttps://gisenberg.wordpress.com/2011/01/25/project-in-review-part-1-archimedean-assault/
https://gisenberg.wordpress.com/2011/01/25/project-in-review-part-1-archimedean-assault/#commentsTue, 25 Jan 2011 01:52:53 +0000http://gisenberg.wordpress.com/?p=4Continue reading →]]>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.