Stress and Release Schedules

I'm a bit of a workaholic. Not a complete one, mind you. I keep pretty rigid workday hours, and have no problem walking away from my work at the end of each day. I'm even good at not working weekends or during vacation. However, as I've noted before, I seem to have a problem with scheduling time off.

The Guilt Release Cycle

I think my issue is related to a sense of guilt or obligation. I find that I am happiest when I have just released a new build, with new features or content. I think that during that time, and for a brief while after, I feel like I've fulfilled my obligations, and can relax a bit.

Gradually, as that new build gets further into the past, my sense of guilt/obligation grows, and I start to get stressed that I haven't released anything recently. That stress increase may vary depending on how much progress I am making towards the next build. It also can be tempered if I'm really confident in what I'm building. But by the time a month has passed since the last build, I feel a self-imposed pressure to get something out soon.

Vacation and Release Timing

With Christmas coming up, I have plans to take time off. Unfortunately, my last uploaded build was November 8th, which means I'm deep in the emotional trough phase of my release cycle. So I've been feeling a tremendous amount of pressure to get a new build released.

I was under the illusion that I could have a new one wrapped up last week, before starting vacation this week. However, that seems highly unlikely now. I suppose I could release what I have, but I ultimately decided that I'd be even more stressed if I just released something incomplete or buggy.

In fact, it's completely counter-intuitive to try and release something before a vacation in order to reduce stress while on vacation. The fresh build would inevitably have issues that need fixing. I'd actually be making my vacation more stressful by having to babysit the new build through its teething period.

Admitting that the new build wouldn't happen before vacation turned out to be a big stress-relief. I still have some stress about being late, but at least the sense of helpless urgency on top of it is gone. I'm no longer facing down an impossible deadline or the decision about whether to release work I'm not completely confident in.

Anxiety and Prioritization

What's more, I find that my approach to work shifts with the reduction in stress. During those urgent days before a release, I discard anything that can't be done in a day or less. I'm in "quick win" mode, and can't commit to any significant changes, sometimes even important ones.

Quick-wins are valuable, but sometimes, they're not the highest priorities. Iterative development teaches us that we should constantly be working on reducing the biggest risk, which is not always the task with the shortest completion time.

When urgency is relaxed, I find it easier to gauge my work, and focus on things that need doing most, instead of things that can be done quickly. I stop thinking so much about time, and focus more on the question of "what adds the greatest value right now?"

Vacation as a Business Owner vs. Employee

Something else I've noticed about vacation anxiety is the sharp contrast between going on vacation as a business owner and as an employee.

As an employee, I can remember looking forward to vacation. Most of the time, I was able to leave work at work, and enjoy my vacation as my time. I did feel a little guilt when taking a vacation while others were working (as opposed to a company holiday, for example). However, I usually didn't feel any urgency while on vacation. I just left work behind.

As a manager within a company, I think more anxiety was introduced to my vacations. I had a harder time walking away, probably because of a sense of responsibility and ownership. Quite often, I would make excuses not to go on vacation, because I "needed" to be there for something, or to finish something.

This sense was amplified when I became a business owner. Now that I am in control of everything, and all responsibility rests on my shoulders, I don't feel excited about upcoming vacations. I feel nervous, and stressed.

Being an internet-based business probably makes that worse, since the business is technically running 24/7, with me as the sole employee. I've had to learn to set hours of unavailability, or else I'll constantly be checking messages and forums.

What To Do About It

I'm still too new to this to have a solid prescription. And I don't have a lot of experience-based data to use as a reference. So I'm still guessing, at this point.

However, observing the above pattern was a good first step. Now that I know it's an issue, I can start paying attention to my behavior in relation to it.

And I've decided to take a vacation without releasing anything in advance. That was already implied above, but I'm repeating it just to be clear. I'll have to make that clear to customers as well, but they seem to already be pretty understanding.

I guess most importantly, take a step back, and look at the situation. Look for signs that you might be letting work creep into your personal life. And if it is, make some adjustments. One of the most powerful tools I've discovered for self-regulating my work/life balance is reminding myself that "crunch is detrimental." Overworking oneself is going to lead to lower quality work, and lower quality of life. By telling myself that, I'm able to use my workaholism to my advantage, since I don't want to detract from my precious work.

And when you do finally take a vacation, make sure the vacation is a vacation. It might not be possible to ignore your business for 168 hours in a row, but at least leave the stress behind, and minimize contact with it. Designate your vacation as a "safe zone," where it's okay not to get work done. Build the week's vacation into your release schedule.

In the end, this is mostly a self-imposed anxiety. I don't think others hold us to as high a standard as we hold ourselves. And in the case of video games, many of the most-lauded studios are those that err on the side of taking necessary time to do their products right.

So this is a note to myself as much as anyone else: take some time off. Use it to relax. Step away from the product and producing for a while. You'll come back refreshed, and ready to make your creation even better.

More Customer Relations

On several occasions, customers have mentioned how much they appreciated that I was both responsive and kept a regular update schedule with NEO Scavenger. It's nice to be complimented, of course, but I was a bit surprised that folks noticed. Does this mean some other indies aren't keeping their customers up-to-date? Or worse, is that negligence the case for such a majority that good customer relations is praiseworthy?

I hope not. And thankfully, that doesn't seem to be the case with many indies I know personally. But I'll admit, my pool of indie friends is pretty small. In the spirit of sharing best practices for aspiring indies, maybe it's worth going over some customer relations policies that I adhere to.

Publish Regular News

I have a pretty strict work schedule. I work 9am-6pm (ish), Monday to Friday. I don't work on weekends nor stat holidays. And I give myself 3 weeks of vacation each year. For each day worked, I publish news on my company website (with RSS, as requested by several customers), at the end of the day .


I also post news about my availability. When I'm going to be out of the office, I post news to that effect. Similarly, I announce vacation plans in advance. I think it helps to set the correct expectations if you're going to "go dark" for a period of time.

My company website's news is for customers to see what I'm up to. It's the primary means of reaching customers in an official capacity. If someone wants to see what I'm currently working on, the news will tell them exactly that, to within one business day.

I think it's easy to forget, as a game developer, what it's like being a fan of a game in development. We may have forgotten the days of poring over every screenshot, interpreting the HUD and UI in previews for hints of unrevealed gameplay, or reading interviews in hopes of glimpsing the creative process. For someone not in the world of game development, even the mundane tasks can be interesting.

So share! Talk about some of the interesting problems you had to solve that day. Or think out loud if something's got you stumped. If you started using a new tool, talk about your experience with it. When it comes to making games, someone, somewhere, probably wants to know what you're up to, or why you arrived at a decision.

There's also a marketing advantage to regular news updates: proving that your project hasn't stagnated. Often times, when checking out unfinished software, one of the big questions we ask is, "how likely am I to see this thing finished?" If you're about to commit resources to software, you want to know if your investment is going to be worthwhile. This is true of both monetary and time investment.

So when you're gauging a project's likelihood of being finished, what's the first thing you do? Well, you probably check to see how frequently it's updated. You read the news, browse changelogs, check the dates, and see if the product is active or dead. If the user sees that your news is only updated semi-annually, there's a good chance they'll assume it's not actively being worked on. So if you're working on the project actively, you may as well let everyone know!

And what's more, it becomes a tool for you to use as well. Wondering what you were doing last month at this time? Check your news! Having a daily, public journal entry about your work is a great way to keep track of your decisions, solutions, and progress.


Open Hailing Frequencies

News is a great way to "push" info out to your users, but communication is a two-way street. You should be prepared for customers to contact you, with questions, suggestions, concerns, and praise.

