Skip to main content

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.

Comments

Popular posts from this blog

Retrospex 32 Review

RetrospexInternational recently sent me a couple units of their new handheld device, the Retrospex 32, a new dedicated GameboyAdvance emulator handheld.  To make the unit playable out of the box, they pre-loaded a handful of homebrew games, including Anguna, which is why they were kind enough to send me 2 of the units to play with.  I was pretty excited to get my hands on the device and try it (I loved my old GBA micro with a good flash cart!), and see Anguna running on it. So here's my thoughts after playing with it.



Their website lists the Retrospex 32 for £59.99, which is around $100 USD. It seems like it's marketed toward people into retro-gaming (which makes sense for a dedicated GBA emulator device). At that price, with that target market, and such a limited set of functionality (why not make it a multi-machine emulator, and emulate all the old consoles?), it would hopefully do a really good job of it.

The short version of my review: it doesn't. It has one job (emula…

Making the game fun

The real trick for Spacey McRacey (as I'm calling it now) is going to be making it fun.  And that's what I'm rather unsure about at this point.

I have a game design that basically works. The technical issues are mostly sorted out, I just need to get a few more implemented before I can seriously play test it.

But fun? It's hard to know if it's actually going to be any fun to play.  With a 4-player party-style game, it's seems like it might be hard to hit that fine line where everyone is close and competing, where everything feels exciting and tense, as opposed to tedious and boring.  And despite envisioning my game as fun, it might just be boring to play.

Some of that comes down to tweaking it. Tweaking the speeds, difficulties, etc, will make a difference. (If it's too easy to shoot people from behind, then it will be nearly impossible to hold a lead for very long, which could ruin it and make it no fun. If it's too hard to kill the guy in front, it wil…

Killer Queen

So at PRGE, I played an arcade game that just left me amazed.  Killer Queen.

It's a 10-player game. You have 2 cabinets linked together, and 5 players huddled on each one. Each one is a team of 5 people, working together to play a simple one-screen 2d platformer.  But what made it work was the high quality game design.

First, the game is relatively simple, yet there is a lot going on at once.  One player plays the queen, the most important and powerful character on the team. The others start as workers, but can become warriors who can fly around and attack in a very joust-like flappy contest of height.  The real trick is that there are three completely different ways to win: either collect a bunch of berries and bring them back to your base, or ride a REALLY SLOW snail across the screen (while other people try to kill you, and you hope your team protects you), or kill the enemy queen 3 times.  There's some other things going on as well (using berries to upgrade, capturing upgr…