Don't go! (WIP)

[vitoco]

The source code has ~1800 lines and it was partially commented, including timmings in the relevant sections, so I started to complete the comments, almost on every line.

 

While I'm doing that, I found an instruction at the beginning of the kernel that it was not required, so I recovered 2 bytes. Even when I think that the game is ready, if I find another 3 bytes during this process, I think I could add another sound FX.

 

On 10/2/2020 at 7:52 PM, atari2600land said:

The only thing that bothers me is the shape of the 5 digit. I think it might be confused with a 6.

As there are only 2 pixels of difference between both digits, so I took your suggestion and tried some variants for both digits, but I liked none of them. Going back to the first bitmaps I created is not a chance, and as squared digits found in original Atari games has only 1 different pixel between those digits, I decided to keep them as they are.

 

No more feedback? Someone else?

 

[+ZeroPage Homebrew]

On 10/16/2020 at 6:27 AM, vitoco said:

No more feedback? Someone else?

We'll be featuring Don't Go on ZeroPage Homebrew on Tuesday so we'll be able to provide some good feedback on it then! ?

 

- James

[vitoco]

On 10/17/2020 at 12:57 PM, ZeroPage Homebrew said:

We'll be featuring Don't Go on ZeroPage Homebrew on Tuesday so we'll be able to provide some good feedback on it then!

So it seems that I'll have to prepare a cartridge label or something like that... I have a couple of ideas for an image/theme.

 

[+ZeroPage Homebrew]

2 minutes ago, vitoco said:

So it seems that I'll have to prepare a cartridge label or something like that... I have a couple of ideas for an image/theme.

Awesome! If you can get one to me in the next couple of hours or I can incorporate it into the promotion for tomorrow's show (which I usually do the day before). If not, I can include your  graphic tomorrow for the show. ?

 

- James

[+ZeroPage Homebrew]

ZeroPage Homebrew will be playing an EXCLUSIVE WIP version of Don't Go! on tomorrow's (Tue Oct 20) stream LIVE on Twitch at 6PM PT | 9PM ET | 1AM GMT! Hope everyone can watch!

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

 

Games:

