Skip to main content


Making progress!

Last night, I've finished the last robo-ninja room before the "flying up high to find Dr Squidbrain" sequence (which is a room or two, then the big boss fight). It's so great to be close to being finished, although the boss fight is going to take a lot of work, a lot of code, and a lot of scrounging trying to find appropriate graphics!

I haven't been doing quite as much with Atari Anguna. (the great thing about having 2 simultaneous hobby projects is that when I get bored of one, I can get excited about the other!) A couple weeks ago I got it to the point where if you killed all the enemies in the right room, a key would appear. You could pick it up, take it to the matching locked door in the a different room, and open the door with it. It's almost like a real game at this point!

But like a said in a previous post, I did the math and realized I'm running out of code space in my primary rom bank. I considered moving a block of code to the 2nd bank (where the kernel and graphics live), but even if I do that, I'm still going to have to sacrifice a number of things I wanted to include (fewer room layouts, fewer enemy types, fewer rooms overall). The other option is a bigger rom, and a different bankswitching scheme!

The folks on the dev forums of AtariAge make a big deal about how the purists pack their games into a single 4K bank. Well, I'm no purist. I'm already using 4K, I have 4K left, and I'd like a little more wiggle room. So I did some research, and there were some good schemes I could use. There were a few weird games back in the day that used a particular 12K scheme, but that one also included extra RAM on the cartridge, which somehow feels like cheating to me. I don't mind using a scheme with a ton of ROM so I can include more content, but one of the fun challenges of this whole thing is working with the limited RAM. So that 12K scheme was out. There's a simple 16k scheme that Atari supposedly used in some of its 1st party games (although I couldn't any mention of what games actually used it), which works exactly like my 8K scheme, only with 2 more banks. So that's what I'm tentatively going to go with.

This week, the plan to make it easier to transition, was first to rearrange all my code. I've been mixing my code between actual subroutines (called with jsr/rts, the native 6502 opcodes for calling and returning from subroutines) and just macros (for most "functions" that I'm only going to call once, so I don't have the 12-cycle overhead of the jsr and rts.) This ended up being a big mess, as it's difficult to tell where in my rom the macro code actually ends up. So I yanked all the macros out of the files where they lived into separate files, so I can move the subroutines around between banks without worrying about where the macros get called from.

Next I need to figure out where all I have references to the room data. If I move the room data to a new bank, all the code that reads that data has to be in that bank as well. It's almost like I have some actual encapsulation and data hiding!


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…