In the case of Blue Bottle Games (BBG), I have several channels, such as my own forums, news comments, Twitter, email, Steam Greenlight, and Desura. Different customers have different channel preferences, so having a variety of channels means most customers can use a method they feel most comfortable with.

I also keep tabs on a few forum threads around the web, as communities will sometimes spring up in the forum of their choice. Usually, Google Alerts is the tool which helps me find these discussions as they appear.

Maintaining multiple channels does place a burden on a developer, though. It sometimes takes me over an hour each morning to keep up with all of these channels, and quite often, it's impossible to cover them all. As a result, I prioritize them, and doing so consistently helps customers to know where they can go for urgent matters vs. casual ones.

For example, my email is one of my top priorities as a business owner. Every single email I receive (save occasional spam, like SEO offers) deserves a response, so I'll usually deal with that first. Comments on BBG news items are also a priority. The news is what I'm working on right now, so customer comments on that are highly relevant.

Tech support is another biggie. I hardly have time to scratch the surface of the BBG forums (particularly suggestions), but tech support is a frequent haunt of mine. If my product is broken or causing trouble, I want to know so I can fix it.

I have a few customers who reach out to me on Twitter, and I always reply if I see them. However, I find that many journalists also tend to prefer Twitter, so there's a second reason to consider opening that channel, if you haven't already.

Desura and Greenlight are also official "presences" that I maintain, though they're a bit easier since most messages are consolidated on one page. In retrospect, the Desura forums was probably unnecessary, as the main summary page comments do the trick for feedback.

There are many others, of course, and it will depend on the community you're building, and the ones you want to interact with. Just make sure you only open as many channels as you can manage. Like news, an unattended channel can reflect poorly on your business, and give the impression that your project is vaporware.

Be Responsive to Customers

So just how responsive is enough for all these channels? As a business owner, you'll have to decide on a timeline that works for you. Generally, I try to respond to customer inquiries within one business day. It gives me some time to consider how I'll respond (and to find an answer, in some cases), but it's a short enough time that most will be understanding.

One exception is in cases involving order issues and lack of game access. In cases like these, I respond as soon as I am able to, usually immediately.

As mentioned earlier, though, it's impossible to keep up with all chatter, everywhere, all the time. So I find it works best to stay 100% reliable on primary channels like email, official platform accounts (i.e. Desura), and tech support, and use any remaining time in my PR schedule to address the most relevant concerns I find (forum comments directly related to my current development, Greenlight comments, etc.).

How to Treat Customers (and Trolls)

In addition to where and when, there's the matter of how one responds to customers. In most cases, politeness and earnestness are the key things to strive for. It's hard to go wrong with being respectful. In my experience, folks are much more willing to discuss things constructively and politely if you lead by example.

Even some of my harshest critics get a "thank you for your feedback," and I do my best to address their concerns. If they bring a valid argument, it's important to recognize it as such, and let them know they're at least heard, even if you don't agree. Often, in these cases, they simply want something different than what you're building. And making that plain disarms any animosity.

The one exception to the above is the internet troll. A troll is someone who's primary interest is causing a stir, and getting a reaction out of people. It can sometimes be hard to tell the difference between a frustrated customer and a troll, but be assured there is one.

Some customers may be insulting, or terse, or misinformed, but they want something better (be it better features, better service, or a better community). A troll is just looking to get attention, at any cost, by any means.

I've talked a bit about this before in my PR policy post, but I'll repeat the summary here: ignore the trolls. Don't use your power of influence to draw attention to them by responding or addressing them. Just pretend they don't exist. If they are particularly disruptive, and your community allows it, you may have to ban or edit their comments. But more often than not, they'll go away in search of more interesting targets if you simply ignore them.

Frequent Builds

This one will depend a bit on your product and how you're distributing it. In my case, I'm offering a game which is still in development, and distributed digitally. As such, I can update the distribution channels with new builds as I develop them. And this is a powerful tool.

For one thing, it's a more powerful version of the aforementioned news updates. It's an actual, functional news item that players can try for themselves. If the updates are interesting enough, it can keep the game relevant in the players' minds for a long period of time, instead of the short-burst often seen in retail releases.

Additionally, adopting a policy of frequent build releases gives the developer a chance to try features and content with customers before committing to it in the final product. And it gives players a real way to influence the game for the better. For example, player feedback was instrumental in making NEO Scavenger's combat orders of magnitude more engaging than the original iteration.

The one caveat here is to be careful not to lean on your customers too much as a source of quality assurance. They will find bugs, and that's natural. But as a developer, you should not expect them to bug test your software for you. In fact, do everything you can to make sure each build is stable enough to be fun. After all, they're still your customers, not employees.

Refunds

There's one other topic that I thought might be worth mentioning, and that's dissatisfied customers. No matter what you're selling, there are going to be some folks who experience buyer's remorse. It could be that your product failed in some way, or perhaps they simply expected something different.

Whatever the case, I think it still pays to be respectful, and I'd probably issue the refund. I can't think of many cases where arguing with a customer over a refund ends well. Even if you keep the money, is it worth the time, bad press, hard feelings, or potentially, the customer disputing the charge with their payment provider?

There are some exceptions, of course. If the customer had the game for several weeks, and then wanted a refund, I'd wonder why it took that long to seek the refund. But even so, as indie developers, a single refund isn't going to break the bank. There's no need to haggle over a few bucks (nor is it even worth it).

You'll probably have noticed a pattern in the above suggestions. Basically, treat your customers with respect.   Customers are a diverse group, with a range of expectations and skill at communicating. For the most part, though, they mean well. Give them the benefit of the doubt, set a positive example, and they'll return the favor!

Haxe NME Follow-up

A few weeks ago, I began working on a Haxe NME version of the NEO Scavenger encounter editor. I endeavored to share my first impressions of NME, but I had two more weeks of experimenting with it, so I wanted to share what I learned. What follows, then, is a brief discussion of each of the highlights from that experiment.

Encounter Editor Screenshot

Speed

The main reason I chose to rewrite the NEO Scavenger editor in Haxe NME was because the Flash version had performance issues. The recent increase in data caused loading to timeout and crash. And what's more, even before this loading failure, I was reluctant to use the tool due to its sluggishness. Faced with rewriting lots of code no matter what, I decided to try Haxe NME.

I'm happy to say that Haxe NME showed its strength as a high performance framework. I haven't done any proper comparisons between NME and Flash, but the editor is quite responsive at 2560x1600 resolution. This was while drawing hundreds of boxes, hundreds of bitmaps, and thousands of triangles simultaneously, all with scaling (no bitmap rotations, though). 

The Windows target also loaded (SQL/URL-based) data much faster than the old Flash version. Though, the NME Flash target still needed optimization to complete data loading before the 15 second timeout.

UI

Form fields are still a weakness with NME on Windows targets. I was able to hack together some quick and dirty UI elements as stopgaps for buttons, toggle buttons, and drop-down boxes. But not having Flash's built-in UI elements was an obstacle.

TextFields

TextFields work on Windows targets, but are extremely limited. They lack support for getting the current caret position, selected text, and copy/paste. Flash targets work fine, however.

Performance can be an issue, though. I was able to get about 2-3 TextField elements per encounter node (about 2200 total) without any noticeable slow-down on my machine. However, much beyond that, and the framerate seemed to drop. I ultimately opted to hide TextFields on all nodes, and reveal them as-needed to keep framerates high.

A closer look at some of the editable fields I have in each node/connector.

Copy/Paste

Copy/paste, itself, turns out to be a general issue in Windows targets. I wasn't able to get access to the clipboard with vanilla NME, and the systools library that I tried wouldn't compile for NME Windows targets. Copy/paste on Flash targets appeared to work fine, though.

Object/Dynamic Weirdness

