Vaadin and ramblings

Well, it's time for some more random thoughts about my hobby development stuff. It's been awhile since I've really had any major projects -- there was nothing that I was extremely excited about, and I was having still a lot of fun playing Starcraft 2 in the evenings. But now the momentum of groups of us playing together has died down (it took a year!), so I've been thinking it's time to start on another project.

Now the important question is "is there any larger-scale project that I will actually take the time to finish up?" I love starting hobby projects. But part of being a hobby project is that I have to enjoy it, or I'll stop. I've got quite a few hobby development projects that I stopped, mainly because they stopped being fun. (and one project that I somehow lost 2 weeks of work on, (did I really go 2 weeks without checking into source control? I can't imagine I did...) which really killed my desire to work on it).

So I've messed around with a number of smaller things recently -- I got an android tablet and was playing with android development. That was fun, but nothing really sucked me in for a longer term project. I toyed with the idea of making a clone of Progress Quest for Android, but qiuckly realized that most of the time spent wouldn't be interesting android-specific stuff, but instead general tedious stuff. I'd still like to eventually make my unofficial Blaster Master prequel, but that's going to have to wait until I find an artist.

So, for now, I've started looking at working on some open source stuff to scratch a few particular itches. I won't go into detail, mainly because I'm tired of talking about projects that I likely will get bored and not finish, but I've realized that to do this current idea right, it needs to be a web app.

And I hate web programming. The web is just an awful platform, from a development perspective. You get a mish-mash of different languages and technologies, a thousand and one frameworks that all try to solve the same problems in mostly the same (unhelpful) ways. No matter what you do, you're almost always stuck messing with HTML (ugly), CSS (uglier), javascript (ranging from hideous to OK, depending on what js library you are using), some other language on the server, trying to manage ajax calls, trying to figure out reasonable designs for UI widgets that HTML doesn't really support, etc, etc, etc. No matter how far we've progressed, we're still trying to make these technologies do what they weren't designed to do. And it's still painful. I could continue ranting (eventually I'll write up my thoughts in another post about why I think the standard MVC pattern that 95% of the web frameworks use isn't really a good solution, but knocking the designs of people smarter than me will have to wait for a different day).

So I've been hunting around for some sort of library or framework to at least make a web app project fun to work on. And I finally found a framework that, while it still has a few rough spots (it's the web, how could it not?), does what I want. It's called Vaadin. And it's pretty cool. The idea is that you don't worry about client-side/server-side. The framework does that -- you just write your code, almost as if it was a desktop application, with a gui toolkit that is similar in general idea to other gui toolkits like Swing or SWT. And thanks to their cool design and a lot of GWT magic under the covers, the framework figures out all the HTML/javascript stuff and makes it just work. So you can spend your time writing the interesting stuff, and not spend the majority of your time trying to deal with javascript and html oddities.

I know there are a few other similar frameworks, like Eclipse's Rich Ajax Platform. I picked Vaadin for two reasons: first, the RAP ui was pretty ugly (visually) last time I looked at it a couple years ago -- everything looked like a desktop app, which is weird and uncomfortable when it's in the browser. (To be fair, I checked just now, and it's improved a lot) Second, and more importantly, Vaadin has GREAT documentation. While most frameworks have a 3 page tutorial then point you at the auto-generated javadoc/phpdoc/etc, Vaadin gives you a few-hundred page book with very detailed information about how everything works.

......

So I started typing this post a couple months ago, saved it, and then never published it. I pulled it back out today because after a couple months of fiddling around with Vaadin, I still completely agree with everything I wrote, and so I'm going to push the publish post button now.

Since writing this, I've made a little bit of progress on my "scratch-an-itch" webapp (not as much as I'd like) and also ended up using Vaadin for a work project where we needed a quick-and-easy but ui-rich tool. It was incredibly easy.

More blank GBA Carts

Hey, just a quick heads-up, I finally found another source for blank GBA carts, which means that for those of you that I had to turn down at some point, I can start selling them again. Drop me a line if you want one.

And yes, I'm still alive, but haven't done much development recently. I got bored with porting Anguna to iphone, and my apple developer license expired, so that's on hiatus. I have some other ideas I'm exploring, I'll tell more if/when they ever develop.

More Progress

I've been quiet, but I've been SLOWLY making progress.  The downtime before and after phase 2 of the Starcraft 2 beta really helped me get a little done.

Recent accomplishments include:

• I got the first overworld area and the rocky overworld area completely working (the outdoor parts)
• I've successfully broken up resource loading into the separate areas, so it waits to load graphics resources for the various dungeons until they are needed.
• HUD stuff including enemy portraits is in place.
• The subscreen is mostly finished.  I've finished the inventory screen, finished the map screen (and thanks to the nice resolution of the iDevices, the subscreen map is just a tiny image of the actual screenshots for each area, which looks slick, in my opinion), added the enemy database, and still need to do the "options" screen.
• The base code for saving and loading is in place, but I haven't yet put any UI in for it.  I'm leaning towards auto-saving each time you change rooms, so if you have to quickly turn the game off, you don't lose any progress.

This is really all to easy at this point -- not interesting and challenging enough to really suck me in, which is I guess why it's going slow (plus this being the 3rd platform for the game, it's not as new to me anymore) There haven't really been any technical hurdles in awhile.  Saving and loading, which I thought might be somewhat tricky, were as simple as writing to a file.  The scrolling for the enemy database took a little bit of thought to implement, but nothing noteworthy.

