Champ Games - Turbo Arcade (2600)

[Thomas Jentzsch]

1 hour ago, Nathan Strum said:

without gobbling up tons of ROM

Please let me know if I might be able to help with compression. But I suppose John is knowing very well what he is doing here. 

[Thomas Jentzsch]

1 hour ago, Nathan Strum said:

If I can figure out some way to bring that curved wall into the scene (without gobbling up tons of ROM) we may add a transition there at some point.

The arcade has some kind of entry into the wall section, drawing shorter vertical lines in the wall. Not sure why it is there, it makes no sense to me. So before you try to replicate that part too, IMO the bytes would be better invested into some kind of transition.

[+Nathan Strum]

5 hours ago, Thomas Jentzsch said:

Please let me know if I might be able to help with compression. But I suppose John is knowing very well what he is doing here. 

It would be great to have some help with it, I'm sure. We still have more stuff we want to add!  

5 hours ago, Thomas Jentzsch said:

The arcade has some kind of entry into the wall section, drawing shorter vertical lines in the wall. Not sure why it is there, it makes no sense to me. So before you try to replicate that part too, IMO the bytes would be better invested into some kind of transition.

I think a lot of what's in the arcade game was done out of necessity of getting things done, rather than smoothly transitioning from one scene to another. We're not as interested in reproducing the glitchy stuff, as we are making sure the essence of the gameplay is preserved. Where better transitions improve the gameplay (space permitting) we'll add what we can.  

[Thomas Jentzsch]

6 hours ago, Nathan Strum said:

We're not as interested in reproducing the glitchy stuff, as we are making sure the essence of the gameplay is preserved.

Not exactly a glitch, but the thing that most disturbs me in the arcade are the car perspectives. On the title screen, the back wheels are waaay to wide. And in the game, you should look at the cars more from behind.

 

Speaking about perspective, I wonder if the top of the road could be changed to look less wide, especially when the road is straight. E.g. by shortening the top road section? But I know that this change would probably mean heaps of work for you.

 

BTW: If you want to utilize the ball, how about a middle line on the road? Maybe only in some sections.

Edited May 24, 2021 by Thomas Jentzsch

[Thomas Jentzsch]

Be careful:

Quote

Turbo was designed and coded by Steve Hanawa. In an interview, Hanawa stated that despite its historical significance as a precedent-setting racing video game, he considers the process of creating it to have been his worst development experience at Sega. Development of Turbo required such a difficult and protracted schedule of coding and debugging that he was hospitalized for a month following its completion due to stress, exhaustion and a spontaneously collapsed lung.

 

Quote

An Atari 2600 port by Coleco was in development and advertised by Coleco, but it was never completed, due in part to the lead programmer, Michael Green, having been struck and seriously injured by a drunk driver while riding a bicycle. 

 

Edited May 24, 2021 by Thomas Jentzsch

[xybot67]

Wow! You guys have truly captured the essence of the arcade game. I was super excited to see this reveal and was surprised to hear James mention that he knew nothing about the game, I guess my age is showing ?. I remember walking into a local arcade in the early 80s and being blown away by the graphics, it looked like no other racer at the time. I can't wait to get my hands on a physical release, a definite must buy! Thanks and kudos

[+Andrew Davie]

1 hour ago, Thomas Jentzsch said:

Be careful:

 

Back in the '80s at Beam Software/Melbourne house, where I worked as a programmer, health was (in hindsight) a serious issue. It seemed normal, at the time, but I still have memories that indicate to the older and wiser (?) me just how high-pressure some of those times could be.

* One programmer had permanently stationed a bottle of antacid by his keyboard. He regularly took swigs of it just to keep things at a bearable level.

* another had bottles of whisky in his desk drawer, which he would routinely sip after-hours.

* many of us worked odd hours, so "after-hours" means after 5pm.

* My typical day started about 1pm when I arrived at the office, and I generally worked till midnight or later

* I fondly recall going to "the taxi place" for snacks at 2am. It was the only place open; a real dive/hamburger joint open for the at-night taxi drivers.

* I was on antidepressants for much of the time I was programming NES

* I suffered from regular heart palpitations during much of this period, being such high stress.

* One project I worked 63 days without a break (no weekends), 14 hour days. Never again. I was refused a weekend off when requested at the end of that period.

* One programmer was sent, at a days' notice, to the USA (from Australia) where he was put in a hotel room, woken at 8am and driven to the office, returned to his hotel room at 5pm... for a month. He eventually rebelled and returned home.

