Thomas Jentzsch

Thanks! I can sometimes win in normal mode, but I have a hard time not to become last in the hard mode. Same here, I suppose that's normal. Yes, that's something I noticed when adding them. I had to make them longer (better for human players) and less effective, else the AI would profit way too much. How is the frequency of the Superboosts? Currently there is a 1/16 chance, maybe that's too high?

Next version 0.7 add to first post. Changes: implemented three difficulties added optional SuperBoosts lowered braking frequencies more detailed instructions in first post Size now increased to 4K.

I would name the project after what all variations have in common (e.g. multi-cart, for the same consoles, using the same CPU...). Or make up a completely unrelated name which could describe the unified character (e.g. "Trinity").

IMO that's pretty good for a 5yo.

The AI is the same, but the game has become easier for human players. I will adjust the AI when the other parameters are finalized. You take your 5yo to parties? Was she able to become not last? Might do. Each switch could control 4 cars. But maybe two levels are not enough to cover all needs.

Yup, 100% Assembler.

Yes, the latest changes made the game easier. I will wait for more feedback before I tweak the AI. You are eliminating the 4th strongest computer player that way, so that shouldn't make much of a difference for you.

The difference is, that braking should happen much less frequently (and computer never brakes). So it should stick out better.

New version 0.6 in first post. Changes: the average boost length increased (less short ones) braking got 20% less strong changed font (still experimenting here, looking for pop art style) button presses change boost arrow color during start phase As always, feedback welcome.

I see. However, James seems to like that. Personally I don't mind too. But can you hear that when playing against 7 other players? The revs have to be based on a car which is not necessary yours. OK, that's a passed negative test. Thanks! Now I need someone with a QuadTari for the three remaining positive tests.

Yes, that might work better. @Keatah provided some feedback into which direction I should go for some parameters. And I think I will extend the average boost lengths (mainly reducing the 2s and 3s boosts). I am still thinking about game variations and tweaks. They just have to fit into a party game. That power boost might work. Currently the skills between players (not computers) are a bit compensated by the leading player's cars positioning more to the right. Which is currently (it could be in short games too) more pronounced in longer games. So the leading players have less reaction time for new boosts. If I implement a more random boost generation mode (currently each player gets the same boosts), I could increase/reduce the boost based on player position. Hm, some like it and some not. And I suppose no one has played this with 8 people yet. Is it the braking sound which makes it worse? Or the different engine sound compared to previous versions? I could create a version which produces the same engine sound as the old one, but with additional brake sound. Cool! Have you tried all four possible combinations?

Actually that's intentional. The AI has different skill levels (hot colors are faster, cold colors are slower), so that it offers competition for more or less skilled players. IMO that's fine. Players should be somewhere in the middle of the field and try to improve from there. When one can beat the AI easily, why would one need an AI at all? It is adaptive already. The better the position, the worse it becomes. But this has to be balanced with the initial AI skills.

It is easier when you are more to the right, leading the pack.

Quite OK. What the game really needs is play testing to fine tune the parameters. How strong should the boost be? How strong should the braking be? How should the boost arrow density be (more or less longer ones)? Should there be more or less friction? How about the minimal speed? The current values are resulting from only a little bit of play testing myself. I hope you and others can provide some good input here.

I still don't get how the numbers would help. The paddles are not numbered too. Too bad. Now I am waiting for more feedback here.

Vertically wouldn't work, way too much flicker even with just six rockets. But the current game could be easily converted into spaceship racing. Just change the few graphics and colors, plus sound.

Good idea. Since the computer cars permanently change color, I could add that feedback for the boost arrows. Or vice-versa.

Added version 0.5 to first post. Changes: improved sound, with brake sound (based on @SpiceWare ideas, thanks) fixed QuadTari detection (thanks @alex_79)

I think refueling would break the flow of the game. And I don't want the game to become overly complicated. It should be easy to understand and quick to play. Maybe there could be game variations which are longer and a bit more complex.

Booth options would be easy to implement. I only have to find a way to make them easily selectable without making the selection overly complicated. I don't think that would work. At least the cars have to stay colored to be distinctive.

A title screen is planned if I can come up with something nice, e.g. the name in pop art style. But I suppose I will need some help here. Regarding starting the game with a controller button, I am not sure if that's a good idea. After a race is over, people might not like to have the result removed by someone accidentally pressing a button. Maybe this is one of the exceptions, where this function should be limited to the console only.

The cars are fixed assigned to a controller. I suppose when this is played on a party, the controllers would be marked with colored stickers.

OK, I will post an new version with updated checks. Wait with your test until then, please.

Thanks for the explanation. My current check is much simpler, I am only checking INPT1/3. And I am only waiting one scanline. Now I have to wrap my head about your improved check (BTW: "and/or" means what? AND or OR?). I am not into hardware at all, so I have to understand from a software perspective. Let's see if I got it right (only considering left port here): Directly (a few scanlines) after dumping: Paddles: INPT0 and INPT1 are usually HIGH (both could be LOW if a knob is turned to maximum resistance) QuadTari: INPT0 is HIGH, INPT1 is LOW (due to pull up) After some frames: Paddles: INPT0 and INPT1 are LOW QuadTari: INPT0 is HIGH(?), INPT1 is LOW (due to pull up) Note: LOW means INPTx, bit 7 is SET, right? The reversed result is quite confusing for me. Is this correct so far? But then the logic is in INPT0 only, no? And then I only have to check INPT0 after some frames. If INPT0 is LOW, we have a paddle, if it is HIGH we have a QuadTari. INPT1 plays no role here, because it can be LOW either due to the pull up or due to the paddle. But that doesn't fit to your logic, so where is my mistake?

Quick update: Added V0.4 to the first post. The only difference is the QuadTari detection. It works in Stella, but I do not have the hardware yet to test on the real thing. Can someone please test for me? Normal paddles (top 4 cars should be selectable during countdown) QuadTari in left port (top 6 cars selectable) QuadTari in right port (top 4 and bottom 2 cars selectable) QuadTari in both ports (all 8 cars selectable)