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.

Tuesday, August 23, 2016

Atari vs NES

It's really interesting to me the differences and similarities between Atari and NES programming. They both use the same 6502 processor (well, a variation on the same processor -- the Atari's is missing a few address lines, and the NES is missing a BCD mode), clocked at similar speeds (the nes is about 50% faster).

But beyond that, things start to diverge.  The most interesting to me is fundamentally where things happen, based on how their video chips work.

On the Atari, the video chip (the TIA) is designed to handle a scanline at a time. Which means that, like I've mentioned before, the whole time your TV is drawing, you spend that time babysitting the process, using all your processing time updating each scanline.  Then during vblank (the time the TV is repositioning the electron beam), you get to hurry and do your game logic updates.

On the NES, it's practically the opposite. The video chip (the PPU) is designed to handle a whole frame at a time (GASP!).  So during rendering, unless you're doing any fancy effects, you get all that time free to do your game logic updates, while the PPU does its thing in the background. Then during vblank, you hurry to push new data to the PPU so its ready for the next frame.

There's still hurrying involved in the NES -- there can be a lot of data that you want to shove into the PPU (new tiles for scrolling, etc), and not a lot of time to do it (most video data has to passed to the PPU over a janky serial interface, written one byte at a time), but compared to the Atari, I feel like I have EONS of time to work with.

It also helps having more RAM than I know what to do with. The Atari had 128 bytes. The NES has 2048 bytes. (Two whole kilobytes!)  It's crazy town.

There's still some challenges. Talking to the PPU is weird, you're limited to only 8 sprites per scanline, mid-screen scrolling (ie if you want to add a status bar) is tricky.  But so far, it's a different world.

Sunday, August 7, 2016

NES Game and LiveCoding

Well, I started messing around with making a NES game. I'm not sure I'm ready to tackle another big project right now, and there's still bits of work to be done with Atari Anguna (mostly fixing bugs as they get reported, then getting it ready for production), so I'm doing a little project:  sort of a simple 4-player space race game.

Tonight's tasks was writing the code to support the 4-player adapter, and scrolling the starfield.


The fun part is that I thought I'd try LiveCoding it, which is basically where you live stream yourself writing code and explaining it as you do.  I've tried this for the past 3 nights.  It's a really weird experience.

First, I don't know why anybody would want to watch someone code. I mean, at least watching someone stream video games is interesting because there's a lot of action. Coding is mostly thinking and typing.

Second, it's REALLY HARD.  Now I'm trying to do all my thinking out loud. Which is a really weird process.  Everything feels blurry and sluggish in my head. I feel like I'm not coding well, and not explaining well.  Maybe it gets easier, I don't know.  Then on top of that, trying to actually be somewhat entertaining while coding and talking?  Yeah right.

Third, I'm used to writing my hobby game code in the late evenings, as a way to sort of wind down. Only this doesn't wind me down, it winds me up. I've been finishing a bit after 11, and I'm all jittery and high-strung. There's just no way I can go to bed after spending an hour performing for strangers on the internet.  And I can't really do it sitting next to my wife on the couch as she watches TV, which is normally where the coding happens.

So I don't know how long this will last. On the one hand, it's tons of fun, because I have an audience. On the other, it's exhausting.  But hey, I might as well have fun with it for now.



Friday, July 29, 2016

Finished world map

Well, I'm still making a few tweaks (the most recent was based on feedback that the off-centered sword was annoying, so I made the sword centered by default, but let you use the difficulty switches to change it back to the old off-centered setting), but thought I'd share the final finished world map: