Why I don't enjoy mobile gaming

Mobile gaming is all the rage. It's where the money is. It's where all the hip new games are. And by golly, it sucks.

I should like it. I love having a portable computer in my pocket to play games on. I like firing up a game while I'm sitting around waiting on something. I just don't like the games. Instead I buy all of Robert Broglia's excellent emulators, and only play ancient console games on my phone. I know this has been discussed to death, but hey, it's the internet -- what's the point of the internet if not to soliloquize into the ether?

So here I go, the main reason I don't like mobile gaming?

(And it's not the lack of control pad. I do miss a control bad, as touch controls are awful for certain genres. But this can be worked around with creative games, or with well-design onscreen touch controls (Robert Broglia did a pretty good job!)

Really, the big problem is long load times, and tons of slow menus.. This is the real kicker. When I want to sit down and play a game on my phone, it's because I have a couple minutes of downtime where I want to be entertained. I want to get into my game, play, and get out. The problem is most mobile games have enough splash screens, resource loading, menus, etc, that it takes forever to actually start playing.

I downloaded a cool game, Gravity Guy, from Google's 25cent app sale last week. Great concept for a game -- a simple gravity-reversal twitch game, reminded me of VVVVVV or my favorite mobile game, The Impossible Game. The only control is touching the screen at the right time. It's fun, fast, and great in short bursts. The only problem, (ok, not the only problem, the biggest problem) is that it takes forever to start playing. I timed it yesterday -- from the time I tapped on the icon until I was playing, took 35 seconds. (A splash screen, a title screen, 3 or 4 pages of animated menus, and another loading screen). That may be fine for a console game where you are planning to devote some time to playing a game, but for simple mobile games, hopping in and out, it's a waste.

Another game that I want to like is Highborn, a clever and relatively well-designed turn-based strategy game. I always enjoy it when I actually play it. But the barrier to start playing is just high enough that I never want to sit down and play it. It just takes too long to get started.

It's even worse when restoring a saved game takes me to some predetermined save point instead of exactly where I left off. Playing mobile games, I often end my game extremely suddenly. I want to resume just as suddenly, without replaying stuff.

There are a few other things that I don't like -- the ubiquity of microtransactions, ridiculous use of "unlockable" things, the tendency to repeat the same boring genres (tower defense, run & jump, etc), but these are all minor things.

Now there are TONS of games in all the mobile app stores. I'm sure there are other games that load quickly and aren't annoying. But how do you filter out and find them? There's no search options for "loads quick and doesn't tick you off with stupid stuff".

So instead I play old emulated cartridge-based console games. They load instantly (it takes about 3 seconds at most before I'm resumed to exactly where I left off). They save instantly.  Some still have annoying unlockable stuff, and there's a different uninspired set of genres, but I don't get pestered to buy something when I'm playing.

So what's my point? I guess if you are a mobile game developer, make your game load fast. That's all.

Coding for a broken phone

So I've been very slowly working on a project to create a network-based garage door sensor (and possibly opener) which will let me check whether the garage door is open (when I left for a trip and suddenly panic because I can't remember if I closed it), and will also alert me if it's after 10 and I accidentally left it open. (Eventually I'd like to add a controller, so I can open/close it from my phone, but that's a long way off).

The first step was finding an easy way to sense if the door was open, and report that to my home server so it could serve it up to me.  Luckily my office-mate handed me his old android phone with a busted screen. Nothing shows up on the screen, and it the touch sensors don't work. 

Theoretically, I can mount the phone near the top of the garage, and write a program for this phone that will monitor the proximity sensor to tell if the door is open or closed (if I position the phone so that the open garage door will sit right in front of the phone near the ceiling) then report that to the home server over wifi.

So the things I would need to figure out:

1. Can I even get code running on this thing without ever touching the screen?
2. Can I get the proximity sensor working?
3. Can I get the phone onto my wifi without being able to use the wifi configuration UI?
4. Can I figure out how to physically mount this thing on the ceiling of the garage so it will work?
5. Can I do all that before getting bored with the project?

1 was easy -- plug in the phone, fire up adb, and go to town. The Android debugging tools work just fine. Luckily Tim had enabled USB debugging before breaking it, or I might have been completely out of luck.

#2 was easy as well. The API for handling the phone sensors is pretty straightforward and easy to work with.

#3 was the most painful. I spent a good while tonight trying to figure out if I could configure the wifi just using adb (the remote debug tool for android). Couldn't figure out how to do it. So then I found the API for doing it programmatically -- so I need to write a program to configure the wifi before doing the rest of the monitoring. The sample code was really simple. Unfortunately it kept not working. And not working. And not working. With no reason reported of why -- either the call to enable my wifi network just failed, or it succeeded, but never connected. *sigh*. Finally figured it out after a ton of mistakes (the most notable, if anyone is here looking for help, being that the SSID and password have to be quoted inside the string, like:  String SSID = "\"myssid\"";, and the Android manifest needs to specify some uses-permissions: CHANGE_WIFI_STATE, ACCESS_WIFI_STATE, and ACCESS_NETWORK_STATE) 

So I finally tonight got that working. Next step: write the code to tie all this together. Then try to figure out how to mount it on the ceiling. Someday I might actually finish this thing.

If anyone tries to do this as well, here's a snippet of code that worked for me:

In the manifest:

    <uses-permission android:name="android.permission.CHANGE_WIFI_STATE"/>
    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

And the code itself:

WifiManager wifi = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);
WifiConfiguration conf = new WifiConfiguration();
conf.SSID = "\"mySsid\"";
conf.preSharedKey = "\"1234567890\""; 
conf.status = WifiConfiguration.Status.ENABLED; 
 
