The 4ge, Object Variety, and You

I recently had an idea that could be useful for Forge, assuming that it is not overly cumbersome to implement. I vaguely recall some statements from Bungie in which they noted that they couldn’t add more Forge objects to Forge World; resources were too limited. I think I may have a solution to this problem.

What’s the problem?
Memory is described as the primary limiting factor on how many objects can be in a map’s palette, though performance costs also influence a palette’s size and contents. The amount of memory available for the map palette is in turn influenced by the complexity of the map itself – particularly with respect to textures, which is why Forge World is as bland as it is. This is why every Reach map has as many Forge objects as memory limits allow, despite many of their palettes being absolutely pitiful.

Memory limits are creativity limits. They limit what the developers can give us to work with, and that is a problem.

What’s the solution?
There may yet be a way to give Forgers more to work with than even Forge World did. What if we could choose a specific set of objects to work with?

Let’s say, for example, that we’re given a memory-efficient canvas map like Forge World. Enough memory is left free for the game to load, say, 100MB worth of Forge object types. 343i could simply design roughly 100MB worth of Forge Objects specific to this canvas map. The result would be that we have to use the objects we are given, even when that set of objects isn’t particularly useful for the specific map variant we have designed and are trying to build.

What if 343i did something else, though? What if they designed more objects than would fit in that 100MB limit, but made it so that objects are no longer tied directly to the canvas maps? What if they give us a huge library of objects, and for each map variant we design, we could choose which ones we use? What if we could choose our own palette for each map we build?

What I am proposing is the application of a tag system feature (that has been used in the past) to the Forge system. Technical details:

In Halo, all objects and all of their data are stored as “tags” – basically, scraps of data. Tags are stored in map files. To give a few examples, every single texture in Forge World is its own tag. The lightmap used to shade objects based on their locations is also a tag. Each object is a tag, which in turn contains links to other tags that define textures, models, hitboxes, etc.

Most tags are tied to specific maps. However, it is possible for one map file to “borrow” tags from another map file. If, for example, you have Halo PC installed, you can browse to the directory where the game stores its files. Open the “maps” folder, and you’ll see one file for every map – bloodgulch.map, ratrace.map… But there are two files in there that clearly aren’t maps, and that are way larger than every other map: sounds.map and bitmaps.map.

These are not maps at all. They’re just containers for tags: for every sound in the game, and for every reused texture in the game. So when Halo 1 loads a map, that map can direct the game to pull tags from these containers – tags being shared across map files. So devs don’t need to copy and paste (all of) the Assault Rifle data for every single map; they can define the sounds and textures once, and use that data in each map.

What I am proposing is simple: take the functionality that allows one MAP file to link to resources in another MAP file, and apply it to Forge objects. Put Forge objects in a set of isolated MAP files, and let any other map pull from those files.

So when a player Forges on any map, they’d have two options:

Basic Mode
This is Forge as we know it today: we load up a map, press “X”, and we have a list of some predefined, map-specific objects. Those objects are loaded when the map is loaded, and appear instantly when we select them.

Advanced Mode
When you load up a map in Advanced Forge, only the map will be loaded – no Forge objects (besides the standard ones, like weapons).

You will have access to a menu: the Resource Menu. The Resource Menu is little more than a list of every single Forge object in the game, each item being adorned with a checkbox and identified by its name. When you close the Resource Menu, all checked items will be loaded into RAM, after which point you may spawn and manipulate them as you please. Items that you uncheck will be removed from RAM.

When you save your map, it will be flagged with a piece of data that indicates that you’ve specifically chosen what objects are available. The next time it is loaded, the game will simply scan through the objects you’ve placed and selectively load those objects.

For extra utility, you can save this “object set” (custom palette). When in the Forge lobby, you can enable Advanced Forge, and then edit the Forge settings and specify any of your saved object sets to be loaded by default when you start your session. There could also be a few predefined object sets (including one for each map). So speaking in Reach terms, we could have a number of object sets: “FORGE WORLD”, “SWORD BASE”, “RAMPS ONLY”, “METAL ONLY”, “OBJECTS THAT LOOK LIKE CATS”, et cetera.

And the point of all this is…?

The point of all this is that memory will be less of an issue, and Forgers will have more to work with.