* Ever heard of 34-hour working days?  They were a thing. That's my personal record. I actually drove home after that, which was a real mistake. Could have killed someone.

* Sleeping under desks was commonplace.

 

So yes, games programming can take a great toll on personal health and wellbeing. I can well believe it sent some of us to hospital, as described above. For me, at times it seemed like I was trapped in a personal nightmare/hell from which I would never escape. And yet, I look back on those days with great fondness.

 

[+D Train]

25 minutes ago, Andrew Davie said:

* another had bottles of whisky in his desk drawer, which he would routinely sip after-hours.

oh, come on.  this is only a problem if he was drinking rotgut and not the good stuff and didn't offer to share it!

 

[+SpiceWare]

2 hours ago, Andrew Davie said:

One project I worked 63 days without a break (no weekends), 14 hour days. Never again. I was refused a weekend off when requested at the end of that period.

...

So yes, games programming can take a great toll on personal health and wellbeing.

 

Not only games programming.  In the 90s we migrated the company I worked at from a couple Wang VS systems to an AS/400. During October, November, and December we worked 7 days a week, 12 hour days.  We did get off Thanksgiving day, Christmas day, and one weekend when the building had no power due to routine maintenance needing to be done on the backup generator.

 

I supported EDI, so I had to implement it on the AS/400. I also had to write all the programs to export the data from the Wang VS as fixed width text files.

 

The migration occurred over the extra long weekend for New Years.  A few days after the migration I resumed my 8-5 workday as everything I worked on was running smoothly, and I wasn't able to help to the others with the last remaining issues (getting me up to speed would have taken longer than them fixing it).  As I was leaving at 5 one day I overheard the president of the company make the comment "I guess the EDI guy doesn't have enough to do".  I was royally pissed to say the least after what we'd been thru for the past 3 months, but held my cool. I informed my boss about it the next day so he could take care of it, which he did.

[+Andrew Davie]

8 minutes ago, SpiceWare said:

I was royally pissed to say the least after what we'd been thru for the past 3 months, but held my cool. I informed my boss about it the next day so he could take care of it, which he did.

Programmers should have unionised. After my 63 days non-stop and a refused request for a weekend off, I resigned then and there. Next day when I came in I was called to the office and was told to take two weeks' paid holidays starting immediately, and was given a huge pay rise (from $25K to $40K if memory serves).

[+D Train]

22 minutes ago, SpiceWare said:

As I was leaving at 5 one day I overheard the president of the company make the comment "I guess the EDI guy doesn't have enough to do".

I've been in other situations where people have said that.  It's not whether you look busy, it's whether you do the things you are asked to do when they need to get done.  Always hated that.

 

bosses.  ugh.

[Thomas Jentzsch]

26 minutes ago, Andrew Davie said:

Programmers should have unionised. 

I had heard similar stories, that's why I never aimed for game development. My company is a mess, with really bad management etc. But the stress level is low, also because we have a strong workers' council. Since my company is US based, it gets into conflict with German worker laws regularly. And the workers' council takes care of it, frequently by having to go to court (and winning ~99%).

Being organized really helps.

[r_type2600]

Another striking Champeau/Strum cooperation, and Turbo is a great choice for a port. Good to see another groundbreaking early arcade game being faithfully converted to the 2600 ?

 

The road strips definitely are essential for the driving experience.

I wonder if the missiles are being already used in the scenery/gameplay portion of the screen?

If not, have you thought applying the technique used in Pole Position for the road strips? It would be a natural fit.

 

Also, would it be possible to have the background in the game data field correspond to the horizon color? (e.g blue for most scenes). Not sure if the current black is due to technical constraints?

A uniform appearance would certainly increase the draw-in effect of the game, akin to the arcade version.

 

Love your plan to create additional scenery, such as the desert/cacti one John mentioned in the ZPH stream. ?

[Thomas Jentzsch]

23 minutes ago, r_type2600 said:

I wonder if the missiles are being already used in the scenery/gameplay portion of the screen?

If not, have you thought applying the technique used in Pole Position for the road strips? It would be a natural fit.

The missiles share color with the sprites.  

[r_type2600]

The player sprite has red and yellow (a good replacement for white). So, accordingly, red/yellow road strips using missiles would be feasible?

Sorry if I don't grasp that properly...

Or, would it mean that the missile color on every horizontal line has to correspond to the one of the sprite color on the same line? Makes sense that it would not help then.

 

Edited May 24, 2021 by r_type2600
elaboration

[Thomas Jentzsch]

You cannot pick just one color from the car. The missiles will have the color of the car in that line. So if the the car has e.g. 8 lines with 8 colors, the missiles will have too.