• Unholy (2020 Exclusive Final Release) by Leonardo Santiago (@Leonardo Santiago)
• A Roach in Space II: Cosmic Bugaloo (2020 WIP | 7800) by Vladimir Zuñiga (@vhzc)
• Don't Go (2020 Exclusive WIP) by Víctor Parada (@vitoco)
• Shattered Earth (2020 WIP Update) by Ric Pryor (@KaeruYojimbo)

 

 (SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

 

Edited October 22, 2020 by ZeroPage Homebrew

[vitoco]

Thank you @ZeroPage Homebrew crew and passengers for all the comments during the show.

 

I tried to stay anonymous so as not to influence on your comments, I just gave a couple of tips to clarify some points. I selected some quotes and some messages from the chat room to reply them here:

 

Quote

James: I think he described it like "Pong by yourself"
@CapitanClassic: Go Pong Yourself

I was bored! That explains many things... ?

 

Quote

@vhzc: This is the type of games that you shouldn't play drunk
Tanya: It's not a beer friendly game
metallatari1969: I am starting to disagree, This is an amazing drinking game! lol

 

Quote

Tanya: Ah!
Tanya: You are controlling different directions on different walls so my brain has to shift "which way I'm turning!?"
Tanya: Oh, it's so hard!
Tanya: (lots of funny faces)
Tanya: Where's my brain?

Tanya: I hate the top.

Tanya: Oh, my brain!!!

I was expecting this kind of reactions during the show.

 

Quote

@CapitanClassic: probably should give you a chance to catch the ball mid-paddle. it appears to miss the second it passes rbe first pixel of the paddle

@CapitanClassic: would mid-sceen obstacles cause flicker? couldnt the playfield be used (same color as ball?)
metallatari1969: hardcore mode
@CapitanClassic: or make the ball the same color as player0 when on the opposite side as the p0 paddle and change color before drawing the ball
@CapitanClassic: as missile0

@CapitanClassic: it does feel wrong to have the ball "miss" before it goes off the screen. to handle this though the paddles would have to be moved in slightly so that additional graphics dont need to e made as the ball moves off fne left/right screen.

The original game in the A8 allows the ball to go outside of the visible area of the screen, and you can also catch it even when it has almost gone, but there are some constraints and unexpected behaviors: as that version is using hardware collision detection, it could be possible to score twice in the same bounce, as the next ball position after the ball was touched could still be in touch with the pad.

I wanted to add visible obstacles using the playfield, but as it uses the same color register than the ball, I look for alternatives such as what @CapitanClassic mentioned, but at the end, I had to discard most of them because I used almost all the machine cycles of every scanline in the kernel. An alternative was to use two frames, but I didn't want to introduce flickering in this simple game. Then I thought about "invisible" obstacles, but as the game was being completed with many game variations, I decided to left them out. With my A8 BASIC tenliners projects, I got used to pick some features and discard others in order to fit the contest's size restrictions while producing an attractive minigame.

 

Quote

@vhzc: I like the neon-ish colors

James: Its an option to simulate black and white
@CapitanClassic: I play Stampede in B&W, because it has higher contrast with the heffers rather than the brown on green background.

Tanya: Color choices... it feels very late 80's - early 90's

I also like those colors. A clear playfield requires color to make it attractive. I tried to distribute them in a "balanced" way.

The B&W option is it not just a simulation, color pads have different brights, but all of them uses the same gray in B&W mode, which is different from the ball to highlight lost balls.

The code that manages both color modes was prepared to enable attract mode (color rotation), but I discarded that because of the lack of space.

 

Quote

@CapitanClassic: It is good that it has a 1-2 second delay before starting.
James: Delays are very nice
James: I don't see why it couldn't be started with the button after the game select

The game handles states in order to activate or deactivate features. The game should be restarted using the button only when the a game is over. It is a bug that you can start the game just after power it on, but I kept it on purpose. I will think about this again, in order to allow the paddle button to start the game after selecting a another game.
 

Quote

 

James: The top one is the hardest one, the sides I can deal

Tanya: Zigzag is awesome, the curve ball gests you when it goes fast

James: Zigzag is weird

Tanya: It is really smart, it just goes against your instinct

James: It doesn't need so much, it's challenging

Tanya: It's pretty cool

James: Variations make the game bigger than it seems

Tanya: Very simple, it really gets your brain tight enough when you are flipping directions

 

Wow... thanks for those comments. I wonder what would you have said if you had reached higher stages, where the ball becames quite fast!

 

Quote

 

@vhzc: cool game.
danavc: another good game
@CapitanClassic: yep. cool game.

James: Very fun

Tanya: I like it

 

Those make me ask myself: Should I release the full version of this game in cartridge through a store/publisher? Is it interesting enough?

 

[+ZeroPage Homebrew]

7 hours ago, vitoco said:

Thank you @ZeroPage Homebrew crew and passengers for all the comments during the show.

You're so welcome, it was a ton of fun playing your game. Thank you for being in the chat to (anonymously) answer questions!

 

- James

[vitoco]

I missed this late comment during the show:

Quote

@CapitanClassic: I think a reset restrainer (as called in the bBasic examples) that prevents the game from starting until the reset switch is released only takes a few bytes of ROM (and 1 bit of ram). an additional delay for waiting until the button is pressed and released should take a similar amount of ROM

My code waits for the release of the reset and select buttons before starting a game or changing the game mode again (but it does not do that for the paddle's button, which is fine).

I reworked the game state's transitions a little and now it is possible to restart the game with the paddle button anytime while not in play state. No bytes were added, neither to ROM nor RAM!

 

Special thanks to you for your comments during the show!

 

During the code inspection while adding comments, I could get many bytes back by supressing redundant code or by optimizing it, so I could add a starting game sound, and there is 21 more bytes free. I'd like to add the "attract mode", but that would require some changes in the kernel of the arena. Another use would be to add a special game over sound or tune.

 

On 10/21/2020 at 3:07 PM, vitoco said:

Should I release the full version of this game in cartridge through a store/publisher? Is it interesting enough?

Any comments about this? Would anyone be willing to buy a cartridge copy with the full version of this game?

 

[vitoco]

Changelog:

• I completed the addition of comments to almost every line of code. I found many places where code could be optimized or reorganized for clarification and also saved some more bytes.

• I was not happy with the ZigZag Run game mode, because it was too slow in the first levels as it could be seen in @ZeroPage Homebrew show, so I had to use half of the free bytes to build a custom data tables instead of to reuse some of the data from other game modes. Now, that game mode is more fluent and interesting... and getting harder on every round!!!

 

If there is enough interest, I'll complete the user manual and rework the art.

 

Edited October 29, 2020 by vitoco

[vitoco]

While trying to solve the problems I have with my VCS in order to play Don't go! in real hardware using the PlusCart (thanks @Al_Nafuur), I did a full test of the current version to fine tune the increasing difficulty of the rounds and I found a bug: when the score reached 999, the round number also got stuck, because its counter depended on the last digit of the score. It took me 6 extra bytes to replace the code and include its own variable (counter).

 

This change gives me the flexibility to set the number of bounces for the rounds at compile time, and currently the round is incremented every 10 bounces. How many bounces would be the best for a round?

 

[vitoco]

At last, I could play all the game modes of the game in my real console. It plays good, and there is no need to more fine tunning, so I decided to close its development and set it as finished.

 

Now, I have to think if I'll produce my own carts and sell them, give it to a publisher, allow playing it through the PlusStore, or release the binary file to the community. What do you think?

 

[+Al_Nafuur]

19 hours ago, vitoco said:

At last, I could play all the game modes of the game in my real console. It plays good, and there is no need to more fine tunning, so I decided to close its development and set it as finished.

 

Now, I have to think if I'll produce my own carts and sell them, give it to a publisher, allow playing it through the PlusStore, or release the binary file to the community. What do you think?

 

I vote for PlusStore ?