int res = wifi.addNetwork(conf);
wifi.disconnect();
wifi.enableNetwork(res, true);
wifi.reconnect();                
   
wifi.setWifiEnabled(true);

Subsonic: questions in open source ethics

So there's a great open-source project out there called Subsonic. It's a streaming media server -- it will stream your music and videos from your home server across the internet/network. It's easy, user-friendly, and has a number of apps for mobile devices.

There's only one problem. You install it, get it configured, then realize that despite being open-source, it's actually shareware. You get the base program, but can't unlock streaming video or mobile access features unless you pay the developer money. And despite him saying "you can donate any amount you want," he only gives you an unlock code if you pay him at least 10 Euro. These locked features are part of the open codebase, but just won't work until you enter an unlock code.

This brings up some interesting ethical questions that I've thought about for awhile. I have no beef with people making money off their software. But the fact that it's open source makes it interesting. Also there's the fact that the website talks about it being free (he doesn't talk about speech vs beer). But then if you read further, you find out that it's not all free (beer). None of those things are problems. But they do make for some interesting questions.

It's open source (GPLv3), so I downloaded the source, and bypassed the registration unlock system. Now I have the full product without donating. What I did was 100% legal. Was it ethical? Does it matter that the author wanted me to donate to unlock it? Does it matter that I felt deceived after I installed it when I realized that these features that the website talked about were actually locked away behind a paywall? Does it matter that the developer had to have purposely chosen the GPL license, so was in effect expressly allowing me to do this?

Let's take it a step farther. Would it be ethical for me to publish a fork that just takes his software and removes the registration requirement? More importantly, would it make me a jerk to do so?

It's interesting, because it's clearly legal, and it's within the general spirit of open-source. But it's also clearly ignoring the developer's request to receive compensation for his work. Is that any different than what CentOS does with Redhat?

.....

Personally, I think Subsonic is great software, so I have no intention of publishing forked code, or even publishing how I bypassed the registration scheme. I figure if the guy keeps getting money, he'll keep making good software. Even if I feel like the donation requirement is poorly worded/explained. But I definitely think it brings up interesting questions.

Maven (cont)

So I finished the book I was reading about Maven. It was amusing paying attention to my own feelings about Maven as I progressed through the book. It went like this:

Introduction and initial explanation: Hmmm, this is interesting, but sounds a bit lame.

Basic tutorials and walkthrough of Maven: Wow, this actually looks really awesome!

Advanced topics, explanations, etc: Seriously, that's how you're supposed to do that? That's awful! And what's up with that weird special case?

Really, it confirms my initial reaction -- if you play the maven way, things are pretty simple. If you try to do something weird, There be Dragons. I'm going to play with it a little more on a hobby project, but I'm not sold on it.

Maven (and Ant, and Make)

For some reason I've had a lot of ramblings in my brain lately, making me want to post. So here I go.

I've been reading up about Maven (thanks, Rob), trying to wrap my brain around it. And I'm torn. I can't decide if I think it's wonderful or if I hate it (most likely, it will resolve to being like most tools, which is "useful but with a handful of caveats").