Haxe uses a type called "Dynamic" to handle generic objects (instead of Flash's Object class). On the Windows target, I was able to use .get() to access dynamically-named properties in a URLVariables object. But when compiling on Flash, the compiler didn't like that method. What's more, the traditional Flash method of Object["propertyName"] threw compiler errors. In the end, I had to use Reflect.getProperty(). Not too much of a pain, just unexpected.

URLRequest and 413 Error

Using URLRequest on Flash targets worked as expected, but caused errors when tried on Windows targets. I kept receiving 413 "request entity too large" errors when trying to execute the request. As it turned out, I needed to initialize the .data field of the URLRequest object to quell the 413 error. I'm not sure why a null data field would cause a "request entity too large" error, which is why it took me a while to figure out. I ended up finding the solution by looking up libcurl issues of a similar nature, since that's the library used by NME.

Key Handling

Flash and Windows targets for NME seem to trigger different key codes for ascii characters. I ended up writing special handling code to convert all key codes to uppercase so each platform interpreted results consistently.

Mouse Handling

I ran into issues getting any mouse scroll wheel events to fire on Windows. I didn't pursue this very far, though, as I could work around it, and had bigger fish to fry.

Extensibility

There were one or two instances where I started digging into NME source code itself, to see if I could work around problems I was having (such as enabling unexposed TextField properties). However, I was unable to navigate the matryoshka-doll-like layers of code to the source I needed.

Specifically, I was trying to expose a field in TextField, like caretIndex, so I could hack together a copy/paste stopgap on Windows. I decided to look at how existing fields were exposed, like .numLines. When I dug into the TextField.hx class, I found that Windows targets used the neash.text.TextField implementation.

However, the neash.text.TextField code redirected .numLines to:

Loader.load("nme_text_field_get_num_lines", 1);

Loader.load uses cpp.Lib on Windows targets, so looking into that, I found that cpp.Lib.load used:

__global__.__loadprim(lib,prim,nargs);

which was loading a primitive from a DLL. I wasn't clear where to go from here, though. It seemed like there should be some sort of table or Rosetta stone for mapping strings like "nme_text_field_get_num_lines" to a block of code somewhere, but no amount of searching seemed to reveal it.

I was pretty frustrated by my inability to get to the bottom of that question. And ultimately, had to switch targets to Flash to get the TextField behavior I needed. Though, that in itself is a pretty strong endorsement for Haxe NME.

Cross-Platform

Being able to change a drop-down from "Windows" to "Flash" was almost all that I needed to do to get around the aforementioned TextField issues. That, and some tweaking in the way I accessed dynamically-named fields of a Dynamic object, had me well on my way to continuing work with almost no interruption. Literally, a couple weeks' worth of development on the Windows target was ported to the Flash target within about two hours. Pretty impressive.

Updates

It's also important to point out that NME is updating fairly frequently. Even in the couple months between the version of NME I first downloaded, and one I recently downloaded, there was significant improvement. In fact, several bugs I was encountering were solved by an update to NME 3,4,4.

Conclusion

I'm still pretty impressed with what I'm finding in NME. It has gaps here and there, and it can be tricky to find support. But I was surprised how far I could take it, given it's relative infancy compared to platforms like Flash. I suspect that if I were making a purely game-like app, without the need for text editing, it would do all that I need without issue. I think that the only feature NEO Scavenger uses which I've not yet tested is the audio playback.
Hopefully, some of the info I've shared above helps other intrepid developers in overcoming similar obstacles. And it'd be great if this info was enough to embolden a few new developers to put Haxe NME through its paces. I truly feel that it's a powerful tool, and just a few more concurrent users could be all that's needed to sustain further growth.

By the way, if you're interested in a more chronological account of my explorations, you can find out more about the editor overhaul in these Blue Bottle Games posts:

• Encounter Editor Overhaul
• New Editor Progress
• New Editor: UI Widgets
• Encounter Editor: UI Almost Ready
• It's Alive! (Almost)
• Encounter Editor Running, Plot Work Resumed

Thanks for reading, and see you next time!

Haxe NME: First Impressions

I've been talking a lot of business the past few months, so I thought I'd mix things up a bit this time. Today, we'll talk about Haxe NME.

What is Haxe NME?

Haxe NME is two things, really, so let's start with the first part: Haxe.

Haxe (officially pronounced "hex," though I tend to pronounce it differently), is a multi-platform, open source, programming language. Using a syntax similar to Java or Actionscript 3 (AS3), one can compile applications to a wide range of platforms, including:

• C++
• C#
• JavaScript
• Flash
• PHP

This, in turn, means that one set of source code can ostensibly be made to work on PCs, browser plug-ins, devices running iOS, Android, Windows Mobile, and webOS.

You might be thinking, "big deal. Java and Flash/Air already make that possible." For the most part, that's true. One difference, however, is that Haxe compiles into other languages, including ones required to make native applications. Java and Flash applications, on the other hand, are interpreted through a virtual machine (VM) on their target platforms.

With Haxe, one can write a single set of code for multiple platforms. And in theory, applications developed in Haxe have the ability to run much faster than VM-based applications like Flash, Java, and Air. It also means that Haxe apps can access features unavailable to some VMs, such as local file access and hardware acceleration.

And NME? What's that?

NME stands for Neko Media Engine, and is a library/framework for use in Haxe. It provides an API that looks a lot like Flash's (literally, many API calls are just a matter of replacing import flash.display.* with import nme.display.*), which can be used to deploy native apps to Windows, Linux, Mac, iOS, Android, webOS, BlackBerry, and Flash Player.

Haxe generates C++, which NME then compiles into the desired target platform's native code. The output applications use native components, such as OpenGL, libjpeg, curl, etc, to provide performance and features like what one would expect from writing platform-specific applications.

In a nutshell, it purports to generate blazing fast native apps on nearly every platform, using a familiar, AS3-like code and API. Even the compiling is simplified, requiring only that the user specify "flash," "windows," "ios," or any of the other target keywords to generate the desired native application.

Wait, are you porting NEO Scavenger to Haxe NME?

No, not yet. It's true that there would be performance benefits, and it would open up some handy local file access, modding, and other neat features. But switching technology mid-stride would be a pretty big risk. It would be a large undertaking, cause lots of down time, and there's no guarantee it would work.

However, NEO Scavenger's encounter editor is in need of an overhaul. Currently, it's built into the game, so that it can piggyback on various data-loading features already in place. That worked fine for the first couple hundred encounter nodes. It was slow to move things around, but I could mostly edit what I needed to.

With the recent influx of random encounters, though, there are over 750 nodes being displayed. And with each of those having UI elements to display, Flash just can't handle it. In fact, Flash can't even finish loading the data before it times out. I could rewrite the data loader to segment across frames (as I recently did for the save game load method), but I'm pretty sure that even after loading, the editor will be unusably slow.

So the editor is going to require an overhaul, one way or the other. I could do that in Flash, but I'll definitely be limited by rendering speed. Haxe NME should be faster, provided I can port things over. And it'll give me a better idea of whether it's worth building anything else in Haxe NME.

I've given myself a time box of a few days, in order to determine whether it's worth proceeding, or backing off and returning to Flash for the editor changes. So far, I've made enough progress over two days to encourage further work in the Haxe NME direction. Though, it wasn't without it's obstacles.

Transitioning from AS3 to Haxe

I'll start with an unqualified success: syntax familiarity. Transitioning from AS3 to Haxe has been trivial. There are some differences, but by far, the syntax feels very familiar. A large amount of the differences can be done with a search and replace, and the ones that can't weren't hard to figure out.

In fact, if you're using Haxe to target the Flash platform, that's about all you have to worry about. All of the API calls one used in AS3 are pretty much the same in Haxe. I was able to get a project compiling and debugging in FlashDevelop with about the same level of effort as a regular AS3 project.

Write Once, Run Anywhere?

Unfortunately, compiling code for non-Flash targets wasn't as easy as advertised.

For really basic applications (ones that use very few API calls outside of flash.display), worked well-enough. My editor used some drawing functions to make arrows and boxes, and these were well-supported. In fact, I was so emboldened by my first test app that I copied the editor's source over from AS3 wholesale, and started porting code. It was when I started delving into non-display libraries that things got ugly.

NME lacks a UI library like Flash's, so that was my first hang-up. There are some UI elements built-in, such as simple buttons. But complex items, such as drop-down boxes, radio buttons, and scrollbars were missing. Some effort has gone into UI libraries for Haxe and NME, but they're not as smooth to use nor as complete as what AS3 users will be used to.

Waxe looked like a pretty good place to start, but I quickly became stuck. For one thing, it seemed to be at odds with the NME way of displaying things, so it wasn't clear how to get them to play nice. The documentation was pretty sparse, too.

Joshua Granick's NME GUI library turned out to be a better fit, and covered much of what I'd need. However, it was still (apparently) missing a drop-down box, which was the UI item that I was currently stuck on. I decided I could probably make something work using basic UI building blocks, so put UI on hold while I vetted some other features.

NEO Scavenger uses some Flash URL libraries to request data from a server, and populates some tables in memory for running the game. The editor piggybacks on this code, in order to display encounters, their images, game items that connect them, and some other bits.

Unfortunately, compiling a C++/Windows target didn't seem to work, even though the Flash target did. And this is where we encounter a potential deal-breaker.

IDE Debugger Support

While the debugging process was identical to Flash development when deploying a Flash build, this was not so when trying the Windows target. There is no support yet for FlashDevelop IDE debugging a Haxe C++ target. There is a C++ debugger, but that is a command-line tool. One can set breakpoints in code, and it will pause, but then the user must interact with the debugger through a console.

One could also use on-screen text or trace, but as someone who suffered Maxscript's lack of IDE debugging for nearly seven years, I wasn't happy about the prospect of tracing my way out of bugs.

One thing I haven't yet tried is compiling the C++ output in Visual Studio, and debugging from there. Theoretically, that seems like it should work. The down side, however, is that I'm debugging C++, not the more user-friendly Haxe syntax. And worse, I'm debugging a target, not the source.

I looked around for quite a while, trying to figure out if I was missing something. Maybe another IDE was a better fit? Maybe I just didn't install hxcpp correctly?

In the end, I turned up little information to guide me through this problem. And that may be the other major flaw in Haxe and NME.

Documentation

Haxe and NME have documentation, first of all. I don't want to make it sound like you walk away from the Haxe and NME websites with a box of tools and a noose.

In fact, Haxe has pretty extensive documentation, if we're being fair. Quite a few of my questions, particularly about object types, syntax, and language features were all answered there. And there is a growing amount NME documentation out there, too.

However, if you're a Flash developer, the current state of Haxe NME support is going to be a cold splash of water. Forget about typing a few keywords into Google and getting reams of documentation and examples to choose from. Worse, if you have a really specific question in mind, there's nowhere near the same chances of finding the answer posted someplace, unlike one does with AS3.

As I struggled with getting the nme.net API to work on the Windows target, I had to turn to a mix of old and new skills to find my answer. 

The "old" part involved brushing the dust off my Maxscript debugging skills: tracing output, and displaying debug variables on-screen. It's clunky, and trace often doesn't output anything until the Windows target exits, but at least it's possible to tweak and get some feedback without having to jump between IDEs.

The "new" skill was learning to seek out answers to library and API issues in non-AS3 (non-Haxe, even) sources. When a URL request failed, I could dig up useful help around the web on libcurl, the library NME wraps in a Flash-like API for URL tools. It gave me more insight into why my specific case was failing. I could see, for example, what C++ devs would do to fix their issues, and then adapt those solutions to NME.

Based on the state of C++ debugging and documentation, I was almost ready to give up on Haxe NME, relegating it to the realm of "would be nice if it worked." However, pushing through those issues has given me some new-found courage. Enough to consider continuing my investigation, rather than retreating to AS3.

Haxe NME: The Verdict

Is it worth it? Is porting to or building in Haxe NME worth doing? That'll depend a lot on your aversity to risk. If your already using AS3, can handle some uncertainty, and have wiggle room for learning a new system, the benefits of speed, portability, and more features are quite tempting.

If, on the other hand, you need a predictable timeline, or reliable support, you may want to wait. Haxe NME sidesteps much of the cost of learning C++, but its relative youth means you'll be on your own from time-to-time.

For me, I've seen enough potential to warrant further investigation with the editor subset of NEO Scavenger. I was able to overcome the major obstacles so far, so I feel that I will be able to continue progress in the face of future issues. And in the worst case, I only stand to lose whatever time I am willing to devote to it. I can always return to AS3 if all else fails.

I'm interested to see how Haxe NME pans out. Currently, it stands in a sort of middle ground between Flash and Unity3D. On the Flash end of the scale, one has accessibility of development, wide consumer deployment, and cheap-to-free costs, but more limited output paths and performance. On the Unity3D end, one has fast and powerful capabilities on a very wide range of target platforms, but significant costs in terms of software and revenue share.

Haxe NME seems to offer the best of both at no cost, but does not yet have the community support and tools of the other two packages. Fortunately, that situation seems poised only to improve over time. If more people decide, like me, to give it a shot, we may see that community support reach a tipping point.

Interesting times may be ahead!

Thoughts on Game Design and Vision

A few players have recently expressed some frustrations with NEO Scavenger, which brought up some questions about core design. In particular, the concerns centered around the combination of permadeath, save games, and randomness.

Game Design

The frustrations stem from the game ending, irrevocably, as a result of chance in-game hardships. I think most players would agree that investing significant time into an RPG character, and then losing it to a die roll, is a real buzz-kill. Some will sigh and re-roll a character, others will walk away for a while, and still others may rage quit, never to return. Whichever is the case, such an occurrence in-game is poor game design. Instead of the player suffering a penalty due to poor choices, they suffered due to bad luck.

A powerful storytelling tool. Also, sucks when it happens to you.

In defining NEO Scavenger, I eventually settled on the idea that I was making a single player computer RPG that could simulate many of the experiences had in a pen and paper RPG session. And many of the game's systems are successes in that regard. For example:

1. players can customize their character
2. there are multiple ways to use the player's skills and items meaningfully
3. there are elements of strategy and tactics
4. there are setting and plot elements to discover
5. there are options to role-play moral choices. 

With the addition of a permadeath save feature, it's even possible to save progress, walk away, and return later: just like one does in a role playing session with friends.

One thing NEO Scavenger lacks, however, is a game master (GM). A good GM does many things in a session. From creating the story, to arbitrating the outcome of conflict and struggle, the GM is a human element which ensures the game is fun for the players. And when an unlucky die roll threatens to spoil the game, a good GM can find ways to fudge the outcome, or interpret the roll in a way that adds drama, rather than removing the fun.

Unfortunately, when misfortune strikes in NEO Scavenger, there's no such GM to ensure the player is having fun. And quite often, this misfortune is game-ending. So, what can be done to fix this?

Save Games

On a few occasions, players have suggested save games as a way to mitigate this problem. With checkpoints and save slots a common feature in many games these days, I can see why. It's an easy way to ensure a player's invested time is not lost. Like an insurance policy, the player can resume where their last save left off, minimizing the amount of time spent replaying existing content.

However, as I've discussed before, knowing one can just reload the game at any time robs the game of two powerful tools: fear and consequence. Thankfully, most players seem to be on board with this philosophy. They enjoy the game exactly for this hardcore nature, and diminishing that would diminish the game as a whole for them.

(Incidentally, players who want to can still circumvent the save-delete by making a copy of the save file, a la Nethack. I'm happy to leave this intact for players who really want it.)

Ultimately, I want the player to have the convenience of playing when they want, but I don't want to use save games to fix what may be a design flaw in the mechanics. So if save games are just a band-aid, what's the actual problem?

Randomness

From the outset, NEO Scavenger has leaned pretty hard on randomness. From random map hexes, to random combat outcomes, Math.random() was a crutch I used liberally.

Randomness isn't inherently bad, mind you. It's a pretty valuable tool for making the game interesting more than once. It can provide fresh environments to explore, a seemingly deeper AI, or random bouts of luck or misfortune to tip the scales of drama.

However, too much randomness can be bad, especially where life and death of a player's character is concerned. If a player feels like their choices don't matter, and that the game will simply reward/punish them at random, then they won't enjoy the game. Or, at least, the type of player I'm building this game for (i.e. me) won't.

Note to self: These are decision-making tools, not decision makers.

One of NEO Scavenger's earliest failures was combat. There was a random chance of injury imposed on the player for participating. In many cases, that injury was instantly fatal.

Players reported feeling that the game would randomly kill them, and felt frustrated because there were no mitigating strategies. One simply hoped for a good outcome each turn. In fact, most simply chose to ignore and avoid combat entirely, instead focusing on more rewarding and enjoyable areas of the game.

Fortunately, we were able to identify this, and we found ways to make combat more interactive. We gave the player more verbs in combat, and more nouns for them to act upon.

Instead of a short "overall injury" meter, the player now had multiple wound locations, blood supply, pain, and infections to manage. Instead of deciding whether to "hit" or "run," the combatants now had additional moves they could choose from, like "trip," "tackle," or "lure into trap." And the addition of situational factors, such as terrain, morale, cover, lighting, and stance, meant that the player could opt for different strategies as the battle changed.

What this did was allow players to see trouble in its early stages, and gave them time to deal with it. There was still randomness, but it was relegated to minor victories and losses. The overall life and death of the player was largely in their hands, and they were left to choose when a reward was worth the sacrifice.

This is still a weak point for NEO Scavenger, and effort still goes into finding ways to strengthen it. I think we're on to something, though. In the linked example above, I think we've identified some tangible causes of frustration, and we're discussing in-game solutions that might help. It has a familiar ring to it: games are more fun if the player's choices determine victory or defeat, not random chance.

Replayability

While randomness is surely a weak point for NEO Scavenger, there's one other area I'm keeping an eye on. That area is the replayability, especially in the early game.

If a player is afraid of dying, that's a good thing, in my mind. It puts them in the right frame of mind for enjoying this game of survival, and making each decision count. It's what most players cite as their reason for enjoying NEO Scavenger, and it enhances the thrill of the game.

However, some players have reported feeling turned off when dying, to the point that they do not want to play again. This might point to a separate problem, one which has more to do with the fun factor in the early portion of the game. In other words, it seems that if the early game was lots of fun, players probably wouldn't mind dying as much.

For example, I'm always willing to start a new game of Civ 4/5 or Galactic Civ II. The early game is one of my favorite parts. There are even times when I'll cut an existing game short so that I can restart.

Mind you, I still enjoy the mid-late games too. But I never feel disdain as my civilization starts to collapse, because I look forward to the next go.

In fact, that was often the case for me with pen and paper RPGs, too. Rolling new characters was "half the fun" for me. I loved exploring other strategies, backstories, and those first few struggles to get one's feet.

I'd like that to be the case for NEO Scavenger, too. So when players say that the Game Over screen gives them pause, I start to wonder if NEO Scavenger's mid-late game is the compelling part, and the start is just a barrier. Is there something really fun happening just before death, that the player is trying to get to as quickly as possible next time? Is the early game too boring or tedious?

So far, when I've asked about this, the general response is that the early game is ok. And frankly, the game is probably short enough that there's little to no mid-late game anyway. Still, it's on my mind. More something I'm monitoring than actively working on.

Perhaps addressing the randomness issue will have an effect on the early game? If players feel more enabled, and that their choice caused death, they'll be more engaged in the character building process? Or perhaps the character building process itself is too limited? Perhaps there's not enough encouragement to experiment?

One thing at a time, I guess. Changing too much at once can muddle the results, so we'll deal with the obvious problem first. Perhaps the way forward will be more obvious after this obstacle is cleared.

NEO Scavenger's First Bundle

I almost forgot to write today! Must be the Thanksgiving leftovers messing with my brain :)

Selling NEO Scavenger via Bundle

NEO Scavenger was included in it's first bundle last week. The bundle is called Be Mine 5 (BM5), and is put together by Groupees.

The general idea is that customers can buy the following 3 games for any price they want, with a minimum of $1:

1. NEO Scavenger
2. King's Bounty: The Legend
3. X-Blades

Spending at least $5 rewards the buyer with the following:

1. Tropico 3
2. Oddworld: Stranger's Wrath HD
3. The Sixth Gun Vol 1 (pdf graphic novel)
4. Sharknife: Stage First (pdf graphic novel)
5. Wasteland Vol. 1: Cities in Dust (pdf graphic novel)

Every few days, they announce new goals, such as mp3 albums at 6500, or additional games at 8500 units sold.

Revenue is split among the developers/writers/musicians, and a 20% cut goes to a charity. In this case, it's MercyCorps.

Wait, Isn't NEO Scavenger Still in Beta?

Yes, it is. I told myself I'd wait on participating in bundles until later in the dev cycle. Perhaps once it was gold and sales had died down. In fact, I gently turned down the first invite from Groupees (as I did with other bundle providers).

Looking over their previous Be Mine and other bundles, they regularly net about 5k units sold. 10 on more successful runs. Some even quote dollar amounts, which was helpful. I estimated that an average run for them was about 5k units sold, at about $5 per unit.

Given the number of titles per bundle (~5 games, plus 3-8 books and albums), and that 20% goes to charity, I expected the revenue share to be pretty low. And running the numbers, it was probably on the order of a few thousand dollars.

Just to be clear, a few thousand dollars is nothing to shake a stick at. That pays rent, utilities, and groceries for a month or two. But I was afraid of what revenue I'd be giving up selling at pennies on the dollar. What if this saturates my market? Would I be selling myself out of future revenue for a short burst now?

On the other hand, that's potentially 5000 new people playing the game. Potentially 5000 new people talking about it. In exchange for the majority of revenue per copy, I get more copies sold, and more publicity. And as many indies have already figured out, raising awareness is at least half the battle.

"What the hell," I decided. I was pretty sure there were more than 5000 people out there who'd buy NEO Scavenger. In fact, I'd bet there could even be 50,000, judging by some voodoo napkin math when looking at Playtomic play stats, Steam Greenlight votes, sales, page hits, etc.

When Groupees got back to me, I decided to ask for more info. Their offer was about what I expected, though their sales expectations were much higher. (They originally had some lofty titles in negotiation, which probably skewed those estimates.) A few emails later, I decided to sign the contract.

So? Was It Worth It?

As is always the case with data at Game Dev Gone Rogue, things are still developing :) 

