Lately, I've been considering looking into decoding some of the file formats used by BFBuilder. There are all sorts of interesting possibilities that could come about by doing so.

One of the most interesting is the prospect of generating maps randomly. A random map script would control things like distance between control points, height and shape of terrain that connects control points, number and type of vehicles at each point, etc.

The whole thing would work something like:
- Requires BFBuilder on all computers.
- Each random map has a set map name, and is controlled by the aforementioned map script that defines what is static and what is random. (Using a somewhat similar approach to random maps in Age of Empires -- though greatly simplified and customized for Battlefront)
- Each random map would have an accompanying set of assets in a DataMod folder, containing all the common portions needed. That includes buildings and structures, gleamed from the assets from various shipped worlds.
- For multiplayer support: People would download a program that acts as a random seed generator. The server end would generate the random seed, clients would receive it. It would then proceed to modify each person's DataMod files (according to the script and the random seed), and invoke the munge process. Once all munging is complete, the random map is ready to be played in multiplayer. The server could run on a timed schedule, where it generates a new random seed periodically. People would run the client program before running the game, to ensure they have the most recently generated maps.

what about the AI, u can't randomly place hubs and paths... can you?

Definitly sounds interesting. I was trying to make my own simple terrain/object viewers based on the TER files, but I wasn't able to decode the structure. But I would love to help out if you make any progress.

Kipp, sure you can. Many different graph theory type algorythms could help with that.

this is where I get lost lol

This is AWESOME theories Riley

if you could do this, you'll be The Multiplayer Generator who made all that happen lol

I'd wish I could help, but I'm lost in all that

- Qdin

Nimlot, I took a cursory look at the *.ter files... Yeah, I can't make sense of it as of yet either. I tried a few basic tests, and very little is jumping out at me.

It's definitely not the same chunk-style format as in the *.lvl files. But it does have a header, and a number of distinct sections. I would presume it has terrain height, color, texture, and water settings.
What's especially odd is... I changed a test map to 16 by 16, and the file size didn't decrease. It stays at about 27MB (even though some of the shipped maps are various sizes). I then tried changing the entire map to a set height value, and couldn't make immediate sense of the values that changed in the file.

Looks like the *.ter files could take some time to decode.

I think I've figured out a large portion of how *.ter files are stored. I'll be adding the structure to my site sometime soon.

When you create terrains using ZeroEditor, it always creates a *.ter file that leaves enough room for a 1024x1024 map. Even if you only actually use 256x256 or a smaller size. When you do use the smaller size, massive amounts of the file go completely unused.
Notice that the *.ter files are always about 27MB in size, when created from ZeroEditor. The shipped worlds files are smaller. This is because they apparently reduced the data stored to the appropriate size. They must have done this outside of ZeroEditor, because as far as I can tell, it does not have that capability.

When you first open ZeroEditor, the camera is facing towards the "last" row. Meaning that if you back up the camera until you see the edge of the map, this edge of the map is the "first" row. By "first" row, I mean the first row's worth of data that appears in the *.ter files. The "first" column is to camera left.
When you use a map size smaller than 1024x1024 (including the default 256x256), the data that actually applies to that map is centered within the larger data block. If that doesn't immediately make sense, hopefully it will with an example...
Terrain Height begins at 0x00000B04 and is exactly 2MB in size. Each row of the map is stored as 1024 signed integers (2 bytes each). But because you typically work with 256x256 sized maps, the first row that's visible in the editor is actually at 0x000C0B04; 384 rows in. And the first visible column of that first visible row is actually at 0x000C0E04; 384 columns in.

You can calculate the first visible row's (and column's) location, with the following (N = map size): (1024 / 2) - (N / 2).

For quick reference:
Terrain Height (2MB): Starts at 0x00000B04. Each grid is a signed 2-byte integer. A height value of 0.01 in the editor = 1 in the data file. (There's actually a way to change the scale in the header of the file).
Terrain Color (4MB): Starts at 0x00200B04. Each grid is a 4-byte ARGB value.
Terrain Texture (16MB): Starts at 0x00A00B04. Each grid is a group of 16 terrain alpha values. Each of these 16 terrain values corresponds to the 16 available texture layers.
Between the color and texture blocks, there's another 4MB block that looks like more color data. I'm not sure what this is.

I'm not sure exactly where the water and foliage data starts, but I know they both come after the texture data.
I'm not clear on how water data is stored.
Foliage data is stored in a bitwise manner, where each foliage layer for a 2x2 map grid gets one bit. This makes it 256Kb in size.

I'm fairly certain there are blocks of data in here that are actually not used by the game. They probably originally planned to include additional features, and either didn't have time to implement them, or found they weren't working as intended.

Awesome, I'll start working on something simple now. I do understand the 1024x1024 size, as that is the same as the shipped world files. I have created a world viewer for these shipped world files, and they do have much more data then the area you play in.

All that said, I should have some screenshots in a couple hours.

if it generates terrain randomly, how bout objects? Are they generated randomly as well?

Made some progress, decoding all the data mentioned thusfar, but I havn't touched the size issue yet (all the empty space) and that is making it hard to view in real time (frame rate is like 4-6, its rendering a 1-2 million triangles). But I do believe it is working correctly, and I will start to play around with the random height effect (I'm thinking something like Photoshops "Clouds" effect). Heres a screeny of what I have decoded from a map I made in a few secs.

