Hive multi-cart - It's alive!

[freewheel]

You'd have to be pretty mad to go from emulation only straight to CIB .

 

Yup. That's why people are clammoring for a multicart

[+DZ-Jay]

Chances are it will *work*, but unfortunately most of us don't have a 16-way controller disc hooked to our PCs

 

(Some) people here scream when a scoring mechanism is off by a few points. Imagine the pitchforks if someone released a CIB game designed around 4 discrete directional controls.

You mean like Donkey Kong Arcade, D2K, Space Patrol, Mrs. Pac-Man, Boulder Dash, or Christmas Carol?

[GroovyBee]

You mean like Donkey Kong Arcade, D2K, Space Patrol, Mrs. Pac-Man, Boulder Dash, or Christmas Carol?

... and Hover Bovver and Apple Snaffle too

[freewheel]

You mean like Donkey Kong Arcade, D2K, Space Patrol, Mrs. Pac-Man, Boulder Dash, or Christmas Carol?

 

These were programmed and tested using only the 4 direction keys on a PC keyboard? Huh. How did everyone manage to deal with the disc behaviour?

Edited May 23, 2015 by freeweed

[+DZ-Jay]

 

These were programmed and tested using only the 4 direction keys on a PC keyboard? Huh. How did everyone manage to deal with the disc behaviour?

 

Yes. I can attest that, in the case of Christmas Carol at least, it was programmed and tested using only the 4 direction keys on a PC keyboard. I even implemented the "fancy" heuristics based on an imagined mental model. When I gave it to Joe Z. to test on hardware for the first time, I was not surprised (though very much relieved) to hear him claim that it worked as good as we expected. Sure, we tested it thoroughly on the console later on, but nothing changed at that point.

 

Nobody here is saying that you should ever go from emulator to cart--that's absurd! However, in my opinion, jzIntv is mature enough to allow for a rather large degree of confidence that your game will work on hardware. Personally, I don't have any qualms implementing and testing in emulation until the last stages of development. In fact, that's how I work.

 

By the way, what do you mean "manage to deal with the disc behaviour?"

 

-dZ.

Edited May 23, 2015 by DZ-Jay

[freewheel]

By the way, what do you mean "manage to deal with the disc behaviour?"

 

 

I thought it was pretty well understood and agreed that the disc behaves a lot differently than people might expect, in terms of trying to isolate discrete directions. There's a "mushiness" to it, simply because it's difficult to every explicitly press "up" or "right" without bringing in some unintentional diagonal input. This is rather different than almost any other control mechanism (d-pad, joystick), where it's a lot more intuitive to the player how to press ONLY up. And just much more isolated because they typically only have 4 diagonals to contend with, not 12.

 

Hence heuristics as you describe.

 

Bully for you to be able to program, test, debug, and implement an entire control scheme that worked flawlessly on real hardware with zero changes afterwards. From both personal and 3rd hand experience (some related on these very forums) I think that's a pretty unrealistic goal for most programmers. Hence the clamoring for a flash cart

[GroovyBee]

As we've discussed before, how you handle the disc controls is entirely governed by your game and the environment the player avatar is in. What works brilliantly in one game might not work for another game style.

[freewheel]

As we've discussed before, how you handle the disc controls is entirely governed by your game and the environment the player avatar is in. What works brilliantly in one game might not work for another game style.

 

Yup. And what works in my head may not work all that well in reality. Sometimes it does, sometimes it doesn't. Hence testing.

 

But I'm a weirdo. The biggest reason I want a hardware test is that jzintv has no scanline emulation (not that this ever truly replicates a CRT screen anyway), and there are some graphical effects I'd like to experiment with.

 

Bring on the flash cart(s)!

[+DZ-Jay]

Bully for you to be able to program, test, debug, and implement an entire control scheme that worked flawlessly on real hardware with zero changes afterwards. From both personal and 3rd hand experience (some related on these very forums) I think that's a pretty unrealistic goal for most programmers. Hence the clamoring for a flash cart

 

Oh, I didn't say it to brag. I thought it was rather a natural effort. I didn't just implement the control scheme to see what happened, I spent a great deal of effort (mostly mental) in designing it. A lot of it came from my previous effort of porting Pac-Man.

 

Honestly, I really would not expect to be unique and brilliant in imagining the 16-to-4 way translation to be the division of the disc into four zones. Here's an illustration from the source code of the P-Machinery framework:

