MS. PAC-MAN for Intellivision ROM now available!

[freewheel]

i would rather have variants than an "upgrade". But that just me. Some people like box and manual variants, i like rom variants.

 

Given that people are already justifiably concerned about this hobby getting out of hand with sub-par games seeing releases (and making it very expensive to acquire an entire collection), I'm pretty sure releasing variants just to correct a single bug would tick an awful lot of people off.

 

Also, you'd still have a ROM variant in this case. A patched ROM would be what you'd end up using to upgrade your cart with. That's the simplest way, anyway (yeah, inline ROM patching exists on other platforms but that's more difficult than just replacing an entire file outright, generally).

[freewheel]

 

Testing is easy. Especially in these times. Simply make the game available (hello… eMail in a matter of seconds to anyone in the world?) to a variety of qualified (can test on real hardware) people during various stages of development. My thoughts on this topic are validated and solidified as more and more bugs surface with each and every release. Simply too many games being "rushed" (do not need to hear how many hours were put into something and tested by one person) before being fully tested and put into production before revisions are finally realized. No apologies as it's the truth.

 

I obviously can't speak for every developer out there, but is this really that common? Games being developed and tested by a single individual? My understanding, at least from a lot of the recent releases, is that a group of testers is exactly what's being utilized.

 

I think you underestimate just how difficult it is to spot every last bug. Obviously it's easy in hindsight to point fingers (every bug looks obvious once you notice it), but I've yet to see a truly bug-free game even in the relatively simple 8-bit era - and in some cases, these things were tested by dozens of people whose fulltime job it was to test them out.

 

I can't argue with you about this one, however:

 

Doesn't help that we're living in times where hardly anybody can admit fault or take responsibility for anything.

Edited April 2, 2015 by freeweed

[+save2600]

 

I think you underestimate just how difficult it is to spot every last bug.

Guess so. And I'll stop kicking the dead horse now.

[pimpmaul69]

 

Testing is easy. Especially in these times. Simply make the game available (hello eMail in a matter of seconds to anyone in the world?) to a variety of qualified (can test on real hardware) people during various stages of development. My thoughts on this topic are validated and solidified as more and more bugs surface with each and every release. Simply too many games being "rushed" (do not need to hear how many hours were put into something and tested by one person) before being fully tested and put into production before revisions are finally realized. No apologies as it's the truth. Some Intellivision games as of late have had such "silent" revisions made already. Doesn't help that we're living in times where hardly anybody can admit fault or take responsibility for anything. So flame away and continue to make excuses. Most all of us will continue to support any and all releases because that's what we do AND some of us actually buy into the hope (that by making the all important purchase) that authors might support their products and/or learn from their mistakes. The hope that some may make revisions, just so we can wash, rinse and repeat. Hell, most all of us are happy to plunk down more cash for said revision - not even asking for an exchange or "field upgrade". We're that dumb. Or loyal. Or hopeful. Or whatever.

i feel that most intellivision "homebrew" games arent as rushed as you feel. Without video this error would be really easy to miss. When beta testing videos arent generally made that would allow noticing such an odd error. I think they go through more testing than games made back in the day did. As a beta tester for several intv games i have seen what goes into testing them. You would be surprised how many fixes are made to give you the wonderful experience you get when the game reaches you. Not to be negative towards you, but having seen previous posts of yours i have never seen anyone else demand (pester about?) a flawless game the way i have seen you do. Most people can understand if a small glitch arises. I understand if you talk about a ton of crap being pumped out on atari but there is far less games with far less crap being released on intellivision. I really would like to know what intellivision games that you feel were rushed. (Besides blix). Other than blix, i cant think of one thats been released that i would feel was rushed. Again not trying to argue, just trying to understand your thoughts towards the situation. Edited April 2, 2015 by pimpmaul69

[+DZ-Jay]

i feel that most intellivision "homebrew" games arent as rushed as you feel. Without video this error would be really easy to miss. When beta testing videos arent generally made that would allow noticing such an odd error. I think they go through more testing than games made back in the day did. As a beta tester for several intv games i have seen what goes into testing them. You would be surprised how many fixes are made to give you the wonderful experience you get when the game reaches you. Not to be negative towards you, but having seen previous posts of yours i have never seen anyone else demand (pester about?) a flawless game the way i have seen you do. Most people can understand if a small glitch arises. I understand if you talk about a ton of crap being pumped out on atari but there is far less games with far less crap being released on intellivision. I really would like to know what intellivision games that you feel were rushed. (Besides blix). Other than blix, i cant think of one thats been released that i would feel was rushed. Again not trying to argue, just trying to understand your thoughts towards the situation.

 

