Entry 2018: Deep Zone

[artrag]

Improved version of the Intybasic shooter inspierd by Gysus and Gorf

This version has 4 bosses, 2 sets of enemies, 2 intertitial warp animations

 

Use ECS for improved Voice and music

dzgorf.rom

[artrag]

I'm not able to edit the first post, so I will add game updates and fix as separate posts

 

Fixes in the meteor storm and in the music when you are killed diring a boss battle

dzgorf.rom

[+DZ-Jay]

I'm not able to edit the first post, so I will add game updates and fix as separate posts

 

Fixes in the meteor storm and in the music when you are killed diring a boss battle

 

I just played a few rounds of this version. Here's some feedback:

• The player ship moves too slow (I thought it was faster before). It feels a bit frustrating running around trying to catch the enemies.
• The music on the title screen sounds great! But it does not seem to fit well the sci-fi theme. It sounds more like for a fantasy RPG or an action game. (Update: after leaving it on for a while and restarting the game a few times, it is growing on me. Hehehe... I really like the tune, I just think that something more "spacey" would work for that title screen.)
• There doesn't seem to be any collision detection between the ships (only bullets): when I collide head-on with an enemy, it just goes right through.
• Is there an indication of how many waves I have to attack to get to the boss? All I see is the changing colours of the enemies, but it all seems the same after a while.
• When the game is over, I hear a voice which sounds like it is saying, "Game Over. Safe Planet." I don't know if this is what it really says, but that's what it sounds like, and it makes little sense. (I like the voices a lot, but I can't understand them very well.)
• The warp star field effect does not seem to be too smooth or at constant time. Worse, it goes up and down in speed while playing. I think this may be an indication of the game engine slowing down when updating many objects.
• The game-play music could stand to be a bit more exciting. Perhaps something like the rhythm track of the opening song. A beat and bass-line like that would make it very exciting.
• There's a counter at the bottom-left corner that increments all the time but I do not know what it means. Perhaps it should countdown the distance to the next zone? That would give some indication of progress.
• There's a number under the life-counter at the top-right corner which never changes from "00." I seem to remember from past builds that it was the number of zones completed (or bosses met, which may be the same thing). However, if it seldom updates, it just takes space on the screen with no use. For instance, I've played quite a bit and never saw it change from zero.
• The player shot sound-fx should be improved. Perhaps a more "lasery" sound. As it stands, it sounds a bit like a short static spike. When I press the fire button continuously, it makes it sound like the music has distortion spikes, instead of shooting rapidly.

 

I really like this game, it has a lot of potential. There are some very clever techniques used which give the game a unique feel among other Intellivision game shooters. I really want to see it polished further so that it appears less of a tech-demo and more as a cohesive game.

 

Thanks for sharing your progress, artrag!

 

-dZ.

Edited April 2, 2018 by DZ-Jay

[+nanochess]

I really would suggest to make enemies bigger since the start, because takes a lot of time to see them "near" and you pass the time shooting small pixels.

 

I mean to see the enemies even if the visual proportion wouldn't be so right.

 

I liked very much the title screen music, I don't feel right the ingame music.

 

Almost everyone knows how looks a Score, so you could remove the letters and instead put "Dist:" to the left number (Am I right?)

[+DZ-Jay]

I really would suggest to make enemies bigger since the start, because takes a lot of time to see them "near" and you pass the time shooting small pixels.

 

I mean to see the enemies even if the visual proportion wouldn't be so right.

 

I liked very much the title screen music, I don't feel right the ingame music.

 

Almost everyone knows how looks a Score, so you could remove the letters and instead put "Dist:" to the left number (Am I right?)

I agree with all your comments except the first point: I actually like shooting at the small pixels, since try are mostly stationary, they are easier to shoot.

 

Although while I was playing it, I also thought that they take too long to take proper shape, and by the time they get close enough to distinguish, Poof! They are gone!

 

OK, then. I agree with all your points.

dZ.

[artrag]

I was thinking about using magnified sprites to increase the number of frames and double the size of the enemies.

Basically once you have passed size 8 you start using size 4 but magnified by 2

[artrag]

There are few points where the game logic needs a severe improvement

 

A) Collisions:

 

