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?

Review: Super Pitfall

Super Pitfall for the nes is TERRIBLE.  Completely awful.  Interestingly enough, it's given me quite a bit of thought about game design for my next project.

 

I've spent the past 22 years trying really hard to like this game. I mean, this game had the potential to be awesome.  It was a huge world that you could explore freely.  Dungeons and spikes and non-linearity and ladders and treasure.  What could go wrong?  Well, everything.  No matter how much I tried, I always came to the same conclusion:  this game was no fun.

 

So, to be productive, I'll try to think about why it wasn't fun, and what could be done about it.

First, the challenge level was way off.  There are numerous frustrating cheap kills near the beginning of the game.  And there's a ridiculously long time you have to wait between dying and when you get to play again...it's something like 10 seconds of waiting.  Considering your first life may only last about 4 or 5 seconds, it's really annoying to have to wait 10 more before you can play.  

 

Also very frustrating is the fact that, although it's a big open world to explore, you find very little compelling or interesting things.  You wander around collecting gold bars that do nothing.  Scattered around are special items (playing card suits?) that are invisible until you jump in a certain correct spot.  But even when you grab them, there's very little sense of accomplishment.  Why did I grab that?  What's it for?  And do I really have to jump at every single inch of the huge world to see if there's an item hidden nearby?  Overall, I get this feeling of a big huge empty world, filled with nothing but ladders and traps.  I've heard that if you are patient enough to map out the world, it all comes together and the game gets interesting.  But I was never patient enough.  

 

So, theoretically, this game could have been fun if:

 

- There were fewer cheap kills, and the challenge curve  had been a little more appropriate

- Your goals were a little more obvious, so you felt you were making progress or discovering something interesting

- There was a minimap (I love minimaps) to help you keep track of where you've been and where you are.

 

So the things I should learn from Super Pitfall:

 

- A huge world to explore is just frustrating if there's no obvious reward for exploring.  This is the trouble I ran into with the overworld in Anguna.

- A huge world is confusing if there's nothing to help organize your brain.  Forcing players to hand-draw a map is a bad plan -- provide a minimap.  This one is relatively obvious these days, as almost all adventure games do this. (and it was forgivable back then to not have one)

- Have someone else playtest a little to make sure the difficulty curve isn't insane.

- Make sure that secrets aren't hidden in obtuse and stupid ways that just require tons of tedium in trying every single square/block.

Overhauling the Anguna engine

The nice thing about doing another GBA/DS game is that I already have a working game engine.  There's plenty that I want to change, and a lot that I'd like to clean up (see the previous postmordem posts), but it's nice to have working code that takes care of a lot of the grunt work.