Let’s go back to the example of the map that leaves enough memory free for 100MB worth of Forge Objects. In Halo 3 and Reach, you would simply be left with what 343i gives you: whatever they choose to design with those 100MB, that’s what you use.

But with this system, they could design a ton more objects, and you could specifically pick the objects you need for your map variant. They could design a gigabyte’s worth of items, and you could cherry-pick only the ones you want. Do you want 100MB worth of ramps? You got it. Or perhaps you’d prefer 100MB worth of different explosives? Go for it.

Here are the main benefits:

  • We can cherry-pick the objects that we specifically need, on a per-map-variant basis, allowing us to utilize the memory for objects however we see fit
  • If we choose not to utilize all available memory, then we’d actually reduce loading times by preventing the loading of superfluous, unused object data
  • All maps’ palettes could be part of this shared repository of objects. Speaking in Reach terms: if you want Solitary decor in Sword Base, you can have Solitary decor in Sword Base.
  • Depending on how the object-dedicated MAP files are named, the palette could be extended post-release, allowing new objects to work in old maps. If each file is named like FO01, FO02, FO03, for example, then 343i could simply rig the engine to check for that pattern, and release DLC Forge objects as part of files whose names match that pattern.

continued in next post

continued from previous post

No idea is without limitations. What’s the big issue with this one?

Indeed. And this idea’s biggest limitation is memory. There is no way around the memory limitation; this won’t allow you to have more object types on a given map than would be possible without a system like this. All this idea really allows you to do is choose, on a per-map-variant basis, how that RAM is utilized, so that you can use the available memory in a way that’s best for the map variant.

So when selecting the objects to load for your map, you would be given a plain display of how much RAM the object and its relevant assets consume, along with an estimate of how “expensive” it is to actually have in one’s map. (Remember: certain objects are more expensive to process regardless of what the actual filesize of their assets is.) So you’d know how much RAM you have to work with, and how much of that RAM any given object will consume.

We would also need to account for DLC objects. If we allow the objects from DLC maps to be retroactively applied to disc maps and maps from older map packs, then we run the risk of compatibility problems. Speaking in Reach terms, you may not be able to play a match on Tempest because some guy jammed a Highlands-specific crate into the map variant. One solution to this dilemma would be to only allow a DLC-introduced object to be used on the maps from that DLC pack. An alternative solution would be to release free “viewer packs” similar to that used for Saints Row 3, which would contain all of the DLC-introduced objects. Such a viewer pack would allow a player to play on any map variant that uses the new DLC objects, provided that the player owns the actual canvas map.

One final problem comes from the fact that the game engine may need to sift through some fairly-large MAP files to find just a few objects’ data. A solution to this could be to spread the Forge objects across multiple files, perhaps categorized based on type or source. Speaking in Reach terms, ramps could be in objects001.map, walls could be in objects002.map, and so on, and each map variant could note the specific file from which it “pulls” an object. So if I’m using Ramp #49, the reference could look something like “objects001.map:49”, meaning that the game engine wouldn’t have to dig through every single Forge object to find that one ramp.

(Fun fact: That solution, spreading tags across multiple places? That’s exactly the same thing an iPod does with stored music. And on a good day, those things can load one song out of a library of hundreds faster than a person can blink.)

Conclusion
Allowing Forge objects to stand on their own, rather than tying them directly to specific maps, will allow us to mix and match pieces as we please and create custom palettes that best suit whatever we’re currently trying to Forge. Clearly indicate memory limits and the “cost” of each object type – in concrete units like megabytes, instead of an arbitrary and meaningless budget system – and this won’t come back to bite us in the butt. Create a “basic” Forge mode where this functionality is hidden and a default palette is used, and you’ll be able to add a huge amount of power to Forge without making it less friendly to newbies.

We won’t be limited to just customizing maps; we’ll be able to customize the customizations as well.

Okay I see where you are going with this, but I think people are after a bit more than just a little more powerful forge. People are looking for a full on map editor with terrain, and I know people are going to complain to me about referencing Far Cry’s map editor again, but why cant 343 at least match it? forge was a nice start, but its clear that a full map editor with terrain editing is the way forward.

I still say a proper map editor is in order.

Or instead, just have an infinite black space and a grid in which you build on. None of this Forge world nonsense. This way we can choose what back drop we want. It will also free up all the space the Forge World map took away and free that up for building. It’ll probably give us enough space to improve forge to the extent that it becomes almost similar to Far Cry 2’s editor (Or should I say creator).

