Entry 2018: Deep Zone

[artrag]

In this version all Define/Define Alternate problems should be solved

I did a little tuning on length of levels and on enemies: now one out 4 enemies is from a different enemy set and the angular enemy speed doubles after level 16

When hit by enemy bullets and you have barrier active you bounce aside, and the barrier lose 100pts of its energy

I will also make shorter the barrier effect, now the game is too easy with them

AR

dzgorf.rom

Edited July 9, 2018 by artrag

[artrag]

Now bosses blink when hit, minor fixes on enemies and on text

dzgorf.rom

[+DZ-Jay]

Now bosses blink when hit, minor fixes on enemies and on text

 

More feed back later but... I just read the scroll-text on the Title Screen -- I was not expecting that.

[+DZ-Jay]

OK, so here's my feedback on this version:

• I like the music!
• I love the voice effects (even if I don't understand some of them, they are still distinctly human speech) -- they feel very old school. They give me that "futuristic feel" impression I got when I first played games with speech synthesis in the arcade back in the 1980s.
• You should allow the disc to start the game directly (it's sort of a standard in the classic Intellivision games).
• Same for changing pages in the instructions screens.
• The glowing power-up orbs flash too fast causing their colours to fade a little and reducing the contrast between each other. The end result is that I can barely tell them apart during game-play. Perhaps choosing more contrasting colours or making the flashing sequence alternate between 2-on and 1-off frames.
• I understand that there are power-ups for speed, but I insist that the initial speed of the ship is much too slow. It feels more like a bug because it bogs down the game during the crucial first seconds when the player makes his first impression.
• The orbs are a great idea, but I think they are over-used. More are dispensed than what I can ever use. At times it feels like every fifth ship on the screen is a power-up orb. Plus, they don't seem to have a penalty: the speed never gets reduced back when I die, and the shield seems to make me invincible forever.
  
  From a player perspective, it sounds like a great idea, but in practice, it reduces their impact. For example, since the speed boost is never lost, why do speed-orbs continue to come out all the time? It makes it feel even more that the initial speed is wrong; it's like I have to just slog through a few seconds in boring turtle-speed until I get an orb and the game really begins. That seems out of place in the game-world.
  
  So, I suggest:
  • Bump up the initial speed slightly (not too much, but at least make it playable).
  • Reduce the number of orbs in play -- make the player feel like he earned them. They should be special power-ups.
  • Make the shield run out of energy eventually (if it does this, perhaps it last too long right now). That way, the player has a motivation to catch another one.
  • On the other hand, the double-shot is the only one that feels right: it's an actual power-up, I lose it if I die, and have to re-gain it. (No coincidence there, it's the only one whose mechanics were already defined and polished in Gyruss.)
• The shield avoids all collisions, including power-up orbs. That feels wrong, since apparently, I can't control the shield and it seems to last forever.
• With all the work dedicated to the game-play mechanics and the rest of the polish, the enemy ships and explosions still seem a bit too much like "programmer art." They are "OK," but it seems like they could have a bit more character. Especially the explosions.

That's it for now, I probably will have more to say later when I get to advance a little more than half-way through the first warp (I suck at this game!).

 

Great job so far. This game has come a long way from what initially felt like a technology demo (for some very impressive technology), to a full-fledge game.

 

-dZ.

[artrag]

Thanks for the feedback. Let me try to go on the single points.

• You should allow the disc to start the game directly (it's sort of a standard in the classic Intellivision games).

I know, but as I'm using the keyboard to detect sfx menu (0), start without music (1), instructions (2), I think that trying to detect the disk at the same time could lead to false hit. Or at least this is what I think found in previous attempts. How can test disk AND keypad at the same time without interference ?

• Same for changing pages in the instructions screens.

Having the problem above in the main menu and in the SFX sub-menu, for consistency, I've left Enter in the instructions.

• The glowing power-up orbs flash too fast causing their colours to fade a little and reducing the contrast between each other. The end result is that I can barely tell them apart during game-play. Perhaps choosing more contrasting colours or making the flashing sequence alternate between 2-on and 1-off frames.

Ok, I will try to make them blink white once each 3 frames, instead of 2 frames.

• I understand that there are power-ups for speed, but I insist that the initial speed of the ship is much too slow. It feels more like a bug because it bogs down the game during the crucial first seconds when the player makes his first impression.

Ok. Dunno if it is easy, but I will try to double the initial speed.

 

The orbs are a great idea, but I think they are over-used. More are dispensed than what I can ever use. At times it feels like every fifth ship on the screen is a power-up orb. Plus, they don't seem to have a penalty: the speed never gets reduced back when I die, and the shield seems to make me invincible forever. From a player perspective, it sounds like a great idea, but in practice, it reduces their impact. For example, since the speed boost is never lost, why do speed-orbs continue to come out all the time? It makes it feel even more that the initial speed is wrong; it's like I have to just slog through a few seconds in boring turtle-speed until I get an orb and the game really begins. That seems out of place in the game-world.

 

I agree, I have to make them sparser. Their sequence is coded in a table that advances at each enemy killed. I will make Orbs less frequent.

 

So, I suggest:

• Bump up the initial speed slightly (not too much, but at least make it playable).

Going to try. See above.

• Reduce the number of orbs in play -- make the player feel like he earned them. They should be special power-ups.

Easy. See above.

• Make the shield run out of energy eventually (if it does this, perhaps it last too long right now). That way, the player has a motivation to catch another one.

Yes, it looses energy with time, you can see the residual energy bottom right when you have a shield. I will make energy drain faster.

• On the other hand, the double-shot is the only one that feels right: it's an actual power-up, I lose it if I die, and have to re-gain it. (No coincidence there, it's the only one whose mechanics were already defined and polished in Gyruss.)

I was already thinking to add something similar also for speed up. Now if you are already at max speed, the bonus sequence will start at double fire (red orb).

 

I should change in a way that each time you die you loose double fire first, and if you was single fire, you loose a speed up.

The bonus sequence should start at a place where you can get again max speed (if you get all speed up orbs) and the double fire.

Given that max speed is 3, the logic should be:

if you start at speed 1, you will see 2 speed up orbs before red orbs (double fire),

if you start at speed 2, you will see 1 speed up orbs before red orbs,

if you start at 3 (you have lost only double fire) you see directly double fire orbs.

 

• The shield avoids all collisions, including power-up orbs. That feels wrong, since apparently, I can't control the shield and it seems to last forever.

 

No, the shield does not prevent collecting orbs (unless bugs), only the special invulnerability you get after you respawn or after having collected any orb, but that lasts 2 secs, not more. Tell me if you spot bugs.

• With all the work dedicated to the game-play mechanics and the rest of the polish, the enemy ships and explosions still seem a bit too much like "programmer art." They are "OK," but it seems like they could have a bit more character. Especially the explosions.

 

This is the best I can fit in GRAM, provided I have 8 scale and 8 enemy types at the same time in only 48 tiles.

Edited July 12, 2018 by artrag

[+DZ-Jay]

Thanks for the feedback. Let me try to go on the single points.

• You should allow the disc to start the game directly (it's sort of a standard in the classic Intellivision games).

I know, but as I'm using the keyboard to detect sfx menu (0), start without music (1), instructions (2), I think that trying to detect the disk at the same time could lead to false hit. Or at least this is what I think found in previous attempts. How can test disk AND keypad at the same time without interference ?

 

 

Aha! It is possible, and I do that with a simple state machine. The idea is that you are expecting either Disc/Action or Keypad entry in a menu scenario, not in game-play, so the inputs should come in sequentially and mutually exclusive.

 

Let me take a look at my code and try to distill the algorithm for you.

 

 

• The glowing power-up orbs flash too fast causing their colours to fade a little and reducing the contrast between each other. The end result is that I can barely tell them apart during game-play. Perhaps choosing more contrasting colours or making the flashing sequence alternate between 2-on and 1-off frames.

Ok, I will try to make them blink white once each 3 frames, instead of 2 frames.

 

 

That should work.

 

 

• I understand that there are power-ups for speed, but I insist that the initial speed of the ship is much too slow. It feels more like a bug because it bogs down the game during the crucial first seconds when the player makes his first impression.

Ok. Dunno if it is easy, but I will try to double the initial speed.

 

 

Hmmm... it should still contrast with the speed-boost, just not so much.

 

 

• Make the shield run out of energy eventually (if it does this, perhaps it last too long right now). That way, the player has a motivation to catch another one.

Yes, it looses energy with time, you can see the residual energy bottom right when you have a shield. I will make energy drain faster.

 

 

I didn't noticed the the residual energy and I just saw it lasting for a long, long time. I'll test again just in case.

 

I should change in a way that each time you die you loose double fire first, and if you was single fire, you loose a speed up.

The bonus sequence should start at a place where you can get again max speed (if you get all speed up orbs) and the double fire.

Given that max speed is 3, the logic should be:

if you start at speed 1, you will see 2 speed up orbs before red orbs (double fire),

if you start at speed 2, you will see 1 speed up orbs before red orbs,

if you start at 3 (you have lost only double fire) you see directly double fire orbs.

 

Personally, it sounds much too complicated. Will the player be able to perceive those discrete changes? How about just doing like the double-fire: double the speed once, and lose it if you die. I also think losing all your power-ups on death is fairly common.

 

It's up to you, though.

 

 

• The shield avoids all collisions, including power-up orbs. That feels wrong, since apparently, I can't control the shield and it seems to last forever.

No, the shield does not prevent collecting orbs (unless bugs), only the special invulnerability you get after you respawn or after having collected any orb, but that lasts 2 secs, not more. Tell me if you spot bugs.

 

 

OK, I'll try again. What I noticed was that I kept moving myself to collide with everything just to test the shield's protection and it worked well (I didn't die), but it also seemed like I couldn't pick up orbs. I'll test more thoroughly.

 

 

• With all the work dedicated to the game-play mechanics and the rest of the polish, the enemy ships and explosions still seem a bit too much like "programmer art." They are "OK," but it seems like they could have a bit more character. Especially the explosions.

This is the best I can fit in GRAM, provided I have 8 scale and 8 enemy types at the same time in only 48 tiles.

 

 

I meant the picture cards themselves. They're fine, don't get me wrong. It's just that the enemies look to me like generic "Space Invaders," and the explosions seem like "Tic-Tac-Toe" crosses.

 

However, at the end of the day, those are very minor things.

 

-dZ.

[artrag]

From this

 

http://arcarc.xmission.com/Web%20Archives/Deathskull%20(May-2006)/games/tech/intvcont.html

 

It seems that keys 1 2 3 can be detected without ambiguity even while disk is used

Can it be?

 

Edit

No, I need to fully decode all directions to be sure it is a key...

Edited July 13, 2018 by artrag

[+DZ-Jay]

First, I'll say that even if technically possible, you should not try to accept disc and key input simultaneously. You should, instead, strive to condition the player to treat the hand-controller in one of two modes:

• Run and shoot (Disc + Action Button)
• Input Entry (Keypad)

 

This is how the Intellivision hand-controller was originally conceived, which is why they worked so hard to ensure that the signals within each of those modes are absolutely unambiguous, while they overlap somewhat across modes.

 

That does not mean that you only read one mode versus the other. Read below for some insight into how to dynamically detect the mode the controller is in at any point.

 

 

From this

http://arcarc.xmission.com/Web%20Archives/Deathskull%20(May-2006)/games/tech/intvcont.html

It seems that keys 1 2 3 can be detected without ambiguity even while disk is used
Can it be?

Edit
No, I need to fully decode all directions to be sure it is a key...

 

 

OK, I took a look at my own code (it's been a while) and below are the heuristics and algorithm I use.

 

Decoding Heuristics:

• State machine keeps track of whether we are in "Idle," "Disc/Action" or "Key" mode, depending on last input. The default is "Idle" mode.
• Full idle (sustained no signal), resets the state back to "Idle."
• When in "Idle" mode, we first test for key input.
• When in "Disc/Action" mode, we don't expect key input, so we assume it's another disc or button press, and discard non-matching signals.
• If bit #4 is set (diagonal), then it is definitely not key input. This signal will never occur in a key code.
• If bit #4 is set with any of the high three bits (action), then it's "Disc/Action" simultaneously and must be decoded.
• Otherwise it's an isolated disc input.

A few other considerations:

• We treat the key and action buttons as "switches," meaning that you press them and release them in exclusivity, one at a time. If any new input is received, it implies that any previous key or button press has been released. Therefore, we issue a "release" event on each change.
• We treat the disc as a "continuous" signal, meaning that you can press it once and roll your thumb over the disc resulting in various disc input values, while still pressed. Therefore, we issue a "release" event only when the controller goes fully idle again.

 

Decoding Algorithm:

The algorithm looks something like this:

• Debounce and filter signal to obtain a stable, sustained input pattern.
• Complement input signal so that "active = high."
• If input = 0, then event = idle
  • If mode was not "Idle," trigger appropriate "Release" events depending on previous input.
  • Set mode to "Idle".
  • End decoding.
• If mode is not "Disc/Action" and diagonal bit (#4) is not set:
  • Mask key bits.
  • Decode key.
  • If match found:
    • Set mode to "Key"
    • Trigger "Key Pressed" event
    • If mode was not "Idle" trigger "Release" event.
    • End decoding.
• Mask action buttons bits, if not zero:
  • Decode action button.
  • If match found:
    • Set mode to "Disc/Action"
    • Trigger "Button Pressed" event
• Mask disc bits, it not zero:
  • Decode disc.
  • If match found:
    • Set mode to "Disc/Action"
    • Trigger "Disc Pressed" event
  • End decoding.
• If we made it to here without a match, then the signal is a glitch and it's invalid, so we discard it and remain in current state.

 

Note that the state machine and the heuristics allow us to make some educated guesses with regards to player intent. Therefore, we can get away with masking the specific input bits and looking for an exact match. In other words, when scanning for, say, a key, once we find a precise match, it does not matter if there's a spurious disc input -- just ignore it. Likewise when scanning for disc. This may not be perfect, but you'd be surprised to know how effective it is in practice.

 

There's additional rules you could apply to decode the input signal in a purely technical way, but I find them overkill, at least for my purposes.

 

For instance, if I have happily decoded a disc signal previously, and the new input matches a disc code but has an extra bit that suggests it could be a key, we could quibble whether it's one or the other. However, at the end of the day, in practical terms, which is more likely: that the user -- already pressing the disc, and presumably aware of the expected input mechanics of the game -- immediately pressed a key; or that simply he pressed the disc too hard or too fast and the hardware glitched? (A 30 year-old Intellivision hand-controller can be notoriously glitchy.)

 

I tend to err on the side of practical use of the controller.

 

Decoding Tables

The decoding of each signal is then done by scanning a look-up table. Below is the table I use for a "generalized" decoder (one that accepts all inputs in a general way):

HAND.TBL        PROC
                                                        ; Input     Code
                ; Keypad                                ; --------- --------
@@Keypad:       DECLE   $28                             ;  Enter    00101000
                DECLE   $88                             ;  Clear    10001000
                DECLE   $24                             ;  9        00100100
                DECLE   $44                             ;  8        01000100
                DECLE   $84                             ;  7        10000100
                DECLE   $22                             ;  6        00100010
                DECLE   $42                             ;  5        01000010
                DECLE   $82                             ;  4        10000010
                DECLE   $21                             ;  3        00100001
                DECLE   $41                             ;  2        01000001
                DECLE   $81                             ;  1        10000001
                DECLE   $48                             ;  0        01001000
                ; Action Button                         ; --------- --------
@@Action:       DECLE   $C0                             ;  2        11000000 - Bottom-Right
                DECLE   $60                             ;  1        01100000 - Bottom-Left
                DECLE   $A0                             ;  0        10100000 - Top-Left/Right
                ; Disc                                  ; --------- --------
@@Disc:         DECLE   $0C                             ;  15       00001100 - NNW
                DECLE   $1C                             ;  14       00011100 - NW
                DECLE   $18                             ;  13       00011000 - WNW
                DECLE   $08                             ;  12       00001000 - W
                DECLE   $09                             ;  11       00001001 - WSW
                DECLE   $19                             ;  10       00011001 - SW
                DECLE   $11                             ;  9        00010001 - SSW
                DECLE   $01                             ;  8        00000001 - S
                DECLE   $03                             ;  7        00000011 - SSE
                DECLE   $13                             ;  6        00010011 - SE
                DECLE   $12                             ;  5        00010010 - ESE
                DECLE   $02                             ;  4        00000010 - E
                DECLE   $06                             ;  3        00000110 - ENE
                DECLE   $16                             ;  2        00010110 - NE
                DECLE   $14                             ;  1        00010100 - NNE
                DECLE   $04                             ;  0        00000100 - N
                ENDP                                    ; --------- --------

Below are the table I use for a 4-way "joystick" decoder. The first two tables are for the standard 4-way mapping that most people use, where diagonals are ignored (dead-zones). The last two tables are for the full 16-to-4 decoder, similar to what I use in Christmas Carol, where the diagonals are included and compared against the previous input to attempt to discern player intent.

HAND.JOYSTK.TBL PROC
@@4wayCross:    DECLE   $18                             ;  13       00001001 \
                DECLE   $08                             ;  12       00001000  > Left
                DECLE   $09                             ;  11       00011000 /

                DECLE   $11                             ;  9        00000011 \
                DECLE   $01                             ;  8        00000001  > Down
                DECLE   $03                             ;  7        00010001 /

                DECLE   $12                             ;  5        00000110 \
                DECLE   $02                             ;  4        00000010  > Right
                DECLE   $06                             ;  3        00010010 /

                DECLE   $14                             ;  1        00001100 \
                DECLE   $04                             ;  0        00000100  > Up
                DECLE   $0C                             ;  15       00010100 /

                ; ---------------------------+----------------------------+
                ;                            |     Bit #: 3 2 1 0         |
                ;                            | Direction: < v > ^    #    |
                ;                            +----------------------------+
@@4wayXref:     DECLE   HAND.JOYSTK.Up               ; 0 0 0 1   -  0
                DECLE   HAND.JOYSTK.Up               ; 0 0 0 1   -  1
                DECLE   HAND.JOYSTK.None             ; - - - -   -  2
                DECLE   HAND.JOYSTK.Right            ; 0 0 1 0   -  3
                DECLE   HAND.JOYSTK.Right            ; 0 0 1 0   -  4
                DECLE   HAND.JOYSTK.Right            ; 0 0 1 0   -  5
                DECLE   HAND.JOYSTK.None             ; - - - -   -  6
                DECLE   HAND.JOYSTK.Down             ; 0 1 0 0   -  7
                DECLE   HAND.JOYSTK.Down             ; 0 1 0 0   -  8
                DECLE   HAND.JOYSTK.Down             ; 0 1 0 0   -  9
                DECLE   HAND.JOYSTK.None             ; - - - -   - 10
                DECLE   HAND.JOYSTK.Left             ; 1 0 0 0   - 11
                DECLE   HAND.JOYSTK.Left             ; 1 0 0 0   - 12
                DECLE   HAND.JOYSTK.Left             ; 1 0 0 0   - 13
                DECLE   HAND.JOYSTK.None             ; - - - -   - 14
                DECLE   HAND.JOYSTK.Up               ; 0 0 0 1   - 15

                ; ---------------------------+----------------------------+
                ;                            |     Bit #: 4 3 2 1 0       |
                ;                            | Direction: / < ^ > v    #  |
                ;                            +----------------------------+
@@4wayFull:     DECLE   HAND.JOYSTK.None             ; 0 0 0 0 0 -  0
                DECLE   HAND.JOYSTK.Down             ; 0 0 0 0 1 -  1
                DECLE   HAND.JOYSTK.Right            ; 0 0 0 1 0 -  2
                DECLE   HAND.JOYSTK.Down             ; 0 0 0 1 1 -  3
                DECLE   HAND.JOYSTK.Up               ; 0 0 1 0 0 -  4
                DECLE   HAND.JOYSTK.None             ; 0 0 1 0 1 -  5
                DECLE   HAND.JOYSTK.Right            ; 0 0 1 1 0 -  6
                DECLE   HAND.JOYSTK.None             ; 0 0 1 1 1 -  7
                DECLE   HAND.JOYSTK.Left             ; 0 1 0 0 0 -  8
                DECLE   HAND.JOYSTK.Left             ; 0 1 0 0 1 -  9
                DECLE   HAND.JOYSTK.None             ; 0 1 0 1 0 - 10
                DECLE   HAND.JOYSTK.None             ; 0 1 0 1 1 - 11
                DECLE   HAND.JOYSTK.Up               ; 0 1 1 0 0 - 12
                DECLE   HAND.JOYSTK.None             ; 0 1 1 0 1 - 13
                DECLE   HAND.JOYSTK.None             ; 0 1 1 1 0 - 14
                DECLE   HAND.JOYSTK.None             ; 0 1 1 1 1 - 15
                DECLE   HAND.JOYSTK.None             ; 1 0 0 0 0 - 16
                DECLE   HAND.JOYSTK.Down             ; 1 0 0 0 1 - 17
                DECLE   HAND.JOYSTK.Right            ; 1 0 0 1 0 - 18
                DECLE   HAND.JOYSTK.Diagonal         ; 1 0 0 1 1 - 19  << SE $13
                DECLE   HAND.JOYSTK.Up               ; 1 0 1 0 0 - 20
                DECLE   HAND.JOYSTK.None             ; 1 0 1 0 1 - 21
                DECLE   HAND.JOYSTK.Diagonal         ; 1 0 1 1 0 - 22  << NE $16
                DECLE   HAND.JOYSTK.None             ; 1 0 1 1 1 - 23
                DECLE   HAND.JOYSTK.Left             ; 1 1 0 0 0 - 24
                DECLE   HAND.JOYSTK.Diagonal         ; 1 1 0 0 1 - 25  << SW $19
                DECLE   HAND.JOYSTK.None             ; 1 1 0 1 0 - 26
                DECLE   HAND.JOYSTK.None             ; 1 1 0 1 1 - 27
                DECLE   HAND.JOYSTK.Diagonal         ; 1 1 1 0 0 - 28  << NW $1C
                DECLE   HAND.JOYSTK.None             ; 1 1 1 0 1 - 29
                DECLE   HAND.JOYSTK.None             ; 1 1 1 1 0 - 30
                DECLE   HAND.JOYSTK.None             ; 1 1 1 1 1 - 31
@@Diagonal:     ; Vertical:
                DECLE   HAND.JOYSTK.Left             ; - - 0 0 0 - NW
                DECLE   HAND.JOYSTK.Left             ; - - 0 0 1 - SW
                DECLE   HAND.JOYSTK.Right            ; - - 0 1 0 - NE
                DECLE   HAND.JOYSTK.Right            ; - - 0 1 1 - SE
                ; Horizontal
                DECLE   HAND.JOYSTK.Up               ; - - 1 0 0 - NW
                DECLE   HAND.JOYSTK.Down             ; - - 1 0 1 - SW
                DECLE   HAND.JOYSTK.Up               ; - - 1 1 0 - NE
                DECLE   HAND.JOYSTK.Down             ; - - 1 1 1 - SE
                ENDP

Conclusion:

All that said, I do not know how much IntyBASIC does for you. I believe it does the filtering of the signal and the decoding, so there may be little that you can do, unless it gives you access to the raw signal for your own decoding.

 

Another thing to consider is that, in my own framework, I poll the hand-controller input on the "idle task," meaning that it's done several times (but at least once) per 60 Hz frame; while IntyBASIC only does it once per frame. I wouldn't expect this to have much impact on the algorithm, it just means that the signal is already quantized and normalized, so less filtering and conditioning is needed (if any).

 

One slight difference might be that the higher resolution polling may have a bigger chance of catching press and release events on the same iteration, but that doesn't seem to be a problem either way.

 

-dZ.

 

 

 

EDIT: Updated algorithm for clarity.

Edited July 13, 2018 by DZ-Jay

[artrag]

In this version:

 

- orbs blink once out of 8 frames

- there are much less orbs

- if you are hit, if you have double fire, you loose it, if you have single, fire you loose speed

- when you re-spawn, the orb sequence keeps into account your condition: if you need double fire you start from red orb (double fire), if you need speed, you start from the cyan obs (speed)

- shield last half of the time

 

The rest is WIP

 

NB: the counter bottom left is for debug: it counts the orb sequence

 

' speed_up = 1,double fire = 2, extra bomb = 3,shield = 4,one up = 5

bonus_hystory:

DATA 1,0,0,0,0,1,0,0,1,0,0,1,0,0,0,0

DATA 2,0,0,0,0,2,0,0,3,0,0,3,0,0,0,0

DATA 4,0,0,0,0,3,0,0,0,0,3,0,0,0,0,0

DATA 4,0,0,0,0,3,0,0,0,0,3,0,0,0,0,0

DATA 4,0,0,0,0,4,0,0,0,0,4,0,0,0,0,0

DATA 4,0,0,0,0,5,0,0,0,0,5,0,0,0,0,0

DATA 4,0,0,0,0,5,0,0,0,0,5,0,0,0,0,0

DATA 4,0,0,0,0,5,0,0,0,0,5,0,0,0,0,0

dzgorf.rom

Edited July 15, 2018 by artrag

[+DZ-Jay]

The updated mechanics you mentioned sound good. I'll give it a go. However, in the meantime, I will say that the 8-to-1 blinking rate is better than before, but too fast.

 

I did some (really cheap, quick and dirty) experiments to test out a few frequencies, and this is what I came up with:

• orb-test-avi.zip

The ZIP contains two AVI movies from the emulator. They are the same, but one is oriented vertically and the other horizontally, so that you can check them out whichever way works better for you.

 

The movie depicts three orbs, each at a different rate:

1. 16-10: 16 frames Blue, 10 frames White
2. 12-6: 12 frames Red, 6 frames White
3. 6-2: 6 frames green, 2 frames White

 

Personally, I am more partial towards #2, but if you must go faster, then perhaps #3.

 

-dZ.

[artrag]

In this version:

 

1)You can start the game pressing disks

2) Orbs in the menu blink in turn and the blinking lasts more. During game play you seen about the same same blinking time.

3) When you are hit, first you loose double fire (if any), and if later one speed up at time

4) The orb spawning system takes into account the current speed and fire of the player

 

The game is much harder but still fair (IMHO)

 

NB: the counter bottom left is only for debug, it is an index to the power up sequence. It will disappear in the final release

dzgorf.rom

[+DZ-Jay]

I really suck at this game, so I have to put in some serious time into it to get better and test the advanced stages.

 

Here's some feedback on what I got to play:

• The orbs blink too slow (sorry!). I would reduce the blinking delay by half or so. This is very minor, really, so don't worry too much about it.
• The initial speed of the game is still too slow and frustrating. I feel like I am steering a large truck when I move around the screen. My view on speed boosts and other power-ups is that the game should be fair, playable, and feel right without them. It should be better to get a power-up, of course, but it shouldn't be necessary in order to enjoy the game. Right now it feels like I am being actively penalized until I get a speed boost. It especially does not match the impression of speed given by the fast approaching enemies and the warp-speed star field effect.
• When I touch a purple orb (speed boost), the resulting speed feels like it should be the normal one. The speed boost can certainly be a lot faster after that.
• The release time of the orbs and their scarcity feels right. Yes, it may be more challenging, but it feels more fair and natural.
• I really recommend damping the movements of the enemies when they are very far away. I understand that the scale is so small that any minor displacement in 3-D space results in a big change in MOB position because of the pixel resolution; but you should add some damping to reduce the jitter effect. Right now the enemies seem very jittery when they are small and far away, which is odd and awkward.

That's it for now. I think the initial speed and the damping are the two critical things right now to get right; these sort of apparently minor details are things that help make the difference between a good game and a classic one that feels right. Unfortunately, I haven't arrived to the Boss Level yet, so I can't provide feedback on the rest of the game. I'll try to put more time and get better at it.

 

Keep up the good work!

 

-dZ.

[artrag]

in this version

 

1) fixed a problem in instructions about denouncing keys

