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.

Lack of graphics....

Well, after that exciting start that I blogged about, I've stalled rather quickly.  That's a bit discouraging.  I haven't done much work on the "next game" for a few weeks.  Why?

Two reasons, really.  First, I've just been busy.  I haven't had as much spare time in the evenings.

But the bigger reason is that I haven't gotten confirmation from an artist for the game.  Chris (that did Anguna's art) had expressed an interest, which was enough to get me excited and started, but he's been pretty busy and had some other stuff going on in life, so I'm not sure he'll be able to contribute.  A couple of other leads have come up, but nothing solid. 

Without graphics, there's not really a game, so I'm waiting and dragging my feet on the development side of things for now.  I guess I could use some free-to-use resources from the web or something to get started, but it's just not very motivating.  So that's where I'm at now.  Maybe I'll hear from Chris or someone soon, and get geared up again later.

Review: Strider for nes

Well, after I got excited and started work, I haven't actually done much recently.  I've been reworking the level loading code from Anguna, but there's still a good bit to do.  I'd really like to get some sample graphics into the engine so I can visualize things better, but that will still be awhile before any graphics are ready.

So until then, I'm still playing old nes games.  The most recent was Strider.  Strider is an interesting game:  it has a great concept, cool story and mechanics, a fun almost detective-style "find the next file of information to see where you can go next" thing.  Unfortunately, the game is riddled with problems.  The play control is glitchy and awful -- if you jump near a wall, often your jump immediately ends and you fall to the ground.  The hit detection is completely wacky.  In most cases, it doesn't really pay off to fight carefully, because you never know when the game will think you've made contact with the enemy, or if it's made contact with you and damaged you.  So you basically run around swinging your little sword thing (the game calls it a "cipher") and hoping you don't die.  This REALLY puts a damper on the fun factor.....it's neat exploring new areas and figuring out where to go next, but it's no fun when you actually get there.

Overall, I enjoyed the game somewhat, but it was also moderately painful, fighting bosses that I had no idea if I was hitting, not being able to make jumps that should be easily jumped, etc.  The game was also a little bit too short for my liking, but that's ok.

So, things I've learned:

• The whole "multiple completely separate areas with a hub screen to determine where you go" concept can be pretty fun.  (Assuming the game doesn't hold your hand TOO much, which Strider balances quite well)
  
• The actual action gameplay has to be fun, or the game isn't fun.  Any single killer mistake (too high difficulty (see super pitfall), bad play control, bad hit detection)...any of these can ruin the game. 
• It's good to limit how many times a player has to run through a particular area over and over again.  In Strider, most of the areas are visited once or twice, but you keep returning to Kazakh.  And each time, you have to play through a pretty boring couple of hallways to get where you are going.  I like the general idea of returning to areas once you've got something new, but I got really sick of Kazakh.
  

More on the asset pipeline

So I'm still trying to figure out what my asset pipeline is going to be like.  What makes it particularly interesting is this:  the GBA doesn't support files (there are hacks out there to simulate it, but I'd prefer not to use them).  Everything gets packed as data into the single game rom, and run.  The DS, on the other hand (at least for homebrew) has a usable filesystem.  Now you can ignore the filesystem and pack things into the rom like I did for the DS release of Anguna, but working with files can sometimes be a lot nicer -- it sure makes the edit/build/test cycle a lot easier, as you don't have to go through a separate compile step.

The tricky part is thinking about how I might implement both of these.  The core of my existing engine assumes everything exists as structs in C, and references to other data is just via pointers.  (Which is easy when the compiler does all the work for you).  But if I use files, I'll basically need to write a file parser, which will then populate those structs, and create all the pointers between the new structs based on text symbols in the files.  Definitely doable, but a bit more work.  Is it worth it to go to files for the DS but not for GBA? 

The other side of the coin is the argument that, realistically, when editing assets, I'll already have to jump through some hoops to save/export it properly using whatever tool I use.  Why not just make sure my tool also recompiles everything during that step, and let the C compiler do all the work of parsing, populating structs, and creating the pointers?