1) main ship agains enemies -> the test is missing

2) main ship bullets agains enemies -> the test can fail, as the condition is tested only when enemies move. If the rate for enemy update is smaller than the rate for main ship update, your bullets could pass through enemies

3) enemy bullets agains main ship -> the test can fail, as the condition is tested only when main ship moves. If the rate for main ship update is smaller than the rate for enemy update enemy bullets can pass through the main ship

 

The game now increases enemy speed at each wave, so we start from problem 2) and we fall slowly in problem 3)

 

I have to guarantee that collisions are tested at the highest update rate among those of the items involved in the test (and add the missing tests)

 

B) Bullet rate

 

The bullet rate of the main ship have be independent by the distance between bullets

Same for enemies

 

C) I need to add 1up and bonus bombs to be collected in the interstitial warps

 

D) I need to add an advancement bar to measure the distance to the end boss

 

dzgorf.rom

Edited April 2, 2018 by artrag

[+DZ-Jay]

There are few points where the game logic needs a severe improvement

 

A) Collisions:

 

1) main ship agains enemies -> the test is missing

2) main ship bullets agains enemies -> the test can fail, as the condition is tested only when enemies move. If the rate for enemy update is smaller than the rate for main ship update, your bullets could pass through enemies

3) enemy bullets agains main ship -> the test can fail, as the condition is tested only when main ship moves. If the rate for main ship update is smaller than the rate for enemy update enemy bullets can pass through the main ship

 

The game now increases enemy speed at each wave, so we start from problem 2) and we fall slowly in problem 3)

 

I have to guarantee that collisions are tested at the highest update rate among those of the items involved in the test (and add the missing tests)

 

B) Bullet rate

 

The bullet rate of the main ship have be independent by the distance between bullets

Same for enemies

 

C) I need to add 1up and bonus bombs to be collected in the interstitial warps

 

D) I need to add an advancement bar to measure the distance to the end boss

 

 

Are you using hardware collision detection? If so, you may want to switch to software-based collisions using bounding boxes or something like that.

 

-dZ.

[artrag]

Software collision. Changing the windows size does not solve as game speed increases indefinitely. I need to change the time when the tests are executed adding a test when bullets or its target have moved.

[+DZ-Jay]

Software collision. Changing the windows size does not solve as game speed increases indefinitely. I need to change the time when the tests are executed adding a test when bullets or its target have moved.

 

Gotcha. Yeah, changing the bounding box size won't help. You'll need to make sure to test collisions when sprites move. Rather than testing for movement and then testing for collisions when moved, would it be cheaper to just test collisions on every game loop iteration and save a test on the worse case?

 

In my own game engine, whenever a sprite moves and it is in a state that accepts collisions, I mark it for collision test. After all sprites are moved, I test for all collisions of marked sprites (avoiding redundancy, of course).

 

-dZ.

Edited April 3, 2018 by DZ-Jay

[artrag]

here some fixes in the collision management

http://atariage.com/forums/topic/243150-deep-zone-gorf/?p=3330672

[+DZ-Jay]

I played the latest for a little bit. I didn't notice much change on the collisions. I did manage to get to a boss now (hehehe).

 

Here are a few observations:

• The more I play, the more I get distracted by the sound effects. They sound too "noisy," like electric static spikes or ripped woofer cones.
• I suppose the big red block on the bottom-left corner during the boss scene is the boss' life meter. You may want to be more subtle about it, or embellish it to make it more recognizable. As it is, it just popped up, and it looked like a color-mode graphic glitch.
• The sound effect of the enemy death (like a pinball "boing!") occurs much too late. There's a brief noisy "crack" when the bullet hits it, then it flashes colours, and then when it finally disappears the sound effect is played. It seems distracting.
• I really like the voice saying, "Warning! Boss ship coming." However, I think you should not call it a "boss." That is a word adopted by the gaming community, sort of like slang, but it is not "diegetic" (i.e., part of the narrative or in character with the theme). In a sci-fi space story, the big bad villain would never be called a "boss."
• I do not like the star field during the boss fight. It does not seem to "flow" too well, and looks more like a flashing pattern. Perhaps it needs more animation frames.
• The music during the boss is good, but not very exciting. Perhaps it would work better during the regular play. I think the music should be more exciting during final battles like that.