[Thomas Jentzsch]

1 hour ago, r_type2600 said:

Also, would it be possible to have the background in the game data field correspond to the horizon color? (e.g blue for most scenes). Not sure if the current black is due to technical constraints?

A uniform appearance would certainly increase the draw-in effect of the game, akin to the arcade version.

I like that.

[+Nathan Strum]

4 hours ago, r_type2600 said:

Also, would it be possible to have the background in the game data field correspond to the horizon color? (e.g blue for most scenes). Not sure if the current black is due to technical constraints?

A uniform appearance would certainly increase the draw-in effect of the game, akin to the arcade version.

We explored this early on, and there were some issues:

• There's no solid sky color. The sky is two different colors on alternating lines that visually "mix" to form the sky (and other objects).
• There's no single TIA color that matches the mixed colors. A solid color would always appear different than the sky, effectively creating a "frame" around the score/data area.
• Against a striped background, the legibility goes right out the window. Even against a solid light sky color, it became very hard to read. The information in there is critical to gameplay, and we needed it to be clearly readable.

We mocked up a couple of sky backgrounds behind the score area, and neither of us liked the way they looked as much as black. Black had the best contrast and was the most readable, so that's what we went with.

[+Nathan Strum]

 

It was great watching James and Tanya playing Turbo Arcade again! You really got the hang of it. That's one of the things I really like about Turbo - there's really not much to learn strategy-wise. It's just about balancing risk vs. reward.

 

A few notes about questions/comments you had (you already figured out some of these):

• You do max out at 41 cars passed (as per the arcade game).
• You are briefly invulnerable after a crash or after the "cars passed" are done being counted (per the arcade).
• When two opponents crash, only the trailing one gets taken out (per the arcade).
• AtariVox/SaveKey support isn't working yet.
• Some of the sequences are very short, but the timing is straight out of the arcade. We may make modes where the scenes run longer.
• If you think it's hard now, you should've seen it just a couple of days before the reveal.  Or play the early arcade ROM set in MAME.
• Advanced will likely be the most difficult level. But we have some ideas for additional gameplay modes. The arcade game will always be there, but it won't be the only thing.  
• There are certainly bugs and incomplete issues to resolve. The gameplay aspects of it were put together really quickly and all within the week before the reveal.
• Only the trees (both types) and shrubs were scaled in After Effects. Everything else was scaled/animated in Photoshop.

Cheap deaths:

• You do get killed if you crash into a crashing opponent. Best bet is to keep an eye on the cars ahead of you - if they get near each other, back off or prepare to dodge them.
• When you crash in Round 1, you will get hit from behind by other cars - a lot. This per the arcade, but we added an "out" because it's so unfair - if you immediately move to the side of the road, they will avoid you.
• Don't slow down too much - cars will take you out from behind. Just like driving in L.A!
• The ambulances should push opponents further out of the way than they currently do. In the arcade game you can more safely chase the ambulance.
• I die most frequently attempting to pass when I know I shouldn't.  

Thanks for playing the game again and giving it a really proper run-through! Glad you enjoyed playing it.  

[Thomas Jentzsch]

Thanks for posting some insights, Nathan.

 

Regarding cheap deaths, personally I do not like them at all. IMO they are either bad game design or meant to milk the players in the arcade. This shouldn't happen in homebrews. If some people want the real, negative experience for whatever reason, add a cheap death variation. But please try to design a variation where cheap deaths do not happen or can be easily avoided. When I enhanced the Turbo proto for a playable version, getting rid of cheap deaths was a major issue. 

 

Just my 0.02 € cents. 

 

BTW: The visuals of Turbo are great (arcade and this version), but gameplay is a little thin compared to that, IMO. So maybe it could be enhanced somehow to provide some more variation? I am sure there are elements from other racing games which would fit in here too. Without having to change the overall game design. E.g. chasing or running away from special opponents cars, reduced visibility, varying round lengths, some (e.g. time) bonus to aim for, being a able to build up a time buffer in lower rounds, Easter eggs.. whatever.  

[r_type2600]

Thanks for the explanation on the background colors rationale, it all makes a lot of sense. I imagined you sure would have tried to go for the arcade look, but likely had to make compromises.

 

I also understand that convincing recreation of the city, tunnel entrance and curved wall were priority and you hence went for PF horizons for those scenes. (I assume the bridges also recur to that technique).

Interestingly in these scenes, one's eye doesn't notice the separation of the data area so much. The overlapping of the scenery into the horizon in these scenes alleviates the appearance of separated areas to a major extent.