I think his point is that, when he asked about testing, he was ridiculed and told that there were no bugs, period. I agree that such hubris is not conducive to the general well-being of the community. Especially when the defect is not some esoteric behaviour, but a violation of one of the most basic and well understood rules of the game: scoring.

 

I also agree that most games are tested by far too few individuals, and not rigorously or systematically enough. That is understandable for a hobby, but then let's take responsibility for that, learn from it and improve our methods, rather than just brush it off.

 

All that said, us authors need to decide how we want to treat this community: If as a hobby, then lets embrace it and ask for help during testing, let's spread the effort as far and wide as possible. Have the community take ownership for the detection of defects, or for coming up with better mechanisms and procedures for thorough testing.

 

If as a business, on the other hand, then justify the secrecy and control by taking responsibility for the quality of the resulting product and customer service.

 

-dZ.

[+save2600]

@pimpmaul: that's why I put the word rushed in quotes. Just generalizing and not pointing to this release necessarily, but something that can get misconstrued when bugs add up or revision changes are made after any game is released.

 

Oh and Lost Caves is one such example that received a revision in the middle of its production, so maybe now that such a bug that effects scoring reared its ugly head, we'll see a revision with Ms. Pac. She certainly deserves it. And would be especially wonderful if the ghost change timing gets tweaked along with it.

 

 

Again, I hope the context of my posts, as it relates to criticisms or observations, aren't seen as attacks or anything else along those lines. I am an avid supporter of the hobby, with both my checkbook and passion for the games. Just hope that some messages get through over time so the hobby can continue to move forward and quality releases are allowed to continue to flow.

 

Perhaps dZ more eloquently sums up my thoughts above.

[+DZ-Jay]

I also do not want my comment to be construed as criticism about Carl's game specifically. It was mostly a general comment in response to pimpmaul's and save2600's. It was just convenient to post it here.

Edited April 2, 2015 by DZ-Jay

[m-crew]

Still one of the best games ever produced for intellivision system.. period.!!! enjoy.. Does really adding another 1000,2000,10000 to the finial score of your game really matter.. Even if you are having a high score comp... everyone is playing with the same.. Enjoy ... I really never even noticed ... just to evolved in game play..

[freewheel]

All that said, us authors need to decide how we want to treat this community: If as a hobby, then lets embrace it and ask for help during testing, let's spread the effort as far and wide as possible. Have the community take ownership for the detection of defects, or for coming up with better mechanisms and procedures for thorough testing.

 

If as a business, on the other hand, then justify the secrecy and control by taking responsibility for the quality of the resulting product and customer service.

 

Probably the best way to approach this. I think it's possible to have a bit too much fear about sharing information in this community, which is unfortunate.

 

Still one of the best games ever produced for intellivision system.. period.!!! enjoy.. Does really adding another 1000,2000,10000 to the finial score of your game really matter..

 

To be fair, Ms. Pac only has about 7 things (depending on how we look at the fruit) that contribute to your score. Being off on one of them is a fairly big "ouch" if you're trying to make a spot-on port. It's actually one of the reasons I'm not a fan of ports in general - you have to get everything EXACT or you're crucified - but that's what this community seems to drool over, so... we kind of bring it upon ourselves.

[Greg2600]

As good as this game is, Mr. Mueller did not invent Ms. Pac-Man. He's recreated the arcade classic. Yes the result is glorious, like several of the ports on 7800 Bob D. has done. But porting a legendary game, and designing a game from scratch are not quite the same thing.

[skosh]

As good as this game is, Mr. Mueller did not invent Ms. Pac-Man. He's recreated the arcade classic. Yes the result is glorious, like several of the ports on 7800 Bob D. has done. But porting a legendary game, and designing a game from scratch are not quite the same thing.

 

Is saying something like this productive? Here we are in a thread where a rom is available that is normally not the case for some homebrews as an option and folks are noting a scoring flaw and your trying to further diminish his work by saying porting is not like designing. In some ways reading this thread is sad. You give praise then take a poke/jab . Kind of like a sucker punch if you ask me.

 

