Game Dev From the Ground Up

Recently, some of the players on NEO Scavenger's forums posted a request for advice on how to start making games. I've talked quite a bit about bootstrapping indie game development here, but a lot of my focus has been on the business aspects. I do mention tools and techniques here and there, but they've been spread across two years of posts, and are often directed at a somewhat more experienced crowd.

Today, then, I thought I might take a bit of time to walk newcomers through the field. There's a ton of info out there. And sometimes, that can be just as bad as there being no info out there. How does one know they're following advice or tutorials that will lead anywhere? What if one follows a tutorial, only to find that it dead-ends somewhere down the line?

As it turns out, there's both good and bad news here. The bad news is that false-starts are common. Even experienced devs are lured into dead-ends. Technology is an ever-shifting field, and games even more so. It's easy to commit time and resources to something that won't pan out, and that's par for the course.

The good news is that there's usually something to be gained from such failures. This is particularly the case for beginners, where every step is contributing to new skills and perspectives, if not the end product. When one is a complete beginner, there's nowhere to go but up.

Where to Go for Info

As already mentioned, there are billions of places to get info on developing games. Google searching can be a bit daunting:

Better make some coffee...

So how does one know where to start?

I considered compiling a list of indie development resources, but then I remembered that someone has already gone through the trouble. In fact, many people have:

1. Pixel Prospector maintains a gigantic list of indie resources. It's probably one of the most comprehensive lists on indie game development tools, techniques, and wisdom, collected from around the web. http://www.pixelprospector.com/indie-resources/
2. TIGForums is one of the more active independent developer forums. Subforums abound, covering every aspect of development, including creative, technical, business, and tutorials. http://forums.tigsource.com/
3. Gamasutra is a major source of all things gaming, with a focus more on the developers than consumers. There is a vast catalog of knowledge here, including news, tutorials, GDC videos, jobs, and op-ed. http://www.gamasutra.com/
4. StackExchange is probably one of the most valuable places to know about when trying to find the answer to a technical question. The questions and answers are usually of high quality and value, owed in part to their curation and voting mechanisms. Many of my epic quests for esoteric programming or technical knowledge end here. http://stackexchange.com/
5. Daniel Cook's blog posts are also a good place to read about game design, business, and the craft in general. Aspiring indies who struggle with art may be particularly interested in his article about sourcing game graphics. http://www.lostgarden.com/2008/07/directory-of-posts.html

Some folks like sharing what they've learned, which might make this a good time to mention an important lesson I've learned: see if someone's already done the work for you. The internet is a pretty amazing thing, giving us near-instant access to a growing proportion of all human knowledge. When it comes to game development, a lot of the problems (most, in fact) are ones that have been tackled before. It's worth doing a quick search first, just in case someone's already saved you the trouble.

Which Tools to Use

Choosing a platform, engine, tools, or project management method is like choosing a religion: fanatics are everywhere, and will try to sell you on their favorite. But in the end, just about any of them will teach you something, even if it's that religion isn't for you.

Again, I'm going to harp on Pixel Prospector. One of the first links they list covers a vast list of tools and engines. Read what people say about them. And more importantly, look up what people are building with them. There's no greater proof of a tool's validity than the thing it was used to create.

What did I learn on? Well, this:

Computers can do ANYTHING

I also learned by copying BASIC code from Antic magazine into an Atari 800, and watching the results go. Also, trying to emulate Leisure Suit Larry as a text app in my junior high computer class, using BASIC on an Apple IIe. And taking a "programming for engineering" course at univeristy. And buying 20lb "Learn 2 Program" books from Barnes & Noble, and copying their C-code into engines like Allegro. And writing Flash apps for my web development employer. And following Microsoft's XNA banner for a while.

The point of my telling you this isn't to say that I've had a lot of training. Most of the above was better described as "flailing," or maybe just "failing." And even the things that did succeed became obsolete with time. Technology comes and goes fast, as do platforms.

The point is to learn something in the process. All of the above taught me bits about how computer programs work, how information is organized, how logic controls data in an application, and how bitmaps work. Sometimes those lessons were learned while modding Dark Reign. Other times, I wrote code that put pixels on the screen in a starfield, and I moved them about in sloppy for-loops.

What's my tool of choice? I'm a fan of Flash's Actionscript, and flixel. Actionscript is a c-style, object-oriented (OO) language, which is a good type of language to learn. Many game-related technologies are c-style, OO languages:

