py.

When Jeff and I were getting ready to release the game we had a bit of a
heated exchange about the game difficulty. It seemed a bit too hard at
first and he thought we should turn it down a bit for the party so that
people would enjoy it more. After we tweaked the difficulty I always
thought it was too easy. Oddly, when I play the original Pacman on MAME I
get about the same score across both versions. One of the things that we
were doing to make the game harder was decreasing the chase/scatter timer,
such that there was a larger period of time when the ghosts were chasing
you vs. heading back to their "home" tiles.

I know a few areas where the ghost AI is mismatched to the arcade. I
really want to dig back into the game and make sure it's correct. I
believe it's possible for the vector math on Inky to overflow and have it
mess up his targeting tile. In "frightened mode" the random direction selection isn't working properly. Also, the order in which ghosts evaluate their moves when two moves are tied for the shortest Euclidean distance to their target tile is different than the arcade. I think this is causing
there to be more than one hiding spot in the maze. The arcade has one legitimate hiding spot.

One thing that would help make the game harder is the faster version I am working on. When you have less time to plan your moves things get a lot
more hectic. I have it running at the full 50 or 60 frames now, but I need
to rework the timing constants for the relative speeds of Pacman and ghosts
on different skill levels before I can release it.

- - - - - - - - - -

Q. How accurate do you think the game is to this version?

A. Hmm... well, it's got to be at least 50% correct. Clyde is supposed
to return to his home tile if he gets too close to Pacman. I made him
return to the opposite Cartesian coordinate area of the screen. I thought
that might make him more interesting. Pinky has a bug in the arcade that I
did not reproduce but rather coded up his intended logic. Inky needs some
more testing to feel 100%. The game does include the two "speed-up" modes where Blinky will increase his speed during a level. This is accompanied
by an increase in the siren pitch.

- - - - - - - - - -

Q. How limited were you with the VIC's hardware. For example, trying to
get the maze to fit the screen and still be faithful to the original. Was
this a challenge?

A. You'll notice the maze has a weird spot in the middle. To match the proportions of the arcade on the VIC the whole maze would need to be
narrower. I didn't like the narrower maze as it didn't leave enough room
in the ghost box for all ghosts to display. The wider maze made some
corridors longer than they should have been. They would not allow you to
reach an escape passage quickly enough. This is why I made the middle
pylons a little larger - to reduce the longest run that Pacman would have before he could turn.

When playing the game on the emulator the non-square pixels of the VIC
really seem to make the apparent speed of Pacman change drastically when changing directions from vertical to horizontal. For some reason, on the
real hardware on a CRT it doesn't seem as bad. I was pleased about that
the first time I played on a CRT. At one point I wondered if it would be
worth altering the horizontal vs. vertical speed to compensate for the
VIC's non-square pixels.

Memory is a brutal taskmaster on the VIC - there is rarely enough,
although, as you pointed out in Issue 79 with the Pulse game, miracles are possible, even in the unexpanded 3.5K.

- - - - - - - - - -

Q. The whole game feels very polished. Was this your first real
programming attempt?

A. The VIC did lead into a programming career. I guess the inventors of
those first machines should feel proud of that; they inspired a lot of
future programmers. I was doing some C++ for a telecommunication company
by 1991. This was the first 6502 assembly project I had ever attempted. I must say - oh my goodness - what a learning experience! I have so much appreciation for how tedious it must have been back in the day. Those guys worked so hard. I think they were some really unsung pioneers of their
time.

- - - - - - - - - -

Q. What do you have planned next? Will it be another port, or do you have
an original game idea you plan to unleash?

A. Everyone loves a cover band - and everyone also loves remakes of
classic 80s arcade games. It's a shared cultural experience we all have.
I would like to pick one of the "Games We'd Like to See" from the list on
the Denial community and take a shot at it. Maybe Wizard of Wor or
Elevator Action would be fun.

- - - - - - - - - -

Q. You mentioned the Denial community. How important was the VIC
community to the project? Would you have just given up without proper
support from the community?

A. When I started the project I tried a promise to not use any resources
from the internet because I wanted it to be like 1982, where all I had was
a paper-printed book to thumb through. I was about 80% successful staying
away from the Internet - until I needed some help. What I love about the community is knowing there is a gathering of people who still use the
system. That makes all the difference. The VIC20 Denial website was a big inspiration and Robert Hurst's amazing collection of VIC20 games inspired
me to try.

- - - - - - - - - -

Q. So the community is an ideal forum for tweaking and helping to spot
bugs. Do you plan any other enhancements to the game?

A. I'd like to release a second version of Panicman. I've been working on
one which runs at full speed, and as you mentioned, uses a full 8K to have
the arcade title screen and the full intermission and fruit complement.
The ghosts should be much closer to arcade AI in it, too.

- - - - - - - - - -

Q. If you could go back in time to the point where you started coding the game, would you have done anything differently, or dare to say, would you
have thought "Nah, I won't bother?"

A. Oh, dear! Yes, there is so much I'd like to do differently. I always thought that when doing a hobby project you could have everything the way
you want it - unlike our day jobs. Well, it's not completely true. Once someone makes a "deadline" for you as I did with the self-enforced date of release, things start to have compromises just like the day job. I would
have preferred using an assembler with a linker because that would have
made compiling for different VIC memory footprints easier. I wish I could
have had time to fix the EMACS mode for DASM so that it would indent
properly. It really got frustrating. I would have liked to try some interlacing techniques to do something about the colour clash.

- - - - - - - - - -

Q. Many readers will ask about the tools, software, etc., you used to
create the game. What tools did you use?

A. One of my early goals was I was not using the built-in debugger in the WinVICE emulator. I made it about 75% of the way through the project
before I cried "Uncle!" on that. The tool set was EMACS Editor, DASM Assembler, SVN Source Code Control. I used some Perl scripts to generate
the compressed data for the maze and perform the bit rotations for the different frames of Pacman. Jeff would prototype his music directly in Commodore BASIC, sometimes with the assistance of an Excel spreadsheet. I alternated between using Windows and Linux, depending on whether I was at
home or ... Ahem, at my "day job."

- - - - - - - - - -

Q. With so many tools available and cross-assembly being used, do you
think it's easier to program the VIC now, or do these tools just make
things faster?

A. That is a good question. I think it makes things faster mostly. I jokingly refer to the assembler as the "Quantum Assembler." With modern PCs it's done assembling before you even hit the Enter key. Certainly some
things I woul

--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair ---:- bbs.vk3heg.net -:--- (39:901/280)