It's mostly in those scenes where the horizon remains separated from the scenery, that the splitting of the screen into different areas becomes most obvious and slightly distracting from the sensation of being "in the game".

 

Would it make any sense to try to mix techniques depending on scenery? e.g. PF horizon /black data area for city, curved wall, etc. & solid color+sprites/horizon colored data area background for the other scenes like forest, hills, etc.

I mean such a mixed approach worked neatly for your Wizard of Wor for example, where you used multicolor sprites for the Worlok and Wizard and monochrome sprites for multi-enemies levels.

Of course the transition should remain smooth to the eye. Not worth it otherwise.

I see the issue of legibility, but experiencing with contrasting colors might address that?

[r_type2600]

12 hours ago, Thomas Jentzsch said:

You cannot pick just one color from the car. The missiles will have the color of the car in that line. So if the the car has e.g. 8 lines with 8 colors, the missiles will have too.

Got it now. Another ignorant question: can missiles appear on screen if the corresponding player is not displayed?

Idea is to then create a phantom sprite (a few lines red, a few lines white) and then be able to use its missiles for the road strips.

Would likely increase the flicker a bit, but the game seems to still have some tolerance in that regard and we've seen how well the flickering has been tamed in Galagon, Mappy, etc.

Redundant idea of course if missiles can only be displayed at the same time as their player...

Edited May 25, 2021 by r_type2600
grammar

[Thomas Jentzsch]

Yes, missiles can be display independently from the players. But there are only two players and missiles in total. IMO it is not worth to add flicker, just to have nice road strips. Also this would break the overall consistent look.

 

But that's only my opinion here.

[+johnnywc]

8 hours ago, Thomas Jentzsch said:

Regarding cheap deaths, personally I do not like them at all. IMO they are either bad game design or meant to milk the players in the arcade. This shouldn't happen in homebrews. If some people want the real, negative experience for whatever reason, add a cheap death variation. But please try to design a variation where cheap deaths do not happen or can be easily avoided. When I enhanced the Turbo proto for a playable version, getting rid of cheap deaths was a major issue. 

 

Just my 0.02 € cents. 

Hi TJ!  

 

Agreed on cheap deaths; I don't think Nathan was listing his examples as "cheap deaths" but quoting James during the livestream and explaining why they AREN'T cheap deaths.    Certainly there may be some tweaking that needs to be done, but IMO most of these 'cheap deaths' can be avoided (thus, not making them 'cheap').  The biggest issue James seemed to have is the enemy cars crashing into each other and your car colliding with the accident.  A quick peek on the top of the screen you can usually tell if two cars are close together, and just like real driving, you should move to the other side of the road if you think they're going to crash (they don't 'crash' when they're far in the horizon).  With that said, I can have the crashed car not slow down to speed 0 so fast so it doesn't appear to come at you so fast after an accident.

 

After you crash and start from the bottom, we've already added in a few seconds of 'invincibility' and unlike the arcade we've also added in logic so if you pull over to the side of the road (which you probably should do anyway after a 'crash'), the enemy cars will only enter from the bottom on the other side of the road, so I think with this strategy you can safely avoid any cheap deaths in this situation.

 

I have already modified the ambulance 'shoving' code so, like the arcade, you can safely follow the ambulance and they will plow through the enemy cars.   

 

There was a bug James experienced in the "After Hours"  livestream where his car crashed for no reason when on the hill; this is because my code was incorrectly checking for collisions with enemy cars even when they're 'hidden' behind the crest of the hill; this has been fixed also.

 

I'm sure we'll get more feedback after the ROM is released and I'm sure we'll be able to make sure the game doesn't have the "quarter eating" vibe that the arcade has.   

8 hours ago, Thomas Jentzsch said:

BTW: The visuals of Turbo are great (arcade and this version), but gameplay is a little thin compared to that, IMO. So maybe it could be enhanced somehow to provide some more variation? I am sure there are elements from other racing games which would fit in here too. Without having to change the overall game design. E.g. chasing or running away from special opponents cars, reduced visibility, varying round lengths, some (e.g. time) bonus to aim for, being a able to build up a time buffer in lower rounds, Easter eggs.. whatever.  

Agreed, we plan on adding in a CHALLENGE mode with some of those elements, different race types, weather, etc.  Lots of options to give the game more re-playability.   

 

Thanks!

John

 

[Thomas Jentzsch]

Well explained, thanks.

 

I guess one would have to play the game to really be able to judge this. But what you write makes sense. Maybe James and Tanya can provide more feedback.