Gauntlet is thrown... badly

Crap!!

I was in a GameStop the other day and saw this monstrosity. Well, fine. Time to start working on this with some intensity. I spent the first half of last week converting the smoke images to tile format (yes, I am dumb with that sort of thing). But now the gloves are off and I am going to make those bastards pay for using my game's name.

Master Chef. Iron Chef for the Master System. Consarnit!

Even Odds

The great thing about coding, particularly in assembly, is that if one is out of their element with a particular operation or concept, there are usually several other directions to take to get the desired outcome. This is a maxim that has given great comfort to me in my efforts.

Apparently my desire to use a subtract operation has caused me to hit that thick wall separating my comprehension from many, many Z80 assembly concepts. I guess these operations use signed bytes, so half the time the pseudo number generator spits out values that this operation considers negative. Well, that's what it looked like while debugging.

Anyway, that's no good. So instead I used an addition and used the carry flag for my conditional jump. This worked like a charm. I set it to less than 1-10 odds so things aren't insane, gameplay-wise.

Oh, and here are DMEnduro's smoke tiles. Time to get this party started!

Androids so do not dream of electric CP

Alright, last week I quashed a bug in my food display code, but was dismayed when I realized that I couldn't change the odds of food changing (down from 100% every single time). I kept debugging the code and it seemed like it should work... except... it didn't. I got my trusty pseudo random number generator (shout out, once again, to z80.info ) to generate a pseudo random number and then set up a CP operation with a value in the C register. Then I implemented a conditional jump depending on whether the sign flag was minus or plus. Everything except for that last bit seemed to work fine. You know the drill - I was crushed, was driven before my failed code, and audible were the lamentations of my women. Well, my wife did wonder why I was crying so much.

Skip ahead one week. I tried just using the zero flag instead. That worked fine (and obviously, with 1 in 256 odds, quite glacially). So my code worked fine. It was just me who was totally retarded. CP has no effect on the sign flag. Duh!

So I'll work on that. Clearly I need to go ahead and use a subtract operation.

Oh, and DMEnduro sent me some awesome smoke grafx. This was a week ago. Anyway, it looked so good in however many shades of gray that I decided to implement these as sprite animations. Pretty risky, what with that finicky, fussy VDP whining even more than I tend to, but life is about risk. I'll post the tiles later once I get this conditional jump all squared away.

Cornucopia

I fixed it.

The Battle of Eggplant Forest

Here's that video I promised. Sorry Google took so long to vet it.

I did try to fix the problem. First off, I should apologize to z80.info - their code is flawless. Well, their code plus a nice little CPIR operation that checks for duplicates. Food identities are updated in RAM plausibly randomly; they just don't match up with what's displayed. Except the first time. So something weird is going on.

Fish à l'Orange

I've finally updated the project (yes, life got really busy). All food items are now tile-based, and once every 8 vblanks each item gets 50-50 odds of remaining. You'll notice from the video* that this would make the game virtually unplayable, but that'll be a simple tweak.

What won't be such a simple tweak is how in tarnation all of those fishes, oranges, and eggplants get chosen. Weird. Well, it could be my code, or else the pseudorandom number generator subroutine I stole from www.z80.info . I'll have to check that out.


*As soon as Google determines it is of sufficient quality to upload to their stupid video thingy. Jerks

Let's do it, let's Burning Rangers

I just finished removing most of my conveyor belt code, except for the random number generator and associated morsels which will be necessary for the magic food table. Yes, I know that took longer than it should have; I was busy again at work. Plus, I needed to give some thought to how exactly I wanted to set the new code up.

There will be a table for each player. Foods will be selected randomly, again, and each will disappear independently- I will use my trusty 3-bit counter so every 8 IRQ counts the random number generator will determine whether each food remains or is replaced. I will tweak the random number generator to prevent every food from disappearing - I suspect something much less than a 50% chance of the food vanishing would be appropriate, though the rate could increase as the game progresses to increase difficulty. Then the raptured foods will be replaced with the smoke tile. Every spot with smoke will have to be synchronized, which is a shame, but otherwise I would be using up too many colors on the palette.

Okay, so the other thing that kept me busy this week was playing some games. But that's totally research for a game developer. And I will tell you what I learned, to prove the point.

