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....
Monday, August 31, 2009
Tuesday, August 25, 2009
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.
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.
Subscribe to:
Posts (Atom)
NES Anguna
Well, I had a little bit of time still, while Frankengraphics is finishing up her game Project Blue, to have a little downtime on Halcyon, s...
-
So I've recently purchased DosBox Turbo , the best (as far as I can find) implementation of DosBox for Android, and have been playing th... -
When I'm too tired/frustrated to work on my NES game, I've been playing around with ideas for another hobby project that I've he... -
Well, I had a little bit of time still, while Frankengraphics is finishing up her game Project Blue, to have a little downtime on Halcyon, s...