;;  NOTE:   The disc is divided into 4 distinct regions for each of the     ;;
;;          cardinal points. Each region corresponds to 3 discrete disc     ;;
;;          positions, which expressly exclude the diagonals. The resulting ;;
;;          disc layout is illustrated below:                               ;;
;;                                                                          ;;
;;                        F   0   1                                         ;;
;;                   E     N..N..N     2                                    ;;
;;                     x  ';:::::;'  x         Legend:                      ;;
;;                D        ';:::;'        3    -------------                ;;
;;                   W:,     ':'     ,:E       N: North    ^                ;;
;;                   ::::-_   v   _:::::       E: East     >                ;;
;;               C  W::::::"> + <"::::::E  4   S: South    v                ;;
;;                   :::::-'  ^  '-:::::       W: West     <                ;;
;;                   W:-"    ,:,    "-:E       x: Invalid                   ;;
;;                B        .;:::;.        5                                 ;;
;;                     x  ,:::::::,  x                                      ;;
;;                   A     S''S''S     6                                    ;;
;;                        9   8   7                                         ;;
;;                                                                          ;;
;;          If the translated disc input results in one of the invalid      ;;
;;          diagonal values, the disc event will be discarded.              ;;

That, I think, is the standard way of doing 4-way on the Intellivision (some of the classic games do this, and I believe D2K and DK Arcade do it as well). The leap of insight I took was how to handle those four diagonals. Now, the code itself did not change at that point, only the look up decoding table.

 

Of course, I couldn't test the "zones" and the "diagonals" on a keyboard, but the mechanism I implemented was such that the difference between, say, positions $F, $0, $1 (i.e., the "North" zone) was only their numeric value. That is, if the code worked for $0 (i.e., pressing the "Up" arrow on the keyboard), then it must equally work for $F and $1 -- of course, as long as the decoding table was correct.

 

To be sure, there is a lot of faith and trust in a theoretical model there, but this is a game not a nuclear reactor, so the theoretical models are rather simple and the margin of error pretty forgiving. To me it is not such a large leap to assume that if my decoding mechanism works for 4 directions, it will also work identically for the other adjacent 4 -- as long as they are mapped to the same values.

 

 

 

 

But I'm a weirdo. The biggest reason I want a hardware test is that jzintv has no scanline emulation (not that this ever truly replicates a CRT screen anyway), and there are some graphical effects I'd like to experiment with.

 

 

 

Oh, please, please, please, please! Do not turn this into another straw-man argument on the virtues of testing on hardware versus NO TESTING AT ALL. We all want a multi-cart, and we all think they will be a great help for developers too. GroovyBee's and mine comments were in response to this comment:

 

i even would have a new small game in pipeline - could not yet test it on a real intellivision.

 

We just suggested that he at least test in jzIntv, and we offered to test on real hardware for him.

 

-dZ.

Edited May 23, 2015 by DZ-Jay

[freewheel]

 

Oh, please, please, please, please! Do not turn this into another straw-man argument on the virtues of testing on hardware versus NO TESTING AT ALL. We all want a multi-cart, and we all think they will be a great help for developers too. GroovyBee's and mine comments were in response to this comment:

 

 

I'm not. I just think this community too easily brushes off the desire (and need) for developers to test on real hardware while designing a game. Not as a final sanity check, but to see how it actually behaves on real gear - and to develop the game FOR the hardware. Not just for an emulator with some minor tweaks at the end. Maybe I'm weird, but I find control mechanisms often "feel" quite differently when actually using my thumb vs a keyboard. And I'd code a game rather differently for the 2 situations (not just dealing with diagonals, although that's a big one with the Intellivision).

 

When someone makes the comment "I have a game in the pipeline but I can't test on real hardware", I see 2 possible scenarios:

 

1. This person is aware of the development tools and environment, except they know nothing about emulation (or how accurate it is), so they haven't bothered to do much of anything because they have no idea how to even test "Hello, World".

 

2. This person already knows about Nostalgia and/or Bliss and/or jzintv and probably has some amount of code written. And recognizes the limitations involved in not being able to test on real hardware, and this is where things get stalled.

 

You guys frequently answer #1; I comment on #2. Personally I think the latter is a far more likely scenario. *shrug* It's nice that you offer to help someone test their game - I've had a couple dozen offers at this point myself, and it's appreciated - but all that's really going to do is confirm that it works on real hardware the same as in emulation. Obviously a nice assist, but it doesn't address the core reason why a developer gets stalled on these things.

 

I apologize if there is a legion of aspiring coders out there ready, willing, and able to write Intellivision games, that have never heard of emulation (or that have and don't realize how accurate it is). Maybe I'm missing the mark here.

 

Anyway, bring on the flash carts! They're desperately needed

Edited May 23, 2015 by freeweed

[GroovyBee]

I'm not. I just think this community too easily brushes off the desire (and need) for developers to test on real hardware while designing a game. Not as a final sanity check, but to see how it actually behaves on real gear - and to develop the game FOR the hardware. Not just for an emulator with some minor tweaks at the end. Maybe I'm weird, but I find control mechanisms often "feel" quite differently when actually using my thumb vs a keyboard. And I'd code a game rather differently for the 2 situations (not just dealing with diagonals, although that's a big one with the Intellivision).