2) orbs during game play blink slower

3) sprites of the first enemy wave have been modified to look more like a sort of birds, this is why you see them going up and down

 

No change on initial speed of the main ship atm

dzgorf.rom

Edited July 17, 2018 by artrag

[+DZ-Jay]

in this version

 

1) fixed a problem in instructions about denouncing keys

2) orbs during game play blink slower

3) sprites of the first enemy wave have been modified to look more like a sort of birds, this is why you see them going up and down

 

No change on initial speed of the main ship atm

 

I made it to the first boss this time, yay! Here's some feedback:

 

 

• The orbs seem fine. However, their release is still odd. The frequency seems fine, but the orbs are too repetitive. I mean, for example, if I already have speed boost, it continues releasing purple orbs. It seems as if the type of orb depends on the phase of the game. This is fine, but perhaps it should be more random (or smart). All I know is that I needed bombs and never saw a bomb orb, but there were plenty of purple and red ones.
• The bombs take out all all orbs in play along with the enemies. This may be technically correct, but maybe not too nice in practical game-play. I guess it's just a minor gripe, no big deal. (Oh, and while we're at it, make the bombs kill the enemy missiles as well.)
• The 3-D collision detection algorithm may be accurate, but it also means that I miss orbs quite a lot because I need to be positioned properly and perfectly aligned in 3-D space with it -- otherwise it won't register the collision, even if the sprite images seem to overlap. Perhaps it could be a bit more forgiving.
• I still feel that the current speed boost should be the initial speed, and the actual speed boost should be even faster than that.
• The jittering effect I referred to before was for all sprites (orbs, enemies, etc.), not just the birds. With the birds it is even more pronounced. Keep in mind that when the sprite is 1 pixel in size, displacing it by even one pixel is the equivalent of the actual object moving twice its full height or length. That is a rather large displacement, and does not really match the reality once the birds get closer, since at that point the wings move up and down by just a few pixels, but the entire sprite does not displace several pixels to any side except as per their velocity. The Intellivision graphics are so blocky that they won't allow for a good simulation of movement for very small sprites.

   

  In any case, it's a matter of perception. In my opinion at least, objects which are very far away should appear more static until they get closer; in the same way that the eye does not pick up much detail and movement when focusing on long distances.

   

  Therefore, I think that some sort of damping factor on far away sprites may help.