I've been playing Phantasy Star Universe, mostly because nearly all the family I have in this hemisphere and some friends are all on it, and because it is a good game, for an MMORPG. But, being an old games connoisseur, a spot in my heart had always ached for the days of Phantasy Star Online (which I used to play with the same crew). So I booted up my Dreamcast and logged on to Schthack's server (http://www.schtserv.com/). I was just playing on my own, which was boring enough - the game is really not optimized for offline play. But the other thing I noticed is some serious frustration with the controls. Though a very complex game with a formidable learning curve, PSU has quite intuitive controls. PSO version 2, on the other hand, really shows a great lack of control optimization, even though it was a huge step up from the original version 1!

So, lesson 1: spend the time to make controls intuitive. I did have a visceral dislike for the learning curve of PSU, but it is a complex game, so I can forgive it. But the controls are pretty decent. My plan for Master Chef is to have one button do everything. I like simple games - Crazy Taxi is one of my favorites. But it plagiarizes, in a way, a Saturn game called Courier Crisis. You go around on a bicycle, picking up packages and dropping them off. The difference between this game and Crazy Taxi is, whereas in the latter you brake, accelerate, go forwards and backwards, and steer, in the former, every single button on the Saturn pad is used. Eight buttons and the D-pad!! So two games, similar themes, but one is a favorite and the other a total mess.

Another thing I learned: I downloaded a quest because this was something I had never gotten around to doing in my PSO heyday, and I happened to have a nearly empty VMU sitting around. I ended up serendipitously downloading the Burning Rangers quest. I always liked Burning Rangers until I read someone call it very ugly. Then I remembered - it is probably Sonic Team's most hideous game. Just awful. But pretty soon after reading that statement, I booted it up and started playing again. Yes, it is a terrible-looking game, but it has so much going for it that that doesn't matter! Novel gameplay, including the vocal guides, set it apart as a worthwhile game. So, while I don't think that novelty alone is going to make a graphically unimpressive game (like nearly anything I could cook up on the SMS), I think that the game industry has always had a tendency to beat the same gameplay ideas into the ground, leaving a lot of possibilities unexplored. Nintendo DS developers are really venturing into this unchartered territory with their lovely, original games, but I think there's still a lot of room out there for SMS developers to come out with new ideas.

Choices

I spent a lot of yesterday and this morning thinking about how to have disappearing foodstuffs, and as I sit down to write this, I actually came up with how to do it! This is what blogging is all about!

I was planning on having palette cycling for the conveyor belts (DMEnduro's idea, as mentioned in my first post) as well as for appliance steam and possibly for the sous-chefs' animations. So why not have poofs of smoke (palette cycled) as each food item disappears? This will certainly add an aura of mysticism to the proceedings, which is highly appropriate given that the Sphynx from Wonderboy in Monsterland is Chairman Kaga's analog in this game. (I was thinking - who is weird and has a kick-ass outfit?)

The other idea I had involves heavy compromises and lots of work, and might not solve the problem of excess VRAM updates. It involves keeping the code for animating player 1 untouched (the six tiles appropriate to the character's direction and animation frame are loaded into VRAM) , while for the other player, all possible tiles are loaded into VRAM. The latter case is how I had initially coded the animation, but with 6 tiles per player, 8 possible directions and 3 animation frames, for two players that added up to 288 spots in VRAM taken up. Oops. But I already have this code. This would limit the number of foods to 26.

The more I think of this other option, the less I like it. I want a fairly broad palette of foodstuffs so it'll be hard to make the same dish twice. Plus, as I mentioned, I like the smoke.

That will bring us back to d'oh.

I hardware-tested a version of my rom with a single food belt, along with player 1, 2, and the belt's VRAM updates all de-synchronized - I'm not even throwing in the second belt here. And whenever one player does tight little circles, the food graphics get garbled. I haven't even tested player 2 moving.

This forces me to come up with another mechanism for food availability. I was thinking of having a magic pantry, where food disappears after some time. Foods could be tiles until they were picked up. I could decrease the length of that interval as the game progresses to increase difficulty.

Anyone out there have any Wonderboy in Monsterland game saves? I need to do some research...

Video Killed the Lazy Coder

What a week! I hardly had any time at work for lunch, which is when I do most of my productive coding (I don't eat lunch, so food doesn't slow me down - ironic for what I am actually coding). Then I had long rehearsals (I sing) on three nights. Not my best coding week.

But I did get the video up. Thanks, anonymous! In case you're interested, eSMS 1.04 works great for recording videos. I just wish I remembered the codec that worked.

The bizarre bug with diagonally-moving players is not an issue on real hardware, since I checked using my Tototek cartridge on my Master Gear/Game Gear. By the way, I get a Software Error on my SMS when I use the Tototek cartridge - I think it might be problem with the physical dimensions of the cart's PCB. But I can try running this on my Power Base Converter, since I have used the Tototek cart on that successfully.

I did begin trying to get the second conveyor belt up and running, but I always have trouble remembering how it works. I have all of the coordinates for belt 1 in the rom (belt 2 uses the same coordinates, of course, except the x coordinates are shifted to the right), and the program just cycles through them. When it reaches the end, it shifts all of the food identities down one and adds another after accessing the random number generator. But my code is getting a tad unwieldy, and it is getting really hard for me to throw stuff in. Did I mention the only formal computer training I have is:

1. A computation biology course I took in grad school where I learned how to use BLAST and Expasy and a couple of DNA and protein sequence analysis programs (that other people wrote) and
   
2. A LOGO course in high school?

So it might take a while, but I'll get it.

You'll notice in the video that I have no code that checks whether a food type is already present on screen. That function is definitely on my to-do list.

I hope you enjoy the video. You might notice some 1's and 0's on the top of the screen; those are just for debugging purposes. Pay no attention to the man behind the curtains.

Crying Wolf

Imagine me trying to capture a screenshot to prove this weird bug I mentioned in my first post. Then picture me realizing that emuKon wasn't going to have anything to do with screen captures, and instead loading up Meka. Finally, picture me trying to have both characters assert a diagonal direction while my wife had her fingers primed to press SHIFT and PRTSC, while I tried combination after combination of diagonal directions, until I realized that there was no problem if I used Meka. I think I am going to have to plug my SMS into a TV and try this out on real hardware.

By the way, I can't seem to get emuKon to capture videos, though this might be solved by reading the manual. In the meantime, enjoy the screen capture. There are two more characters already done (gold stars if you guess correctly!) and a total of 41 foods completed.

Welcome and Master Chef overview

Welcome to my blog! I'll warn you that the purpose of this blog is self-indulgent: it's really mostly for airing thoughts (mostly half-baked) out into the ether in the hopes that this process will aid in their development. Secondly, the presence of an audience (likely imaginary) is a way to trick myself into feeling some sort of accountability for my SMS projects.

That's okay. As far as I can tell, most blogs are self-indulgent anyway. I would hate to pollute the development forum at SMSpower with my dribble, so here I am. Incidentally, if you really are interested in developing for the SMS, you should check out smspower.org/forums/development, as well as the whole smspower.org website.

Right. You've cleared those first two paragraphs, yet miraculously, your interest is unabated. I might as well talk about the main project I am working on: Master Chef.

In the autumn of 2002, after my evil grad school (rhymes with Wail) was so evil I could take no more and quit, I spent, oh, six hours a day playing Puyo Puyo 2 on my Game Gear. I started thinking, why are all puzzle games pretty much a variant of Tetris? No disrespect towards PP2, which obviously I love, but can't there be more variations? This was five years before I discovered Twinkle Star Sprites, so forgive my ignorance.

Anyway, at the same time I became obsessed with Iron Chef. So I thought, why not a Master System game with the same idea: a cooking competition? Thus, Master Chef was born.

Two players enter (I may someday add AI for solo playing); two players leave with steaming hot plates of food. Two conveyor belts convey pseudo-randomly selected raw food items (though nothing will stop one player from taking the other player's foods). Additionally, a table with a limited number of the "secret ingredient" will be available - every dish requires this ingredient. Players take raw food items to appliances or a sous-chef for frying, baking, roasting, chopping, etc. Every raw food has stats - sweetness, sourness, savoriness, texture, etc. - and the various cooking processes alter these stats. Mixing food items will also alter the stats. This should result in an infinite variety of final dish possibilities.

So, where am I right now? Well, I have two fully animated characters controlled by two players. I have one procession of foodstuffs (the conveyor belt will be palette cycled background tiles - an idea contributed by my brilliant graphic artist collaborator, DMEnduro).

What I am working on right now is decreasing the number of writes to VRAM to avoid graphical glitches. As you probably know, the SMS VDP is pretty sensitive to VRAM writes - I learned this in a really brutal manner when I spent six months working on a game that updates the entire screen every frame before I realized the VDP is not up to the task. Anyway, I have eliminated all glitches except when one player makes tight little turns (and probably a second as well - I've been testing on a Game Gear).

I decreased the number of foods per conveyor belt and am now including a check for whether y coordinates need updating and a separate one for x coordinates. This should help.

But a bug came to light - basically, there are some diagonal directions that are impossible with both players. It's all very complicated, and I am going to have to sit down and tabulate which ones don't work. I'll get that in my next post. I will also try to grab a video using emuKon (which I think can make videos) and try to post it using youtube, which seems to be what all the kids are using these days.