That's it for now. I hope this feedback is useful, even if you decide to ignore some of it. Next week-end, I'll aim to test on the console and provide some feedback then.

 

-dZ.

[Intymike]

Quick...have to play it until the next version arrives...

[emerson]

Just spent some time playing this and it's pretty good! I have only a few thoughts at the moment:

 

- To me, the elongated star light on the post-boss starfield insinuates your ship is moving at a faster speed (warp speed), and I feel there should be some sound to accompany that. I'm thinking if you were to increment the star pixel count from 1,2,4,8 and have an increasing jet sound as you tear through space, it would really sell the idea of "This quadrant of space is now safe, warp speed to save the next". I play a lot of Starmaster for the atari 2600, so that is where this idea comes from.

 

- Is there an explanation of the keypad controls that I missed? If I knew how the keypad works then this next thought might be irrelevant. Anyhow, I feel as though the keypad should reflect the disc movement, only you are firing as you travel. For example, if I press 1 on the keypad, I would expect to start moving toward the top left corner of the screen while firing, 3 would move me toward the top right, 8 would place me at the bottom middle, and so on. 5 could be stationary fire and the player would move with the disc. Not too sure about the bottom row of keys, maybe have three types of missles to choose from?

 

You've got a good game here, keep it up!

[+DZ-Jay]

- Is there an explanation of the keypad controls that I missed? If I knew how the keypad works then this next thought might be irrelevant. Anyhow, I feel as though the keypad should reflect the disc movement, only you are firing as you travel. For example, if I press 1 on the keypad, I would expect to start moving toward the top left corner of the screen while firing, 3 would move me toward the top right, 8 would place me at the bottom middle, and so on. 5 could be stationary fire and the player would move with the disc. Not too sure about the bottom row of keys, maybe have three types of missles to choose from?

 

You've got a good game here, keep it up!

I think one problem is that, on the Intellivision, you can either read the keypad, or read the disc, but not both at once. If you wish to accept either, then you'll have to take some steps in identifying their differences, which may not be perfect (some of the signals overlap), and is more expensive than just assuming one type of input.

 

It requires additional code, some assumptions and special heuristics, which on an action game like this one may have an impact on performance.

 

dZ.

[artrag]

I should add collision between enemies and main ship.

Bombs and a couple of bonuses.

 

About lifebar, that is the best I can do using grom tiles. Any better proposal?

I have also spare gram actuality

[artrag]

Improved energy bar for enemies (link as usual)

[artrag]

A new video

[+DZ-Jay]

Improved energy bar for enemies (link as usual)

 

Where's the link?

[+DZ-Jay]

Improved energy bar for enemies (link as usual)

 

I saw the new energy bar in the video, and it is very close to what I was going to recommend. I was just putting together a post on how to use GROM for it, but yours looks cool.

 

A few comments on the new bar:

• I recommend "anchoring" the left edge by squaring it. It will then give the impression of a bar growing from the left to the right.
• The progress step is too steep. As attested in the video, it barely moves when you shoot the boss, and then, wack! a chunk is missing. It should be smoother than that.
• If you are using GRAM for this, you only need cycle the right-most card with 9 different steps (one bar pixel less on each, including zero bar pixels). You could use a combination of GROM and GRAM if you are low on the latter, but it shouldn't take more than a couple of cards.

 

Below is an example. Notice that with this configuration you only need to use 3 GRAM slots:

• A solid "middle segment" which is repeated to extend the bar
• A "right most" segment which is cycled through 9 different steps
• A "right tip" segment which is cycled through 5 different steps at first, then remains on the last one (empty)

The left-most anchor can be taken from GROM.

; GROM   GRAM
; ------ --------------------------
.......# ######## ######## ####....
.......# ........ ........ ....##..
.......# ######## ######## ####..#.
.......# ######## ######## #####..#
.......# ######## ######## #####..#
.......# ######## ######## ####..#.
.......# ........ ........ ....##..
.......# ######## ######## ####....

