Jump to content

LRR remake project


miningmanna
 Share

Recommended Posts

lol username

Great stuff.

 

2 hours ago, miningmanna said:

If any of you are interrested in getting the project files and libs, I could give you them. You could try to load different models, and just try it out.

My guess is, you guys have expirience with programming, since you have written map editors, patches and more for the game. Though it was probably not Java.

I could leave some comments, so you could find the important variables fast, and also make a video for the eclipse project setup, if you are not familiar with it.

Yeah, I'd be interested in playing around with it or just seeing more of how it works. Maybe put it on GitHub or something?

  • Like 1
Link to comment
Share on other sites

GitHub repository:

https://github.com/miningmanna/LRR-remake

 

libs are included. Import the project, and change the build paths in the project settings, to match the path of the lib folder. Dont forget the natives folder of the lwjgl.jar

 

EDIT:

Info for picking an animation is in the README.md

  • Like 3
Link to comment
Share on other sites

Next thing I will work on is fixing the positioning of the "telepthing" and getting the transparency frames for the LWS animation, making the teleports as good as in the game.

The shader must also implement some basic shading, since, in LRR, the cursor is treated as what seems to be a point light. I would need to address that.

 

Once most of the graphical stuff is done, I would continue to map loading and generating the coresponding meshes to view in the camera.

1st and 2nd person would come after that. Since those views use some premade meshes (except for the recharge seam apparently).

 

On a side note:

For the next week or so, posts will come rarer, but with more content I guess? I will be moving in 6 hours to the city, where I study, and I havent gotten an internet connection in my new apartment. So I will be using public wifi, when I have made some solid progress.

Just in case, so that nobody thinks im forgetting/leaving the project.

  • Like 2
Link to comment
Share on other sites

So, I´ve worked on the transparency component for the animations. The buildings should now transition in, in their teleport animation.

The changes are on the github

 

Anyone who has tried to import and use the project: Have you had any issues? If so write them in here, and tell me whats going on.

 

Edit:

I have found a closer spot for an internet connection. So I might be able to update more often than I thought.

Compared to the ~6km to IKEA, this one only is about 1 km

  • Like 2
Link to comment
Share on other sites

lol username
5 hours ago, miningmanna said:

Anyone who has tried to import and use the project: Have you had any issues? If so write them in here, and tell me whats going on.

I haven't had time to try it yet (been pretty busy with various other things) but it's definitely on my to-do list, I'm especially interested in learning more about the LWO format myself and maybe trying some things with it (curious if I can get them loaded in Unity, just for fun... Then maybe if I do that, I could also easily rig up an OBJ exporter since I've already done that in a few other Unity projects. I don't think OBJs officially support all the data LWOs can contain, but I'd personally still have use for at least the basic geometry in an OBJ with planar textures converted to UVs - other conversion methods I've tried are unable to do that).

  • Like 1
Link to comment
Share on other sites

This is great. A while ago I was messing around with some LRR stuff again but stopped because I'd never be able to legally release it without including my converted LRR models. With a built in LW importer you don't have that problem and you can release this remake without the original game files like OpenRCT2 does. Very nice :D 

 

Edit: Forgot to say this but, best of luck! Most LRR projects don't end up finished (looking at myself too lol) but I hope you can make it. Too bad I won't be able to help you out alot because I haven't done game development in Java. I could maybe try to port your importer over to unity to see how that would end up :)

  • Like 1
Link to comment
Share on other sites

So, I´ve paused working on the animation loading for now. I cant figure it out right now. I will go back to that on another day.

Searching through the game files: I have found some files for the level scripts called: "NERP". Which seems to be compilable with C and the defined macros.

However it might be smarter to just write an interpreter for it, or maybe a compiler to Java byte code?

 

I have had a little break the last days (since I move my stuff into my apartment), but I have made some progress on the map loading (hence the level scripts).

maps.PNG.fa77394bb95196052b235119dcb0b35b.PNG

from left to right: Surf_01.map, Dugg_01.map and Croc_01.map.

 

As proposel:

instead of the NERP scripts I would include lua as level scripting language (maybe with some spins like brackets), what would be your opinions on that?

 

as of now:

I will work on map loading and make a little demo, so you can try it out.