• You should wait until a user presses any key (disc or key) on the "Game Over" screen before returning to the "Title" screen. This lets the player bask in the glory of their score, and perhaps take the time to get a camera or take a screenshot. (You may want to play a nice end-of-game music at that point.)

 

All in all, I think my biggest gripe is with the initial speed and the speed boost, which seem inadequate to me. Other than that, the game is very challenging without being frustrating or appearing unfair, even to a lame-o player like myself. I'll try playing a bit more to see if I can reach a higher level.

 

 

-dZ.

[+DZ-Jay]

Damn! wrong thread... sorry.

[artrag]

In the end I've submitted

The final version fixes the ending screen in order to wait for a key if you did a new hi-score.

 

I can't increase the initial speed of the main ship easily.

If I keep 3 levels of speed up, the last level would be too fast, and collecting orbs would be very hard.

If I reduce to 2 levels of speed up, I should recode the orb sequence.

 

Now it is fine, only you know that you must get orbs if you want to survive

[+DZ-Jay]

In the end I've submitted

The final version fixes the ending screen in order to wait for a key if you did a new hi-score.

 

I can't increase the initial speed of the main ship easily.

If I keep 3 levels of speed up, the last level would be too fast, and collecting orbs would be very hard.

If I reduce to 2 levels of speed up, I should recode the orb sequence.

 