For some background, most of my experience with automated build systems comes from Make. And let me tell you, other than the syntax (which is one of the worst crimes against humanity), Make is incredible. Make is less about procedurally defining your build, and more about creating a bunch of rules about what files you need, and how to go about generating them. It then recursively looks at the dependencies of those files, and how to generate them, etc. It's a thing of beauty. (Again, other than the syntax). When I was working on Anguna, my makefile did all sorts of crazy nasty things to build my project: converting room definitions, converting sprites and level graphics, using perl scripts to transform certain scripts into C code which then got compiled, etc etc etc. It was a weird, complicated build. And my makefiles were weird and complicated and ugly. But they were great in that Make automatically understood and handled knowing when to rebuild files (based on the sources changing) and when not to. And not just for C source, but for the whole build process.

Then I started doing java development at work. And for a long time, Ant was the defacto build system for java. This felt like a complete downgrade after working with Make. First, Ant is extremely procedural. Sure, there are targets that can depend on each other, but (as far I have found, not being an expert on Ant), the ability to check dependencies to avoid rebuilding only occurs for java source/class files. If I have to run weird commands to convert an image file to the right format, Ant doesn't seem to know how to check the source image file for changes before converting it. (Again, maybe I'm wrong, I rather hope so). And Ant's syntax is only marginally better than Make's. Instead of terse weird symbols and problems with tabs/spaces, everything is xml. Writing procedural code in xml is just dumb. So Ant felt like a step back from Make as far as overall flexibility and utility, but still wasn't terrible, as it still let you wire up weird builds and do whatever odd build steps you needed. I guess the biggest con of using Ant was that it didn't make the easy parts easy. Building and jar'ing a simple java project still required a good amount of xml.

Then along came Maven. I'm not hip and trendy enough to have started using Maven early on, but I haven't been able to avoid it forever. My first experiences with it were awesome, trying to build various existing open source projects -- you check out somebody's code, do "mvn install" and it actually goes and downloads dependencies and the build works the first time. When does that ever happen?

But when I started using Maven for some of my own projects, I started to get a little frustrated. The pom file (the maven equivalent of the makefile or build.xml) specifies almost nothing. What if I want to copy a bunch of files to a different place partway through my build? Or run some weird commands? What's actually going on?

As I'm learning, Maven has a lot of conventions. It's like Steve Jobs and Apple -- if you are happy doing it the way they want you to, it's great. If you try to do something different, beware. In Maven you spend less time specifying the steps you take in your build, instead you're mainly telling it what kind of build you are doing, and Maven assumes you are doing it the same way as everyone else, and then (hopefully) just works. In this case, Maven seems to be making the easy easy (unlike Ant). If you put your code in the right place and are doing a build that matches one of the many standard builds that exist (or that there are plugins for), then it's really easy, and everything just works.

Things get harder when you try to do something different, or weird. Unlike Ant and Make, you can't simply and easily tell it what steps you want to do -- the step definitions are all buried in layers of plugins and defaults. Not that it's not possible, but it requires digging in and mucking about with how maven really works. Unlike Ant (where accomplishing the easy things and the hard things are both a little bit of work), in the Maven the easy is REALLY easy and the hard is pretty hard.

The more I think about it, thinking through this by writing, the more I think Maven is a good thing, especially when you're willing to follow its conventions. But that doesn't always it's the right tool for every job.

Now I just need to read more about calling ant scripts from Maven (which is possible, and might solve some of my issues), and read up on Apache Ivy, which seems to be a useful tool for managing dependencies without living in a world as script as Maven's.

Oh, and why I gave up on Anguna for IPhone

While I'm here posting stuff, I never really explained what happened to Anguna for iPhone.

I gave up and quit.

For a few reasons:

First, I got a bit bored. I was tired of writing the same game for the 3rd time. Most of the interesting parts ported over pretty quickly and easily. The parts that were left were mainly fiddling with asset (graphics and sound) formats. And that was no fun at all. (If I was smarter, I might have figured out a way to automate some of the conversions, but they tended to be really fiddly based on how I handled them on the GBA/DS side).

Second, I got frustrated at Apple. I paid them my $100 for a dev license. And then part way through development, they changed their developers terms with a clause that strongly sounded as if they wouldn't approve any apps that were using the 3rd party toolkit I was using. Their wording was just vague enough that it was hard to be sure. Talk about discouraging. I paid my money, was half-finished developing my game, and suddenly they decided that my game might not pass their terms. A few months later, they changed it again, and this time the game would have been fine. But at that point, I was done with it -- I have no interest in trying to hit a randomly moving target of what's allowed to be published.

Third, which was really a result of the first two reasons: my annual developer license expired. I didn't finish the game in the first year, and had to decide if I wanted to fork over another $100 to try again. I enjoy doing hobby development, but I don't enjoy having to pay a subscription to do so. So that was the end of that.

So there you have it.