News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Lode Runner 3D for N-64 level editor  (Read 2598 times)

fellowroot

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Lode Runner 3D for N-64 level editor
« on: June 03, 2012, 02:03:21 am »
I know I already mentioned about this in another thread but I'm just dieing to know.

What would a person have to do to make a level editor for this game?

What's involved?

How feasible is it?

Anyone willing to give it a shot?

I just think it would be really cool to be able to make your own levels especially since its a puzzle game.

Thanks.




Zoinkity

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
Re: Lode Runner 3D for N-64 level editor
« Reply #1 on: June 04, 2012, 09:47:03 pm »
I'll have to take a good look at it to figure out the level format, but interestingly this is one of very few N64 games to use PKzip. 
It appears to use a cookie-cutter approach with stock objects, but I won't swear by this.

fellowroot

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Re: Lode Runner 3D for N-64 level editor
« Reply #2 on: June 04, 2012, 10:07:33 pm »
I'll have to take a good look at it to figure out the level format, but interestingly this is one of very few N64 games to use PKzip. 
It appears to use a cookie-cutter approach with stock objects, but I won't swear by this.

Thanks for considering taking a look into it. I don't know too much about hacking and I really don't know any programming languages. (well, I took visual basic, matlab, mathematica)

Anyway, the whole thing is that I've a very passionate video game player and video game designer and I would love to make several high quality hacks one day.

I would like to think that a level editor wouldn't be that hard for this game because all it is, is a bunch of 3 dimensional blocks arranged in a 3 dimensional world. All you would need is a list of the different types of blocks and to be able to place them in the environment. That's pretty much it.


Zoinkity

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
Re: Lode Runner 3D for N-64 level editor
« Reply #3 on: June 05, 2012, 05:39:32 pm »
Ohh, okay.  Sorry, wasn't certain on the scope.  At first I was thinking a full editor (images, DLs, etc.)
Interestingly, the game doesn't just use a microcode system to set up stages and events, but like Eurocom's games also uses one in lieu of display lists.

Pushing files around would be remarkably easy.  I would suggest building against the Japanese and PAL releases instead of North America.  Japanese is already set up for NTSC and european for PAL, but uniquely the filemap for those two regions (after base ASM) is exactly the same and their tables are even at the same location.  Both also supply the same amount of multilingual support.

I'm still tracing the microcode commands used for stage setups.  There's quite a few commands and they are also used for triggers.  Text triggers off of of an ID system, and altering text is remarkably simple once you work out the special escaped characters.

[edit]
Have the formats for the FDOs, all but one type of PAK entry, most if not all text file escape sequence variations, and half of the world binary format.  MUTs are a bit esoteric and one of the sound formats is undocumented as of right now.  Actually, dumped all the FDO images.

[edit edit]
I should point out those are all the resources that are drawn upon.  Level files are the LRL files in PoolLRL.  They use one of three major formats (BBLR, BBL1, BBL2) with string designators for each class within them.  They reference the base textures and special object types, but oddly 'blocks' are defined more by a system of contour and repetition.  It's a unique system to be sure.

[edit edit edit]
Stage construction is remarkably simple.  Right now in documentation phase for all the different possible values and special features.
Basics are first four bytes of a CELL indicate its type and connectivity.  Next three words are simple cartegian coordinates indicating where it belongs.  There's optional floats after this to distort them and all, which is part of the reason for more documentation.

Things like circular and squiggly paths are defined by PATHs.  These connect two cells automatically using particular mode flags and a given number of steps.  Each step has a coded value, just like cells, to indicate their type and connectivity.  For instance, the semicircle at the beginning of level 1120 consists of six steps between cells 1 and 7.  Each is a 2way indestructible tile. 

LODE sets your starting position and MONK starting positions for monks.  EXIT is obvious and has a minimum gold value, and LOOT would be items.  Right now I only a few item codes: basically keys, gold, and some powerups.  LIFTs connect two rooms and are fairly straight-forward.

[edit edit edit edit]
Figured out the demo format too.  DEM files just periodically probe the controller port.  It's a slightly-simplified format, and the recorder might still be embedded (part of a debugger is), but basically just periodic probing.  'World 8' are all the demo files, which really just clone existing stages.
The only thing I'm not certain of yet are how falling gold is set versus static gold.  Might be world-dependant, as both gold are a special case.

You could probably build an editor very simply.  The only non-aligned blocks are generated via paths.  These 'stretch' from one block to another and can follow curves, assigned via bitflags.  Sometimes a few of the members will be invisible, in particular the 'stairs' in the first stage.  Invisible blocks are occationally used, mostly as placeholders on lifts (this permits falling off one) but occationally to place an item/monk so they're above the stage and drop in. 
Block schemes are hardcoded to worlds, as are what images are applied when using different pathing.  If a block is destructible directly affects the image set, although once the level is loaded you can circumvent that.  Arrows (and therefor connectivity) uses a different set of bitflags.

Special blocks and items are all simple to set up.  They're applied to cells, and occationally invisible cells are used for this purpose.  The only annoying thing is when an item/block is set in the middle of a path, although that just means you need to use an offset value to position it.  Everything else is simple cartegian graphing.

Also, amazingly you can stuff comments into level headers.
I'll start typing everything out sometime between work.  Might make a few proof of concept stages to demonstrate different things.  It uses a simple filetable so really all you need to do is stick each file in sequence and mark the file offset.  Decompression is based on extension.
Stage names are generated via formula and use the extension LRL: world, stage, level, sublevel (1110.LRL being the first level).  So long as you stick to the original filenames all is well, but otherwise you'll have to hack the lookup.  Other resources like objects are a bit dicier and do lookup based on name lookup in the general directory and relevant zip files.  So, if you wanted to change one of those names you'd need to hack the codewords and/or lookup method. 

Overall, super simple.  You should be able to make an editor easily.
« Last Edit: June 09, 2012, 10:43:14 pm by Zoinkity »

Zoinkity

  • Hero Member
  • *****
  • Posts: 557
    • View Profile
Re: Lode Runner 3D for N-64 level editor
« Reply #4 on: June 18, 2012, 06:30:17 pm »
Sorry, figured would do an update in a new post.
Since the above poster mentioned they don't program, I've been reading up on using python to make a simple editor.  At first it would probably only have a 2D interface since, well, I'm not that hot either.

The interesting thing worth posting over is that in documenting the different level block types there's a few that aren't used.  They may be used 'internally', insofar as the same code they generate can be generated by other blocks.  Most notable is the worm, which is a specialized PATH type particular to certain worlds.  The actual camera is set via the first CELL, which is always 'empty'.

The unused types are:
AUDIO
CAMERA
TILE
RAIL
WORM
POOF

There's about four bitflags left common to all objects, but after that I'll look into how the other commands expect to be formatted and try demoing their usage.  Looks like the actual commands are invalid within a level file, as in using them will try to jump to a NULL function pointer, but there is a complete set of handlers for each type assuming formatted data was already provided.

Oh, did find a few extra features you can activate in the start menu.  You can use the GS codes:
80152937 000E
80152947 00FF
-in a north american game to unlock all the different options.  The first sets the number of entries that are selectable in the menu, and the second is a series of bitflags that enables each.  Note the stage select will not let you choose the levels 8110, 8120, 8130, 8140, and 9999.
« Last Edit: June 18, 2012, 09:06:19 pm by Zoinkity »