Fixes will of course come as I go.

  • Like 2
Link to comment
Share on other sites

Searching through the game files: I have found some files for the level scripts called: "NERP". Which seems to be compilable with C and the defined macros.



However it might be smarter to just write an interpreter for it, or maybe a compiler to Java byte code?



We already have a NERPS compiler:
https://www.rockraidersunited.com/topic/2143-npl-scripter-v20-new/

I have no clue how any of it works, but you needn't remake it - I'm sure @Cyrem, who made it, will be able to help you with that!
Link to comment
Share on other sites

  • 2 weeks later...

Update:

 

I´ve started working on creating a MapMesh, so maps can finally be displayed. At the same time, it is now possible to write scripts for entities in lua, to create an AI for them. Next up is the level scipts. @aidenpons thanks for the hint, but since this will be running in Java, I´ll need to make a custom (if I dont want to mess around with pointers and jumps).

 

Level mesh:

 

The mesh is generated only with the surface information, since im not really sure how to make transform the mesh for the heightmap. But I´ll work on it.

The current version will be pushed to GitHub. It includes a new library "LuaJ".

 

The entity scripts will have acces to position, rotation, current animation and A-star pathfinding.

Any suggestions are welcome.

 

Next addition will be the texturing of the mesh.

 

Sorry for the large delay, but I had some stuff to do in preparations for uni.

 

Edit:

In order to run the program, drag the World/Shared, Pilot, Slug, CAPTAIN and Level01 folder from LegoRR0 into the project folder

(I will simplify this, so you only need to drag the folder LegoRR0 into the project)

  • Like 3
Link to comment
Share on other sites

So, I´ve implemented some basic texturing (not final, but for the sake of visualization). And transformed the maps mesh according to the heightmap.

The general form is correct, but it doesnt match the original. Has anyone ever looked at, how LRR applies the heightmap?

 

 

Regarding the textures: there is some system for the textures, since all hard rock textures have the filename: "rockX4.bmp".

 

Im guessing they have a simple algorithm for applying the map data to a mesh, but I cant figure it out at the moment...

Link to comment
Share on other sites

12 hours ago, miningmanna said:

Regarding the textures: there is some system for the textures, since all hard rock textures have the filename: "rockX4.bmp".

 

I believe they were originally made in a sprite sheet, then split. The naming system seems to be either rockYX.bmp or rockXY.bmp. If you lay them out, you'll see what I mean (this is YX form): http://prntscr.com/krhgo9

  • Thanks 1
Link to comment
Share on other sites

The heightmap only specifies a single corner per tile. You already know this, but for context: the maps are laid out with the top-left corner being the origin and positive directions being right and down. The top-left corner of the tile is affected when adjusted by the heightmap. Walls are affected by this, such that you can create a wall that looks like a floor (in other words, flat) by raising the lower corners by 7? units and lowering the higher corners by 7? units. Think of the heightmap in corners only and it will make sense.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

@Cirevam What I meant exactly was, that given a field is made of a square. And one of the squares corners is rised by some levels. The square is split up in 2 triangles. It is folded over one of the diagonals, but i cant figure out which diagonal is used.

 

If you dig into a cliff, it changes given the direction you dig:

So im currently not sure  how it works.

 

by the way: thanks for mentioning the scaling of the heightmap. I didnt know how many levels make up one block.

 

@Cyrem

thanks for the tip, makes it much more clear how they have done that. :)

 

Meanwhile I have made some progress on the script converting.

I´ve written a (somewhat) basic compiler from NERP to Lua. The lua enveironment only needs the already used functions (GetR1, SetR1, GetEnergyCrystalsStored, ...) and it should be working just how it is supposed to.

@aidenpons

Your level scripting tutorial was quite helpful. :)

 

I will improve the compiler to handle the weird scripts like "01.nrM", which has some wonky lines like:

TRUE ? AddR6 1 TRUE ? SetR2 1 TRUE ? AddR2 GetR3 GetR2 != GetR6 ? :WaitForCrystal/ WaitForCrystal:
{
	GetCrystalsCurrentlyStored = GetR1 ? Stop
	TRUE ? SetMessagePermit 0
	TRUE ? SetR1 GetCrystalsCurrentlyStored
	TRUE ? SetMessage GetR1 1
}

 

