ORR-D: progress update and a request for input

[bartvbl]

Hey all!

It's been a good while since the last time I posted on here to show off progress on ORR-D.

Since that time, the project has undergone a complete rewrite from scratch, and it has now come to a point that there is finally something to see

It may not look like much, but what you see is the result of the OBJ file loader doing its thing, which is part of a resource loading system.

I'm also making this post because I would like to have some input. It has become time to implement the map loader, which means there will need to be established a map format of some sort.

So I'd like to ask what you'd like to see from the format; things like:

- Should it be contained in a zip file for easy distribution?

- Should it be the old rock raiders file format? Are there any downsides to the old format? (I'm not particularly known to it, unfortunately)

- Was there anything in particular that you wanted to do when creating a map, but couldn't?

- How do you imagine the process of creating a map?

Please share your thoughts!

If you'd like to keep track of our progress, we have our repository here:

https://github.com/bartvbl/ORRE-V2

[Addictgamer]

I'd prefer the map be contained in a zip.

I'm not aware of any downsides to the old format other than I wouldn't use it for my own programs. Actually, there is the annoying thing where you have to specify in the cfg every map file. I wish it'd stop being lazy and look for it itself. The files would need to follow a naming convention, but that's a given, and should, anyway.

Yes, no enforcement of the solid borders around the edge of the map. It makes it impossible to show rivers due to that piece of solid rock at the map's edge.

I'd imagine I set a size for the map, it'd floodfill it with material of my choice, and then I'd "carve out" the caverns (in the case of solid rock floodfill), or "raise up" some island (in the case of a liquid floodfill". After the terrain is done, I'd set up base. Then, monster hotspots. Afterwards, erosion. Finally, touch everything up and make sure I've done everything that's needed, including the objective of the level (such as, say, finding some lost Rock Raiders).

[Cirevam]

- Should it be contained in a zip file for easy distribution?

- Should it be the old rock raiders file format? Are there any downsides to the old format? (I'm not particularly known to it, unfortunately)

- Was there anything in particular that you wanted to do when creating a map, but couldn't?

- How do you imagine the process of creating a map?

1) Yes please.

2) Try what addict said and have the game look for map files on its own. If you must, the naming convention could be something like name.surf.map, name.cror.map, etc. so it would be easy to keep the files organized and to name them whatever you wanted.

3) I always wanted some way to do waterfalls or a scalable mountain that doesn't have to be so enormous or square because of the 2x2 rule that walls have. Maybe just a heightmap system that doesn't suck. Also, water with real depth instead of what we have now would make everything look so much better and could open up possibilities for new content, like dredgers or underwater miners.

4) Similar to what we have now is fine. I'll get used to whatever system is made final.

[bartvbl]

1) Yes please.

2) Try what addict said and have the game look for map files on its own. If you must, the naming convention could be something like name.surf.map, name.cror.map, etc. so it would be easy to keep the files organized and to name them whatever you wanted.

3) I always wanted some way to do waterfalls or a scalable mountain that doesn't have to be so enormous or square because of the 2x2 rule that walls have. Maybe just a heightmap system that doesn't suck. Also, water with real depth instead of what we have now would make everything look so much better and could open up possibilities for new content, like dredgers or underwater miners.

4) Similar to what we have now is fine. I'll get used to whatever system is made final.

2) I think that it will be something like minecraft's system then; you drop the map in the maps folder, and you start it from the main menu.

3) How would a grayscale image do for a heightmap? Real water is an interesting idea. I'd have to think a bit on how to determine the water level to use, though, but I bet it will at least will be a nice visual touch.

[le717]

Don't really have something to say about ORR-D, but I have a bit of feedback for you.

One, Ah, you're using LU textures I see, which means you UV'ed your minifg to match the LU textures, unless you remade the texture. My brother has made a few minifigs of his own, and while he says the LU UV is OK, a different one would be better for a minifig.

Two, if you are going use ZIPs in anything that will read them directly, you will need to define how the files are to be contained in the ZIP. I would think the files would be in the root of the ZIP, but a lot of people, when creating ZIPs, compress a folder into a ZIP, so when extracted, you have a structure like "Map1/Map1/MapFiles". It should look like "Map1/MapFiles". Unless you coded the game to keep searching through multiple folder layers, the map would not load and people would probably complain to you saying there was a bug. Your map documentation would need to clearly state how the ZIP is to be laid out.

Sorry if this sounds a bit nosy or "I'm a know-it-all", but I'm just going over some of the basics that some people would overlook until it was too late. ;)

[bartvbl]

One, Ah, you're using LU textures I see,

Two, if you are going use ZIPs in anything that will read them directly, you will need to define how the files are to be contained in the ZIP.

One: I used nifSkope at some point to export the lego minifig model as an OBJ file. Luckily, it also exported the texture coordinates with it. Then I only had to edit one of the textures, create a material definition file, and the minifig was done

Two: Given some other things I have in mind, I think I'll do a series of tutorials anyway when the time is ripe, so people will know how to do stuff (I hope..) :)

[TheDoctor]

Oh dear. Finalizing formats is a pain. I would suggest a new map format, but keep support for the LRR maps. The new format could have all the different maps in one file, with a header for each one. Also cfg information. Maybe even a converter for LRR > ORR-D maps. The new format would be in zip format, of course. We could make maps in the tools we have, then export and convert them.

[Sharkly]

Nice work! I've been meaning to try the D Language myself. This is the most progress I've seen on any ORR project in a while. Keep it up.

[Addictgamer]

ORR-D is actually written in Java, not D.

The D in ORR-D stands for Delta.

Aye, it is. Might be for another half a year or so. Sooner if miracles happen.

[Sharkly]

ORR-D is actually written in Java, not D.

The D in ORR-D stands for Delta.

I feel stupid. Thanks for clearing that up.

[Addictgamer]

Stupid? Don't. ORR-C does not stand for ORR-Gamma (Greek Equivalent of the third letter of the alphabet). ORR-C stands for ORR-C++, the name of the language it is programmed in. Thus one might assume ORR-D is programmed in D, instead of the actual case where it is a play on words and proceeds to the fourth letter of the English and Greek alphabets, thus creating the cool naming phenomenom seen in "ORR-C" and "ORR-D".

Sorry, I overthink things.

[Antillies]

I feel stupid.

No worries, mate. The only reason you would know the meaning behind it is if you were present in the ORR chat or had been following us since the beginning. Originally, we were programming it in Python but since Mouse already had ORR-Py, we decided to change it to ORR-Delta to separate it from the existing Python fork. I can't remember precisely why we choose Delta (as Delta is the fourth letter, not the third, which was the placement of ORR-D in the line of forks: C, Py, D...) but I think we thought it was cool. More info here if you'd like to read up.