| Name: | Mario Clone |
|---|---|
| Version: | 1 |
| Author: | Mike Wiering |
| License: | Free |
| Operating System: | Dos |
| Website: | http://home.wxs.nl/~mikewiering/mario/ |
Mike Wiering wrote an impressive clone of Super Mario Brothers as a learning exercise. The program was never intended for release. Instead, an original game, Charlie the Duck, was to use the game engine. Unfortunately some unscrupulous person modified a beta version and began selling it as shareware. Dismayed, Mike released the source code for the Mario clone and eventually went back to finish Charlie the Duck.
The Mario clone is written in Turbo Pascal. Two versions of the source are available, one for Turbo Pascal 5.5 and one for version 6.0/7.0. This was done so that those without Turbo Pascal could enjoy the program thanks to Borland's release of 5.5 for free(1). The Free Pascal compiler is not an option because of the low level VGA routines used. Although the routines could be converted easily enough, I decided to stay with Turbo Pascal 7.0.
Why use Turbo Pascal for game development? The simplest answer is ease of use. The integrated development environment of Turbo Pascal is excellent and you don't have to play with the various memory models found with Dos C compilers. Additionally, tools or libraries may be available for the language that simplify certain tasks. For example, the Mario clone uses the Gred sprite editor, which automatically produce the code to compile the sprites directly into the executable(2). Except for the limited ability of pointers, Pascal is just as capable as C.
Not all the features of the original Super Mario Brothers game are found in this clone. Without the limitation of two button Nintendo controller, the program separates the run and fire buttons to the control and space keys, respectively. Gameplay remains the same except for the lack of a time limit. A time limit is relatively easy to implement. Here is a patch but some tweaking may be required to make it reasonable for all the levels.
Only six levels are provided. Like the sprites, the levels are compiled into the code eliminating the need of any files except the executable. This is convenient for players since they can easily install the game, but makes development more time consuming. If a flaw is found in an image or level, the program must be recompiled. There is no level editor which makes modifications even more complicated. No user modifications are possible(3) and the 640K limitation on Dos programs further restricts the design. There doesn't appear to be any boss creatures nor support for restricting the character to a particular area while fighting the boss(4).
A save game feature is provided but it may not be readily apparent how to use the ability. If you simply started a game and expect to be able to save it later, you are in for a surprise. There is no way to specify the save slot after beginning a game. Instead the game slot is only specified when you start playing. Even so, the system only allows restarting on the last level you played. Score and lives are reset, making the feature of questionable value.
There is one other interesting addition. From the pause screen,
several cheats and features are available; everything from added lives to
recording demos. The feature I want to call your attention are the
credits. In play.pas, the constant Credit is defined
but it is not simply the string "PROGRAMMED BY MIKE WIERING." The string
is encoded to prevent easy tampering of the executable. Shifting the bytes
by a constant value does not provide a significant deterant since the
pattern of increases and decreases between the letters is easily scanned
for. The Mario clone uses a pattern of constants to adjust bytes. A
determined hacker could still trace through the execution and uncover the
decoding but it would slow them down.
Although Super Mario Brothers is a well regarded game, it never really appealed to me. That changed with the introduction of the Game Genie. By using the Game Genie to tweak games, old tired games become fresh and interesting. As I recall, in the case of Super Mario Brothers there was one called "moon gravity." It allowed Mario to jump incredibly high, but the longer you held the button the shorter the jump. So what's to stop such an implementation in this Mario clone?
The algorithm for jumping turns out to be very specific to the needs of the program. The Y component of the velocity is set at the start of the jump and slowly decreased. The simple implementation of "moon gravity" would be to increase the starting velocity value and decrease it faster when the jump key is held down. Unfortunately, the desired results were not achieved even after toying with several values for the constants.
I wanted someone holding down the jump button to have a lower height than the starting blocks holding the coins and mushroom. Additionally the maximum height was to be about the same as the screen height. To accomplish this, many modifications to the algorithm were tried. The final algorithm, available here, had a fixed starting velocity but several conditions that added or subtracted from the value over time.
A determined level designer, or someone recreating the original Super
Mario Brothers levels could create a reasonable finished game out of
Mike Wiering's clone with only a little programming. The code does seem
to have a number of unexplained idiosyncrasies, however. The positioning of
status items in the ShowStatus procedure, for example. Instead
of a simple position value, several constant value are added together. Why are
they discreet values in the code and not a combined value? Too bad Charlie
the Duck does not include source code as it would be interesting to
see how the project progressed.
(1) Go to Borland's Community site for further details.
(2) The Gred sprite is written by same programmer as the Mario clone. Although it might not have been an existing tool for this game, it could serve as one for future developers.
(3) Compiling the data files into the executable does not entirely prevent user modifications. A hex editor could be used to hack the executable but the number of user modifications will likely be significantly lower.
(4) Mike Wiering gave some suggestions for restricting the character's ability to leave an area. The code at line 571 and 572 in Worlds.pas, disables scrolling from that point and seperate "two area's from each other, so you don't see the other. If you placed the code in line 572 about 16 lines before the code in line 571, you would have an area you can scroll to, but would not be able to leave it."