All old levels, aswell as user-created levels with nerp-scripts should be supported. But Lua should enable some more complex level-scripts.

I will also add the possibility to change the levels surf, height and other maps through the script. That should enable people to make some interesting levels, were caves could collapse or water break through the roof, flooding the cave partially.

Link to comment
Share on other sites

On 9/9/2018 at 1:13 AM, miningmanna said:

@Cyrem 

thanks for the tip, makes it much more clear how they have done that. :)

 

Despite how they have done their file naming, I have always created definitions for the map types so things don't get confusing, for example:

 

	public enum def_surf {
		solid (1),
		hard (2),
		loose (3),
		dirt (4),
		ground (5),
		lava (6),
		water (9),
		oreseam (8),
		cryseam (10),
		recseam (11)

etc...

That way you can just assign textures to each type and you can do any sort of lookup using these like: tex[def_surf.hard] would return the hard rock texture id for the loaded biome.

  • Like 1
Link to comment
Share on other sites

@Cyrem You specified an enum there. Is that enum described in the config files? or is it hardcoded?

 

On a side note:

The FLH files containing the animations for the captain lifting the score can now be loaded. It is, however in a different project:

 

I still need to write a parser for the JASC file (.jbf) and the FLIC file (.flc)

even though it has the same specifications as the .flh files, I need to include support for the sub-chunk types in the flc file, since i currently only support the sub-chunks in the flh files.

 

I will add all projects regarding LRR on github.

That would be

  1. inputstreams for content from wad-files
  2. FLH/FLC file loader
  3. a basic NERP to lua compiler.
  4. JASC file parser (soon)

I´ve also worked on some lighting, and adding the required features to the shader.

I will start to work on the UI components. Also getting some structure into the run function. Then there should be a somewhat working prototype soon, at least for the menus and such.

The main game however will still take some time, as I need to create some compatibility functions for the converted NERP scripts, so it will be able to run completely in Lua.

The rock raiders, slugs, spiders, monsters all still need their standard scipt, so they behave like their supposed to.

 

On a side note:

Does anyone know anything about the pathfinding of the rock raiders?

Link to comment
Share on other sites

9 hours ago, miningmanna said:

On a side note:

Does anyone know anything about the pathfinding of the rock raiders?

 

As described by one of the original programmers:

https://www.rockraidersunited.com/topic/2132-wow-people-i-am-both-stunned-and-impressed/

 

On 12/18/2010 at 2:03 PM, rrcoder said:

I remember the routefinding worked such that it would calculate the blocks along which the unit needed to travel, then it would pick a random point within that block (near the centre), and create a bezier curve that passed through each of those points. If there was a 'tight turn' required by a walking unit (i.e. the RockRaiders), then it would stop and play its 'turn' animation (which is why you would often see a unit stop and turn periodically while walking around). After that we put in 'avoidance' code, to prevent the units from trying to walk through one another (although this we had to balance carefully, as when you have many units, you sometimes must allow them to intersect otherwise they would get *far* to confused).

  • Like 1
Link to comment
Share on other sites

16 hours ago, jamesster said:

 

This is helping with the random movements, but the exact pathfinding (which blocks it needs to travel along), is still missing.

Rock raiders tend to walk on walls. Its as if the lower half of the wall is interpreted as a floor

Link to comment
Share on other sites

  • 3 weeks later...
Erisdar_Skolir

This looks fantastic! I came back after a few months and was delighted to see someone started a remake in java. (also hello, I've been on RRU for awhile, but this is my first post)

 

Initial excitement aside, I want to ask how you are planning to implement the game itself? All of the code would have to be written from scratch since, as I gather, there is no access to the original source code even as a reference. This allows for a lot of possible improvements and opportunities even the original authors might not have had at the time, but also means all of the code has to be reverse engineered. Though I might be wrong about this, I'm not entirely certain how far people have managed to reverse engineer the game already.

 

And while the code on github so far has several parsers and renderers, which are certainly needed and necessary (I shudder to think about trying to figure out decades old file formats), there does not seem to be any hint at what the game systems themselves might look like. I would be happy to discuss ideas and offer what (probably limited) insight I can, or perhaps even write some code myself.

  • Like 2
Link to comment
Share on other sites

4 hours ago, Erisdar_Skolir said:

This looks fantastic! I came back after a few months and was delighted to see someone started a remake in java. (also hello, I've been on RRU for awhile, but this is my first post)

 

Initial excitement aside, I want to ask how you are planning to implement the game itself? All of the code would have to be written from scratch since, as I gather, there is no access to the original source code even as a reference. This allows for a lot of possible improvements and opportunities even the original authors might not have had at the time, but also means all of the code has to be reverse engineered. Though I might be wrong about this, I'm not entirely certain how far people have managed to reverse engineer the game already.

 

And while the code on github so far has several parsers and renderers, which are certainly needed and necessary (I shudder to think about trying to figure out decades old file formats), there does not seem to be any hint at what the game systems themselves might look like. I would be happy to discuss ideas and offer what (probably limited) insight I can, or perhaps even write some code myself.

 

That is correct. Currently there is no structure for the game, just rendering. I planned on making a level class, that will contain the level script, and all of the used entities.

You are very welcome to help :). I am currently working on making the UI structure, which will have a "scene" class, where the ui elements will be inside of.

To do that, i need to read the config file. I made a loader for it already, now i need to read all the necessary information out of it. Which in itself isnt hard, but it is a lot, just like the NERP compatibility.

 

You are right about the reverse engineering. There are a lot of things that are already known, but the exact details are still quite hard to find.

 

Anyone is welcome to come with information regarding the game mechanics :) that would certainly help a lot.

 

Edit:

regarding the game implemantation:

I thought it would be smart to make lua scripts for all entities. That would allow for new entities (monsters, raiders, bats, etc.) to be added, without being limited to be hardcoded. Though i am unsure about the performance of this approach.

Link to comment
Share on other sites

Erisdar_Skolir

You might want to look into Entity Component Systems (ECS) as a way to structure everything. After taking a dive in the wiki, it appears that the LRR engine was structured similar to an ECS originally, though clearly it was made "to just work" rather than something that was made to be reused and extended. And re-usability and extendability is presumably what a remake is for, after all.

 

There are plenty of resources online that can explain what an ECS is and what its advantages are better than I can, but basically it would allow for content creation and addition to the game to be trivial. Possibly even as simple as creating a single script to add new monsters, vehicles, buildings, etc. (excluding additional assets like textures and models), like you said yourself, and anything extending the actual engine could be done with a few java files through the help of an API. There are a lot of other advantages as well such as easier to maintain code, less resource hogging by objects, possible performance improvements, etc.

 

It also reduces spaghetti code. Of which any coder is undoubtedly guilty of at least once.

 

Either way this is just food for thought (that delicious spaghetti code), and I am by no means an expert on ECS design.

 

Also lua is a great idea for a scripting language. I took a look at LuaJ and the performance seems comparable to java as long as it is compiled into bytecode instead of interpreted. But then again lua probably runs faster on modern hardware than LRR did originally, so... this is a moot point. LRR isn't exactly a resource intensive game.

  • Like 2
Link to comment
Share on other sites

Erisdar_Skolir

I realize my last post was a little ambiguous, so example time.

https://github.com/ErisdarSkolir/LRR-remake/tree/entity_component_system_prototype

 

Credit to

https://github.com/adamgit/Entity-System-RDBMS-Beta--Java-

for the entity manager code.

 

I partial refactored an ECS system into a fork of your project as it stands on github. I have lws animations working, but I didn't mess around with too much else.

A lot more could be optimize/organized, especially in the loader classes, but this was just a small example of how an ECS system could better organize this project.

Also recognize it isn't a complete ECS example because logic still exists within the components, but that is just due to me not wanting to completely refactor data classes such as the LwsAnimation file. A real implementation would change those files to just be structs (or as close to structs as you can get in java) and move all the logic into factory/loader classes and systems.

 

If you think it is worth looking into I can work on making a prototype engine to demonstrate scripting, better entity creation, multi-threading, etc. that an ECS would allow. Though I am definitely not touching those file formats. They scare me.

  • Like 2
Link to comment
Share on other sites

  • Cyrem pinned this topic
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.