> Okay I see where you are going with this, but I think people are after a bit more than just a little more powerful forge. People are looking for a full on map editor with terrain, and I know people are going to complain to me about referencing Far Cry’s map editor again, but why cant 343 at least match it? forge was a nice start, but its clear that a full map editor with terrain editing is the way forward.

I understand the desire for a more powerful editor, and I’d love to see some more powerful editing features. At the same time, such things would have to be done in a way that doesn’t compromise Forge’s biggest, and only, advantage: ease-of-use. Anyone can pick up Forge and build something, though it may not be exactly what they had imagined.

If 343i can add terrain editing while keeping Forge easy to use, then they absolutely should. People could express their creativity even more, and they’d still be able to do it easily. If, however, 343i can’t implement terrain modification without dragging down Forge’s usability, then they would gain very little from adding it: they’d be trading Forge’s biggest and best advantage for a feature that most contemporary map editors already have.

Let’s say, though, that 343i can and do add an easy-to-use terrain editor to Forge. That would be wonderfully useful, but we will still need the ability to place non-terrain-based structure objects in maps. So someone will still need to ration out the remaining memory and decide what Forge objects are worth spending that memory on. We can have 343i make that decision and do that rationing in a manner that is set in stone for all map variants, or – using the system I have proposed – we can be allowed to directly make that decision on a per-variant basis.

I think I understand this… Basically this prevents the situation when you can’t add more wall pieces even though you have like 80 ramps? And it allows you to take objects that are normally exclusive to Sword Base and put them on Forge World, and vice versa?

Sweet. And please people, try to stay on topic. There are around 9001 threads already asking “giv us far cri 2 map editur plz”. We don’t need to derail another thread that has a genuinely good idea.

> I think I understand this… Basically this prevents the situation when you can’t add more wall pieces even though you have like 80 ramps? And it allows you to take objects that are normally exclusive to Sword Base and put them on Forge World, and vice versa?

My idea doesn’t solve the first problem, though there is something else that can be done about that issue. But yes, my idea would allow you to take objects from one map and use them on another.

To elaborate: it costs a certain amount of memory just to have a type of object – its model, graphics, hitbox, et cetera – loaded. That cost depends on the object and never changes. This is the kind of memory cost that my idea would allow us to control for our maps.

However, you need more memory on top of that when copies of the object are actually on the map, and this memory usage is harder to predict. For example, a Scorpion driving around the map takes more resources than a Warthog driving, because it has more contact points with the ground. A Scorpion that’s staying still, however, might take less memory at that specific moment than the driving Warthog. This second, less predictable, memory cost is why some of the per-category limits exist, though many of the per-category limits are just completely arbitrary and useless.

So we can’t get rid of per-category limits even with this idea, because a piece could be really simple and cheap to load, but once it’s on the map, that particular piece could be very expensive to process. That second memory cost messes us up a bit.

However, we can still work around the more annoying category limits by using less-specific categories. For example, walls, building blocks, and ramps are all very simple, cheap pieces, and seem to use about the same amount of memory when they’re actually on the map. So instead of having 50 walls, 100 building blocks, and 100 ramps, we could safely combine all of those into one single category: 250 basic pieces. And that way, if you need 200 building blocks and 0 ramps, you can have exactly that. Alternatively, the per-category system could be removed and objects could be priced solely using the budget system, with prices reflecting how expensive they are to have on the map.

> > Okay I see where you are going with this, but I think people are after a bit more than just a little more powerful forge. People are looking for a full on map editor with terrain, and I know people are going to complain to me about referencing Far Cry’s map editor again, but why cant 343 at least match it? forge was a nice start, but its clear that a full map editor with terrain editing is the way forward.
>
> I understand the desire for a more powerful editor, and I’d love to see some more powerful editing features. At the same time, such things would have to be done in a way that doesn’t compromise Forge’s biggest, and only, advantage: ease-of-use. Anyone can pick up Forge and build something, though it may not be exactly what they had imagined.
>
> If 343i can add terrain editing while keeping Forge easy to use, then they absolutely should. People could express their creativity even more, and they’d still be able to do it easily. If, however, 343i can’t implement terrain modification without dragging down Forge’s usability, then they would gain very little from adding it: they’d be trading Forge’s biggest and best advantage for a feature that most contemporary map editors already have.
>
> Let’s say, though, that 343i can and do add an easy-to-use terrain editor to Forge. That would be wonderfully useful, but we will still need the ability to place non-terrain-based structure objects in maps. So someone will still need to ration out the remaining memory and decide what Forge objects are worth spending that memory on. We can have 343i make that decision and do that rationing in a manner that is set in stone for all map variants, or – using the system I have proposed – we can be allowed to directly make that decision on a per-variant basis.