DZ-Jay... your comments are also confusing as I doubt that just adding folks to find a bug would happen considering it would need a bit of effort. Just throwing bodies at a problem does not solve or find the problem when proper testing skils / test plans / etc are in place. I think basically what happened is people played the game and said "OMG" what a nice job on the Intv.

 

Save2600 - I guess you would of caught the flaw

[m-crew]

played again tonight .. tried to catch the flaw even knowing there was one.. And Dam I couldn't. to play and notice that it didn't add it right is virtually impossible .. especially when your watching the game play and every thing adds right on there... ..This issue is really not even worth discussing in my opinion.. but to each there own...

 

Thanks again Carl.... Your effort is much appreciated..

 

Oh-is this getting to be another overlay thread.. Nothing in life is perfect.. perfect is imperfections.. Just enjoy and look to the positive side of things.... now pass me a beer and put the game on...

Edited April 3, 2015 by m-crew

[+DZ-Jay]

DZ-Jay... your comments are also confusing as I doubt that just adding folks to find a bug would happen considering it would need a bit of effort. Just throwing bodies at a problem does not solve or find the problem when proper testing skils / test plans / etc are in place. I think basically what happened is people played the game and said "OMG" what a nice job on the Intv.

 

 

Read it again, here are some key points:

 

 

I also agree that most games are tested by far too few individuals, and not rigorously or systematically enough.

 

 

 

Have the community take ownership for the detection of defects, or for coming up with better mechanisms and procedures for thorough testing.

 

It's not just "adding bodies," it's testing smarter. Just to beat a dead horse, as a convenient example but not really as the poster child of problematic releases; if you had something as simple as:

 

Test Plan:

• Scoring
  • Normal: dots, fruits, power-pill
  • Bonus: 1x, 2x, 3, 4x ghosts
• Ghost path finding
• Power-pill timing
• Extra life awards
• Speed/handling/cornering
• Chase/Scatter/Frightened state switches

You could split that among testers, each one concentrating on a particular use case, aspect, or behaviour. That would soon uncover a rather basic scoring error.

 

However, this is not how we do testing. We gather a few friends and say "play!" Sure we need some of that too, but the most fundamental, systematic testing is not done, or done superficially.

 

It's not about testing more, it's about testing smarter.

 

-dZ.

[+intvsteve]

Testing is not easy. In fact, it's quite the opposite.

 

In the Boulder Dash testing process we did targeted testing. We had testers of varying levels of skill and familiarity with the original game, and with access to different kinds of hardware (e.g. PAL consoles). Those with better playing skills / familiarity focused on how "playable" and how difficult gameplay was. Others focused on feature interactions (1 player / 2 player / controller modes / game options). Some tested exclusively on PAL or compared PAL to NTSC. Everyone provided feedback even on areas outside their 'official' roles. Sometimes someone unfamiliar with the original game (in the case of a port) can see something overlooked by others, even if it's only a matter of documentation to clarify a point. (And having been one of those 'ignorant' testers, I'm sure I've annoyed people with some of my questions and arguments. )

 

I've been fortunate enough to be part of testing several games now, even making a small code contribution to one. I wish I had more time to devote to it - as most of the testers do. How you test depends on a lot of things. If the game's a strict port, it's far, far different than a brand new, original game. If it's a sequel or associated with a franchise, other aspects come into play, such as whether the game "feels" like it belongs in the canon of the franchise, has features people would expect, et. al.

 

Even with all the best-laid plans, reality interferes. Bugs remain undiscovered until too late or post-ship. Some testers simply won't have time.

 

Having a large pool of testers often proves to be one of the worst approaches to testing. It's a case of "Oh, there are so many testers, I'm sure someone else will do it. I just don't have time." I've seen that happen. Sometimes I've even been guilty of falling into that same trap. The more successful efforts have been small groups with high participation rates, and a game with well-defined features. Not everyone needs to play 5 hours a day. Often a good deal of focused testing for just 30 minutes a couple nights a week is highly valuable. Too often, free-form testing just turns into feature requests.

 