Now it is fine, only you know that you must get orbs if you want to survive

 

No worries, I understand. I suppose the speed is currently adjusted by shifting (doubling/halving) which limits the practical times it can be applied.

 

Perhaps as a future modification (after the contest, when you have more time to work on it if you so desire), you may want to consider using sub-pixel/fractional velocity vectors and control the speed boost as a percentage, say in 30% increments.

 

In any case, the game is very playable right now, and as you suggested, once you pick up your first orb (which is very soon after starting the game) it feels rather natural.

 

-dZ.

[+-^CrossBow^-]

Well...I have to ask a question as I'm working on an intellivision right now and have discovered something...

 

Has anyone tested and played this on an Intelly II yet? If not, That needs to be done to confirm some things I've discovered with the contest submitted version of the rom:

 

- Graphics for the player bullets seem to disappear and not be visible about every other time you shoot. Although you will still hear the sound of your shot being fired and can still kill enemies with these ghost bullets.

- Player ship sprite will frequently change into what looks like an infinity symbol that will change shape and looks generaly glitched. It remains this way until you lose a ship. Next ship comes back normal but will glitch out again.

- Sound is different on the Intelly 2 and to be honest, it sounds much better as the tones are more synth like and even appear to have some reverb like effect to it?

- When you pick up the shield power up your ship just turns into a big filled in white circle on the screen. I mean...huge..like 3x your normal size.

 

