Game Info The Cruz site offers instructions on how to play, a complete list of game objects, playing guides, and much more. Sub-topics Basic Information Controls Item and Terrain List Strategy Guide Scoring Guide Differences from Kroz Miscellaneous Differences from Kroz NERD ALERT: THIS PAGE INCLUDES TECHNICAL INFO. There are many differences between Kroz as it originally looked, played, and sounded, and the way Cruz looks, plays, and sounds. This section describes the differences to the best of my ability. I say "to the best of my ability" because there are many complications when describing differences on such a grand scale. Mainly: The original series of Kroz games, compiled in Pascal and run in CRT text mode, relied on fundamentally different computer architecture than what you would expect for a Flash game, running in graphics mode, with mostly real-time interactions and event-driven routines. Substantial differences are therefore inevitable. There are eight different Kroz games, and several of these games were released more than once, resulting in slight version differences between releases. Some were just bug fixes (like forgetting to include exit stairs on an unordered level) or aesthetic mods. Others involved complete engine re-architecture, like the differences between Caverns I and Caverns II or Dungeons I and Dungeons II. Reconciling all these differences is a huge challenge. Game interactions often differ between episodes. For example, text may or may not be whippable, trap default visibility and chance item probability can vary across episodes, gem pouches don't always give 25 gems, bombs don't destroy same spectrum of items, quake traps can drop breakables in some episodes but boulders in others, and the list goes on. It is tough to account for all these subtleties, but it is nevertheless absolutely necessary. While the level designs for the original Kroz games were extracted directly from Apogee's 2009 freeware release under gnu GPL license, there is no guarantee that these designs match whatever version you might have actually played. The last "master" set of source code files in each folder formed the basis for the extracted levels. Determining the proper timing for Cruz gameplay has been an absolute nightmare. It required careful tuning of emulated speeds on all the original Kroz games and close inspection of the source code to figure out how timing was supposed to work in the first place, on relatively slow machines. Differences have been categorized into the following sections: Graphics Sound Timing and Control Gameplay Scoring Level designs Metadata Graphics The most obvious difference is that Cruz has far better graphics. The Cruz color scheme and general sprite design closely resemble the layout used in CRT text mode for Kroz. Cruz allows transitional animation between individual squares, as well as overlays to the game grid itself. Nothing is "locked" into a specific unit cell, which would be the case if CRT text mode were emulated purely. Of course, Cruz still locks objects in the grid to unit cells when they are not moving. This is a gameplay staple. The perspective for the Cruz game grid is "slightly" more square than in CRT text mode, although it is not totally square. Kroz did not have a zoom feature. The entirety of any given level is ALWAYS visible for Kroz. The status bar and title bar info are displayed above and below the game grid in Cruz; they were right-justified for Kroz. Sound The original sound in Kroz was generated using PC speaker effects. This usually meant programming the single-tone speaker to a specific frequency and using time-delayed loops to manipulate the pitch and duration. However, in some cases, a limited form of pulse-wave modulation was used to generate sound, which involves turning on the speaker for a small fraction of a second in order to generate more complex waveforms (monster movement, moving wall movement). Kroz sound effects are played in foreground. While sound is being programmed, nothing else can occur. The illusion of sound effects happening while visual effects are also happening is based upon the fact that in many instances, the PC speaker would be left on at a particular frequency while visual effects were manipulated as interstitial operations between sound programming. In this respect, the sound programming actually helped time the visual aspects of the game and even the gameplay itself. The Cruz sound system uses ActionScript 3.0's preferred mechanism for audio playback: waveform audio, played in background. Making Cruz sound effects "sound" like Kroz meant recording the PC speaker effects digitally for playback purposes. Some editing was done on the recordings to make the sounds more pleasing to the ear or fit within the new game's timing expectations. Cruz has some of its own sound effects. A small PC-speaker-programming application, run in an emulator, was used to generate effects that sound similar to those used by Kroz. A lot of Kroz sound effects can sound substantially different depending on the emulated computer speed used during gameplay. It complicated the task of determining what sort of sound any one effect should have in Cruz: should it be the "slow" version, the "medium" version, or the "fast" version? After experimenting with different playback speeds, I decided which "speed" of effect to use on an individual-effect basis. Kroz did not have any music. The Cruz soundtrack is an extra; enjoy. Timing and Control Kroz did not utilize any directly taken-over timer routines, which meant that timing relied on the Pascal "delay" function, waiting loops with constant counters, and actual computer speed. A confounding factor to determining the speed at which Kroz should "really" run is its fast/slow CPU setting at the start of many of the episodes. Far from determining a simple delay counter, this choice in fact modifies many different timing nuances in diverse ways. I ended up picking the "Fast CPU" set of time delays when implementing gameplay in Cruz. The crux of the timing issues in Kroz is how its main gameplay iteration proceeds. The following is a brief summary of a main gameplay iteration: After pausing for a set amount of time, an iteration takes place, which controls bulk monster movement, terrain multiply/toggle/evaporate, generator spawn, statue gem steal, and player's falling movement in levels that have gravity. If player had moved, whipped, or teleported, the delay that normally would have caused the pause before a main gameplay iteration is erased, causing it to occur immediately after the move. There are other timing nuances concerning monster movement: Every nth main gameplay iteration, monsters move in bulk. The value of n will depend on the following: type of enemy, fast/slow cpu setting, and various other gameplay-oriented speed-up and slow-down effects. When the player pushes a boulder, the program drastically reduces the value of n for all enemy types. This seems to imply that it takes a while to persuade a boulder into motion, allowing enemies to sneak up on you very rapidly. Slow-time, speed-time, and freeze-time items alter the number of n iterations for monsters. However, the extent of the alterations depends on the fast/slow CPU setting. In a similar vein to monster movement requiring bulk servicing every n iterations, other events also require servicing, including blindness potion time left, slow-time time left, speed-time time left, and freeze-time time left. These also depend on fast/slow CPU setting. Concerning Kroz-specific bulk events, Cruz implements virtually identical business logic for its gameplay iteration. The one missing piece to all this is how often to execute a gameplay iteration when the player is standing still: what is the ideal rate? Although the answer is somewhat subjective, I believe the relatively slow rate picked is appropriate, with fast blue monsters moving at the rate (without any item mods) of just under 1 move per second. This gives the user enough time to apply good strategy, but without giving him or her a functionally infinite amount of time to decide what to do, either. If the timing seems unusually drawn-out, it's because the original speed was supposed to have worked with an 8086 processor. Unfortunately many newcomers to Kroz do not remember how fast it originally ran. But I do, and I remember the gameplay was more strategy and not so much action. But regardless of how fast Kroz "should" run at, one thing is definite: if the player moves, the gameplay cycles one turn by default regardless of CPU speed. Therefore, running won't let you sneak past monsters in Cruz any easier than it would be for Kroz at ANY speed. I have noticed that other people's attempts at porting Kroz over to Flash have shown that such individuals have come to very different conclusions about timing. From my inspection of the source code and testing of the original games in massively slowed-down emulated environments, I have found that player movement and interaction actually SPEED UP the gameplay, whereas others have determined that player movement and interaction SLOW DOWN the gameplay. The rationale for player movement slowing things down probably has to do with sound being played in foreground. The "footstep" sound has the effect of throttling the player's movement, and while such sounds are being played, nothing else can happen. This makes everything, including monster movement, seem slower. Cruz does make concessions for some "Kroz-like slowdowns." For example, certain events like quake traps do not allow monsters to move in real-time, and the player cannot move while such events are occurring either. Similarly, key events do not occur while the player is moving from one square to the next. Kroz also confounds bulk monster movement timing with a rather odd algorithm: every time a monster moves, there is a probability (varies depending on episode and type of monster) that the player can execute an interstitial move before the bulk movement is complete. This lack of determinism was deemed undesirable for Cruz. Cruz does not allow such interstitial player movement. Some effective gameplay strategies in Kroz involve waiting for long periods of time (ostensibly to wait for monsters to approach and suicide into breakable walls). Cruz makes it easier to "speed up" such strategies by including a "Fast-Forward" option, which speeds up everything as long as the "Fast-Forward" key is held down. Gameplay Copying the Kroz gameplay as much as possible, while toning down the frustrating elements, was the core challenge during the development of Cruz. There are many different nuances to Kroz gameplay that are found in only one type of game: Kroz. Difficulty settings were removed in Cruz. I figured there was not enough replay value for Kroz games the way difficulty was implemented. This is because Kroz simply manipulates a few inventory items and probabilities for useful item bonuses, but does not differentiate final scores for higher difficulty, leaving little incentive for greater challenge. Cruz assumes a virtual difficulty setting of Novice in its calculations. Kroz used a relatively inefficient system for unordered level generation: picking random spots to place a specific type, and rejecting coordinates already taken in favor of other coordinates. This means level generation with few or no "spare" spaces could take a long time to generate. Cruz improves upon the above system by treating the entire grid as a random list: each coordinate picked is removed from the set of available spots for the next random pick, resulting in no rejected coordinates. The red, green, and blue enemies, as well as moving walls, move in bulk in both Kroz and Cruz. But Cruz keeps track of these moving objects in a different fashion, storing them differently in the grid and iterating them in a different order. Kroz had two records of moving objects: the grid types themselves (identifying enemies, items, walls, empty space, etc.), and an array to store the positions of each moving object. This meant that enemies would not necessarily iterate in a predictable order; rather they iterate in their spawn order. The spawn order depends on three factors: If ordered level: At the start, enemies will move in the order from left to right, then proceeding down each row. If unordered level: Arbitrary order, since enemies have positions selected randomly initially. If mid-play spawn: Order is after every other object already spawned. Iteration, of course, still depends on how many ticks are remaining for the monster type. Blue enemies have the smallest tick reset value, while red enemies have the largest tick reset value. Gaps will inevitably appear between diverse monster clusters as a result of these out-of-sync counters. There are two problems with the Kroz implementation of monster storage and movement: Depending on spawn order, gaps might appear between monsters of the SAME type if the player is located to the right of a long row of monsters, making it impossible to coax them to one side as a solid pack. For this reason, most of the times you will need to move them like this, you will be on their left. Destroying some monsters (using whips or bombs) causes existing monster data to be moved into the array-of-monster-positions gap made by the ones just destroyed. This is bad because the game does not veto the movement right away for monsters that had already taken a turn--they might get two or more moves per iteration, erasing any veneer of safety you might have gotten from whipping the closest monsters! Cruz fixes these problems by iterating monsters in a completely different fashion: Most monster positions are not kept track of in a separate array--there are ONLY the gridded types, nothing more. It is possible to create a monster just by setting the grid, and removing a monster by replacing the type with something else. Iteration uses a radial-outwards algorithm (if not a sideways level) or a horizontal-outwards algorithm (if sideways level) Radial iteration guarantees that monsters will not leave gaps depending on which side of the player they are on. It also prevents the monsters from taking more than one move per iteration, since the grid is the only record of them. For sideways levels, the horizontal-outwards algorithm moves columns of enemies towards the player, starting from the bottom of the screen and scanning upwards. The reason it isn't top-down is because there are some cases where many objects move column-at-once and need a valid floor to stand on (like the moving walls in "Crushed and Beaten"). Sideways levels in Kroz do not automatically stop monsters from moving off the edge of cliffs. The reason monsters normally don't move like this in the game is because closeable wall types line the cliff edges, which stop monsters and moving walls. Cruz DOES automatically stop monsters from "walking on air." A monster will only walk on a square that would stop you from moving into it. Cruz supports 11 new types of monsters. Some of them are iterated in bulk, while others have their own dedicated object instances stored in a separate vector. Whipping objects does the same amount of damage in Kroz and Cruz for the FIRST swing. Cruz departs from the Kroz "probability to destroy" system when it comes to multiple whip swings against a wall, tree, boulder, or statue. The reason for the departure is common sense: you would expect a weapon that could potentially break something on the first hit to at the very least weaken the object hit, if it were not broken. Cruz applies a 2x whip power multiplier for the second swing and a 3x whip power multiplier for subsequent swings. Cruz reveals the damage on such weakened objects with a visible change in the tile that is hit (always darker, sometimes comic). Kroz games varied slow time, speed time, and freeze time counts across episodes. Cruz uses the counts from Lost Adventures. In Kroz, teleport scrolls and teleport traps could take the player anywhere, including to the same spot repeatedly. In Cruz, teleports cycle through ALL available spaces in the grid, not picking the same place twice until all spots have been checked once. There are some levels in Cruz that impose greater control over where teleports take the player. This is mostly accomplished using field effects. Enemies, boulders, growing lava/trees, and grid modification events like quake traps do not destroy nearly the same combination of types upon movement for Cruz as they did for Kroz. In particular, the Kroz letters, keys, and certain critical types for completing the level, like close-spell pentagons, are no longer destroyed quite so casually. The quest artifacts in Kroz give points when gotten, but the player usually has to walk into a special passage after that in order to end the game. I figured this was kind of pointless, so in Cruz, the game ends automatically when the quest artifact is gotten. Note that the AMULET and STAFF types don't necessarily cause the game to end; they are just implemented that way for the final level of every adventure. Tunnels in Kroz always picked a random destination (if there are more than two tunnels in a level) and a random spot to exit from the selected destination. In Cruz, tunnels default to a round-robin system that cycles through every possible destination and exit spot. Some levels in Cruz revert to the random system. Both Kroz and Cruz prevent a tunnel from being traversed in such a way that the same tunnel entered is also exited, but a different exit spot is chosen. This means that it is often necessary to open an available spot adjacent another tunnel, so that tunnel can be navigated to next, and then back to (presumably) a different exit spot. Some Kroz adventures referred to the golden nuggets as "ancient artifacts." In Cruz, they are always referred to as golden nuggets. Kroz sometimes colored the nuggets differently on each level. In Cruz, they are unmistakably gold. Some versions of Kroz adventures have quake traps visible as question mark symbols. Quake traps are always invisible by default in Cruz. Quake traps sometimes arbitrarily stopped dumping rock in Kroz based on a probability. In Cruz, this does not happen. Creature creation traps sometimes arbitrarily stopped dumping enemies in Kroz based on a probability. In Cruz, this does not happen. Generators randomly pick spots for enemies to spawn while at least one exists in the level. They function the same way in Kroz and Cruz, except that it is possible to manipulate the generation probability per gameplay iteration in Cruz. In both games, the rate of generation is NOT dependent on the number of generators present; it's either all or nothing. Creature zap spells sometimes killed less than 50 enemies in Kroz based on a number of factors. Creature zap spells kill at most 50 enemies in Cruz, provided they are the killable type (e.g. moving walls are not affected). Reveal gem scrolls sometimes arbitrarily stopped dumping gems in Kroz based on a probability. In Cruz, this does not happen; you are guaranteed the maximum number of gems unless there is no room for new gems in the entire level. Gem pouches always have 25 gems in Cruz, and are not destroyed casually as easily as they are in Kroz. Kroz only supported one statue per level. Cruz can have any number of statues per level, requiring you to kill them all as a way to stop them from robbing your gems. Like generators, the number of statues in a level does not control the gem theft rate. Wall vanish traps sometimes arbitrarily stopped hiding walls in Kroz based on a probability. In Cruz, this does not happen. The Kroz bonus letters were liberal in how you could get the bonus multiple times in one level: if you had gotten the first three letters, you could just get the "Z" repeatedly to get multiple bonuses. In Cruz, you have to gather the entire sequence in order again to get a second bonus. No cheating. :-( The closeable wall types have always been somewhat quirky in their implementation across Kroz games. Some block enemies, while some don't. Some stop tunnel traversal; some don't. In Cruz, tunnel traversal is blocked by the second closeable wall type. In all other respects, Cruz imposes the rules used in Lost Adventures. The open-wall spells and close-wall spells can be destroyed by boulders based upon their visibility in Cruz: visible=no, invisible=yes. Boulders in Cruz can be gotten rid of by pushing them into water or lava. Cruz has the ability to force drop-rope chords to fall to a certain spot even if there is a temporary obstruction. If the appropriate field effect is placed over the path a drop-rope is likely to take, the rope will pause at any obstruction until the obstruction is removed, whereupon it continues to drop. Spears can go through lava in Cruz. Scoring Scoring in Kroz has always been tough to characterize. Although some scoring elements are fairly consistent across episodes, there were enough differences to make it hard to account for them all in Cruz. The original Kroz trilogy (Kingdom I, Caverns I, Dungeons I) was far more generous with points than the games that came later. Such items as blindness potions, golden nuggets (originally called artifacts), chests, and even contact with lava originally yielded twice as many points or even more. The revised trilogy and the later games in the series (Return, Temple, Final Crusade, and Lost Adventures) cut down the point value on many of the items significantly. In Cruz, I have tried to make the point value for most of the items consistent across episodes. If a common, basic item has a different point value across episodes, I favored the point value given in the later episodes (like Lost Adventures). Certain episode-specific features, like the quest artifacts, have their original point values. Kroz does not let your score go negative. Cruz does so only if the player is not on level 1 of any given episode. Cruz gives more points for enemies killed with bombs. Kroz only gave points for standard enemies killed with explosions (the standard point value of 10, 20, or 30). Cruz gives the standard point value for ALL enemies killed with bombs, including moving walls. Some revisions of certain episodes of Kroz did not give the standard point value for enemies that suicide into crumbled walls. Cruz always gives this point value. Kroz did not give points for enemies killed with spears. Cruz gives the standard point value for all enemies killed with spears. Kroz only gave 100 points for destroyed statues. Given how hard it is to destroy them, I found this amount to be so outrageous that I had to change it in Cruz. Now you get 2,000 points. Creature zap spells gave points in Kroz based on a formula for how many enemies were killed. Cruz gives either 150 points for some enemies killed or no points for fewer enemies killed. In Cruz, if a level is restarted, or if progress is restored, the score is reduced by 1,000 points. Repeated saves and reloads will double this reduction amount each time, resulting in progressively lower scores. This acts as limited protection against "high-score scumming." Running out of whips (or teleports, in some cases) usually means the game must end in Kroz. In Cruz, special "compensation" whips and teleports are dispensed if the player runs out of the item. However, these items impose a huge scoring penalty if picked up. Level designs The source for the Kroz level designs in Cruz was the "MASTER2" family of folders in the Kroz GNU GPL source code release of 2009. Having played through the entire series multiple times, I have found this to be the best match for what most people have probably played. From a technical standpoint, Caverns is the most primitive in terms of fewest number of object types used in the game. Despite the fact that Caverns is billed as the second in the Kroz series, it appears to be first if you consider the more primitive nature of the source code. And few would argue that Caverns is by far the hardest of the series! With Return and Temple, most of the types present in the remaining Kroz games would appear, including the full set of trap items, the Kroz bonus letters, etc. Terrain growth was also implemented with these games. Final Crusade introduced boulders and high-voltage walls. The level designs in Kroz games would undergo a paradigm shift with these types, because enemies could now be killed without the use of whips or bombs, and there were many more ways to implement puzzles and strategies. Lost Adventures (and some of its levels borrowed for Kingdom II) introduced still more features, such as ropes and drop-rope chords, gravity, blinking electric walls, surround-spawn triggers, and special effects from tablets. The Underground Empire of Cruz implements many new object types, allows for the use of field effects, and supports a special scripting language for tablet and quest artifact effects. While the gameplay is essentially the same as for Kroz games, Cruz is designed to be a reusable engine, not stand-alone like the individual Kroz executables. Kroz levels did not have named titles; Cruz levels do. When the original Kroz episodes were ported over, I came up with my own level titles. If some text within the level identified a feature about the level that could serve as a satisfactory title, I would nearly always just use that text as the level title. In most cases, no such text was available. Typos and grammatical mistakes in the Kroz games have been fixed. Several Kroz levels now have scripted zoom features based on certain items gotten or certain areas entered. I added the special zoom ranges based on how well zoomed-in areas fit with a particular level. In some cases, the original entire-level-at-once zoomed-out view was used. "Footnote" tablets have been placed in some of the Kroz levels, providing special information that is not pertinent to the gameplay. These tablets are supplemental only; they do not provide clues. My role as editor has been John Hancocked on some of the walls in Kroz. Sideways levels that have bottomless pits will place additional pit tiles across the bottom border, if there is a pit tile directly above the border. "Wicked Corridors" has the close-wall trap applied only once you get the key in the trap area. It no longer seals off this area if you try to get other keys first. "Fork in the River" has an added pair of tunnels to get to the right side of the level. Managing to get to that area by teleportation is very tricky, even with the Cruz algorithm that tries to visit every point at least once before cycling. The "Return to Kroz" opener now gives the user a free teleport scroll to escape the upper-right corner trap. The trap also does not lock away the key at the lower left; it simply seals away some of the nearby items. "Wall-to-Wall" is no longer quite as mean about sealing away the "O" letter. Approaching it from the wrong direction now just makes it harder to get to. "The Water Labyrinth" now prevents quake traps from blocking the tunnels. "Chamber of the Crown" no longer applies wall vanish traps to the breakables in the upper right corner. This is because if they vanish, the level cannot be finished. "Traversal Torture" no longer ruins your chances of completing the level simply because you get the tablet. It just seals you in. "Chasm of Fate" now gives you the "K" letter. This was perhaps the most egregious level editing mistake on the part of Apogee, which prevented getting the Kroz bonus despite 3 letters already present. Not knowing exactly where the "K" should be placed, I chose an intuitive spot that was not being used anyway. "Crazy Cubicals One Last Time" now gives you an extra creature zap spell. The reason is that the red enemy blocking the final tunnel exit might not get zapped with the first one, forcing you to restart the level from the beginning...and hopefully get luckier the next time around. Now the only way to miss that enemy is if you trip too many of the creature creation traps in the upper left corner, causing the rooms to be filled with over a hundred enemies. "Monster Marketplace" now gives a teleport scroll near the freeze creature spell at the mouth of the lair, since you might not have any other teleport scrolls to escape the trap this early in the game. "Diary Day Three" makes the right path at the start more difficult to navigate than the left. Previously the right path was a dead end. "Crushed and Beaten" no longer seals off access to the exit if you get the tablet. It just seals off the tablet itself (including you if you are inside). "Mystery Ramp" no longer seals off one of the keys to form the walkway for another key. Now it just forms the walkway. Metadata The complete characterization of game data in Kroz was fairly straightforward, although the storage for every nuance of gameplay was not necessarily co-located. A Kroz level's layout could be characterized by either a "PF" ordered level array or a "DF" unordered spawn count list. Terrain modification info, hide-item-type flags, gravity info, start delays, and item-specific appearance modifications tended to be characterized by assignment statements at or near the body of the Pascal procedure that set up the level. Small details in levels, however, were often characterized by information far away from the rest of the metadata. For example, tablet messages and tablet effects had their own separate file, and other incidental things could be accounted for literally anywhere in the entire code base of the program. With Cruz, the details for any one level are entirely self-contained with the exception of the level number. Level name, level features, and all gridded overlays are co-located within the same XML element. The level features in Cruz closely resemble the names and values used in Kroz. This made the episode conversion process much faster than it otherwise might have been. Cruz supports many level features that Kroz did not support. The character encodings for an ordered level's main layer are nearly identical in Kroz and Cruz. With almost no re-architecture necessary for any given level, reconstituting the gridded data was quite easy. There are exceptions to the original character encodings in Cruz: Encodings do not necessarily map to the same zero-based gridded item type during gameplay. Text characters (the lowercase text characters) and text punctuation metadata in Kroz have become their own separate "text layer" in Cruz. It would have been hard to maintain text in the original format, especially considering that certain characters, like !, ", ', ?, ;, and : utilized extended ASCII encodings that did not even come close to looking like what they were supposed to represent. Cruz lets the user have more liberty in what can be placed in the grid as text. Both uppercase and lowercase letters are permitted, and punctuation does not require Alt+Number combinations to enter. Cruz requires XML entity markup to be used for some encodings per the rules for parsing XML. Cruz supports its own unique character encodings, in accordance with the greater number of supported object types in the game itself. Unordered levels in Kroz were text versions of spawn counts, parsed at run-time into integers. Cruz uses XML to represent the spawn counts and organizes the counts by name instead of by numeric order. Like Kroz, the Cruz unordered spawn counts lack support for some of the higher-numbered activator types (5-12). Cruz supports additional spawn counts, in accordance with the greater number of supported object types in the game itself. The field effect list, containing a variable number of type-and-rectangular-range instances for any given level, is a Cruz-only phenomenon. Kroz did not use field effects. Cruz allows for a "color layer" to be used in conjunction with the main layer and text layer. The color layer was not used in the game, though.