The BM5 bundle launched last Thursday (Oct. 4th) at midnight. The offer runs for 2 weeks, so we're coming up on the end of week 1. As of this post, the bundle is selling better than my expectations, and more in-line with their other Be Mine bundles:

Figure 1: Not bad!

Of course, units can sell for as little as $1. However, the highest donation so far was $425, and with a bonus offered at $5, I expect we'll see an average price of $4-5 per bundle.

Web traffic also increased. The BM5 promotion roughly doubled visitors over the past few days:

Figure 2: Also not bad!

Given that the BM5 site doesn't directly link to bluebottlegames.com, that's pretty cool. It means a lot of people are bothering to learn more about NEO Scavenger than usual.

"Wait, BM5 doesn't link to your product page? What gives?"

True, this might seem a bit counter-intuitive. Though readers who have run promotions before won't be too surprised. The point is to sell bundles, and raise money for charity, first and foremost. So it doesn't make sense for them to lead viewers to another purchase option directly. 

However, they were good enough to direct-link to my Greenlight page. And the effects were pretty staggering:

Fligure 3: Blowing the average out of the water.

This is what game authors see on their Greenlight dashboard. It's a graph showing voting trends over the past week, compared to what an average top 100 game in Greenlight gets. The tiny green slivers on Wednesday and Thursday are what I'm used to seeing.

