kikipdph

I added submarines to the game, and that's where the sea ends, and after that, you fly above the land. First, I will do the gameplay over the sea (losing lives, there will probably be bar for energy, etc.), and then the game can be experienced. Information on how to shoot air targets and bomb targets on water and land can be found in previous posts. plane.bin

If you have a good idea, then it's not as important. For example, Solaris and Secret Quest are based on a good gameplay without many changes during the game. In Solaris, the action always takes place on the same planet and in space, while in Secret Quest, it's like going from room to room, but the idea made the game complex.

Let's say player1 changes appearance three times, and I think the term "sprite" correctly refers to a single graphic, with each frame being one sprite, while player1 remains the same. Regardless of the exact definition, you need three different images for one character, or you can use even more for a better effect. In a 2D game, with the same amount of memory usage, you could have 3 enemies. In 3D, with that same memory allocation, I would get one enemy. When I was creating more beautiful islands, specifically Jutland, which is a peninsula, it consumed half of the graphics memory, but it looked much better when zoomed in. Unfortunately, I had to simplify it.

The following should be submarines and airplanes, and on land, maybe tanks or something like that. It hasn't been decided yet what it will be. Many things are not yet done, such as sounds, and many things will likely need to be simplified because, for example, for one sprite, like an airplane, you actually need three different sprites, and a lot of memory is consumed by these effects. So, adding more detail and effects for the sake of experience could significantly burden the game.

I've made the enemies shoot, and I've created a title screen. Although in some other 3D Atari games, they didn't pay attention to this, I listened to the advice and made the ships a bit slower than the airplanes. I still haven't implemented the feature where you can lose a life by getting hit by an enemy missile. Information on how to shoot air targets and bomb targets on water and land can be found in previous posts. plane.bin

Wow, it looks great

When you've already named the game even though I was hesitant, then the final game got its name I'm trying to remember other historical Atari 2600 games.

Since James on the forum suggested the name "Jutland Skies," even though it hasn't been officially chosen, the game will be called "Jutland Skies."

The game will most likely be called "Kaiser's Kapers," and another name I'm considering is "Jutland Skies."

The width is limited, but the height can be as large as the screen. These are cosmetic matters and can be adjusted later after the gameplay is done

I've made it so you can hit the enemy, and there will be some sort of animation for hitting the target later. To shoot at airplanes, use the fire button on the joystick, and for bombing ships, you must pull the joystick backward and then press the fire button on the joystick. plane.bin

Yes, the game is being developed in Batari Basic DPC+. I don't like it when flicker happens in an Atari game, so I'm trying to design games to avoid it as much as possible.

It is now possible to shoot at enemies on the ground and bomb targets on water and land. Bombing might not be perfectly executed, but it's Atari :). Hitting enemies hasn't been implemented yet. The fire button on the joystick is used for shooting, and for bombing, you pull the joystick handle backward and press the fire button. A targeting reticle appears during bombing. How it looks can be seen in the video via this link. https://www.facebook.com/mirsad.sarajlic/videos/685335556602124/?idorvanity=29814905254&notif_id=1697106956925761&notif_t=video_processed&ref=notif Or you can download the Bin file plane.bin

I have arranged the first stage of the enemies in the game. Those who like to follow the game development steps I will put a bin file with the new progress. Right now, only airplanes and ships are arranged in one part of the game, and after that, something else should appear, perhaps submarines. The enemies will not go outside the screen to the left and right as they do now. plane.bin

The idea was that the targets on the ground and in the water should be bombed, while shooting at those in flight, but it's still too early to say. The second option of having a target is not a bad idea either.

That's a good idea. One option could be that the airplane moves left and right with the joystick, and by moving it up and down, you adjust the targeting. Another option is to shoot, and when, for example, you pull the joystick back and press a button, it targets and bombs ships and other ground targets.

I had a suggestion to land on an island, but for now, it's too early to say. First, I would create a battle before the island. There is also an idea for something like fast rockets that would be a significant challenge in the game, as well as a fight against the main enemy, but I haven't thought too much about the complete game scenario yet.

Now we have a ship

DPC+ additional hardware support provides better graphics, which may not be particularly necessary in this game because a 3D environment uses more graphic resources. Therefore, a decision must be made whether to have lower graphics but more gameplay elements or vice versa The original concept of the game was intended to be set during World War I.

The game should be a shooter, but I don't yet have a storyline for the game. The idea is to have ships and airplanes as targets that you shoot at, and slowly make your way to an island. The island should have some significance.

In development is a game for the Atari 2600, which currently lacks a defined storyline. It revolves around an airplane, and so far, the airplane is programmed to fly with another plane approaching it. Over time, the plane approaches an island. That's the extent of it for now. You can download a test BIN file if you wish. A 3D environment consumes a lot of resources, so at this point, I'm unsure how much can be achieved within the 32-kilobyte limit. However, I'm hopeful that the game will turn out to be decent both in terms of graphics and gameplay. plane.bin

I initiated this topic for both beginners and advanced programmers who can provide some tricks and tips from their programming approaches. Here's an example of how we can use a single variable instead of using 3 variables to control the movement of three independent sprites. Each sprite is assigned a specific decimal value, designated here as 'v'. The sprites move up and down, reaching a certain screen height, and change direction, effectively bouncing back. ; Moving sprite 1 if player1y = 18 then v = v | 1 ; Set the first decimal to 1 if sprite 1 has reached the upper wall if player1y = 57 then v = v & 254 ; Set the first decimal to 0 if sprite 1 has reached the lower wall if (v & 1) > 0 && player1y < 195 then player1y = player1y + 1 ; If the first decimal is 1, move sprite 1 downwards if (v & 1) = 0 && player1y < 195 then player1y = player1y - 1 ; If the first decimal is 0, move sprite 1 upwards ; Moving sprite 2 if player2y = 67 then v = v | 2 ; Set the second decimal to 1 if sprite 2 has reached the upper wall if player2y = 100 then v = v & 253 ; Set the second decimal to 0 if sprite 2 has reached the lower wall if (v & 2) > 0 && player2y < 195 then player2y = player2y + 1 ; If the second decimal is 1, move sprite 2 downwards if (v & 2) = 0 && player2y < 195 then player2y = player2y - 1 ; If the second decimal is 0, move sprite 2 upwards ; Moving sprite 3 if player3y = 110 then v = v | 4 ; Set the third decimal to 1 if sprite 3 has reached the upper wall if player3y = 150 then v = v & 251 ; Set the third decimal to 0 if sprite 3 has reached the lower wall if (v & 4) > 0 && player5y < 195 then player3y = player3y + 1 ; If the third decimal is 1, move sprite 3 downwards if (v & 4) = 0 && player5y < 195 then player3y = player3y - 1 ; If the third decimal is 0, move sprite 3 upwards I use this < 195 when the sprite is in a section where movement is needed. For example, if we shoot the sprite, I move it to y = 200, and then movement is not necessary.

This game has been cancelled because it does not work properly on the real Atari.

I have found a way to combine Ball and Sprite while keeping it synchronized to move in all directions. I think I will base the game on this.