So, I guess, just enjoy some new screenshots:

Subscreen

Well, now that the Starcraft 2 beta is closed (at least for a few weeks) it's time to get some more done.  I haven't done much since the last post.  Mostly it's been reworking UI bits.  I'm not a huge fan of the lack of buttons on the iphone/touch, but I guess everyone has to deal with that.   I've been working on getting some on-screen UI for health/control buttons/etc.

Tonight I finally also got the main inventory subscreen somewhat laid out, mostly similar to the gba version, but slightly different, since the font resolution is much higher.  I'll also need to add options to toggle to the map or enemy database, but that can come later.

The other thing I need to work on is the control scheme.  It will use a simple on-screen control pad, but in playing other iphone games to get ideas, I've noticed that some of them with control pads work well, and some of them are completely miserable to use.  A lot of it will be fine-tuning the hot spots, dimensions of the control areas, etc.  My friend Rob also made a suggestion that I think will really help -- if you hit the attack button, and there's nothing in front of your character, but there is something that could be hit if you had turned before attacking, it will auto-turn your character.  The part of me that likes crazy difficult games wants to fight against the idea, but I do think it would really help make up for the fact that it's REALLY hard to accurately control a character with a touch-screen control pad.  So good suggestion, Rob.  That's something I'll need to add in, maybe once I get the subscreens and menus working.

Progress

Well, progress is going a little slower than anticipated, mainly due to the fact that I finally got into the Starcraft 2 beta, so my spare time is being split between Anguna and Starcraft.  But that aside, things are going fairly well.

The framerate issue from before is trivial to fix, so that's been addressed.

Performance was more interesting.  If I render the entire background every frame like I planned on doing, things USUALLY worked fine, but would occasionally get sluggish if the device was doing stuff in the background (checking mail, getting push notifications, doing whatever else that crazy thing does).  So I decided as a workaround to prerender each background to an offscreen surface, then just blit that to the main display every frame.  Which worked fine, except that there was some sort of odd behavior in the graphics system where it wouldn't actually destroy/release memory from offscreen surfaces when I was done with them (or at least do so in a timely fashion), so after about 10 room transitions, I'd run out of memory and crash.  Of course, since it was only on the device, it took quite a while to figure out exactly what was happening.  Turns out Apple has a nifty tool called the Iphone Configuration Utility which, believe it or not, actually runs on windows!  It lets you view the device console logs in real time, which was amazingly helpful in tracking down the issue.  Fixing it was then just a matter of reusing the same offscreen surface for every room, drawing over the last one, instead of destroying and recreating them with each room transition.

I'm also running into long load times -- I'm not sure how I managed to see only 5 seconds before, but it's often taking 7-10 seconds to load the resources for the game, and that is with them being marginally broken up.  That's a bit higher than I'd like.  I think that I might be able to reduce the perceived load time by doing part of it while showing a splash screen, doing some more at the game start, etc, but I'd still like to get that a lot lower.

Overall, though, things are running well.  The first dungeon is completely working (although a lot of the UI to make it really play right is missing, such as life bar, subscreen, button for activating secondary item, etc), and the first little chunk of the overworld is mostly functional.  (the graphics for the bridge to the desert area are messed up right now).

I really need to start messing with the UI now.  Which should be a lot easier than it was on the GBA or DS, but still a good amount of work, as it's going to be completely different than the GBA UI, meaning a lot of it will have to be completely rewritten from scratch.  So that's my next task....(well, after I play some more Starcraft 2).....

Running on Hardware

I just got into the developer program, so I can finally run things on hardware!