That was all I was able to discover. To make sure it wasn't an issue with the Intelly 2 I was using, I tested it on another Intelly 2 that has worked fine in the past for me. Same exact issues... so I find it hard to believe that two separate Intellivision II units would both have the exact same problems causing this. But I could see the revision and overall differences in the Intelly II models causing problems with the game.

 

I had only tested the game and the other contest submitted roms through my SVA previously. But I'm in the middle of recapping an Intelly 2 and AV modding it for a client and decided to try Deep Zone as a quick test since I was fancy a play at the time.

[artrag]

What you report seems to be related to the sprite multiplexing.

It is like you are missing one frame out two.

Which TV do you use? LCD or any other digital system?

Have you modded the output or used a digital converter?

 

Have you used a intellivision 1 on the same TV set without problems?

Edited October 25, 2018 by artrag

[+intvsteve]

Regarding sound, there are differences on Intellivision II consoles in the actual hardware, compared to the other versions of the console, so that may explain the different qualities of the sound.

 

As to the graphics behaviors -- the other judges did not indicate how they tested, whether in emulation, or which model(s) of the console were used. In fact, this would be a great bit of information to record! I created a Google spreadsheet to record this kind of information for testing games. It simply did not occur to me to share it during the judging - that could have proven useful!

 

FWIW, when validating the ROMs, I was using both an INTV System III and a Sears Super Video Arcade, and had the ECS and Intellivoice connected most of the time. I would use the LTO Flash! settings to modify some of the compatibility settings to try out some different scenarios.

