Skip to main content

Getting stuff done...

So I got a lot done this weekend (not counting the work I did on my back porch, but this isn't a home improvement blog, so....)

  • I got the basics of the scripting system working for cutscenes in Robo-Ninja. I reworked my original design slightly (to put the entire script in a single file, instead of a different script for each "puppet" in the scene). I still need to flesh out a number of the script commands, but I have a very ugly basic cutscene working, where Robo-Ninja stands there as Prof. Treeblot walks away from him, and then a buggy half-broken Dr Squidbrain shows up.

  • On Atari Anguna, I did some thinking, and realized the way I had written 3 completely separate kernels was dumb. I managed to rework it so that the the smaller, simpler kernels were just subsets of the bigger more complicated kernel. They are a couple cycles slower, as I had to add a branch to possibly jump out of the kernel loop for the smaller kernels, but I managed to squeeze the branch into a spot where the timing wasn't as critical. So that saved me a good 500 bytes (1/8 of a bank, or 1/16 of my total rom space). If nothing else, that frees up space for at least 6 more room layouts. (to allow for more total number of rooms, I'll reuse the layout data across multiple rooms in the game)

  • I also got my bankswitching scheme all set up, so that the main game logic happens in one bank, and the display kernel and graphics data lives in the other bank. This was a little messy because I originally divided my code into separate files, based on what sort of game element each file was about. So I had a file for enemies, a file for backgrounds, a file for the main player, etc. But by default, the assembler just lays out everything sequentially in memory. So I had to do a little bit of rearranging to make sure that everything was declared in the right bank. (There was one small set of data, used for positioning sprites, that I ended up having to include in both banks, so I hardcoded its location, so that it was in the same place in both banks).  The fact that I mostly use macros to break up my code (instead of actual subroutines) make it a bit easier, as the macros get substituted inline where you call them, instead of existing where you declare them.

The big thing that annoyed me this weekend is realizing, once again, how slow development is, when you don't have much time to put into it. Often I've only got about 30-60 minutes of useful brain function left in my spare time in the evenings, before I get too tired to do anything useful. It's just hard to get anything done in that time. (which is partially why I like blogging about it -- it takes less brainpower, so I can do this during that weird gap of time where I'm not quite ready for bed, but my brain refuses to produce more code.) I guess if I only had 1 project instead of 2, it would move faster. Although I've really enjoying the fact that I have 2 options. If I get bored of one project, I just swap to the other.

Ok, my brain is fully shutting down now....


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…