The time spent refining your input control method is likely to be very small in the grand scheme of making the whole game. You'll spend much more time laying out levels, tweaking graphics/animation and working on your game logic/AI/collisions and special effects. Nobody is disagreeing with you about the importance of testing your control method on real hardware. However, both DZ-Jay and I have similar working methodologies that don't have a high reliance on continual testing on the hardware. Once you get to know the platform you spend less time fighting with it, and more time being productive and getting on with your tasks at hand. Unless of course you are pushing the system or trying out new tricks.

 

It's nice that you offer to help someone test their game - I've had a couple dozen offers at this point myself, and it's appreciated - but all that's really going to do is confirm that it works on real hardware the same as in emulation. Obviously a nice assist, but it doesn't address the core reason why a developer gets stalled on these things.

Not all beta testers are created equal . If somebody asks me to test something that is exactly what I'll do. If its control method is wonky or erratic I'll say so and suggest improvements. If the game crashes I'll try and find out why. The same critiques will be applied to logic/AI/FX level layout problems and so on and so on. The game will be put under a microscope in exactly the same that my own games are during their development.

 

I apologize if there is a legion of aspiring coders out there ready, willing, and able to write Intellivision games, that have never heard of emulation (or that have and don't realize how accurate it is). Maybe I'm missing the mark here.

There are traditionalists in any scene but luckily, they are few and far between .

[freewheel]

The time spent refining your input control method is likely to be very small in the grand scheme of making the whole game. You'll spend much more time laying out levels, tweaking graphics/animation and working on your game logic/AI/collisions and special effects. Nobody is disagreeing with you about the importance of testing your control method on real hardware. However, both DZ-Jay and I have similar working methodologies that don't have a high reliance on continual testing on the hardware.

 

Overall? Obviously. Input design is probably a fair bit less than 1% of any game development effort. But the industry is absolutely chock-full of otherwise decent games with godawful control schemes - and it really shows how little actual time was spent in front of "the real thing" making sure the game was actually enjoyable to play. Control isn't an afterthought - in a fun game, it's one of the most critical things to get as close to perfect as possible. You can screw up a graphic and not ruin a game. You can have bad music/sounds and still enjoy a game (hi Blix!). Screw up your controls and the game is basically a turd. Just ask Mattel - they re-issued at least 2 games because the end-user disagreed with what, to the developers, "felt right" in terms of input. Granted that one of these had nothing to do with the controllers per se, but the same idea holds true.

 

Anyway, my real point is and has always been that what works for you doesn't necessarily work for others. Perhaps the 2 of you are very gifted and have the "knack" for banging out responsive, consistent, and accurate controls without a lot of hands-on testing. My experience after playing thousands of games in my life is that most developers do not share your talents. I certainly do not A lot of people have different working methodologies than yourselves. Sometimes for good reason, sometimes just because we ain't that good at this. But you can't just hand-wave it away with "eh, I don't work that way, so neither should you".

 

And I'm still dying to see my games on a CRT. Maybe I'm the last of a dying breed, but looking at blocky pixels on a high-resolution LCD screen doesn't really give me a true sense of what the final game will look like.

[GroovyBee]

The other key part in game development, in my experience, is to find honest beta testers that will tell you that you have any problems in your games. Without a 2nd, 3rd, 4th... set of eyes on your game you can just get used to how things are way too easily because you want to get on with the fun stuff. Taking on board constructive feedback and doing something with it, usually makes for better games. Obviously, there are cases where you can't/won't implement new suggestions, maybe its because there are resource constraints, or it doesn't fit with your vision and so on. I've had long discussions with nonner242 (my team's pixel artist) about certain aspects of our games and sometimes I just didn't get his vision but implemented it anyway and the game was always better for it . So don't throw ideas away just because you don't like them or don't get it.

[+DZ-Jay]

 

I'm not. I just think this community too easily brushes off the desire (and need) for developers to test on real hardware while designing a game. Not as a final sanity check, but to see how it actually behaves on real gear - and to develop the game FOR the hardware. Not just for an emulator with some minor tweaks at the end. Maybe I'm weird, but I find control mechanisms often "feel" quite differently when actually using my thumb vs a keyboard. And I'd code a game rather differently for the 2 situations (not just dealing with diagonals, although that's a big one with the Intellivision).

 

 

Hmmm... To each his own, I guess. I really don't mean to argue with you because we are usually mostly on the same page and, as they say, horses for courses. Personally, when I design games for the Intellivision, they are designed for the actual console--a machine I grew up with, and which with I am intimately acquainted. I can hold the constraints, limitations, and style in my mind while I design and implement it, and the emulator does a good enough job of giving the "feel" of the machine.

 

Again, I do not think this makes me any more special, it's just a matter of style. I guess it's different if you program for multiple platforms, of which the Intellivision is just one more, and not necessarily ingrained in your psyche.

 

Cheers!

- j.

[+DZ-Jay]

 

Overall? Obviously. Input design is probably a fair bit less than 1% of any game development effort. But the industry is absolutely chock-full of otherwise decent games with godawful control schemes - and it really shows how little actual time was spent in front of "the real thing" making sure the game was actually enjoyable to play. Control isn't an afterthought - in a fun game, it's one of the most critical things to get as close to perfect as possible. You can screw up a graphic and not ruin a game.

 

I guess my saving grace, and perhaps the part that you are missing, is that I take into consideration 30 years of experience playing games, and 30 years of other people researching and implementing different control mechanics. Especially on the Intellivision front, I did not work in a vacuum: there is a very friendly and open community of experienced developers offering assistance, and their collective knowledge. There is absolutely no need to start from scratch.

 

I am here, and so is GroovyBee, Joe Z., and catsfolly -- the latter one being one of the original Blue Sky Rangers. We're here to help, so use us.

 

-dZ.

[mjarnold7]

When did groovy announce Hive was boxed? That is great news though. I'm not a fan of loose carts. Looking forward to both multicarts. In boxes!

 

I meant Rocketeer, Mars Minis, etc (I guess they weren't CIB)......

[+Tarzilla]

As we've discussed before, how you handle the disc controls is entirely governed by your game and the environment the player avatar is in. What works brilliantly in one game might not work for another game style.

I was going to quote a bunch of the replies above, but this one will suffice.

 

I have a bunch of games in progress, with different control schemes. I read and research before I ask for help so I was well aware of the quirks of the controller and system while developing.

 

The control schemes I'm using can be grouped into several types

1) Strict 4 way controls like Pacman

2) turning in place and moving, sort of like Asteroids