• C/C++
• C#
• Objective C
• Flash
• Unreal/UnrealScript
• Java
• HTML5/Javascript
• PHP
• Perl
• Haxe/OpenFL (a.k.a. NME)

Learning one is usually a good head-start in any of the others.

Flixel is a game engine built on Flash actionscript, and is a good balance of existing systems and free-reign to do what I want.

Would I build my next game in Flash/Flixel? Probably not. Flash is starting to limit me in some ways, and I'm looking towards Haxe and HaxeFlixel as a next step. It takes a lot of what I like about Flash and Flixel, adds some powerful abilities to it, and frees it from the clutches of Adobe (and the Apple-Adobe-Android wars).

That said, building something in Flash/Flixel now should put one in a good position to transition to HaxeFlixel later. They're similar enough that learning one teaches most of the other.

Hello, World

And once you've chosen your tools of choice, what then? Should you write an epic design doc, plan out all the facets of your game, and start building?

I'd focus on "Hello, World." If you can get code to compile and display that phrase on the screen, there's nothing stopping you from writing "Health = 100," or "You are standing in an open field west of a white house, with a boarded front door."

Or simply print some ascii art, and let the arrow keys move it around the page. Or maybe write some text about how much candy you have. Or how your dwarves feel.

The point here is that once you've got something displaying on the screen, the rest is just tweaking and watching the results. NEO Scavenger was originally a sprite of a man, and clicking a button moved that man closer to a dot. Each time he moved, his sleepiness went up. If you clicked another button, he slept, and his sleepiness went down. I kid you not.

So choose a tool, any tool. Search Google for:

tutorial "hello world" <tool name>

and don't give up!

Sometimes, Running a Business Stinks

The past 72 hours been a pretty wild ride. And it's highlighted some of the less glamorous aspects of running an online business. I think things are starting to stabilize this afternoon, but I'm pretty exhausted from the experience.

Things Were Running Smoothly When...

Friday was a pretty normal day. Quiet, even. Most of the day was spent working on plot development for NEO Scavenger. The day didn't go without it's hitches, but as days go, it was nothing unusual. I was happy to finish the day with some plot knots to untie over the weekend, so I wrapped-up, had some dinner, and Rochelle and I went bowling with some friends.

The next morning, I was pretty excited to see a sudden spike in traffic in my logs. NEO Scavenger was mentioned in a post apocalyptic survival reddit post, and dozens of folks were popping by the site to check out the game. Cool!

Site Maintenance

Except, my ISP was doing scheduled maintenance early Saturday morning. It wasn't until I tried loading bluebottlegames.com that I realized it was down.

5-day Site Visitor Graph: Hourly

Well crap. That stinks. Just as a bunch of new folks are drawn to check out my game, the site goes dark. And worse, dark for close to 12 hours.

"Oh well, " I said. It's a bummer, but nobody's fault, really. I mean, I guess I could blame myself for not having a redundant server or something, but I'm not that high tech (or deep-pocketed). I decided to just live with it. Besides, friendly Reddit server take-downs were nothing new. Folks probably would just figure my little server was flooded temporarily.

Site Flakiness

Later that day, bluebottlegames.com was back up and running. I did my usual email and forum check, to verify nobody was reporting any issues. And all seemed clear.

Except for one thing: every other page load seemed to turn up blank. No error message, no content, nothing. Just a blank white screen. Refreshing the page seemed to fix it, so I figured it was a temporal thing. "It'll sort itself out."

No, it won't. The following day, I was replying to a customer having issues with NEO Scavenger on their Mac, and it was still happening. Happening everywhere. Sometimes it was a content page on the site. Other times it was a forum. Even some of the site admin pages were failing. And as before, usually a reload would fix it. But the reloading was becoming less and less reliable. Sometimes, I had to reload the page 4-5 times to see anything. And if my customers were seeing the same thing, then that was unacceptable.


The White Screen of Death

I decided to dig into the issue a bit more. I started searching for related issues on the web, and was initially happy to see others reporting the same issue. Blank screens in Drupal (the content management system I use, v6.28) were pretty common. Maybe finding a solution will be easy?

However, upon further investigation, I was less happy to discover I had the same problem. This problem, as it was known to the Drupal community, was the "White Screen of Death."

The WSOD is a common issue with Drupal, but it doesn't have a common solution. In fact, there are almost as many causes of the WSOD as there are Drupal installations, and finding the right one for you can be a real quest.

The link above is probably the biggest authority on the issue, and even there, there are no less than 28 different causes listed in the article, and some 80+ comments detailing other issues customers have had. Basically, Drupal's WSOD is a symptom of practically every Drupal disease. I'm having trouble thinking of a human analogue. Headache? Fever? Common cold?