[+-^CrossBow^-]

What you report seems to be related to the sprite multiplexing.

It is like you are missing one frame out two.

Which TV do you use? LCD or any other digital system?

Have you modded the output or used a digital converter?

 

Have you used a intellivision 1 on the same TV set without problems?

The missing bullets actually seem to happen in the same places around the screen. Basically if you use a clock face to map it in the 1, 5, 7, 11 positions but actually more like between them so say between 1-2, 4-5, 7-8, 10-11.

I have a Sony Bravia LED HDTV

Neither of the Intelly model 2 units have been AV modded. The one I confirmed these issues with is in fact all stock and still has all original parts. The other that I first discovered these issues I had just recapped and was using DZ as a test.

Both systems were connected straight to the TV via a small 3' thick shielded RF cable.

 

I only tested with my SVA that has been AV modded and it did NOT exhibit these issues during the testing I did for the contest.

Edited October 25, 2018 by -^Cro§Bow^-

[artrag]

Have you tested the same TV with a intellivision 1?

I have a Sony Bravia and its RF part is very bad, at point that I wasn't able to use it with my intellivision 1 and I had to move to an older sharp aquos.

 

I think that what you are seeing is the result of the inner digital conversion and sprite multiplexing.

Have you also tried to change the TV settings? There could be a gaming option for reduced processing, but here I think that the most appropriate is 'not' gaming setting.

