Neat stuff from Halo Infinite’s first Forge video
343 Industries released their first video of Halo Infinite’s Forge mode. In their terms: It’s a mode that allows you to create maps, modes, and share them with friends, and it would ship in the free to play version of Halo Infinite. It being in the free to play version is super exciting to me, as that would make it so much more accessible for everyone to try and build things! Whether it can be used to create multiplayer levels only, or also singleplayer, I am unsure of. In the video they use a controller instead of a mouse and keyboard, so all 3D editing is supposed to work with a single controller. I think they’re showing some neat stuff, and that it deserves some attention!
Magnets (Snapping)
Snapping is often overlooked as an important feature, but it’s crucial for a good level design editor workflow. A tiny imperceptible gap between two objects can cause issues such as players falling into the void, players getting completely stuck, weird camera bumps, AI acting strangely, as well as light bleeding and much more.
For example, when building any game with AI, you will bump into issues sooner or later. You will have to debug why an AI is acting strangely and probably will start digging through their scripting. You are going to be very disappointed and frustrated when, hours, days, or weeks later, you find out it’s all because two objects were just 0.1 centimeters too far apart. (Or inches, feet, ‘units’, etc.). The same goes for player physics being strange, players getting stuck, etc. By having a good snapping system, you can prevent thousands of those tiny Jira tickets!
Anyway, what they show in the video, around 3:10, are these cubes in specific positions that they call ‘Magnets’:
I am guessing these magnets are in specific positions for each object, and hand-authored for each specific asset by 343i. This is probably slightly limiting, but if you were to snap per vertex, edge, or face, you’d probably have so many different snapping positions to choose from that it becomes unwieldy with controller input, so the limitation here makes sense.
And so, the object snaps, magnet to magnet:
That’s neat! I wonder what other magnet locations will exist on other assets and if many users will build similar things because of the ease-of-use of those magnet locations. I’m also curious if the users can place magnet locations themselves. Allowing the user to place such magnet locations, so they can easily decide where to snap things, seems very interesting to me for all kinds of 3D DCCs. Though upkeep of proper magnets is of course an issue, not having to use a specific grid size, or even having to worry about a grid size, makes the workflow look very smooth in this demo.
Undo & redo
They call this out as a big thing that wasn’t in previous Forge iterations, and it makes sense for folks to be happy about it as it is, again, critical for good level design. Of course folks are able to create anything they want within the limitations of tools, it’s not like undo & redo can be argued to literally stop someone from creating a good level. That is, from my experience, usually why undo & redo do not get enough attention in level editors: Because you cannot literally argue it has a P1 priority, as it’s not technically a blocker for workflow!
It’s so important for it to exist if you want to get the user into a good flow state though. If all your possible user actions can be severely punished by having to manually undo what you did, it really puts a damper on the creative flow. Allowing users to just ‘try things out’ without huge penalties is necessary when wanting to easily facilitate innovative designs. Without undo & redo, folks often become much more conservative with their changes, or have to spend that much more time to make their unique and cool thing.
So here is the UI of undo & redo in the video, around 4:10 in the top right, with the top and bottom D-pad buttons being used:
The one issue I see here is that there isn’t an undo history list, like for example Photoshop has. That could show you what is being undone and in what order. Most level editors are lacking that kind of easy to view undo list. I would say most 3D DCC tools, or editors for any purpose are lacking such a visible undo list. It’s a problem especially if you also have tabs and other tools that each have a separate undo stack. The moment you perform an action you may also be completely undoing an undo stack, and starting fresh in a new ‘branch’ of that undo stack. I have never seen an undo stack actually branch though, so that means you will have lost some of your previous work. This means if you want to build something, undo it, then build something else, and then go back to your original build anyway, you will have to rebuild it again from scratch. Undo does not ‘branch’ to that other section. Now think of the multiple undo stacks over multiple tabs and tools, and it becomes a question about whether there is one big undo stack, or an undo stack for each kind of tab or tool. I know some of you reading this have, when drawing something on paper, automatically did the ‘Ctrl+Z’ finger movement by muscle memory, hoping it would erase a drawn line. Undo stack design isn’t easy, and it’s a big and important part of any workflow! I can talk for hours about this, but let’s move on!
Snap to ground
At 4:33 they show being able to instantly snap something to the ground. This has almost the exact same benefits as the magnet system shown above. You can be sure something exactly aligns, isn’t floating a millimeter off the floor, etc. Also, it speeds up the process of placing a lot of stuff!
Not necessarily everything though. For example, placing assets with flat edged bottoms on a flat surface is now infinitely faster! The classic problem most 3D editors run into though, is placing a tree on terrain. You snap it down, and its trunk will often be half in the ground, and half floating above it. They don’t show how this works in the video, but they do show some terrain being moved around, so I am curious how that will work with the terrain.
Lastly, there is no visual indication of where the asset will go when pressing the ‘Snap to Ground’ button. No line, and no shadow. This is another classic issue that many editors have, where you don’t really know where an asset is located in the air because you are looking at it in a 3D view. Without separate 2D views in the X, Y, and Z direction, you’ll never really know where an asset is until you start moving around the camera. (Not that Forge should have 2D views, though!)
For example: Where will this asset snap to ground to?
It will snap to here:
You don’t really have a way of finding out where it goes, until you snap it. Thankfully I am guessing you can quickly undo it though, if the asset snaps to a place you did not anticipate! Another great example of undo & redo being important.
As a small aside: This reminds me of a really neat workflow in the Skyrim Creation Kit, meant for items and smaller objects. In that editor, you can activate physics on an object in the editor. For example you float an axe above a table, and then activate physics on it. It falls down realistically onto the table. You stop the simulation of physics, and it stays there. That works like this:
Anyway, just something neat that I would love more 3D DCCs did. Back to the Forge video!
We got a Zoo!
They show an asset zoo, fantastic! Is it manually set up by the creator, or a zoo that can be easily imported and used by other users as well? That’s unknown, but I am guessing this was set up manually by the creator of the level.
Zoos are important, as one of the big issues with asset browsers in general is that you can never name things completely correctly. I’ve joked about this before in a GDC talk, where I showed assets and made the audience guess the names, because if you cannot guess the name, you cannot type the name, so you can’t find that asset in the ten thousand assets available! A zoo circumvents that problem. A zoo is a 3D area filled with assets that is usually organized by type (windows, tables, chairs, etc.), so you can fly through the zoo and then copy paste what you need from there into your level. No need to ever learn the names, or even go through an asset browser UI: Everything you need is right there, just take a look! So I am glad that in the video they show a zoo that does fulfills that purpose, even if it may be manually set up instead of auto-generated.
To talk a bit more about names: Perfect names for assets are unfeasible, everywhere. You can add as many descriptors as you like to a name, and it will never be enough for everyone to find the exact asset you need. For example, you may have a ‘metal door’ and someone will search for it by typing ‘iron door’, and they will never find it. That may seem silly, but descriptors like that are easily misremembered if their concepts are similar (iron vs steel, for example), but even more so if your team is diverse. Some folks will have English as their native language, and some won’t, so you cannot rely on every descriptor in an asset name being easily understood or remembered. You can make that search fuzzy over multiple descriptors or tags, which helps, but then you may still end up having to define how fuzzy a term can be, and what other terms it relates to. For example: Does iron also search for steel? What about aluminium, silver, or gold? Do you count those as ‘metals’, and so they should show up in a search for ‘iron’ assets? You will have to make these difficult decisions. Or you could have the name include many descriptors, but you don’t want your assets to end up like the things you buy from web shops: Entirely written so that there are enough search terms in the name that they’ll show up first in a giant list of items to buy.
For example, I may have bought an item in the past called: “Pitch Black Solid Thermal Insulated Grommet Blackout Curtains/Drapes for Bedroom Window (2 Panels, 42 inches Wide by 63 inches Long, Black)”, which isn’t a name anymore. It’s just a description in the title, especially when it starts to include the actual measurements. I understand why sellers would write out that name though, as when it gives you a better chance to be found among ten thousand other items on sale, the market will force your hand to do it that way. Again I can talk for hours about this, but let’s move on!
Flattening (Scaling)
There’s this interesting thing around 5:20 which involves scaling down an asset until it is completely flat. They mention using an asset ‘as a decal’, which is a nice idea, especially with the texture detail some assets have in the Halo universe. The asset starts out like this:
And then is scaled on one axis until it looks like this:
Which I think is super neat if it weren’t for the deep worry of where all the triangles went. I hope it auto-optimizes the asset so it isn’t literally all the same triangles but now in a flatter shape. That would immediately remind me of this hit tweet by Dan Jordan.
The same goes for some cool terrain pieces they show off around 8:19 in the video. I wonder whether that is automatically optimized when scaled up and down. I think and hope so, but it’s not 100% clear to me from the video. It’s important though, as that brings us to the next topic.
Budgeting
Throughout the video we see a ‘Budget: Simulation Memory’ bar in the bottom left corner. Around 19:30 I hear that budget is defined by ‘objects’, and that the limit is about 7000. I am really curious to how that works underneath the hood! For example I would expect 7000 small and low-poly objects to be fine to render, but a whole load of expensive high-poly assets to more quickly fill up that budget bar. Where do triangles come in?
I am not implying here that showing a full on breakdown of the number of triangles, edges, faces, lights, materials, animations, etc, is necessary. For a full on pro workflow in which you need to tightly regulate limits for on a console game, yes, that’s necessary. For a User Generated Content (UGC) tool that is supposed to be easy to pick up and do things with though, a single ‘Budget’ bar like that is in my opinion a great way of doing it. I’m just curious about what affects the bar underneath the hood!
One thing though: Those metrics
There is one thing in the video that I would like to touch on as something I personally dislike: The metrics in the bottom section of the view:
Why are those metrics there, and how are they expected to be used in a workflow? You can see the position, rotation and scale of an object, so you know it has been moved or edited in some way, but in what workflow is that useful? For now, it seems like this adds a lot of visual noise to the UI. Can the values be copied and pasted? Can the user decide to copy only one of those values between assets? For example, could I copy only the scale value, and then apply that to a few other similar assets very quickly? That could be useful, but in that case you would only have to show the metrics when wanting to perform those actions.
This is something I personally dislike when I see it done in any 3D DCC tool: Stuff that’s covering the 3D view and which does not have a readily applicable reason to exist at all times. My opinion is: If something isn’t useful at that exact moment in time, then it shouldn’t be covering the 3D view. This goes for text, buttons, graphs, etc. Which is why I am wondering about the use of those metrics. Maybe there’s a really good reason for them to be there?
Material swaps
Oooooh this is neat! Having a lot of materials organized in a zoo is a great way to view those assets. It shows you what the material looks like under the lighting conditions you have, for example, which is incredibly important when your material can have any kind of normal, or other parallax effect to it.
But the really neat thing is this: Allowing folks to switch materials of a specific region of an asset! So you can have an asset look like this:
And then change only that specific region to something else like this:
Now that’s super neat! There’s no need to go through a material node graph, find out where the color or texture nodes are, wire things up in a different way to change the final result, etc. You just go through the properties, find the region, and then change that specific region’s color, intensity, roughness, etc. You also get to see the result directly on the asset in front of you, and not in some separate 3D view on a cube, sphere, or other test object. This again means the lighting is correct to your situation, so it becomes a real ‘what you see is what you get’ workflow. For a UGC tool, this is very neat, and it looks really easy to use.
Asset browsing
Forge is doing something interesting when it comes to asset browsing: It shows the asset not in some separate 3D window or view, but shows the asset directly in the scene as you are browsing. This is incredibly powerful. For example you look at the scene first, without an asset:
And then browser for an asset:
Or another asset:
It’s such an amazingly good workflow! The reason I believe this to be super powerful is two important things: Lighting and scale.
Often with an asset browser that has a separate 3D view in it, you can see the asset, but it will be lit in some default way, and you don’t see the scale of the asset. Especially if you automatically create thumbnails for each asset in a browser, you will see each asset fill about the same frame of that thumb. So by looking at all those thumbs, you cannot tell the size of the object. You will have to drag it into the main 3D view, look at it, and only then will you know whether it’s the right size. By instead directly showing the asset in the 3D view, when browsing, you circumvent this issue. I have not seen an asset browser with this kind of workflow before, and it’s really neat to see.
In this case, 343i says in the video that with every asset being scalable, you wouldn’t need differently sized assets, as you can set anything to the size you want. That may be true, but it does re-raise the above questions of triangle optimization, and budgeting. I’m sure they have this figured out somehow, I am just really curious about how it works!
Prefabs
Creating quickly re-usable groups of assets is important when creating level designs at scale. Forge seems to have a system where you can select multiple assets, and then make a prefab out of them to quickly place in other places, which they show around 12:57. So they select two assets:
And then create the prefab from that selection:
I am wondering whether updating the original prefab will also affect all the other placed prefabs, and whether prefabs can be part of other prefabs. For example, if nested prefabs are possible, and whether changing a nested prefab affects all the other prefabs.
The gains on user workflows from having prefabs are immense, and I remember the balloons coming down at Unite when Unity revealed nested prefabs. They can be difficult to implement, but they’re worthwhile for speeding up workflows, especially in the mid to late stages of development when you would want to make one change that affects 1000 instances rather than adjust each instance manually.
The prefabs in Forge seem to also be shareable to your friends, your other maps, and to the public! That is really good stuff. I am betting some creators’ content will be reused by a lot of folks. It again asks the question on whether a change by those creators would affect everyone else’s use of their prefab though, and whether that change could be ‘denied’ if it were to break your use of the prefab. Prefabs and nested prefabs can become a whirlwind of UI, workflows, and permissions very quickly, so it’s difficult to make them easy to use!
There’s more videos to come!
I highly recommend watching the video if you are at all into level editors, or user generated content, as I am. They describe a few more things in the video, such as seeing the status’ of objects (static, dynamic, etc.) when hovering over them, fitting all options onto a controller, and how in the future they will discuss the node graph editor! Lastly, there’s interesting anecdotes about each object in Halo 5 being a dynamic object so every frame every object was checked up on during runtime, and previous Forge iterations not having a noclip mode. Both of those surprised me a bunch!
I’m looking forward to the next 3 videos. How would a node graph editor work well on a controller? How do they make terrain? How do they handle scripting, bots, lighting, etc? So many neat things I am looking forward to hearing about it! You can find 343i’s blogpost with future video topics here: https://www.halowaypoint.com/news/halo-infinite-forge-fundamentals
Thank you for reading
If you’d like to see more of the stuff I write, you can visit my Twitter, subscribe for e-mail updates when a new blog post goes live, or subscribe vs RSS. Also, if you’re at the Game UX Summit in Seattle next week September 21st and 22nd, come say hi, I’ll be there!