Start your engines!

[GroovyBee]

Its 10 days until the contest deadline so its time to start thinking about wrapping up your game (even if its part finished) and submitting it into the contest.

Make sure it meets the entry criteria. If you are in doubt, then submit your entry early and then we'll have time to give you feedback if something needs addressing. You can resubmit a more advanced game before the contest closes (should you wish).

Some "spit and polish" tips:

• By now you should hopefully have tested your game on real hardware (or enlisted the help of a CC3 owner if you don't have one) to make sure there are no disc control issues. If there are issues perhaps you need to implement a 2 or 4 way gate (game dependent) or change how your control method works.
• If you have a part finished game, make sure whatever levels you have working are rock solid.
• Are all the game transitions smooth? E.g. GAME OVER displayed for long enough etc.
• Are the fire keys de-bounced when needed?
• Add extra eye and ear candy if you have time:
  • Add a title page (with animations etc.) to welcome the player into the game.
  • Add a credits screen.
  • Think about displaying the best score, time, distance on your title page so it entices the player to "have just one more go" in order to better it.
  • Add more in game sound effects (if appropriate).
  • Add in game intermissions (if appropriate).
  • Some title page music (if appropriate).
  • Perhaps an in game pause on keys 1+9 or 3+7 to give the player a breather from the action.
  • Some kind of configuration/options screen to enable/disable music/fx/voice or alter the number of lives/difficulty etc.
  • Is a consecutive two player mode possible?
• If your game isn't complete then how about adding some notes in its release *.zip explaining whats missing e.g. in-game concept art, missing features/levels etc. Then at least we can get an idea about where you wanted to take the game.
• If you haven't had time to add an adjustable difficulty level, perhaps some notes on how you'd implement that too.

Have fun and good luck!

[PuzZLeR]

By now you should hopefully have tested your game on real hardware...

 

Not really "real hardware", but on emulators. However, I find Nostalgia and Bliss have their own agendas, even regarding O/S. For example, do you believe that my game, at least at this point, works "fluidly" on Bliss with Win XP, yet "wrong" on Bliss with Win 10. What gives?

 

I'm using what runs with jzIntv as some sort of "standard" - taking this as some form of "common denominator" of compatibility. For the meantime, and at least for this contest, my mantra is that "if it behaves the way I want it to behave" with jzIntv, then "it behaves the way it's supposed to"...

 

I'd love to see what the community's take on this is. (In case I'm blasted here, no, I was too lazy to do a search on this, so there, I admit it. )

[GroovyBee]

Jzintv is the best Inty emulator out there. In the past I've had code that worked fine on real hardware and jzintv but crashed on Bliss and Nostalgia. However, that was pure CP1600 assembler. With IntyBASIC you shouldn't have many problems on the emulators unless you are using extra on cart RAM.

 

Disc control in a game can be an issue. Lets say you have a game like bump'n'jump and you control your avatar using left/right. It'll play OK in emulators because the left/right cursor keys are next to each other so you get all the fine precision you want. On the disc, exact left/right are quite far apart so you'd lose control precision. However, if you made all 7 available disc directions on the left move the avatar left and all 7 available disc directions on the right move the avatar right (avoiding direct north/south on the disc) then the game would also retain precision on the real hardware and be as fun to play.

[PuzZLeR]

Hi GroovyBee.

 

Jzintv is the best Inty emulator out there. In the past I've had code that worked fine on real hardware and jzintv but crashed on Bliss and Nostalgia. However, that was pure CP1600 assembler. With IntyBASIC you shouldn't have many problems on the emulators unless you are using extra on cart RAM.

 

Yes, Intvnut's baby is indeed a gem. And I am using it as my current "Intellivision reality", and "finger-crossing-compatibility", for the moment, and for the balance of the time remaining for the contest. I won't be able to test it on real hardware as my bricks-and-mortar Intellivision is at my parents place many miles away at this time. Not saying I'm going to win anything, but I believe we can deal with such things in the future hopefully if it's an issue.

 

I have content aside for GRAM, maybe music, etc, but for now just testing motion and dynamics, so it's still a rather small program with no RAM overflow. It compiles well with IntyBASIC as well. This is why it's strange in how there's a dilution of equality here among emulators. I can actually blame it on the O/S in some ways when the exact same version of Bliss runs it differently on WinXP (correct) and on Win10 (wrong). Bizarre.

 

Disc control in a game can be an issue. Lets say you have a game like bump'n'jump and you control your avatar using left/right. It'll play OK in emulators because the left/right cursor keys are next to each other so you get all the fine precision you want. On the disc, exact left/right are quite far apart so you'd lose control precision. However, if you made all 7 available disc directions on the left move the avatar left and all 7 available disc directions on the right move the avatar right (avoiding direct north/south on the disc) then the game would also retain precision on the real hardware and be as fun to play.

 

This would be a left-right game I'm submitting, and have compared it with other left-rights, and the play mechanics, and precision, are no better (or worse, according to the Intellivision disc critics), so this shouldn't be an issue. (I hope.)

 

But I'll tell you my problem. Pretend it's like our example, Bump 'n' Jump. In Bliss on Win XP, it would move left and right smoothly, and when you hit jump/shoot, it would jump from exactly the last position you had it last with the disc. That's what we want, of course.

 

In Bliss on Win10, it moves left and right fine, but when you hit the jump/shoot button, the vehicle takes off from another position entirely, depending on where the disc was on a previous loop I'm using and set of frames or interrupts in it.

 

If this is my program, and not the emulator or O/S, can I get points for revealing bugs in an emulator or O/S.

 

[GroovyBee]

This would be a left-right game I'm submitting, and have compared it with other left-rights, and the play mechanics, and precision, are no better (or worse, according to the Intellivision disc critics), so this shouldn't be an issue. (I hope.)

If you've implemented a "2-way gate" then you should be fine on the real deal too.

 

But I'll tell you my problem. Pretend it's like our example, Bump 'n' Jump. In Bliss on Win XP, it would move left and right smoothly, and when you hit jump/shoot, it would jump from exactly the last position you had it last with the disc. That's what we want, of course.

 

In Bliss on Win10, it moves left and right fine, but when you hit the jump/shoot button, the vehicle takes off from another position entirely, depending on where the disc was on a previous loop I'm using and set of frames or interrupts in it.

How about starting your own question thread and in that post the code thats causing the problem. Hopefully one of us will be able to spot the problem and suggest a bug fix or a different way of achieving what you want to do.

[PuzZLeR]

How about starting your own question thread and in that post the code thats causing the problem. Hopefully one of us will be able to spot the problem and suggest a bug fix or a different way of achieving what you want to do.

 

Yup. Sounds like a good idea. I will be posting a thread on the game shortly, and will post this question in it as well if it's still an issue by then.

[Opry99er]

Getting down to it!!! Man, I sure would love to see a couple more games make it in. I have had fun playing the ones that have been officially entered. If I had just another month or two, I would absolutely have had time to make a game up for consideration.

 

Some good entries so far. I hope all the games that have been started will be officially submitted.

[PuzZLeR]

I could use a bit of help here before submission.

 

Any advice on locking down the controllers? For example, I want the disc to go left-right, but other buttons do this too, and it's creating some bugs. In other words, when I want the disc to be the only interface that does something, how to I block out other buttons or keys? (Or vice versa.)

 

And I want to implement the 1+9/7+3 feature. I know this is an EXEC feature, so any pause feature will be Ok if so. But what would be an effective "infinite loop" to pause the game until another key is pressed? Anybody got a snippet of code they don't mind sharing?

 

Thanks.

[GroovyBee]

Any advice on locking down the controllers? For example, I want the disc to go left-right, but other buttons do this too, and it's creating some bugs. In other words, when I want the disc to be the only interface that does something, how to I block out other buttons or keys? (Or vice versa.)

Personally I wouldn't try and eliminate all the numeric keys by explicitly checking for them. False positives can be generated on keypads that are "spongy". The simplest way to implement a two way gate would be to check for all Easterly directions and move East and all Westerly directions to move West.

 

And I want to implement the 1+9/7+3 feature. I know this is an EXEC feature, so any pause feature will be Ok if so. But what would be an effective "infinite loop" to pause the game until another key is pressed? Anybody got a snippet of code they don't mind sharing?

Pause on 1+9 (or 3+7) generates a bitwise AND key code if you hold both down simultaneously. Coming up with a workaround so that you don't enter "pause mode" from normal disc usage can be a challenge.

[GroovyBee]

My mistake! This :-

 

Pause on 1+9 (or 3+7) generates a bitwise AND key code if you hold both down simultaneously.

Should be this :-

 

"Pause on 1+9 (or 3+7) generates a bitwise XOR key code if you hold both down simultaneously."

 

I have added KEYPAD_PAUSE to my latest constants.bas.

[fsuinnc]

 

And I want to implement the 1+9/7+3 feature. I know this is an EXEC feature, so any pause feature will be Ok if so. But what would be an effective "infinite loop" to pause the game until another key is pressed? Anybody got a snippet of code they don't mind sharing?

 

Thanks.

 

 

 

Pause on 1+9 (or 3+7) generates a bitwise AND key code if you hold both down simultaneously. Coming up with a workaround so that you don't enter "pause mode" from normal disc usage can be a challenge.

 

I too am wondering what the program should do when it enters Pause mode. If keypad 1+9 is pressed, do you go into an infinite loop looking for any controller input and just return when any controller button or disc is pressed? I know the old games used to blank out the screen but I am not sure how that was done (or how to do it in IntyBASIC).

 

The one game I've created has plenty of pauses in the action so it doesn't really need a pause feature but I would kind of like to add it for authenticity (or nostalgia depending on you look at it.)

[GroovyBee]

The best thing to do would be to put up a "PAUSED" message on screen. Then if you don't get any button or disc activity after a couple of minutes then plank the screen. If you detect "1+9/3+7" again or a side button, then leave pause mode. However, if the disk or top button is pressed when the screen is blank redraw the screen but stay in pause mode until a fire button or "1+9/3+7" is hit. That way the player isn't dropped back into the game immediately when they touch the controller to see if the game is still alive.