3) 8 way motion on a scrolling playfield, like Super Cobra

4) Using both discs at the same time to move and shoot or 2 player simultaneous

 

I have also been part of playtesting some games by others.

 

I can say with conviction that there is a major difference between playing a game with a PC keyboard versus the Inty controller itself, not just the 16 position disc.

I was fortunate enough to recently be lent a CC3 by a very generous fellow and the first time I tried all of my games it was an eye opener. I was able to go back and adjust my controller code until it felt right, not just for the disc, but which buttons I used. Not only that I had my kids and friends also playtest and give me instant feedback. I was able to watch their hands as they all rolled their thumbs around the disk, rather than strictly pushing down or left like they would with an NES controller. I could see them struggling with trying to push buttons on the opposite side of the controller at the same time.

 

That said, now that I have tweaked things, I'm back to using the emulator, but the intial testing (1% or otherwise) was invaluable.

 

The knowledge and help by everyone is appreciated and welcome, and playtesting by multiple people on multiple systems (Inty 1, Inty II etc) is a definate requirement to make a professional release but I want to test my games on my system whenever I want like I can with the ColecoVision courtesy of my AtariMax Ultimate SD

 

To sum up:

After years of practice, reading and advice of others, I was still the one that had to get "hands on" in order to get my wife pregnant...

[GroovyBee]

Apart from the getting your wide pregnant bit, your development methodology pretty much matches mine and DZ-Jay's :-

 

- Develop on the emulator.

- Tweak controls as necessary on the real hardware.

- Use the input of beta testers.

- Go back to using the emulator .

[+DZ-Jay]

Apart from the getting your wide pregnant bit, your development methodology pretty much matches mine and DZ-Jay's :-

 

- Develop on the emulator.

- Tweak controls as necessary on the real hardware.

- Use the input of beta testers.

- Go back to using the emulator .

 

Hehehe, that's what I thought when I read Tarzilla's comment. Like I said before, I grew up with the Intellivision and know how the controllers behave and how games should play using them. Therefore, "rolling the thumb" on the disc is how I expect it to be used naturally.

 

Perhaps this is not as natural to those who come to the Intellivision from other platforms. In that regard, just play a few Intellivision games and get acquainted with its mechanics.

 

-dZ.

[+DZ-Jay]

Anyway, back on topic: When is this thing coming out?

[GroovyBee]

Anyway, back on topic: When is this thing coming out?

Soon!

[+DZ-Jay]

Soon!

 

In the immortal words of Morrissey...

https://www.youtube.com/watch?v=hnpILIIo9ek

[+JasonlikesINTV]

Are other things coming soon as well? I'm getting amped for playing Mars Minis

[GroovyBee]

Are other things coming soon as well? I'm getting amped for playing Mars Minis

Yep! Both Rocketeer and Mars Minis are getting some love too.

[+DZ-Jay]

Yep! Both Rocketeer and Mars Minis are getting some love too.

 

But... is it the good kind of love? Or the skanky shades of grey kind of love? I'm sure Rev wants to know!