Oh, I forgot to add when I was looking at the shipped TER files they are all much smaller than the 27 megs, so it might be possible to cut out a lot of the empty space. Maybe you will find the size markings in the header somewhere.

Yep, I mentioned that about the shipped worlds *.ter files being smaller... Hoth, for example, has no unused data. What I mean by that is: there is no data in the *.ter file that is ignored during the Munge process.
Edit: I have some of the size info figured out in the header. I'm just out of time right now. I'll post again when I've got it ready on my web site.

Which map is that? Bespin Cloud City?


The best way I can explain this random map idea is through examples... If you're at all familiar with the differences between maps in Warcraft and Age of Empires, you likely have a good idea what I mean. Putting aside the obvious problems of comparing an RTS game to a Battlefield-style game: Warcraft maps are completely predetermined, while Age of Empires maps are generated randomly while maintaining similar features and a certain level of symmetry. (Star Wars Galactic Battlegrounds uses the Age of Empires II engine)

Battlefront uses the Warcraft method of predetermining the entire map, down to every last detail.

Consider the Bespin Platforms map for a moment. Each team is given 3 control points arranged in a somewhat triangular shape. Between each team is a single neutral control point. Turrets, fighters, health/ammo reload stations, and the orientation and position of the buildings and pathways are all pre-determined.
Now imagine if you could have hundreds or even thousands of variations on this map. Sometimes it might come up with four control points per team. Sometimes the control points where the fighters are might be located further out or at a different angle. Maybe there will be a second pathway leading to the neutral control point.

So the maps wouldn't be totally random. They would be controlled by a map script that specifies what is common; and for what can change, provides ranges and other hints for how to generate those areas of the map. For example, minimum/maximum control points per team; minimum/maximum neutral control points; minimum/maximum distance between control points; minimum/maximum angle that a team's control points are oriented from one another; minimum/maximum number of turrets or vehicles (as well as the type of vehicle) at each control point; minimum/maximum number of pathways between related control points. And many many other possibilities, perhaps some even related to modifying certain parameters in related ODF files (at the moment, I'm thinking of the "GeometryScale" parameter).

Updated my site to include as much I as know about the *.ter file format... I also updated the index page to be a bit more streamlined. All the relevant file format information is under the "Reference Information" section.

Link is in my sig, as always.

Just wanted to post a minor status update...

My time is pretty limited, but every once in a while I'll put in an hour or two on this. The first thing I'm doing is building a Terrain Management API in C/C++. It's basically just a collection of C++ objects that let you manage terrains (height, color, texture, foliage, water).

I tend to be very open when it comes to sharing information, and the same will be true for source code. So when I'm done, expect the source code to be released in full, under a free public licence.

Just an example of a main.cpp program, to show how easy it will be for programmers. This terrain was produced by this program:

Wow nice, looks great. I'd be happy to share the code I was working on if you want, was written in C#, but you should be able to understand it.

Ah yes, the glory of programming.

Question though, what happens if the random arrangement of spawn points on the map is too generous to one team, giving say the empire a complete advantage over the rebels. How would you determine what is fair to both teams for the generator?

Nimlot, I'm glad to hear you're doing it in C# and not VB. And at some point I would definitely like to grab a look at the code.

Astute, that part (the balancing and "artistry" of the map) will be largely up to the writer of the random map scripts. The programmatic part of all this will handle it to a certain degree through symmetry.

Also wanted to mention: I'll be working on a way of generating better-curved hills and valleys as well. So far, I've just implemented the equivalent of ZeroEdit's paint/raise box/circle.
By making the API open to all, I'm hopeful others will join in making additional classes that generate new types of hills. The only one I'll be building initially is a standard half-ellipsoid (that can be at any angle). Mainly because the formula for it is relatively easy to deal with. It would be neat if some math-wizards could help come up with formulae that let us make other shapes. I've been away from all this 3D geometry stuff too long.

Sounds good. I decided to rewrite all my code, and was able to get it working fairly quickly. This is a picture of a map created with just a "simple" random generator, basically just assigning values 0-10000 at each coordinate.



This was more of a test to just see if I could get the code working, and now that it is, I can start to add new generation algorithms. I will try to add Perlin noise tomorrow, which should result in some really cool looking random maps. It should also be very easy to create random maps based on heightmaps, so it should be possible for anyone to create maps that way and then import into Zeroedit.

Have you made any progress on textures or colors? I havn't tried testing any of this out yet, but it does scare me a little bit.

is it possible to make it so like u can make a grayscale picture of the map and u can use that for the terrain hight?

I didn't even know ZeroEditor had a console...

One thing I noticed while playing around with texture layers... ZeroEditor uses the "tile rotation" if you set it, but it doesn't get saved in the terrain file. When you load the map again, the rotation is set back to zero.

At any rate, I figured out a few more pieces of the *.ter file format -- where the "tile range" and "tile mapping" values get stored for texture layers. (See link in sig for update)

Edit: For some reason my signature isn't appearing?
Riley's Editing Reference

Edit2: Responding to the below post... Based on a good number of the posts, I'm not sure people are understanding what I mean by "random maps". The only way I can really describe the idea is: go play any Age of Empires game (or Star Wars: Galactic Battlegrounds) and load up the same "random map type" several times. Notice how the map is "similar but different" each time you load it. Age of Empires actually had a scripting language that people could use to create new random map types -- and that's what my eventual goal is here.