Though it isn't always easy to do, having 'development mode' features available in the test versions of the game is invaluable as well. Doing this does introduce risk of more bugs, and does require an extra round of true "release" testing. But it also allows for testing modes that few or only expert players could reach in the final release. Sometimes those features remain as Easter Eggs. But the old saw about designing for testability holds true -- it helps a great deal.

 

--

 

In any event, this thread is really about Ms. Pac-Man and its ROM being available. If you haven't gotten it, buy it. It's worth it.

 

It's an impressive game, and a great deal of fun to play. The fact that you can get this as a ROM to play in emulation or on your multicart is wonderful, and makes the game accessible to an even larger audience, which a lot of people complain about w.r.t. other titles.

 

There's a scoring bug on the cartridge release. Unfortunate. That doesn't diminish how fun the game is, for me at least. But here's an honest question: If the scoring bug is addressed in the ROM release, then does that mean there must be two separate HSCs? One for cart-only players, and one for ROM release players?

[Games For Your Intellivision]

@pimpmaul: that's why I put the word rushed in quotes. Just generalizing and not pointing to this release necessarily, but something that can get misconstrued when bugs add up or revision changes are made after any game is released.

 

Oh and Lost Caves is one such example that received a revision in the middle of its production, so maybe now that such a bug that effects scoring reared its ugly head, we'll see a revision with Ms. Pac. She certainly deserves it. And would be especially wonderful if the ghost change timing gets tweaked along with it.

 

 

Again, I hope the context of my posts, as it relates to criticisms or observations, aren't seen as attacks or anything else along those lines. I am an avid supporter of the hobby, with both my checkbook and passion for the games. Just hope that some messages get through over time so the hobby can continue to move forward and quality releases are allowed to continue to flow.

 

Perhaps dZ more eloquently sums up my thoughts above.

 

The Lost Caves of Kroz indeed had a revision done, but it was not because the game was broken. It was done because of a design decision. It was not changed because of some bug. The difficulty of ONE room was slightly adjusted.

 

It is no different than a running change done on Auto Racing when Mattel found out that the steering was better (in their opinion) 'intuitive, or with Armor Battle when they felt the tanks needed speeding up or in Space Battle when it needed to be made more difficult.

 

The Lost Caves of Kroz works and can be completed. The new version has a slightly redesigned room. It is not something that needs to be 'swapped out' with the first copies. If you collect all variants then buy both. However, I think it is unfair to say that the game wasn't put through its paces enough. The game was exhaustively tested.

[+save2600]

I think it is unfair to say that the game wasn't put through its paces enough. The game was exhaustively tested.

 

Okay, fair enough, but I was mostly pointing out that at least one game did end up receiving a physical revision in the middle of production... Hoping Ms. Pac-Man gets the same treatment.

 

I can't be the only one that believes/feels that such a scoring bug *is* a big enough deal that warrants an exchange. Or heck, some of us would be fine with just the chip. Perfectly capable and willing to desolder the old, etc.

[intvnut]

When beta testing videos arent generally made that would allow noticing such an odd error.

 