So the past few weeks I've been giving some needed love to the code that drove Anguna.  The first goal was to merge the gba and ds codebases into a single source tree, and just have different make files for the different platforms.  Not for Anguna's sake, but to reuse for the next game.  Of course, some of the stuff (hud, menus, all the code for the DS's second screen) will have to be a bit different for the two platforms, but the majority will be the same.

The next task has been pulling out stuff bit by bit and reorganizing it, reducing coupling when needed, and generally making things less "icky".  Unfortunately, this also means breaking things, so I'm back to that crazy point where I cheer every time I get a sprite to appear correctly on the screen.  It's a bit tedious (especially because I've done this all before), but it's nice to know that as I get this all cleaned up, I'll have a ton of the work done towards my next game (even though I'm still not sure about all the details of said game).  So tonight I managed to get a "black triangle" onto the screen.  It's ugly, but it made me happy:

 

This, my friends, is my black triangle:  That nasty green background is an ugly "level" that properly got loaded by my level loader and screen drawing code.  (Despite the fact that I didn't bother to find good looking tiles to test with).  The green toady guy from Anguna is a stand-in to make sure my character/sprite code still works.  Which it does.  The fun part is that I hadn't even tested the DS version, but just now, while typing this, I compiled the DS build, and ran it, and it showed the exact same thing!

On a completely different note, I've been playing through a lot of the old-school 2d side-scrolling adventure games (mostly for NES, but some others), trying to get ideas for what works well and what doesn't, for what I like and don't like.  So I might have a few posts here basically just reviewing some of the old games, which will help me organize my thoughts.

Next Project

Ok, on to what my next project might be.  I'm not content unless I've got a project I'm working on, so there's not really an option of "no project".  While working on Anguna, I had lots of ideas of things that I might want to work on next.

I've considered doing some sort of 3d OpenGL-based game on the PC to learn what I'm doing with 3d game programming.  I've messed around with 3d before, but nothing more than little demos. Other things I've considered include some sort of NES homebrew, dreamcast homebrew, Atari 2600 homebrew, making an iphone game, doing a flash game, and finishing a digital scrapbooking tool for my wife. I also bought an Arduino and decided to try to make a simple robot with it.  So that's been occupying a good bit of my hobby time.  (Maybe I'll post some pictures/thoughts about the robot building at some point).

Really, though, the answer to "what's next" seems to be coming down to a few things:

1.  Whatever I make, I want people to actually play or use it.  I made an RPG engine for the PC once a long time ago that didn't really have a target market.  It was a fun project, but not very satisfying in the end, when there was nobody using it.

2.  There's already a HUGE pool of existing games out there on the PC (freeware games, or flash games, or whatnot).  If I made another one, the chance of getting my game played is pretty small.

3.  Although iphone game development would be fun, I don't feel like investing the money to buy a quality mac as well as an iphone or touch.  That's somewhere around $1000 to $1500 to drop.  I'm too cheap to pay that kind of money unless I'm REALLY sure that's what I want to do.

All of those seem to point to doing another console homebrew game.  It's a small enough niche to get noticed, and it's fun to see games running on the actual console.  As far as what system to develop for?  Dreamcast has a lot of overhead (emulators are poor, so I'd have to be tied down to testing on the physical console, which needs a TV).  Atari development is nasty hard (your code has to prepare and render EACH SCANLINE separately), and I'd have to brush up on my 6502 assembler.  I'd like to do a NES game -- I think I have a good enough grasp of how to program for it that I could learn it fairly quickly.  But it'd probably need to be in assembler also, which would limit my progress. 

So I'm leaning right now towards another GBA/DS game.  When I started on Anguna, I had debated between a Zelda clone, or a Metroidvania-style game.  (sorry for the cheesy label, but that describes it well).  I eventually settled on the Zelda clone, but I've still got some ideas for a side-scrolling adventure that I'd like to eventually work on.  So that's likely to be the next project.

More specifically, I'm thinking about doing something based loosely on Blaster Master.  I'm still debating exactly what that would mean and what it would look like, but that's the direction I'm looking.  I've been reading some reviews of older 2d side-scrolling adventure games, and playing through a few of them (Super Metroid, Symphony of the Night, etc) trying to boil down what I like and don't like about each of them.  Like Anguna, my goal will be to make the game that I want to play.  We'll see where it goes.  Especially considering I tend to start lots of hobby projects, and only finish the really interesting ones....

Looking back and looking forward

I guess now that I haven't posted anything in quite awhile, and Anguna's been all finished for what seems like forever (it's only been a few months?), it's time to do a post-mortem and then figure out what's next.

I've got a lot of rambling thoughts, so I may spread this into a few posts.

First, looking back at Anguna.

Overall, I'd call it a success. For the most part, I made the game I set out to make. The addition of Chris's graphical magic transformed it into something that was actually capable of attracting attention, and feeling like a "real game" as opposed to a toy project. The game wasn't quite as long as I'd like it to be, but it was good enough. A few thousand people downloaded the game (from my site, no clue about the total numbers), people played through it, and seemed to like it. It's currently ranked as the 19th most popular gba game on gbadev.org. I couldn't ask for better.

The biggest complaints or criticisms that I saw were:

1. It needed towns, or more people to talk to
2. It needed more story, or the story was lame.

These made me chuckle a little, as this was purely by design. I really enjoy action-adventure games, but I always get bored when I have to spend a lot of time in a town talking to people, or watching cut scenes. So I purposely made a game with no towns, very few people, and a cheesy plot. I guess there's not too many of us that want that sort of thing.

3. Once you get out of the first dungeon, you don't know where to go, and wander aimlessly.

This is true. It was partially by design, but I didn't implement it well. Again, I wanted to go back to that "big world to explore, and who knows what I might find?" feeling that some of the older adventures games had. Newer games that hold your hand, tell you where to go, or force you to uncover the world one piece at a time don't have that feeling for me.

That being said, when I was playtesting, I found that it was a little too easy to wander around and find nothing. The world was a little too empty or something. I added the purchasable maps to help combat this, and I think it helped a little, but not enough.

4. It was too short.

I agree. But I've learned two things from this: First, that level design (even for a simple game like this) is tedious, time consuming, and difficult. Second, that the quality of level design tools makes a HUGE difference. If/when I do my next game, I'll invest more coding time making (or google time finding) better tools.

5. Bugs or other hardware-related issues (not sleeping properly on the DS, glitches, places you could get stuck, etc)

There were a lot of bugs. That's pretty par for the course on this sort of project. I'm not sure I'd handle it much differently had I to do it over again.

So that's it for the things other people mentioned. Now for my own observations:

1. Crufty, ugly code.

Looking back at the code, there's quite a few places that's it's ugly. It's not decoupled properly in many places. This is all a mixture of a laziness during development, inexperience, and my iterative design process. It's rare to finish a large project and NOT find spots that are ugly (I tend to find that any large body of code that I wrote more than 18 months ago is ugly), but it still bothers me.

Specifically, I tied my sprite management system too closely to the sprite hardware. The same with background graphics. Small bits of platform-specific code were scattered through various places instead of all wrapped up nicely.

2. Separate GBA and DS codebases

I'm not going to go as far as to call this a mistake (because the cleanup required to integrate them might not have been worth it), but it was really annoying. The code is 90 or 95% the same between the two versions. I really should have made it one codebase with two different builds. This will be the plan for the future.

3. Cumbersome Graphics Asset Pipeline

This was really annoying. I didn't have a standardized and easy way of getting graphics assets into the game. Level graphics had to be hand-massaged in a tedious and error-prone way to get them in. Enemy graphics had to be dumped out a certain way. Splash screens a different way. All by hand. I learned my lesson halfway through, so enemy portraits were automated as part of the build process. In any future games, I need to automate away as much of the asset preparation pipeline as possible.

4. Martin Korth is still missing

And I'm still annoyed about it. He's the guy that made the best debugging tool for the DS. But he didn't set up any reasonable way of purchasing it without interacting with him directly. And he's disappeared. So there's no good debugging tools available for DS. That really stinks.

That's all I can think of at the moment. There will likely be more later.

The other thing that I learned from Anguna was just how helpful people are. I was amazed at how many people provided help, code snippets, hardware, testing, etc. It was fun working with everyone who was happy to help.

Ok, that's enough typing for now. Next will be another rambling post about what might come next after Anguna.

Open sourcing Anguna?

So I've been thinking for awhile about open sourcing Anguna. I had forgotten about it then until other day when my brother mentioned OSS and Anguna in his blog.

So, anybody out there have thoughts about the idea? I'm debating mostly between:
1. Doing nothing because I'm lazy and don't want to clean up the source and put it somewhere.
2. Pulling the core engine code out and open-sourcing that.
3. Open-sourcing the whole shebang, code, assets (graphics, level maps, etc) and all.

Opening the engine wouldn't practically be all that useful -- realistically, is anybody going to use my mediocre engine instead of some better engine, or instead of doing the fun work of making a new one?

Opening the assets means I need to check with everyone that made assets. Daydream made most of the graphics, so his will be easy to check on. But the music and some of the other graphics already have their own licenses attached, so I might not be able to include everything. Is it worth including some but not all? Is it worth the effort of sorting it all out?

I guess a lot of it depends on conversations with Daydream. Which I should have with him instead of here. Anyway, those are my rambling thoughts. Please chime in if you have advice or opinions.