hypothetical Reskronchulonch editing guide

From hyperpixel, 9 Months ago, written in Venderant Nalaberong, viewed 97 times.
earl https://txt.blorgblorgbl.org/view/3d0db3e5 Embed
Download Paste or View Raw
  2. hypothetical how-to-edit text:
  4. You can create your own Reskronchulonch levels using commonly available
  5. cross-platform tools. You'll need Tiled or another editor that can work with
  6. TMX files, and Python 2.7. If you share your levels, please do it in a way that
  7. makes it obvious they aren't official ones.
  9. To edit a level, first edit the TMX file corresponding to the level number,
  10. then run make_mapdata.py to compile the TMX files into a new version of
  11. mapdata.js. (To run make_mapdata.py, you might type something like
  12. "C:\Python27\python make_mapdata.py".)
  14. If make_mapdata.py encounters anything it doesn't understand, or that it
  15. thinks would break the game, then it will print a message and also save
  16. that message in a file called make_mapdata.log.
  18. For your maps to work, you need the following:
  20. - Exactly one tile layer using the foreground.tsx tileset. This contains most
  21.   of the game elements.
  23. - Optionally, one layer using the background.tsx tileset. This contains
  24.   immaterial elements the player can pass through, such as reverse-gravity
  25.   fields. The "gravity core" tile is invisible during play; if you place one,
  26.   gravity in the level will point towards that tile.
  28. - An object layer with objects using the objects.tsx tileset. This is how you
  29.   place game elements that can have individual properties. Objects will
  30.   always snap to be tile-aligned in the game, even if you place them
  31.   off-center in the editor. Objects are identified by their tile from the
  32.   tileset; the "type" is never used, and the "name" is only used for certain
  33.   orbs.
  35. You need to export the file using the verbose XML or CSV format, as
  36. the make_mapdata.py script doesn't understand base64 or compression.
  38. Here are more details about what you can place:
  42. - Walls and diagonal walls are simple solid obstacles. They'll block bullets,
  43.   except for bullets that are flagged as penetrative. They'll never block
  44.   moving orbs. The color of a wall is purely cosmetic.
  46. - Blinkwalls are shown in the tileset with a checkboard pattern and a number.
  47.   All blinkwalls open and close to the same rhythm. The number indicates
  48.   which beat of that rhythm a blinkwall uses. The color of a blinkwall is
  49.   purely cosmetic.
  51. - Doors are shown in the tileset with a color letter; this letter does not
  52.   appear during play. The color determines which buttons or dropoff points
  53.   can open the doors.
  55. - Icosahedra wait to be towed to a matching dropoff point.
  57. - Dropoff points open doors of the matching color when an icosahedron is
  58.   brought to one. Like doors, they are shown in the editor with a color
  59.   letter that does not appear in game.
  61. - Buttons open doors of the matching color when shot. They are shown with
  62.   a color letter in-editor. A button that you place using the foreground
  63.   tile layer has a permanent duration; for a timed button, you must use
  64.   the object layer.
  66. - Timers are invisible except when a timed button of the matching
  67.   color is in effect. While a timer of the color is ticking, the button
  68.   shows the approximate time remaining in seconds, or 99 for very long
  69.   durations.
  71. - Orbs are there to be shot. An orb that you place using the foreground tile
  72.   layer does not move or shoot and has no shield; more complex orbs
  73.   use the object layer.
  77. - Reverse gravity fields (blue) reverse the direction of gravity. (On
  78.   difficulty 1 only, reverse gravity is also stronger than normal gravity.)
  80. - Sideways force fields (striped) push the player sideways with a varying
  81.   degree of force. The types with arrows push in that direction; the type
  82.   without arrows alternates back and forth. The arrows are not shown in-game.
  84. - White arrows are visible, but have no physical gameplay effect. Note that,
  85.   even if they display behind walls in the editor, they will display in
  86.   front of walls in-game. These are the same as sign objects containing
  87.   just a single "u", "d", "l", or "r" character.
  91. - Sign objects display in-game as text. To be displayed, these objects
  92.   must have a property named "text" with a value of the text to display.
  93.   Only certain ASCII characters are allowed. These are the space and
  94.   ABCDEFGHIJKLMNOPQRSTUVWXYZ.:0123456789. The lowercase letters udlr can
  95.   also be used; these become up/down/left/right arrows rather than
  96.   lowercase letters. For multi-line text, place multiple sign objects.
  98. - There must be exactly one player object. This may have two properties,
  99.   "title" and "description". If these properties are used, they give
  100.   the level-select-menu title and level-start description for the level.
  101.   They are limited to the same characters as text objects, except that
  102.   description may also contain line breaks.
  104. - Button objects use their color in the same way that foreground-tile
  105.   buttons do. They may also have a property "duration", an integer which
  106.   says how many frames the button keeps doors open for before closing again.
  107.   (30 frames = 1 second.)
  109. - A gravity core sets the level so that gravity is towards the core, rather
  110.   than downward (and reversed gravity is away from the core, rather than
  111.   upward). You may not have more than one. The game physics are
  112.   counterintuitive very close to the core, so walling it off is recommended.
  114. - Orb objects are much more complicated than the others, with many
  115.   optional properties. It's easiest to copy and paste an orb that already
  116.   does close to what you want, then edit it, instead of trying to set all
  117.   the relevant properties from scratch.
  118.  - shield: If this is a positive integer, the orb will have that many shields.
  119.  - regen: If this is a positive integer, and shield also is,
  120.           then the orb's shield regenerates. A higher number is slower
  121.           regeneration: one shield is restored every X frames, so for
  122.           instance regen=30 makes an orb regenerate once per second.
  123.  - spectral: If this is set to anything but blank or 0, the orb will be
  124.              a spectral orb, meaning it is invincible until all non-spectral
  125.              orbs have been shot.
  126.  - shotSpeed: If this is a positive integer, it defines the speed of the
  127.           orb's shots. 256 means one pixel per frame. For the orb to actually
  128.           shoot, shotTime must also be set.
  129.  - shotTime: If this is a positive integer, it defines the rate of the orb's
  130.              shots, in frames. For example, 60 means the orb shoots once every
  131.              two seconds.
  132.  - shotDelay: If this is a positive integer, the orb will wait this long
  133.               before firing any shots. This allows you to place orbs with the
  134.               same shotTime that don't fire on the same frame as each other.
  135.  - shotAngle: If this is an integer, it defines the angle the orb shoots at.
  136.               This is in degrees where 0 is up, 90 is right, 180 is down,
  137.               and 270 is left. If this is unset, and shotAngleStep is also
  138.               unset, then the orb will aim directly at the player.
  139.  - shotAngleStep: If this is a nonzero integer, it defines a change to
  140.                   apply to shotAngle every time the orb shoots. For example,
  141.                   if it is -45, the orb will fire in an 8-shot counterclockwise
  142.                   pattern. If this is set without shotAngle, then shotAngle
  143.                   is treated as initially zero.
  144.  - shotHoming: If this is an integer from 1 to 45, then the orb's shots can
  145.                home in on the player, turning by this many degrees per frame.
  146.  - shotPenetrate: If this is set to anything but blank or 0, the orb's shots
  147.                   will pass through walls. A homing shot loses its homing
  148.                   ability when it touches a wall.
  149.  - chase: If this is a positive integer, the orb will chase the player
  150.           at a speed of this many pixels per frame. Its "path" and "parent"
  151.           properties, if any, will be ignored.
  152.  - parent: If this is set to the name or ID of another orb object, then
  153.            this orb will move with that orb. For example, you can use this
  154.            to make orbs that accompany a chase orb, as in the level 8 boss.
  155.            This can be combined with the "path" property for relative movement.
  156.  - path: This gives the orb a looping movement path. It must be a string,
  157.          and the string must be formatted in a specific syntax. This is much
  158.          more complicated than any of the other properties.
  161. An orb path looks something like "60cw:+2,+2 60:-2,0 60decel".
  162. This is one or more space-separated fields of the form
  163. <duration><optional modifier>:<xmove>,<ymove>
  164. except that the last field can just be
  165. <duration><optional modifier>
  166. with no colon.
  168. Each field says what the orb is doing for a number of frames indicated
  169. by the duration, which must be a positive integer.
  170. The xmove is how many tiles it moves horizontally, as an integer that may be
  171. positive(right) or negative(left).
  172. The ymove is how many tiles it moves vertically, positive(down) or negative(up).
  173. With no modifier, the orb moves at a constant speed in a straight line.
  175. The modifier, if present, must be one of:
  176. cw: The orb moves in a 90-degree clockwise arc. xmove and ymove must both
  177.     be nonzero (they do not have to equal each other; an ellipse is allowed.)
  178. ccw: 90-degree counterclockwise arc; xmove and ymove must be nonzero.
  179. accel: The orb moves in a straight line, but it starts slow and speeds up.
  180. decel: The orb moves in a straight line, but it starts fast and slows down.
  182. The xmove and ymove of the last step are computed as minus the sum of
  183. all the other xmoves and ymoves, so that the orb will loop back to its
  184. starting point. If they are explicitly stated, they must match this value.

Reply to "hypothetical Reskronchulonch editing guide"

Here you can reply to the paste above