Fun fact: On at least one game I assisted with, we actually managed to capture an Intellivision hardware bug on video, and worked around it in software. (I think I posted about it on AA, but can't find the thread. This is a different hardware bug than the flip-to-colorstack bug.) The hardware glitch turns out to have some interesting electrical properties that cause it not to appear on all systems, or at all times on the same system. But, for one of our testers, his system showed the glitch reliably, and with a video in hand I was able to meditate on possible causes and eventually reproduce it with a targeted test, and then go tweak the game to eliminate the glitch.

 

I remember reading somewhere that back in the day some shops would use a VCR to capture gameplay and then go back and review the tape for issues. Still, this stuff takes going over with a fine-toothed comb. dZ mentions building a test plan and then executing to the plan. That is an excellent idea. However, even the best laid test plans can have gaps. I say this after earning my stripes writing some rather creative and brutal chip validation programs that caught test escapes on real, complex systems on a chip produced by my employer. (Ok, that's maybe a bit more hardcore than homebrew video games. But, even when there's millions of $$ on the line, bugs slip through.)

 

With Space Patrol, I remember using jzIntv's "movie" feature to record stretches of gameplay that I would then pore over frame-by-frame. Especially tough was getting the "apply deferred score on successfully landing" logic, when jumping over craters, rocks and land mines. Oy. Especially tough if you die right near landing. I earned a few grey hairs debugging that logic.

 

I'll reiterate what many others have said: TESTING IS HARD.

 

Space Patrol shipped with at least one (harmless but amusing) bug. Sad thing is, I've tried to fix it and I still haven't figured out what's going wrong. Testing is hard, but fixing bugs is sometimes harder!

 

If you're curious what the bug is, highlight the text below. (I haven't really tried to keep it a secret, FWIW, and find the quirk strangely endearing. I white it out only for those who want to maintain a fiction it's bug free. )

 

If you hit fire just as the game restarts after dying, the horizontal bullet that the tank shoots comes out of the left border of the screen rather than out of the tank's front cannon.

 

As for the Elektronite games I've assisted: I can attest to the brutality and thoroughness of the testing. I've put in my own forms of testing, although admittedly, it's been focused on specific elements more than overall gameplay. Elektronite has some truly skilled gamers in their tester roster. I'm quite happy to claim a hardware and technical support credit in lieu of a tester credit. Those testers are good.

 

_____________________________________________________________

 

For those interested/curious about the hardware bug: It has to do with sequences of uninterruptible instructions. The Intellivision requires code to have interruptible instructions every so often to allow the STIC to fetch a new row of BACKTAB cards from the RA-3-9600 system RAM. It turns out in certain circumstances, you can get a glitch where the leftmost card on a row gets corrupted with garbage for a single display frame if you're on the hairy edge of the maximum amount of non-interruptible time the STIC tolerates. That said, I think there must be some other ingredients, because we had to crank our "max allowed non-interruptible instruction" threshold way down to something like 44 cycles to eradicate the glitch, while the STIC routinely copes with much larger thresholds.

 

When the glitch happens, it takes a recent value that had been written to system RAM and uses it instead of the value fetched from system RAM for the leftmost card. If you run a test that exposes the glitch in a tight loop, the glitch will show up for several seconds and then eventually fade away. This hints at some weird electrical issue in the RA-3-9600 and the logic that switches its internal buses around. Bleh.

Edited April 4, 2015 by intvnut

[+JasonlikesINTV]

Out of curiosity, let's say people willing to return their old Ms Pacman PCB for an upgrade or simply purchase an upgraded one. Would this be feasible? Or too much effort and cost? I'd probably pay a good $5-10 for a replacement PCB. Just a thought.

 

When if another multicart ever releases this will be less of an issue for those who buy/bought the ROM.

[intvnut]

When if another multicart ever releases this will be less of an issue for those who buy/bought the ROM.

 

When if another multicart ever releases....

 

FTFY.

[Carl Mueller Jr]

Bump :-)

[freewheel]

 

When if another multicart ever releases....

 

FTFY.

 

When we get into multi-year waits, it reverts back to if

[intvnut]

 

When we get into multi-year waits, it reverts back to if

 

Not when the production run is sitting in my living room and I'm wrangling fulfillment options...

Edited October 12, 2015 by intvnut

[freewheel]

 

Not when the production run is sitting in my living room and I'm wrangling fulfillment options...

 

Option 1: sell them.

Option 2: don't.

 

Option 3: Release only 60 30.

 

The suspense is killing me!

[bikeguychicago]

 

