Thursday, January 19, 2017

Testing time

Well, Spacey McRacey is at that point.

That point where I feel like I'm finished.  But I need to play through the game a hundred more times.  Well, except that to properly test, I need more players.  And time.  The deadline for the development contest is in about a week, but I'm currently in the middle of buying and selling a house.

I really hoped to add AI as well, so you could play the game with 1 player.  Not sure I'll get to that now, at this point.  We'll see what happens.

If anyone wants to download and play with it, let me know.  I'll eventually put it up on my Bite the Chili website, but for now, just email me or comment if you want to give it a try.

Thursday, December 22, 2016

Title Screen

What I really need is a title screen.  I don't have tons of graphics rom space left (this game is using the most simple, primitive cartridge setup, with very minimal graphics space), but I'm sure I can come up with something better looking than this.  I just don't have much inspiration, or confidence that I can make something that looks cool, given the limitations I have.

Pay no attention to the green background on the small "press start" subtext.
That's just a palette issue that I haven't fixed yet.


That being said, it's close to being done!   My todo list is down to only minor things: adding a scoreboard between rounds, adding additional music (the single song is going to get pretty annoying!), improving title screen and player-select screen UI, etc.

Oh, and testing, tweaking, and testing, testing, testing.

Saturday, December 17, 2016

Testing the fun

Well, it's been about a month since my last post. I haven't said much.  Partially because I haven't done much.  Another consulting gig has kept me busy.  But also what I have been doing is mostly uneventful things that I haven't felt like talking about.

Getting a per-round splash screen working, getting different graphics and palettes for different rounds, etc.

But I did decide it's far enough along to actually start play-testing the fun.  Before I get much further, I need to know if I'm remotely on the right track.  First I got a coworker to play a 2 player match with me just to see if it seemed playable.  Despite some bugs, that worked out ok.

Tonight I made my family play with me.  My son (8) loved it. My daughter and wife put up with it.  That was a better test.  We found a few bugs and confusing things, but it seemed like there might possibly be some fun involved.  (Although the girls didn't exactly play competitively) I still need to get a few people that actually LIKE video games to come over and test and see how it plays.

So far it seems.....ok enough.  Not amazingly exciting (which I hoped) or completely boring (which I feared) or just completely broken (which seemed possible).  It's really hard to design a really exciting party-style game, so I'm fine with "ok" for my first shot at it.

Time to make some tweaks, fix a few bugs, then hopefully recruit some testers over the Christmas break....

Friday, November 18, 2016

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 will be tedious the other way. If the barriers are too hard to dodge, then players won't have any attention left to fighting each other, which will be boring.  If they are too easy, then they will be pointless, and it will just be a shoot-em-up)

So I'm really looking forward to getting a bit more done, and then conscripting some friends to come over and spend an hour or two playing it.  I might need to have multiple builds ready that night, with slight variations in the timings and speeds and difficulties, to see which works the best.


The Theory of Fun and books about game design

I got a book out of my local library called Theory of Fun for Game Design which is (or is supposed to be) all about this concept. I was a bit disappointed. I thought it would give some good principals for coming up with a good game design.  But it really didn't.  It was mostly fluffy stuff about how the author thinks about games from a theoretical point of view, but didn't really have anything practical.   We have another book in our library called The Art of Game Design which I read once years ago (it was checked out when I recently went looking for it), and is a MUCH better resource about this topic. I don't really remember much about it, but I remember being really inspired to try to make something fun after reading it.

Thursday, November 17, 2016

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.
I'm not sure it would be as fun with only 4 people instead of 10.

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 upgrade points with the queen, etc), which means there's a lot going on at once.