Following the BM5 launch, though, NEO Scavenger skyrocketed to four times the top 100 average, and is still holding at several multiples above what it used to be. What's more, NEO Scavenger ascended ranks from #71 to #62 in a matter of days. As a Greenlight promotion tool, BM5 was an unequivocal success.

So What About Sales?

What about the thing that scared me? Did the bundle cannibalize sales?

So far, that's a definite "no." In fact, I'm still watching the data to see if it might actually be the reverse. Sales at Desura appear almost unchanged so far. They're the usual spike-and-trough I've been seeing in days previous to BM5.

Sales through bluebottlegames.com, however, have either not changed or increased (depending on the weekend effect). These direct sales fluctuate a lot, even before BM5, so it's hard to pinpoint cause and effect. What I can say is that the days following BM5 have been better than average, but not-quite-media-event big.

Conclusion

Am I glad I did it? I am, actually. I won't know for some time whether there were any cannibalizing effects, and what the final tallies are in terms of sales and publicity. But it has definitely helped in the past few days, and might be just the kind of surge needed to level-up NEO Scavenger's success.

Plus, I was treated to some really entertaining mini-reviews of NEO Scavenger in unsuspecting players' hands:

MagSlug
It's like a Choose Your Own Adventure book combined with the early "explore the world" phase from a Civilization game combined with that one scene from They Live where Keith David and Rowdy Roddy Piper beat each other up in an alley.