Edited October 25, 2018 by artrag

[artrag]

Items multiplexed at 60Hz are all bullets, the player ship when you get double shoot, explosions.

 

If, by any reason, your system misses one frame out of two, you should see exactly what you report here, i. e. invisible bullets, a single color for the main ship and probably one frame explosions

[+DZ-Jay]

these issues I had just recapped and was using DZ as a test.

 

Wait, wutt? What did I do?

 

 

Have you tested the same TV with a intellivision 1?

I have a Sony Bravia and its RF part is very bad, at point that I wasn't able to use it with my intellivision 1 and I had to move to an older sharp aquos.

 

I think that what you are seeing is the result of the inner digital conversion and sprite multiplexing.

Have you also tried to change the TV settings? There could be a gaming option for reduced processing, but here I think that the most appropriate is 'not' gaming setting.

 

I don't think it's TV related.

 

Items multiplexed at 60Hz are all bullets, the player ship when you get double shoot, explosions.

 

If, by any reason, your system misses one frame out of two, you should see exactly what you report here, i. e. invisible bullets, a single color for the main ship and probably one frame explosions

 

What he reported initially sounds more like GRAM glitches, and the multiplexing issue just a side-effect of that. From his original message:

• Player ship sprite will frequently change into what looks like an infinity symbol that will change shape and looks generaly glitched.
• When you pick up the shield power up your ship just turns into a big filled in white circle on the screen. I mean...huge..like 3x your normal size.

Those do not sound like just a missing frame from a slow multiplexing effect. I'm just saying, it could be something specific to his console. I will try to test on the week-end, I have an Intellivision II.

-dZ.

[+DZ-Jay]

Regarding sound, there are differences on Intellivision II consoles in the actual hardware, compared to the other versions of the console, so that may explain the different qualities of the sound.

 

Yeah, but ... reverb effect? How cool is that!

 

-dZ.