yeah, I know, I had to think about this too, since forge allows multiple people a full blown map editor could be a bit difficult, which is why I thought maybe they would split the terrain editing and forging into two seperate parts that link up, with multiple people in the lobby, and only be available together in a single player forge session. I know it can be done, I’m not entirely sure of how the programming works, but honestly, I wouldn’t really mind if they reduced the player count in forge to a maximum of 4 for a map editor, because really? how many people who make maps, have more than 4 people putting in useful input at once? most of the time the rest of the lobby just run around killing each other and making problems. The way Far cry did it was it had a memory unit meter, and a frame rate meter, which basically said you can do this much in total, but you can only do this much in this area for the game to run properly. And it worked marvelously, I would sit down to make a map, and tell myself it’d be about two hours. 8 hours later I would finish a masterpiece (in my opinion) and I’d be proud to upload it to the community. This is what the new forge should be like.

> I think I understand this… Basically this prevents the situation when you can’t add more wall pieces even though you have like 80 ramps? And it allows you to take objects that are normally exclusive to Sword Base and put them on Forge World, and vice versa?
>
> Sweet. And please people, try to stay on topic. There are around 9001 threads already asking “giv us far cri 2 map editur plz”. We don’t need to derail another thread that has a genuinely good idea.

“Sweet. And please people, try to stay on topic. There are around 9001 threads already asking “giv us far cri 2 map editur plz”. We don’t need to derail another thread that has a genuinely good idea.”

Don’t get me wrong, I’m only using it as a reference for people to picture what I have in mind, trust me, if you had used the far cry map editor, you’d want it too. I don’t want that exact editor, I wan’t a halo one with those advanced options included. Forge is getting better all the time, and the next step forward in my opinion is terrain editing allowing us to sculpt the maps we want to create, so we are not limited to the options we have now (simple object manipulation), allowing us to make beautiful, immersive maps that people want to play on again and again.

> yeah, I know, I had to think about this too, since forge allows multiple people a full blown map editor could be a bit difficult, which is why I thought maybe they would split the terrain editing and forging into two seperate parts that link up, with multiple people in the lobby, and only be available together in a single player forge session.

This makes sense. Others have often suggested that terrain modification and object placement be entirely-separate modes, which could also work if there’s no way to combine them while maintaining usability.

> I wouldn’t really mind if they reduced the player count in forge to a maximum of 4 for a map editor, because really? how many people who make maps, have more than 4 people putting in useful input at once? most of the time the rest of the lobby just run around killing each other and making problems.

I agree with you here. I certainly wouldn’t be surprised if we did see a lower player limit in Forge, even if they don’t add terrain editing, simply because the underlying architecture and the netcode will most likely be improved, which means more data being sent for Forge objects and less room for player data.

> The way Far cry did it was it had a memory unit meter, and a frame rate meter, which basically said you can do this much in total, but you can only do this much in this area for the game to run properly. And it worked marvelously, I would sit down to make a map, and tell myself it’d be about two hours. 8 hours later I would finish a masterpiece (in my opinion) and I’d be proud to upload it to the community. This is what the new forge should be like.

I’ve heard great things about the frame rate meter, and I personally love the idea, but up until now I’d never even heard of the memory unit meter.

It’s my understanding that the budget was intended to fulfill a similar function, but it failed miserably because the units were, in practice, entirely arbitrary, and not related to the object’s properties. (A Brace Large is as expensive as a Small Antenna? A Coliseum Wall is as expensive as a Long Tunnel? Yeah, sure.) A more direct measure would be nice. Even if 343i can’t definitively say, “This object, if placed here, will use X CPU cycles,” or anything like that, it’d still be nice just to have budget values more directly tied to an item’s actual memory usage and complexity rather than to its category.