The joy of it is that it really pulls you together as a team in a super fun and exciting way.  You'd jump into a game with a bunch of strangers, but suddenly you're talking back and forth (in close proximity as you're squeezed around a tight arcade setup) about what everyone needs to do, how to stop the other team, etc.  My description doesn't really do it justice -- the game is so simple, yet did such an amazing job of pulling in people to work together and have fun.

My only complaint is how hard it is to find a way to play the game. There's only a handful of the machines made, and no way to play it other than to go somewhere that has it.  I keep daydreaming of somehow coming up with a way to buy one and put it somewhere in my town, because I was so impressed with the game design.  There's just very few times you play a game where they nailed the game design so perfectly.

Really, I'm jealous that I didn't think of it. Any programmer could make a clone really easy. But to come up with the design like that that worked so well?  Sigh.

Tuesday, November 8, 2016

PRGE

I couple weeks ago I had the chance to go out to the Portland Retro Games Expo, where Al from AtariAge had Anguna set up to demo.



What an amazing time. I could talk for a long time about how cool it was, but a few highlights:



  • Getting to see my game on display, and see people try it out
  • Meeting people who had played previously Anguna and enjoyed it
  • Meeting other homebrewers that I've interacted with on the forums
  • Hearing from and talking to the developers of the old original Atari games, hearing about what it was like to make those games, and how they dealt with many of the exact same technical issues that I do now.  (At one talk, they started drawing out how the display kernels work, and talking about how you can use the RESP0 register to set up your kernel to reuse sprites on multiple scanlines....I'm not sure how many people in the crowd enjoyed that level of technical detail, but I had a blast)
  • Playing Killer Queen, a ridiculously well-designed 10-player arcade game.  I'm going to post my thoughts about that game at some point, but I was blown away by what they accomplished with it.
  • Meeting up with my friend Tim Lapetino, author of the awesome new Art of Atari book

Atari Anguna is finished at this point, I'm waiting for some art, and then I'll declare it officially "released"  whenever we get a chance to release the cartridge through Atari Age!


That's Howard Scott Warshaw.
The genius behind Raiders of the Lost Ark, Yars Revenge, and E.T.

Sunday, October 16, 2016

Titles

Thanks for the title suggestions everyone!

The 3 suggestions that I like the best were:

  • Pew Pew Pew
  • Reginald McGillicutty's Big Boom Blast Party
  • Spacey McRacey

After some thought, I decided:

Pew Pew Pew just isn't google-able enough. There's too many cultural references to "Pew Pew Pew" nowadays, which will make my game get buried even if people are looking for it. And alternative spellings (someone suggested Pew Pue Pu) are just too weird.

Reginald McGillicutty blah blah blah....I love this one from author Jeffrey Aaron Miller. What disqualifies it is really the format of the game required for the game competition I'm hoping to enter with this. The requirements of the game use a NES cartridge format that's quite limited in video ROM, which means I have to share space between the title screen and gameplay.  Which means I can't spend a ton on a giant fancy title screen. (Unless I'm misunderstanding the specs of the format, which is quite possible).  

Which leaves Spacey McRacey. Which is what I'll go with for now until something changes my mind otherwise.




Tonight's work was the "start game" screen (not the title screen), where players push start to register that they're in the game. (since it's a 4 player game).  Mostly, that involves drawing 4 big frames on the screen that each say "press start".  So I've been working on a reusable routine for drawing frames on the screen of arbitrary size and location.  

That's a task that should be pretty easy. But with the limitations of the 6502 combined with the oddities of how the NES handles background data updates, it's slightly more complicated that intuition would lead you to believe (to write any given chunk of background tiles, you have spend 4 instructions telling it what tile address you want to write to, then serially write data to a register, which is great for horizontal or vertical stripes, but annoying for an arbitrary rectangle in the middle of the screen, as you have to keep re-positioning the address register).

Anyway, it's getting there!

Saturday, October 8, 2016

Rapid Progress

I told my office-mate that if I ever finished that background mess, I'd start making much faster progress.  And it turned out to be true.

Earlier this week, I decided it was time to look at audio engines. I understand the concept of how audio engines work on the nes, but I just don't want to take the time to build one myself.  After trying out a couple of them, I found one that integrated really easily, and lets you play music imported from the popular famitracker format. After digging around, I found some interesting famitracker compositions under a Creative Commons license from a guy that goes by Ozzed.net. Turned out to be a really nice guy and was helpful in providing me info to get some of his music integrated into the game. So now I have background music!

The next steps were collision checking, explosions, and player bullets. No problems there!  Most of that is pretty simple stuff, or would be in C. In assembly, it's a little more error-prone and slower-going, but not substantially more difficult: the logic is the same, but at a lower level. In just a few hours of work this week, I've those things all working!  (Well, there's still a bug where if a barrier's gap isn't aligned on a 16-pixel boundary, my collisions don't work quite right. Should be easy to fix though).

At this point, it's quickly starting to take shape!  I just need to add the points system, and suddenly the skeleton of the game is complete.  Then comes the fun part: adding the actual polish.

This includes:

1. Title screen and screen to select number of players
2. Sound effects
3. More interesting background graphics behind the barriers
4. Powerups
5. Different rounds with slightly different behavior

The last one needs a little more explanation.  The first round will be straightforward, with no tricks.  To keep it interesting, subsequent rounds will have a theme, such as:

  • Speed round (everything is super fast)
  • Battle round (the barriers are spaced out more easily, but everyone is maxed out with all sorts of weaponry, and you also gain points for kills)
  • Collision round (touching other players kills you)
  • Survival round (you lose points for dying)
  • (and I'm trying to think of other similar ideas)

That all being said, send me ideas for a title. I'm serious, I need help with this.

Monday, October 3, 2016

PRGE, and I need a name

It's been awhile since I posted anything here!

First off, Anguna 2600 is pretty much done. I'm currently in the process of working on some promo material for the Portland Retro Game Expo, where we'll be showing off the game at the AtariAge booth.  I'm excited to be in a giant room full of people that are into retro-gaming, and have my game on display.  Should be a fun time.

I'm still slowly working on the nes game I talked about. I got hung up for awhile on displaying the barriers. I just kept running into bugs trying to get the game model to work right, then have it render properly based on the game model.  Part of it was scrolling -- the game has the appearance of scrolling through a world, but because the 6502 is only an 8-bit processor, I didn't feel like doing the math to track giant scroll values. So it's somewhat fake in terms of in-memory model.  The barriers move, the player stays motionless.  But because the nes background register is scrolling, (and it thinks that the top of the screen is 32 pixels off because of my top status bar), and because of mistakes I made while using fixed point path, and because the vertical resolution wraps at 240 pixels instead of the nice 256, I kept getting my math slightly off.

(it would have been easier if I just decided it scrolled 1 pixel per frame, so I'd know that every few frames, we'd hit an exact 8-pixel boundary, and would know to draw the next tiles. But because I'm scrolling by a variable amount (using fractional fixed-point math), it's more work to know when I cross that boundary.

Anyway, I FINALLY just threw away most of my background code and sat down with a pencil and paper and worked all the numbers out on paper, then re-coded it to match my paper-work. It worked much better when I did that.

Once that was out of the way (ok, I'm lying somewhat...I still have some issues with the background palettes, but I'll tackle that math later), I've finally got back to some of the game logic -- player collisions, etc. Fun stuff.  Today it was adding explosions and resetting the player position when you hit a wall:


It's actually started to vaguely resemble a real game at this point.

Next up: I need a title.  It's a party game with spaceships racing through barriers. My first thought was "Space Jam" until I remembered that that was that terrible movie with Michael Jordan. (Ok, I never saw it. Maybe it was actually awesome?)  I need a name.  And eventually a cool title screen to go with it.  Any suggestions?

Monday, September 5, 2016

Backgrounds and debugging

One of the hard things. Ok, so far the ONLY hard thing about NES development is how the background tile maps work.  In theory, they're pretty simple -- a big array of memory where you write a tile number, and the PPU (the video chip) draws that tile at that position.

But there's so many little gotchas:


  • The nes addresses 4 different screens' worth of data, but by default only has ram for 2 of them. So unless you provide more RAM on the cartridge, you set up (via actual wiring on the cartridge!) mirroring where data is duplicated between screens. 
  • The screen nicely pans and wraps between screens'-worth of background data. Except that there's only 240 tiles high, so you have to do math instead of letting bytes just wrap around
  • Setting color palettes for tiles is painful -- you do it in a separate block of memory, mapped in a funky way where you map 4 tiles to 2 bits of a particular byte.  Which means you have to do odd math to work out how to change colors of backgrounds.
  • Mid-screen scroll changes are weird.  To do a header bar, many games will switch scroll positions after the header (since there aren't layered backgrounds). But switching scrolling mid-frame requires more weird math, because you can't just write to the scroll registers like normal -- you have to do weird gymnastics with the various PPU registers instead.
It's not horrible, but it's driving me a little crazy. Really, I just wish I had better debugging tools. I got really used to Stella (the Atari emulator)'s quirky debugger, and realized how awesome it was. The nintendo debuggers I've used just aren't nearly as usable, at least with my current level of experience with them.

This is a debugging diagram of the four screens of data. I'm mirroring vertically, so the top and bottom are cloned.
The left half is my game background. The right half is the header bar.
Each frame, I start by telling the NES to set the scroll to where the header bar is.
Once it's drawn, I reset the scrolling to point to the correct position on the left half.


I finally broke down today and wrote routines for my game that let me do some primitive on-screen debug messages, displaying decimal versions of values using the player score headers. That will help, I hope.