or this pair:

Robert Miller
Who cares? As an indie bundle addict with hundreds of steam games I've never touched, I can say that Neo Scavenger is by far my favourite game in this bundle. It's tons of fun, even if it is still in Alpha and incredibly difficult.

nickelpat
Robert: I feel the same way. I bought it for Stranger's Wrath, but thought "Ah, what the hell, might as well check out this non-Steam piece of crap game." Yeah... still playing it.

Encouragement doesn't pay the bills, but it definitely feeds the soul :)

Every indie game and studio needs different things, so this isn't a one-size-fits-all case. But it's yet another valuable tool to consider when growing a brand. There's no doubt that bundles are a fast way to ratchet up awareness of your game. And it gets you a small boost in income.

On the flip side, it's sales at a fraction of the revenue you're probably used to. Especially if you sell your game in the double-digit dollar range.

I'll probably shy away from doing more bundles in the near future, at least until NEO Scavenger gets further along. I have a feeling that even in successful cases like this one, I would see diminishing returns from overusing the bundle approach. I'd like to try out some other tools before coming back to bundles.

However, I'll definitely be looking into bundles for later in the NEO Scavenger sales cycle, as well as for future titles.

The Week of Hardware, and Sales Follow-up

I bought my first Mac last week.

Gone Rogue Going Mac

I've been a PC user since the early 90s. Before then, I owned an Atari ST (and an 800, prior to that). My dad occasionally brought home his work IBM, and my friends all had IBMs (or compatibles like the Franklin), so I had some exposure even when I was an Atari owner. And my schools always seemed to have Macs/Apples, so I've had my fair share of Mac exposure as well. But I've leaned in the Windows direction for decades.

However, once NEO Scavenger was released on Desura, I was on the hook to make good on my multi-platform promises. Flash had served me well to-date, but Desura doesn't sell Flash games. It sells downloadable applications. So it was time to accelerate plans to acquire some Mac hardware.

Deciding on which Mac to buy took a bit of research. Any old Mac would probably do for creating Flash projectors. However, if I'm going to drop some cash on a Mac, I figure I should look into what else it could do. iOS development, for example, requires an Intel-based Mac running OS X Snow Leopard or later. And since my Windows laptop is from 2001, and chugs even when running Lubuntu, maybe I can dual-boot the Mac as my Linux box.

Ok, so Snow Leopard and up, Intel-based Macs. My search begins.

First of all, new Macs are expensive. The cheapest new Mac is the Mac mini, starting at $600. And that's without any display nor input devices (I'd need a KVM or similar setup to share my current PC's monitor and inputs). The next cheapest option for a new Mac is $1000+ for a MacBook Air.

So what about Apple's Certified Refurbished program? Surprisingly, that's not much better. The minimum price there is $700 for a MacBook Air. Granted, that's cheaper than a new Air, but for an indie on a budget, who just needs a beater to generate Mac binaries, that's still too much. I'm thinking sub-$500.

Off to eBay, kijiji, and craiglist. A ha, that's more like it. MacBooks in the sub-$500 ballpark. There are even some Pro models in there. In the end, this is the route I take. And for $500, including shipping, here's what I got:

Dan's first Mac: a 2008 model MacBook Pro

 As you can see, it's been around the block once or twice. Maybe even fell onto the curb. But it runs fine. The dent is cosmetic, the "D" key needs re-seating, and apart from some scuff marks and an aging battery, it's in good shape. A few days of finagling later, it even dual-boots OSX and Lubuntu.

So what do I think? I'm still pretty new to the world of Macs, so it's too soon to be sure. But here are some initial impressions:

Pros

• Slick Design - Without a doubt, this is a very well-designed piece of hardware. At every turn, I can picture Steve Jobs hovering over the engineer's shoulder, pushing for uncompromising perfectionism. The way it latches shut, the back-lit keys, the machined parts and shape of it...it's an industrial designer's dream.
• Everything Works - Probably related to the above, it just works. There are no missing drivers, no features that sometimes fall short. Everything you expect it to do, it just does, out of the box.
• UI - It takes some getting used to, coming from the PC world, but the UI is well-designed. The trackpad scrolling, accessibility options, brightness control...I was impressed at what control I had over these little things.

Cons

• Expensive - One could already guess this from the previous paragraphs. Macs are downright pricey. Even used ones seem to suffer from the inflation of the Mac brand.
• Closed Ecosystem - I don't like the "closed" feel of the Mac world. They're harder to upgrade, they have proprietary connectors for everything, they can have unfriendly customer relations, and they seem to have an inordinate fear of users accessing their own data. Did you ever have a friend who's parents were OCD about decorating? You know, like everything was wicker and crochet, tables had doilies on them, and the bathroom towels are not meant to be used? This is what using a Mac feels like to me.
• UI - As much as I praise the UI above, it has its quirks too. Like the right-click. Ok, I get it. Macs are different. They don't need a right mouse button. Except that's not true. Context menus are everywhere in OSX, and I have to double-finger-tap my trackpad to get at them. Why is this? And what's with the app install process? Is it really more user-friendly to download, then mount an image, then drag an app from the left side of a pop-up to the right, instead of double-clicking a file and following prompts?

Like I said, I have a lot to learn when it comes to Macs. So far, though, I like it overall. It won't replace my PC anytime soon, but I enjoy playing with it. And it finally means I can deploy Mac and Linux builds!

Why You Shouldn't Deploy Mac and Linux Builds

Ok, that's not really what I'm saying. But I want to caution indies out there who are gung-ho about multi-platform. 

