






|

 |
Game Info
The Cruz site offers instructions on how to play, a complete list of game
objects, playing guides, and much more.
Sub-topics
|
 |

 |
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
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.
|
 |
|
 |
|