This is a very interesting thought exercise on "what if you could send modern programming languages back to the 1980s?" http://prog21.dadgum.com/6.html
It would be interesting to analyze early Apple ][ game images and see which didn't use assembly. Wizardry was a notable example for using USCD Pascal, essentially running in a VM. Infocom games of course used Z-code. Applesoft BASIC was fine for some text adventures (Eamon for example).
There were also programs like Microsoft's TASC that compiled Applesoft to binary, much of the speedup gained by converting floating point values to integer.
The SWEET16 interpreter was also built-in to ROM, but I don't know if any titles used it.
But almost every game relied on some kind of special graphics technique to wow the player, and that usually meant at least one neato routine hand-optimized in assembly. Drawing a sprite to the Apple's frame buffer was actually much more complex than blasting RGB values like we do today.
Aztec-C's performance on the II at least was terrible. A colleague explored it for a project and gave up - the program ended up being developed in GraFORTH.
It would be interesting to analyze early Apple ][ game images and see which didn't use assembly. Wizardry was a notable example for using USCD Pascal, essentially running in a VM. Infocom games of course used Z-code. Applesoft BASIC was fine for some text adventures (Eamon for example).
There were also programs like Microsoft's TASC that compiled Applesoft to binary, much of the speedup gained by converting floating point values to integer.
The SWEET16 interpreter was also built-in to ROM, but I don't know if any titles used it.
But almost every game relied on some kind of special graphics technique to wow the player, and that usually meant at least one neato routine hand-optimized in assembly. Drawing a sprite to the Apple's frame buffer was actually much more complex than blasting RGB values like we do today.