Fun fact: On at least one game I assisted with, we actually managed to capture an Intellivision hardware bug on video, and worked around it in software. (I think I posted about it on AA, but can't find the thread. This is a different hardware bug than the flip-to-colorstack bug.) The hardware glitch turns out to have some interesting electrical properties that cause it not to appear on all systems, or at all times on the same system. But, for one of our testers, his system showed the glitch reliably, and with a video in hand I was able to meditate on possible causes and eventually reproduce it with a targeted test, and then go tweak the game to eliminate the glitch.

 

I remember reading somewhere that back in the day some shops would use a VCR to capture gameplay and then go back and review the tape for issues. Still, this stuff takes going over with a fine-toothed comb. dZ mentions building a test plan and then executing to the plan. That is an excellent idea. However, even the best laid test plans can have gaps. I say this after earning my stripes writing some rather creative and brutal chip validation programs that caught test escapes on real, complex systems on a chip produced by my employer. (Ok, that's maybe a bit more hardcore than homebrew video games. But, even when there's millions of $$ on the line, bugs slip through.)

 

With Space Patrol, I remember using jzIntv's "movie" feature to record stretches of gameplay that I would then pore over frame-by-frame. Especially tough was getting the "apply deferred score on successfully landing" logic, when jumping over craters, rocks and land mines. Oy. Especially tough if you die right near landing. I earned a few grey hairs debugging that logic.

 

I'll reiterate what many others have said: TESTING IS HARD.

 

Space Patrol shipped with at least one (harmless but amusing) bug. Sad thing is, I've tried to fix it and I still haven't figured out what's going wrong. Testing is hard, but fixing bugs is sometimes harder!

 

If you're curious what the bug is, highlight the text below. (I haven't really tried to keep it a secret, FWIW, and find the quirk strangely endearing. I white it out only for those who want to maintain a fiction it's bug free. )

 

If you hit fire just as the game restarts after dying, the horizontal bullet that the tank shoots comes out of the left border of the screen rather than out of the tank's front cannon.

 

As for the Elektronite games I've assisted: I can attest to the brutality and thoroughness of the testing. I've put in my own forms of testing, although admittedly, it's been focused on specific elements more than overall gameplay. Elektronite has some truly skilled gamers in their tester roster. I'm quite happy to claim a hardware and technical support credit in lieu of a tester credit. Those testers are good.

 

_____________________________________________________________

 

For those interested/curious about the hardware bug: It has to do with sequences of uninterruptible instructions. The Intellivision requires code to have interruptible instructions every so often to allow the STIC to fetch a new row of BACKTAB cards from the RA-3-9600 system RAM. It turns out in certain circumstances, you can get a glitch where the leftmost card on a row gets corrupted with garbage for a single display frame if you're on the hairy edge of the maximum amount of non-interruptible time the STIC tolerates. That said, I think there must be some other ingredients, because we had to crank our "max allowed non-interruptible instruction" threshold way down to something like 44 cycles to eradicate the glitch, while the STIC routinely copes with much larger thresholds.

 

When the glitch happens, it takes a recent value that had been written to system RAM and uses it instead of the value fetched from system RAM for the leftmost card. If you run a test that exposes the glitch in a tight loop, the glitch will show up for several seconds and then eventually fade away. This hints at some weird electrical issue in the RA-3-9600 and the logic that switches its internal buses around. Bleh.

Dave,

 

I work in software QA and we have scripted tests for common functionality that we execute but we also do ad-hoc or exploratory testing as time allows. Sometimes the later finds issues that the scripts don't or wouldn't cover. Our exploratory testing is usually time-boxed for a specific amount of time.

 

For your testing, I would suggest a combination of both forms of testing if time allows. Feel free to contact me if you have any questions or are looking for additional testers.

 

Thanks!

Keith Sheehan

[+DZ-Jay]

dZ mentions building a test plan and then executing to the plan. That is an excellent idea. However, even the best laid test plans can have gaps. I say this after earning my stripes writing some rather creative and brutal chip validation programs that caught test escapes on real, complex systems on a chip produced by my employer. (Ok, that's maybe a bit more hardcore than homebrew video games. But, even when there's millions of $$ on the line, bugs slip through.)

 

 

All I meant with my comment was that game testing should be more organized and structured that just playing the game and running around the world to see if anything is amiss. Like bikeguychicago suggested, there should still be some of that, but there should also be some discipline and rigor to the initiative, and this commands thorough test cases.

 

I know that my own game could have used a bit of that. I will be the first one to say that Christmas Carol was tested exhaustively for over a year, and that many features and elements were thoroughly drilled in order to polished them to perfection. Still, this thoroughness was not applied evenly to the entire game, which meant that a few stupid little bugs slipped through inadvertently and needlessly. (I mean, a bug that prevents you from entering the boss level?? How could you miss that except, by actually never reaching the boss level during the last round of testing!!)

 

Testing is hard, but it is a discipline on its own. I still stand by the comments I said:

 

 

All that said, us authors need to decide how we want to treat this community: If as a hobby, then lets embrace it and ask for help during testing, let's spread the effort as far and wide as possible. Have the community take ownership for the detection of defects, or for coming up with better mechanisms and procedures for thorough testing.

 

If as a business, on the other hand, then justify the secrecy and control by taking responsibility for the quality of the resulting product and customer service.

 

-dZ.