####.... ####.... ####.... ####.... ####....
....##.. ....##.. ....##.. ....##.. ....##..
####..#. ###...#. ##....#. #.....#. ......#.
#####..# ###....# ##.....# #......# .......#
#####..# ###....# ##.....# #......# .......#
####..#. ###...#. ##....#. #.....#. ......#.
....##.. ....##.. ....##.. ....##.. ....##..
####.... ####.... ####.... ####.... ####....

######## ######## ######## ######## ######## ######## ######## ######## ########
........ ........ ........ ........ ........ ........ ........ ........ ........
######## #######. ######.. #####... ####.... ###..... ##...... #....... ........
######## #######. ######.. #####... ####.... ###..... ##...... #....... ........
######## #######. ######.. #####... ####.... ###..... ##...... #....... ........
######## #######. ######.. #####... ####.... ###..... ##...... #....... ........
........ ........ ........ ........ ........ ........ ........ ........ ........
######## ######## ######## ######## ######## ######## ######## ######## ########

If your energy bar is 8 segments long, and each one comprises 8 steps, that gives you a scale of 8 x 8 = 64. These do not need to be mapped 1:1 to the player shots; they can just be used to smoothly animate the reduction of a chunk corresponding to the energy lost on each shot. This will give it a more "analogue" appeal than merely removing a big chunk of energy at a time.

 

To illustrate:

• Let's say the energy bar is full, at 64 energy units.
• Player shoots and hits enemy, with a cost of 8 energy units.
• Instead of reducing the bar by 8 pixels, you start an animation sequence which will reduce it in 8 steps, one pixel at a time.
• When done, the bar is now at the correct reading.
• If another shot comes in while the previous animation is still running, you can increase the animation speed by removing two pixels on each step while the total cost is greater than one shot.
• You increase the number of pixels per step for each "overlapping" shot, until you catch up.

 

By keeping the base animation rate fast enough (8 pixels, one per frame, is 8/60^ths or about 1/8^th of a second, which is pretty fast), you will not encounter much "overlap" between the shots, due to the slower human reaction time. At most, you may overlap two shots, which can be handled like I said above, or in other visually interesting ways.

 

-dZ.

Edited April 7, 2018 by DZ-Jay

[artrag]

I agree about the energy bar, mine is a sloppy solution

About in game music, try this last rom (with ECS)

[+DZ-Jay]

I agree about the energy bar, mine is a sloppy solution

About in game music, try this last rom (with ECS)

 

Did you forget to attach it, or is it in the first post?

[artrag]

1st post

[artrag]

This is an experiment in order to collect opinions. I have implemented scaling for enemies using hardware ZOOM for sprites.

When size is <= than 8 the sprite has normal resolution, when size is >8 the frame is taken size/2 and HW ZOOM is activated.

 

I see critical the step from scale 8 to scale 9, where the nicely defined enemy turns in a huge coarse blob of pixels.

There are exceptions, like e.g. the red stars coming backward in the 7th and 8th wave of enemies that seems to scale very well across resolutions, but generally I do not see a real improvement...

What do you think ?

 

PS

I've manually edited the sequence of frames now, it seems better but the issue is there. What do you think?

 

dzgorf.rom

Edited April 8, 2018 by artrag

[+DZ-Jay]

This is an experiment in order to collect opinions. I have implemented scaling for enemies using hardware ZOOM for sprites.

When size is <= than 8 the sprite has normal resolution, when size is >8 the frame is taken size/2 and HW ZOOM is activated.

 

I see critical the step from scale 8 to scale 9, where the nicely defined enemy turns in a huge coarse blob of pixels.

There are exceptions, like e.g. the red stars coming backward in the 7th and 8th wave of enemies that seems to scale very well across resolutions, but generally I do not see a real improvement...

What do you think ?

 

PS

I've manually edited the sequence of frames now, it seems better but the issue is there. What do you think?

 

 

Personally, after running it for literally 10 seconds, I hated it. I much prefer the way you had it originally. It's a neat technical trick to do it this way, but it looks too chunky and clunky.

 

-dZ.

 

P.S. The in-game music is much better in this one, although it needs work.

Edited April 8, 2018 by DZ-Jay