Unfortunately, I had the same experience as last time I did the switch from purely testing on simulators/emulators to testing on hardware.  Things were working great in the simulator, I loaded it on hardware, and it just crashed and died.  It took it about 5 seconds sitting at the loading screen, then crashed back to the menu (or whatever it's called on the iphone/touch).

A couple hours of debugging turned up the same issue as last time -- I was initializing some things incorrectly, which led to some bad pointers, which somehow, out of pure luck (would that be good luck or bad luck?  I'm not sure) worked just fine in a simulator, but caused seg faults/null pointers on the real thing.

Luckily, it wasn't as hard to track down as it COULD have been, so as of today, it's running on hardware!

A couple thoughts/surprises:
1.  My framerate is too high.  The framework I'm using locked things to 30fps on the simulator, so I assumed it would do the same on the hardware.  Nope.  So I need to manage that myself.

2.  It'll also be nice to really see how the performance works.  In the simulator I was running into performance issues blitting the tiles for large backgrounds.  I found a workaround, but it'll be nice to do some experiments to see what I can get away with and what I can't.

2.  I can actually now observe how much time it spends loading.  My biggest gripe with a lot of the iphone games is the long load times -- for small portable gaming, you should be able to get into the action very quickly.  I'm at about 5 seconds right now.  That doesn't include music or sound effects, but does include loading ALL the graphics up front.  I can probably lower it a bit by breaking up the art assets and loading them as I need them.  We'll see.

If I had a camera handy, I'd take some video or at least a photo of it on hardware, cause pictures are fun.  But I don't, so you'll just have to use your imagination.

Back at it

Well, I'm back at it.  Without an artist, that means one of 3 things:

1.  Make a video game with ugly graphics (either a plain ugly game, or some game where I can cheat and use the theme in some way to my advantage to get away with some sort of ugly)

2.  Have my next programming project be a non-game (that doesn't require an artist)

3. Port Anguna to something else!

So, here I go on step 3.

I recently found a cool product called the Airplay SDK, which is a whole toolkit for doing handheld game development in C++.  Using it, depending on licensing and whatnot, you can build games for all sorts of things:  iPhone, Android, Windows Mobile,  etc.  The important part to notice was that I could make iphone games without going out and buying a Mac! (I had an old mac mini at one point, but it was too pathetic to do development on...and the iphone develepor tools required an intel mac, which this wasn't). 

So I bought an iPod touch and started porting.  Unfortunately, a week or two into my efforts, Apple changed their terms of service, which, as far as I can tell, make it really unclear whether Airplay apps will be approved for the app store.  That was a bit discouraging, but I'm hoping they will be, so I'm moving forward with the effort anyway.

So, after a few evenings and lunches of work, here's what I've got (this is a screenshot in Airplay's simulator):

At Chris (the artist)'s advice, we decided to scale all the images double, which means it will look a bit more pixelated than most games, but it exactly matches the full screen resolution of the iphone, and if we push it as a "retro" feel, may go over ok.

The porting so far is coming along fairly easily -- it's amazing how much easier it is to get graphics on the screen with a more powerful device and thus more powerful sdk.  No more messing with vram and OAM attributes.  The biggest hurdles I ran into so far are based on the differences between C and C++.

C has designated initializers (which I used all over the place, thanks to a tip from Kashiwa), but C++ doesn't...so I had to go back and manually change a lot of code from using designated initializers to just initializing an array in order. 

I also ran into a difference in how referencing external constant structs works.  In C, I did a lot of:

const struct EnemyType enemy_bat_def = {....};

and in a different file:

extern const struct EnemyType enemy_bat_def;

and then referring to it in that file. 

Well, for some reason something is different in C++, and this doesn't work.  I'm guessing it has to do with the differences in C++ about how const is handled, or more likely, how structs are actually just classes without functions, but my knowledge of the gritty details of C++ is embarassingly lacking.  So I just changed how I did it. (now in the 2nd file, I'm referring to a pointer to the struct instead of the struct itself).

Other than that, it's been incredibly straightforward -- the bulk of the codebase just worked.  I'm still having to muck with how palettes are handled a little bit  (my animation definitions indicated which base image to use for an animation, so a set of palette-swapped enemies just all used the same animation definitions.  I can still do this, but the SDK handles palettes a bit differently, so it's a few changes).

I haven't yet applied for my iphone developer's license, so I've been running everything in a simulator so far, so the next step is going to be to get that and actually run this on the hardware, and see what breaks.  (or what the performance is like).

Then, it will be time to work on the UI -- the UI, menus, and controls will need a complete overhaul, so that will likely be the biggest portion of the work involved in this port.

So there you have it.  Let's see how quickly I can get this thing done.