When I was only deploying Flash versions to bluebottlegames.com, a build was a matter of maybe 30 minutes. It involved changing some compiler constants, switching from debug to release, compiling, uploading, and maybe doing those steps a second time for the demo as well.

Now that I have downloadable versions, the build and upload process takes hours. It's literally most of an afternoon to get all SWF versions compiled (Flash beta, demo, and downloadable beta), then create projectors for all three platforms, then create the Desura MCF versions (their build management system), then upload them all.

So if you're thinking of distributing multi-platform, either be prepared for build headaches, or find a way to build more efficiently than I do.

You could also just wait until later in the dev cycle to release to the public, but I wouldn't. Having NEO Scavenger out there and in the hands of actual players has been an amazing help in shaping the game that we have today. Like the Agile philosophy of always having a working build, this goes a step further to put it in the hands of the end user. Sure, there are sometimes speed bumps along the road, but I wouldn't do it any other way.

Other Hardware Fun

Also, within a few days of getting my MacBook Pro, this happened:

Bench testing my PC for faults.

My video card went kaput. I got some fuzzy blue dots, then everything froze. Subsequent reboots yielded strange ascii characters in the BIOS, then eventually, nothing.

It took about a full day of testing and research to narrow it down to the video card. It was fairly obvious, based on symptoms, but I wanted to be sure before I made the trip for new parts in town.

And better yet, my primary HDD started clicking within a day of getting the new video card. I spent almost another half day checking backup data, and probing the HDDs for faults. Both checkdisk reports came back ok, and the clicking has since subsided. But I have a new 500GB HDD sitting in anti-static paper on my desk, just in case.

As I said to readers at bluebottlegames.com, it's like I drew a card in a board game. "Hardware failure! Pay $200."

It was an expensive week, let me tell you. But it's good to have the PC running again, and to know that my target platforms are covered now.

Desura and Greenlight Follow-up

Last week, I talked about the effects of Desura and Greenlight on revenue. Before I depart today, I want to provide some follow-up data. Here's how things are looking, two weeks later:

Daily gross revenue in USD since launch.

The main thing we're looking at here is at the far right. Not surprisingly, the Desura and Greenlight launches produced a short-lived spike. I expected as much, so I'm not too disappointed.

However, the thing I was keen to see was how this spike differed, if at all, from the initial launch spike. Interestingly, I think the spike has about the same width as the March launch spike. It's not as high, but it lasts about the same amount of time: about 2 weeks.

Both spikes have tails beyond 2 weeks, of course, but that's an interesting figure to keep in mind if you're launching or making a big announcement. Expect roughly 2 weeks of activity to result from a PR push.

I'm also interested in seeing how long tail sales are impacted by the additional Desura channel and Greenlight PR. It's a bit soon to tell for sure, but so far, there's an additive effect. It's not quite enough to tread water, financially, but it helps.

That about does it for this post. Maybe someday I can create another sales spike, and do a follow-up with Android/iOS ;)

The Effects of Desura and Steam Greenlight

It's been about 5 months since I last spoke about NEO Scavenger sales. The playable demo and beta are both pretty advanced, compared to the game that released in March. And with its recent debut on Desura and Steam Greenlight, it's starting to get a lot more attention.

Since I've seen some folks discussing the impact of Greenlight on indie games, I thought I might share some (thinly veiled) data to illustrate my experiences.

How is NEO Scavenger Doing?

First up, how is NEO Scavenger doing? And for that matter, Blue Bottle Games in general?

NEO Scavenger development started way back in May 2011. It was almost a year before I was able to launch the beta, opening it up for pre-sale. Here's a snapshot of what that means, in terms of finances:

Figure 1: Daily gross revenue in USD since development started.

There are some interesting spikes in there, but the large majority of the past year and a half are low-to-zero income. That purple line represents my cost of living: paying rent, buying groceries, utilities, etc. It's missing a few spikes of its own, for things like software licenses, service fees, hardware, and such, so the cost is slightly higher than depicted. But it's good enough for comparison.

How do the peaks and troughs compare?

Figure 2: Revenue vs. Cost to-date

Unfavorably, I guess you'd say. We're still a long way from recovering our investment. However, NEO Scavenger has been selling more than cost of living during the past week. And while it's likely to be a spike similar to the first one (visible in Figure 1, around March 2012), it's possible that the additional sales channel of Desura means the subsequent trough may be closer to break-even cost of living per day.

Did Greenlight Affect NEO Scavenger Sales?

Yes. However, it's hard to say by how much. Here's a better look at the lead-up to Greenlight launch:

Figure 3: Daily gross revenue in USD since August 16, 2012

Prior to August 16th, I hadn't done too much to promote NEO Scavenger. I primarily published news on bluebottlegames.com, which folks either followed directly, or read about on their forum of choice (primarily Something Awful forums).

However, on August 16th, I started integrating with IndieDB and ModDB, and publishing news there as well. Here are some details on the lettered annotations in Figure 3:

A - Launched on IndieDB.com/ModDB.com. First news item published, and product page started.
B - Launched on Steam Greenlight.
C - Launched on Desura, and offered for sale.

As you can see, the IndieDB news was a pretty subtle effect. There were a few postings in the following days, and it started to create momentum, but it was hard to distinguish from the regular sales behavior.

Steam Greenlight caused a pretty significant surge, however. Over that whole weekend, awareness increased, and sales with it. It was a welcome financial shot in the arm.

Desura also caused a boost in awareness and sales. It's hard to tell if it's as great as Greenlight was, but it definitely caused its own spike. And what's more, Desura sales seem to have surpassed my own website's performance.

What's the Big Picture?

Figure 3 shows us some interesting data points, but what do they mean? Well, look back at Figure 1. Better yet, here's a zoomed-in version of it:

Figure 4: Daily gross revenue in USD since launch.

Greenlight was good, but take a look at that spike in March. What was that? Looking over Google Analytics, that month's biggest contributors were:

Figure 5: Top referrers to bluebottlegames.com in March 2012

Rock Paper Shotgun was the leader by far, followed by Something Awful forums, YouTube, and IndieGames.com. Of course, not all of these referrers were definite sales, and as you can see by the gray portion of the pie chart, a large number of folks arrived via no referrer (i.e. direct URL).

That month was also the world's first taste of NEO Scavenger, so it likely had a larger proportion of visitors who were not yet customers.

Conclusion

So far, Greenlight has proven to be a valuable marketing tool, if nothing else. It drove a significant number of sales on its own, and the comments on the Greenlight page have served as a welcome ego boost. What's more, calculated approval rates appear to be growing slowly. They're only at 2% now, but it's good to see them grow over time. Perhaps once NEO Scavenger is ready for prime time, the votes will be nearing critical mass.

One unfortunate downside to Greenlight, however, is the lack of direct linking to my product page. I had to present a link to my demo as plain text in my Greenlight page, which means users must type the link manually to see it. I'm betting a significant number of users are lost to this barrier, despite their interest.

Additionally, Greenlight is still sorting out discoverability issues. People need to be led directly to my NEO Scavenger page there to know it exists. There are a few brave souls who browse the games, page-by-page, rating them all. But I suspect most are too tired to slog through the hundreds that are presented.

Desura has also proven to be a valuable partner. As a sales channel, it may even surpass my own website's. No doubt this is due, in large part, to the existing customer base and ease of reaching them/deploying builds. I'm very interested to see how it's sales performance changes over time. Will it prove to be another flash in the pan? Or, fingers crossed, will the additional sales channel help push NEO Scavenger daily revenue up to sustainable levels?

Finally, don't underestimate traditional coverage. RPS, Something Awful, and the other major players can really help to get the word out. In fact, this most recent surge in traffic is also largely driven by non-Steam sources, such as PC Gamer, The Indie Stone (Project Zomboid forums), Reddit, and RPGCodex. There's definitely a synergy effect going on, too.