I spent hours on Sunday trying to make rhyme or reason of it. None of the remedies I saw seemed to help. I couldn't even get error or log messages. And worse, it was an intermittent problem, so I couldn't even reliably cause it to happen.

The only things I could verify about it were:

1. I only get the WSOD on my live server. Migrating the db from live to my localhost didn't duplicate the WSOD issues.
2. I only started getting the WSOD since my ISP's scheduled maintenance, when the server was (apparently) upgraded/restarted.
3. I only get a WSOD in Chrome.
4. Additionally, Chrome seemed to exhibit stylesheet issues when the page did load. Textareas would be too narrow to fit their <div>, or the page would nudge upward when I clicked a link (seemingly to adjust alignment with the Admin Menu module's topnav bar). Something was stalling the css until I clicked a link, upon which it would fix itself, then load a new page with stalled css (or js, or WSOD).
5. Firefox never exhibits any issues.
6. IE seems to work too, except for one page partially loading (later determined to be a known issue with YouTube embedding)
7. No errors appeared on the page, in Drupal's logs, nor server logs, even with error reporting hard-coded to be on in index.php.
8. Using Chrome's "Inspect Element" context menu option revealed that the page was entirely missing the <body> tag and contents. It was just an <html> and <head>, and the <head> seemed to be missing some elements. Also, Chrome usually complained of "Failed to load resource" on the page itself, but all css/js/images were loaded ok.
9. Using "View Source" on Chrome apparently reloaded the page, and showed the correct, full content source.
10. The WSOD appeared more frequently when js and css optimization was turned on (but still occurred when all Drupal optimization/compression/caching was disabled).
11. Flushing all caches had no effect.
12. Running update.php had no effect.
13. Manually truncating Drupal db tables had no effect.
14. Using Backup & Restore on Drupal's db had no effect.
15. Disabling all modules outside of Core and Core Optional had no effect.
16. Switching from BBG's custom theme to the Garland theme had no effect.
17. Rebuilding permissions had no effect.

By the time Sunday evening rolled around, bluebottlegames.com was stripped down to core modules, no theme, no caching, and had a rebuilt database. And it was still flaking out.

Worse, the node access modules I disabled caused the permissions table to get out-of-date, which caused all site content to disappear for all users, all the time. Basically, when the WSOD wasn't happening, all of the site's pages were empty blue shells, and the forums all had 0 posts in them.

Even worse still, to rebuild the permissions and fix the empty content, I had to run a script via Drupal. And that script failed with a WSOD whenever I attempted it.

I had totally messed up my site. The "Site Crash" label in the above image refers to the time when I took the site offline to avoid any more users seeing the empty shell of a site.

Fortunately, Firefox was able to run the permission rebuild script without any WSOD. And I was able to at least get the site showing content again.

But as my efforts continued past 10pm, I decided it wasn't going to be solved anytime soon. I started making changes necessary to return the site to the formerly flaky intermittent WSOD. It wasn't ideal, but the occasional user reload was a far cry better than no site at all. If nothing else, I wanted the forums and contact page online for users to report issues, if needed.

I posted a news item to the homepage alerting customers to the WSOD issue, and apologized for the inconvenience of the downtime. Then, I went to bed.

Come Monday, It'll Be Alright

I was back at the computer at 6:15am. And unsurprisingly, the site hadn't fixed itself. I fired up the usual websites, checked messages, looked for forum posts. Some users reported seeing similar WSOD issues. And, bless them, they blamed their internet connection instead of me.

I decided to try a different approach this time. Instead of grasping at straws offered by forums on the net, I decided to debug Drupal. I added print statements to Drupal's index.php, to see if I could trace the value of the content. And when that failed to reveal anything, I started adding traces to Drupal's core code (*.inc files).

I don't like doing this sort of thing, as I'm nervous about screwing things up worse than they are. Plus, doing it in a way that doesn't affect the live site's users is tricky. But in retrospect, it's the only way to really know what's going on.

I found a function in bootstrap.inc which loads various Drupal bits in phases: drupal_bootstrap($phase). Every page on a Drupal site calls this function first, doing a full bootstrap (all phases). I added a trace inside the while loop that executes for each phase as it loads, and I printed the ID of the phase.Testing on my local site, I could see that my site loads phases 0-8.

When I uploaded the modified bootstrap.inc file to the live server, I saw traces for all phases. Reload. All phases again. Repeat this another dozen times, on different pages where I most often encountered the WSOD. Everything loads normally.

Was the WSOD gone?

Tentatively, I backed out the bootstrap.inc changes, so it was back to normal. Still, the site seemed to be loading ok. I reenabled caching to normal. Still ok. Turned on page compression. Still ok. I stopped short of turning on optimized js and css. Maybe I'll muster the courage for that tomorrow.

A Wizard Did It

So what happened? Uploading that file seemed to stop the WSOD, and leave it fixed even after that file is restored. What dark magic is this?

That's actually my first theory: dark magic. But if you pin me down for a more mundane answer, I'm going to guess it was some sort of behind-the-scenes cache. I'm not sure what else would explain a site's complete performance alteration when a single file is uploaded and then un-uploaded again.

That was at about 11am today. As of 5pm, I haven't seen a WSOD. Mercifully, no players have posted in the White Screen tech support thread on my forums, either. I'm hopeful this issue is resolved.

But What About That Mac User?

Oh yeah, remember me mentioning way up there that this whole investigation started when trying to help a Mac user with NEO Scavenger? Yeah, Mac compatibility is an issue in it's own right, concurrent with the site debacle.

I'm not going to detail that issue here, as it's a pretty lengthy topic of it's own. The forum thread linked above has all the details. And what's more, I've partially touched on it in the past.

The short version is this: Flash is rapidly becoming as much a burden as a boon. For someone trying to develop a stand-alone application, I'm at the point where I am highly reluctant to recommend Flash as a viable option. Issues include:

1. "Create projector" no longer supported on Linux, as of v11.2.
2. Flash CS6 no longer supported on OSX 10.8.
3. Any projectors one does create are going to trip security on modern OSes. And in Mac's case, Gatekeeper is a sticky issue for OSX 10.7.3 and 10.7.4.
4. Digitally signing Flash projectors appears to have spotty support, unless one uses 3rd party wrappers (which are, in themselves, reportedly unreliable).
5. Adobe's recommended solution, building AIR apps, is unsupported on Linux. Also, AIR's installation process is flawed, at best. Also, AIR has the periodic "Update AIR" nagging dialog.
6. Flash is no longer officially supported on Android nor iOS.

I was a long adherent to Flash. It served me well. NEO Scavenger wouldn't be if it weren't for Flash's ease of use, and then-universal deployment options.

So it's unfortunate that this era appears to be in it's winter.

All's Well That Ends Well

The good news? At least we're back to normal. The site seems to be running again. Upgrading OSX to 10.7.5 seems to fix Flash projector Gatekeeper woes until I can find another way to certify projectors. I think I may actually be able to return to plot development tomorrow.

Let's just hope that stretch of actual game dev continues for a while!

On Resolution and Fonts

I wanted to talk a bit about screen resolution and fonts today. A larger resolution and font has been one of the most requested features in NEO Scavenger, and it has come time to do something about it.

Where We Are Now

NEO Scavenger currently runs at 800x600 resolution. Back when I was first making the decision on resolution, I chose 1280x800, half my monitor resolution, so I could see full-screen with 2x scaled pixel art. Shortly after that, I switched to 1280x720 (720p), to better align with standard HD.

However, since NEO Scavenger was originally intended as a portal-sponsored title, I decided to scale it down to 800x600, using 1x scaled pixel art. It was a tough decision (I liked the 2x scaled look), but it made better business sense at the time. (Portals typically have an upper limit of 800 pixels for game width.)

Outside of the portals, though, 800x600 is a pretty restrictive resolution. And while NEO Scavenger can be played in resizable windows, the nearest-neighbor scaling can make things pretty ugly. So if players want to see NEO Scavenger in a larger format, what resolution makes the most sense?

User Statistics

Before deciding on a new resolution, I thought it would be helpful to see what most users have. Unfortunately, that's one statistic the in-game NEO Scavenger metrics don't track.

However, one benefit of running one's own storefront, and hosting one's own game, is that I have website logs to turn to. It's not as good as tracking that info from within the game, but it's pretty close. So I opened up Google Analytics to take a look:

Figure 1: Total Visits Sorted by Screen Resolution

Hm, that's not as clear-cut as I had hoped. The top 10 resolutions only cover about 57% of all users. Worse still, look at the lower right hand corner. That's right, there are 1336 different screen resolutions used to view bluebottlegames.com! (Also, damn! Missed it by one!)

Ok, so it looks like we'll need to do some data-slicing and bucketing.

Aspect Ratio

What about aspect ratio? Overall screen size may vary quite a bit, but surely most are either standard (e.g. 4:3) or widescreen (e.g. 16:9), right?

As it turns out, between the various device types (LCD monitors, laptops, netbooks, tablets, phones, index spiders) and display configurations (portrait vs. landscape, single vs. multiple displays), there are ~400 aspect ratios in the logs.

Fortunately, this is their distribution:

Figure 2: Histogram of Aspect Ratios

In other words, only a handful of aspect ratios are in significant quantity. And if one looks closely at the values along the x-axis, many of these aspect ratios are only marginally different. So I ran some algorithms on the data to group things further.

First, I grouped identical displays with different orientations, so portrait and landscape orientations were combined (with the largest dimension reported as width). I realize this may not be perfect, since users who prefer their monitors in portrait mode may not be willing to rotate their screen to fit a wide game screen.

However, since NEO Scavenger is a landscape-oriented game, accommodating portrait mode on most monitors would restrict the game screen considerably. It's current width of 800 pixels would already break the limits on many monitors. Besides, I suspect most gamers will have a landscape orientation, as that's how most games are designed.

Second, I grouped similar aspect ratios such that there was a +/- 8% tolerance in the final aspect ratio value. For example, 1.7708 and 1.7778 would be in the same group, but 1.6 would not. Doing so reduced the spread considerably:

Figure 3: Histogram of Aspect Ratios, 8% Tolerance

Now we're starting to see some familiar faces. 16:9 is the HDTV ratio, used with displays that are meant for 720p (1280x720) and 1080p/1080i (1920x1080), as well as many widescreen computers and tablets (e.g. WXGA). 4:3 is the SDTV ratio, which was common in older televisions and desktop computers, such as 1024x768 (XGA), 800x600, 640x480, etc.

16:10 is also quite common in desktop displays, as well as many tablets. And 5:4 is a common ratio found in many non-widescreen LCD displays.

Five buckets is a much easier dataset to digest. And fortunately, the answer seems pretty clear: the vast majority of users (~80%) are on a widescreen aspect ratio.

Screen Size

So what about the actual screen sizes? Assuming I decided on a widescreen format, what size would fit the largest number of users' screens?

To answer this, I took the most common 16:9, 16:10, and 4:3 resolutions, plus a handful of other common resolutions from the top of the web logs, and calculated what percentage of users could display each size without cropping. Here's what I found:

Figure 4: % Users Supported at Various Game Resolutions

Again, it looks like we're pretty fortunate. There are 5 screen sizes that would each support 90% or more of my site's visitors.

480x320 is there because it was one of the top 15 screen sizes, but it's a bit deceptive. It's actually a common smartphone screen size (e.g. iPhone, BlackBerry, etc.), so it's not likely players of the game as much as web surfers. Furthermore, the number of users in this screen size only account for about 1% of all users. They just have a tightly-grouped bucket. Like I said, deceptive.

That leaves us with 800x600, 1024x768, 1280x720, and 1280x768. I'd really like to do a widescreen format, since the data shows that most users have that aspect ratio. However, both the 1280x720 and 1280x768 formats would leave ~10% of the site visitors with a squashed or cropped screen.

However, as I'm mulling over these values, a thought occurs to me.

Steam User Data

Each year, Steam does a hardware survey of its users, and publishes the results. And with over 6 million concurrent gamers at peak, that's a lot of useful data.

So I grabbed their screen size data, did some number crunching, and applied the same filters and sorting as above. Here's what I found:

Figure 5: Histogram of Aspect Ratios, 8% Tolerance (with Steam)

Figure 6: % Users Supported at Various Game Resolutions (with Steam)

First of all, it's good to see similar numbers. I can't say for sure if my calculations are accurate, but at least they're precise :)

Once again, we see that widescreen is a big winner. And in fact, the gap between 16:9 and 16:10 is more pronounced. Perhaps even more heartening is that the top two widescreen resolutions are more widely available to Steam users. Just about 95% for 1280x720, and 94% for 1280x768.

The "Right" Resolution

So what's the "right" resolution for NEO Scavenger? I'm leaning towards 1280x720. Knowing that widescreen is more widely supported than not, I'd prefer to chose a widescreen format. The question is, which one?

Of the widescreen formats, it seems 1280x720 (720p) and 1280x768 (WXGA) are the two most viable. 720p is slightly more widely supported than WXGA in both my and Steam's users, so that's one reason to prefer that format. 720p also seems like a more standardized format, since it is the HDTV standard, and many devices are designed to support it for that reason (tablets, consoles, projectors, etc.).

The main reason to go with 1280x768 would be to get the extra vertical real-estate. However, when looking up screen sizes, it occurred to me that many 16:10 devices are computers, and this extra vertical height might be a design response to the OS taskbar. It's possible that designing software for 16:9 still fits a 16:10 monitor better, since it leaves room for tabs or other OS UI.

I can also see that 16:9 outstrips 16:10 considerably, in pure aspect ratio terms. It would seem that no matter the reasoning behind 16:10, 16:9 simply has more reasons to choose it.

So, 720p it is.

What About the 10%?

Unfortunately, choosing 720p still makes life difficult for 10% of my users (or 5% if you judge by Steam's numbers). What about them?

And what about the Flash portals? I'm always saying how I'd like to publish NEO Scavenger's demo on portals for broader awareness. Won't this screw that up?

It does. And to the question prior: I'd like to support them too, if possible. So my current plan is to see if there's some way I can setup the UI to work in both 800x600 and 1280x720 modes. It's a daunting task, since the available real-estate is quite different. And it means storing either two different sets of coordinates and zoom, or else some sort of UI-scaling rules.

Neither are going to be trivial. But I think it's at least worth trying.

And What About Fonts?

Right, I mentioned fonts too, didn't I?

Fonts are another area that needs improvement in NEO Scavenger. More than a few users have complained of eye strain trying to read the tiny pixel font in NEO Scavenger.

I'd like to just bump up the font size, and be done with it. However, the font I'm using is actually a custom made one. So simply scaling it up won't make it clearer. It'll still be pixelated, because that's how it was designed.

I briefly started toying with 3rd party fonts, like Arial, Verdana, etc., but then the question of licensing popped into my head. I did some research, and for a moment, thought I was in the clear. Then I saw a comment that gave me pause.

So I did some more research, and then it seemed like I was in the clear again (search for the string "SWF" in that last adobe.com link). Unfortunately, after an hour-and-a-half of this ping-pong, I was only learning one thing: font licensing is in a state of hell, and I want to have nothing to do with it.

My current leaning is to just eat the time cost and make my own font again, just for a larger size this time. The only thing that bothers me is that I don't want to "guess and check" a bunch of times if each time means designing a font. They don't take too long to make if you know what you're doing, but I can't afford to make 15 different fonts just to find out each doesn't look right.

So what I may do is use well-known fonts to gauge the size and style I want, then go make my own in the same style and size.

Scaling

Lastly, a note about scaling. Whatever screen size I choose, it won't fit everyone's screen. So when the game goes to full screen, it won't always be a perfect fit. So I have some choices to make.

The first one is whether or not to scale at all. I think this one's a given. Some folks just want to zoom in, and see things bigger. So I plan to make the game scale up to fit the full screen, but maintain the aspect ratio, using black to pad the extra space. I'll probably also add an option to just leave it at 1x zoom with black bars at full screen, for those who want it (should be trivial to add).

The second is what type of filtering to use. Up until now, it used the default flixel nearest-neighbor filtering. This type of filtering produces clean, crisp images when zooming in whole increments (e.g. 2x, 3x, 4x). However, fractional zooms (e.g. 1.5, 2.1) produce horrendous artifacts. This is likely the source of many font complaints so far.

I could switch it to use bicubic (or similar) filtering. This would make things look smoother when scaled, but would also introduce blurring. I opted not to do this originally because it's usually better used on photos than pixel art.

However, it may be an improvement over nearest-neighbor if I am to allow non-integer scaling of the game (which is likely, given the wide array of screen sizes in use). I think other games, even pixel art games, are doing this nowadays, too.

And then there's the question of whether to change fonts when scaling. This might be overkill, but it might look better if graphics use one filter, and fonts another. I haven't tested it out yet, though.

For now, I'm getting things setup for alternate screen sizes in the code, so I can start testing these ideas. I welcome any advice or experience on the matter!

2012 Retrospective

With the ringing of the new year, I thought it might make sense to look over the previous one, to get a sense of where I've been, and what that might imply about where I should go next.

January 2012

Twelve months ago, I was just becoming a Canadian permanent resident. After months of sitting on my hands, it was time to start making things official. I still had a lot left to do before launch, but I could finally submit paperwork and other requests, and start on the process of making my dream business a reality.

NEO Scavenger already looked pretty much like how it does today:

January 2012 vs. January 2013

January 2012 vs. January 2013

However, despite the shared map and item graphics, quite a lot changed under the hood. These changes are only hinted at by some of the UI differences shown above.

NEO Scavenger finally got its logo:

And it also received an overhaul to its scavenging mechanic. Prior to 2012, scavenging involved visiting a hex, opening the inventory screen, and hoping there were items on the ground. Not exactly the most engaging mechanic, especially considering it was the namesake for the game.

Skill selection was finally becoming more like what we see now, instead of this:

Nominated for most intuitive UI of 2011.

The inventory screen was changed to rely less on ctrl and shift clicking, instead using "modes" triggered by visible buttons. The UI also got hotkeys for the various screens and modes.

I implemented Playtomic for metrics, which was a partial success. The basic stats are still useful, though the more complex stats I setup are not very usable. A preloader was added, which is still used today. SecureSWF is likewise still pulling its weight as a code obfuscator. And save/load was in its infancy.

January was also the month when I decided on NEO Scavenger's final business model. Until this point, I was expecting it to be launched under the sponsorship model. I also decided on feature voting, as a means to gather measured user feedback.

The game switched from 1280x800 (arbitrarily chosen as half my monitor's screen resolution) to a more universal 800x600 (palatable for game portals). Finally, I added site-locking as I prepared to put NEO Scavenger out there for people to test.

February 2012

In February, I began piecing together all the necessary components for launching a business on the web. Quite a bit of time was spent on everything from creating a website to setting up a payment provider. It was a month filled with more business work than game, though I still managed to cobble together some new in-game items, new artwork, and a spate of newspaper loot with back-story snippets to read.

March 2012

March marked the public launch of both NEO Scavenger and my company, Blue Bottle Games. 9 months after starting development, NEO Scavenger was available for all to try and pre-purchase.

And with that launch came the stresses of running a public-facing service company. I had to quickly adapt my schedule to balance development with PR, and adapt my psyche to the ups and downs of public opinion. Fortunately, most of that opinion was positive. But it was still a bracing experience.

March also marked my first taste of revenue. It started small, then surged wildly with some press coverage, then settled back down to a stream. Fortunately, that stream continues to this day, and even had a few additional, albeit smaller, spikes along the way.

April 2012

In April, sales settled into their steady state, which was (and continues to be) a little less than cost of living. This shrinking of a major launch spike caused some existential concern. As it turns out, this question of "when is it 'done'?" never goes away. It just changes circumstances and specifics over time.

I was also faced with my first major public game design decision: permadeath and save games. I ultimately decided to keep the game more rogue-like in that permadeath means save games are deleted. Months later, I'm glad I did. It was a decision which could have drastically altered NEO Scavenger, and I'm glad that it was altered in a way that keeps it challenging, unique, and with some later tweaking, fun.

I also started to formalize my PR policy by the time April came around. Fortunately, I wasn't faced with too much internet hate, but the hate I did receive forced me to grapple with my rules of engagement. Put succinctly, ignore attacks, and focus on being constructive and responsive to those that are constructive.

In development of the game itself, the camping and night/lighting features were big items. They were the first major features, in fact. Lots of loading/saving fixes were required as well. And the website and order process had some growing pains to resolve.

May 2012

During the month of May, blog posts focused on more meta-topics such as tracking data and money-saving tips, to keep overhead costs minimized.

Development of the game, on the other hand, was in full force. As I would soon discover, plot is hard to do. For nearly a month, all that readers saw coming down the wire was "did more plot work today." I don't enjoy phases where there's little to share with fans, but I also don't want to spoil the fun by revealing the story out of order.

Encounter Editor

Fortunately, there were a few updates sprinkled in to keep folks entertained. One such change was the chase, which opened up various new gameplay tools for tracking and hiding AI. The oft-requested pockets were also added.

And May is also when I started working with my first collaborator: Cameron Harris. His input to both design and plot has been a real asset, and I believe NEO Scavenger is a better game for it.

June 2012

I was on the road for part of June, so activity was a bit limited. It did give me a chance to try out developing on the road, and to see how poorly I was prepared.

Still, a lot got done on NEO Scavenger in June. In particular, I made my second major decision: to work on improving combat ahead of schedule. Combat was pretty poor in early versions of NEO Scavenger. Its dependence on luck made it more frustrating than fun.

New Combat UI

By the end of June, combat had a new face, and it was far more tactical and engaging. It also included some improvements to AI.

July 2012

In July, I started lamenting my poor work and exercise habits. While I feel my workaholism has improved (I took 2 weeks off at Christmas, despite the temptation to only take 1), I'm still short on exercise. I made my second, and more serious, dip into the world of business accounting. And I was approached by Desura for inclusion in their service!

With the new combat system launched, I began work on a wounding system that would integrate with the extant player conditions, and offer opportunities for resourcefulness and strategy in dealing with wounds. I would argue that this suite of combat and wounding systems was one of the more important changes to NEO Scavenger so far, as it greatly enhanced the game's uniqueness, depth, and fun factor.

July is also the month where I began working with my second collaborator, Josh Culler. Josh's music has added a wonderful sense of atmosphere to the game, and has been very effective in promotional trailers as well.

August 2012

August was the month of getting ready to launch NEO Scavenger on Desura. For the first time since March, the demo gets an update to reflect the new features and content. NEO Scavenger also got its first trailer. A lot of research goes into making NEO Scavenger downloadable.

With those fulfilments complete, I began the Desura application process. Coincidentally, Steam Greenlight launched that same month, and within 24 hours, NEO Scavenger was added to Greenlight!

NEO Scavenger also had combat fleshed out with new moves, terrain resources (e.g. water, wood), and a new encounter to allow players to return to the cryo facility and make a permanent base.

September 2012

With the Desura and Greenlight launches done, I decided to do a mini retrospective. In it, I look over some of the sales stats to-date, and how both launching on Desura and Greenlight affected them.

I also officially enter the Mac and Linux realm with my first Mac hardware. $500 netted me hardware I could create Mac binaries with, as well as dual-boot Linux for that version.

I also had a few hardware failures, which cost some time and money to isolate and fix, but were thankfully minimal in impact otherwise.

NEO Scavenger gets the ability to delete items, a new thank you postcard design, and work begins on random encounters. Josh's first batch of in-game music is also added.

October 2012

NEO Scavenger is featured in its first bundle. While a success by most standards, I decide that I'll probably wait until after v1.0 is done to do another, and turn down subsequent bundle offers accordingly.

Player frustration mounts, and the question of game design and permadeath resurfaces. I decide to take a long look at the game's design, to see where it might be failing. I still want to keep permadeath and NEO Scavenger's rogue-like qualities, but I also want to offer players the tools they need to overcome adversity. It is likely to be an ongoing balancing act.

The process of plot work remains slow and grueling, with little to show while in progress. However, I finally finish entering data for the random encounters. The Desura website gets the ability to connect owners there to accounts at bluebottlegames.com.

Work begins on one of the most deceptively difficult bugs in history: item stacking.

November 2012

With random encounters increasing the encounter node count above 750, the encounter editor fails to start anymore. I begin rebuilding the editor in Haxe NME, partially as a solution to the above performance issue, and partially as a test to see if NEO Scavenger is worth porting to NME. The results are pretty good, but there are a few stumbling blocks. I decide that NME holds promise, but I might wait a while before porting NEO Scavenger.

The stacking change continues to ripple bugs into mid-November, but finally works. The mouse is upgraded to take advantage of new Flash plugin features: hardware mouse and right clicking. Plot work resumes in the new editor.

DMC City Map v1

I also needed to take a step back to revise overall plot and mythology. And once course-corrections were in place, it was time to start work on opening the DMC to players. A lot of the work revolves around the map used to represent the city to players.

December 2012

As work continues on the DMC content, I focus the blog on more business related musings. I take some time to discuss my policy for customer relations, and how to avoid stressing out over release schedules.

Work on the DMC map continues, adding both detail and animated VFX for interest. Rather than releasing a full screenshot of it, I decide to do a teaser with one of Josh's new music pieces for the city.

I briefly start thinking about currency, then exercise some discipline and decide to focus on higher priorities: city encounters. Finally comfortable admitting the DMC will not be ready for Christmas, I decide to take a player's suggestion to release some wallpapers instead.

Desktop Wallpaper of DMC

Looking Back, and Looking Forward

It was a good year, overall. I had some good successes, made some mistakes, and learned some big lessons. NEO Scavenger earned more than I expected, but less than I hoped. It's poised for success, though, as long as I keep working hard.

The biggest issue I see, moving forward, is determining when to consider NEO Scavenger finished, and to move on to the next project. I'm resolved to release it this year, and have been telling myself and others that spring is the timeframe. Spanning that last stretch, and finishing with the right suite of features will be a big decision.

But as I go into 2013, I am more seasoned and confident, and I have optimism for the year to come. I'll no doubt make new mistakes, but also surmount new obstacles and claim new victories. Here's to acknowledging the past, and looking forward with hope!

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!