Click on the green flag, then the coin. This is a copy of a project that was shared previously (now deleted). This is the final version of the project as adding any other game mechanics will likely slow the running rate significantly. I deeply apologize for the heresy of adding the game over screen and sound from the Super Mario Brothers game. To Do: Optimizations.
Seems to be very slow on Windows 8 Chrome. This was made on Mac OS X Yosemite in Safari which seemed to have little trouble in running the program. Movement reference from the Scratch Wiki that demonstrates a source that allows for simultaneous directional movement. Since the original Donkey Kong largely does not include increasing velocities in x movements, "set" command was used rather than "change." A hit box should be utilized (if not already) to keep the player sprite from being able to jump from the stage if not touching by the shoes. The hitbox could also be used to allow elevation up ramps. As the ramps are all constant elevation, adjustments to y movement could allow proper movement. (Use of if touching for hitbox, set indicator The repeat in blocks with minor costume adjustments was done to allow for appearance change while moving without the need to slow down movement with "wait." As the costume could only change when on the ground, x movement on the ground was slowed significantly compared to x movement in the air. http://wiki.scratch.mit.edu/wiki/Physics_Engines http://scratch.mit.edu/projects/101212/#editor Post primary "coding" notes: It should be said that the complexity and sometimes the use of rather non-optimized methods to "make the wheel turn" had not been intended at the beginning. As complexity further amounted on top of a rather simple movement system (which would mostly be overhauled by the end of it all), there came a concern that perhaps what had been generated was not done correctly. It should be said that it could have been simpler, however, it would not have emulated the game that it was meant to copy with accuracy. Each function would begin to conflict with the simple method. What could this game have been? Beyond the possibility of not using actual game images, sprite costumes, and sounds, movement could have been short but inaccurate. The initial program would allow the player to adjust x velocities in mid air. The initial program caused the player to drop when on a ladder or at the top of it and allowed the player to get on a ladder in mid air. The initial program did not change frames (costumes) for simulated movement when walking. But the original game did not do that. But to uphold these functions, complexity was added. Example? In order to keep the player from being affected by the y velocity gravity when on a ladder, a separate state (onLadder) had to be created and a check to isolate any other behaviors not related to it. The player can not get on a ladder when in mid air. Appropriate checks had to be thought and employed. Isolation was the theme. The amount of if statements that was used perhaps suggests inefficiency. Perhaps such thought is correct, but there was no better implementation thought of at the time without affecting other functions. This program operates primarily with switches. Nice little practices (though not employed comprehensively) allow slight value tweaking (yVel, xVel, other velocities of various sprites). An interplay of image resources and code is also a common motif. The stage and ladders had to be adjusted with pixels of certain colors for if-statement detections. The stage itself was prepared from a screenshot image. Hitboxes for detection. Test. Test. Test.