It's a ton of work keeping up with the various sites that mention your game, but it's totally worth it. Show them you appreciate them, and they'll do the same!

Flash as a Native App

Just a heads-up: Readers of news at the Blue Bottle Games website will find much of this info to be familiar. It's an expanded version of the post from last Thursday. I wanted to share it here, as it may be useful to readers interested in publishing their game in Flash.

Last week, I mentioned I'd be looking into creating a downloadable version of NEO Scavenger. It turns out that's a bit more complex than I expected.

After nearly two full days of research and experimentation, I think I've got a way forward, but it isn't as elegant as I had hoped.

Why Flash?

Before I get into how, let me briefly speak about the why. Part of the reason I chose Flash as a platform was because a lot of people on the web have the Flash plugin. Adobe propaganda aside, it's probably one of the single largest install bases for game platforms in the world. People can just visit www.bluebottlegames.com and try the demo with little to no effort.

If I had chosen C++, C#, XNA, or any of the native application types, I'd have to present a "download" link, and people would have to:

1. Trust me
2. Download my game
3. Install/Launch my game

It doesn't sound like much, but those three things cause an enormous drop-off in the number of people willing to try a game. Each of the above is a barrier to entry. The first is a trust barrier, the second a patience barrier, the third a laziness barrier.

As a rule of thumb, I estimate 50% of interested people just say "screw it" and move on to something else when presented with a barrier. There's some leeway, of course. Clicking a link is a smaller barrier than fishing out a wallet to pay for an app. But I assume I'm losing customers with each step along the way to trying my game (and selling my game). So minimizing that flow is important.

With Flash, the game just appears in the webpage. Players can pass a link to a friend, and all that friend has to do is click the link to see the game (and potentially wait for it to download).

Using Flash also means I can deploy the demo to Flash portals, to help spread the word. Plus, there's the unplanned bonus of people being able to play NEO Scavenger at their workplace, even in places that prohibit installing apps!

The down sides? It has a few, to be sure. This week, it's figuring out how to create downloadable versions for distribution on services like Desura and Steam.

Flash as a Native App

There's a way to make Flash into stand-alone executables. Several, in fact. However, as I'm discovering, each has it's own idiosyncrasies.

Flash Projector


The simplest, most straightforward way to get a downloadable version of Flash games is to create a projector. Just fire up the stand alone Flash player, load your swf, and "save as projector." Easy! Or is it?

Pros:

• Easy - As above, just load the swf in a stand-alone player, and click File->Save as Projector. Voila! Native app created.
• Cross-platform - The process works on PC, Mac, and Linux.
• Packaging - The process makes a single executable. Neat and tidy.
• Proven - Examples include Machinarium, VVVVVV, The Binding of Isaac.

Cons:

• Hardware - You need a Mac and a Linux box to create those versions. I only have a PC at the moment. I can probably get Linux running on one of the machines in my house, but Mac is out of my reach for the time being.
• Sandbox - Save files must use the unintuitive (to a user) Flash SharedObject system, and can be deleted via browser cache/cookie clearing. (It's possible the fscommand() method offers a way around this, but I need to research it more.)
• Mods - Modding support may be hard to setup in the future, if the projector cannot access local files.

Adobe AIR Projector

I could also create Adobe AIR projectors. AIR is Adobe's solution to cross-platform software. It's designed to allow a developer to create a single .air file which can be presented as a link in a webpage. Clicking that link on any platform launches the appropriate processes to download and install a native executable for the user's platform (including installing AIR, if necessary).

It also provides a means of creating native apps for each platform, which can be downloaded and installed like most traditional software. This bypasses the need for AIR on the user's machine, but creates a somewhat messy install (see below).

Pros:

• Fairly Easy - Making an AIR app isn't as easy as making a Flash projector, but it's not too hard, either. Using FlashDevelop, it's possible to setup an AS3 AIR Projector project, import your source code, and follow the auto-generated readme to tweak the batch files needed for publishing. Compile to swf, then run the "packager" batch file to make the app. Some research into the packager parameters is needed to make .air vs native .exe/.dmg/.deb files, however.
• Cross-platform - Output works on PC, Mac, and Linux*. In theory, it also supports Android and iOS, though I haven't looked into it much yet.
• Sandbox - Local file access means save games can be safe from browser flushing.
• Proven - Proven examples include Defender's Quest.

Cons:

• Hardware - While generating an .air file can be done from any platform, and the output works on all destination platforms*, generating native apps still requires native hardware (Mac to generate .dmg, Linux to generate .deb, Windows to generate .exe).
• *Linux - As of 2011, Linux is no longer supported for the .air path. The native apps approach still works on Linux, but generating a working .air file for Linux involves some heavy tweaking using older AIR versions.
• Packaging - Both the .air and native app outputs generate an installer which must be executed, and this throws up all kinds of ugly prompts on most machines. Also, both paths will generate a messy collection of support files alongside the application.
• Licensing - You may need permission from Adobe to distribute AIR installer. Looking into this, it may only be the case when including AIR's installer on its own with your download, and the .air and native app approaches may sidestep this. Still, it's a consideration, and that kind of legal complication is an effective deterrent to adoption, if anyone at Adobe's reading this.

Port NEO Scavenger to HaXe

While researching cross-platform distribution, it's impossible to miss HaXe. Purporting to "write once, deploy anywhere," it may sound a lot like Java. The difference is that HaXe not only compiles directly to multiple platforms, it compiles into other languages, including C++, C#, Flash, JavaScript, and soon, Java.

There's even a framework within HaXe, NME, which smooths the transition from Flash even further. It's a pretty impressive tool. However, it's a relatively young platform, meaning its community support pales by comparison to AS3. It's also just different enough from AS3 that it would mean a lot of rewriting of code.

Pros:

• Packaging - Produces actual native apps. No virtual machines.
• Cross-platform - Works on PC, Mac, and Linux (and iOS, and Android, and Flash, and...)
• Sandbox - Local file access means save games can be safe from browsers, and mods are supported.

Cons:

• Hardware - Need a Mac and Linux OS to generate native apps for those platforms.
• Effort - I would have to rewrite huge amounts of code to port to HaXe. As mentioned above, AS3 and HaXe (NME especially) are close, but not close enough.
• Support - As a young(ish) platform, community support is still pretty small. It can be harder to find answers to questions as compared to AS3/Flash. 

3rd Party Wrappers

There are also some third party wrappers out there (e.g. Zinc, SWF2EXE, mProjector). However, their reputation appears to be mixed. Some claim support is poor, others say the performance is bad, some don't even support all platforms. And then there's the price tag. With many of them costing several hundred dollars, I might as well buy a used, Intel-based Macbook, which not only lets me develop for Mac, but iOS devices as well.

Conclusion

Is there a conclusion? Not yet. No silver bullet, anyway. My likely approach for now is to actually go with the simplest option: the Flash projector. It generates native .exe files that work right now, and I can probably get Linux running on one of my PCs to do a .deb version. If sales pick up, I can probably justify $500 for an old Macbook to compile Mac versions.

And since I'm still in beta mode, the downloadable file will be updating with each new version. It's not too hard to swap in an .exe generated via another means when I need to. It's just the easiest working path open right now.

If you're looking for more info, here are a few links to resources I used in my research:

1. Making Flash EXEs (Terry Cavanagh's VVVVVV research)
2. Flash to EXE Projector Help (Leans towards projector)
3. Packaging a desktop native installer (Adobe AIR documentation)
4. Lone Survivor Linux Woes
5. Flash for Downloadable game. Some tips? (Projector vs. AIR vs. HaXe)

Hope this helps some Flash devs out there. If you have any additional info or corrections to add, post in the comments!