Alright so below is a relatively brief write up on how I think forge could be improved in the future... starting with the recent talk on coloring.
Overview [TL;DR]
Below is a mini quick and rough pseudo design document for possible changes for forge (and a little bit to theater) that I have been designing since its inception. These features are made to increase the capabilities that community designers have at their disposal to more effectively create content for the Halo community. This is in no way comprehensive with all of my ideas, but it gets the core features out there. I've been a programmer since I was 14 (so over a decade now)... while I'm no expert in game programming, I do have a little experience. Most of these features are feasible as far as my knowledge goes.
The suggestions below are also not just additional systems... they are designed to be enhancements and build on what Forge currently is to minimize the development/design time required for them. Almost all of the features could be integrated now with little change in technical requirements, but in order to maximize some of the features more storage memory would definitely be recommended. Again that is only to maximize the potential of features as they are all designed around a modular design point of view(like skyboxes, grounds, textures).
I am a huge advocate of user created content and its effect on the longevity of a game as well as how it allows people to learn and set themselves up for the industry that they want to be a part of, if they so choose. User created content has the potential to benefit everyone in the Halo community, not just the designers and casual gamers so I think a focus on it would be very beneficial to the development of the franchise.
Object Coloring
So we've been talking about a lot of coloring, but nothing really feasible has come up. With something like forge, a pre-set color palette is going to be an obvious choice to limit the number of materials at runtime. In order to avoid storage memory issues (adding tons of new textures for color masks) while still keeping a uniqueness to each piece there would have to be a mix between use of couple of repeating textures and texture atlases. Texture atlases provide the ability to make each object in the palette unique, but coloring those would be a nightmare and would require a coloring mask for each texture atlas.
Each object would utilize its respective texture atlas for all of it's "unique" detailing, however each object would also utilize one or two tileable textures (like two different types of metal textures) that could be colored. These two tileable textures would be utilized throughout the WHOLE palette for coloring while texture atlases would be tied to their respective objects. So say the textures below would be used across all objects:
Along with these textures we would have a pre-selected set of colors (say the color palette given to spartan coloring). The one or two tileable textures would be coloreable... NOT the texture atlases. And they wouldn't require a color mask as you can just do a simple color multiply shader with their diffuse texture. This would ensure that those two textures would be coloreable giving the potential for providing a piece that has a main texture and a detailing texture, one as one color and one as another color. The main texture could be Texture1 or Texture2 with the detailing texture being the opposite. This would allow for some variety in style with some pieces being heavily tied to Texture1 and other pieces being heavily tied to Texture2. Because the other texture is being used as detailing, they will still work nicely together.
This allows objects to have two tones to them. There would only be an amount of materials equal to the number of tileable textures time the number of color options, and the texture atlases would still be in place to allow for a unique look for each object that keeps them distinct enough to allow for immersion when pieces are used together, rather than a bunch of obvious repeated textures. lol...
Base Map Creation
Some of us are tired of being fully restricted by the base maps that we are given. I think lot of level editors have it right in which they have pre-selectable options that essentially load up the right kind of map you want. Map creation would include selecting certain options that would fit what you are trying to build. The options would allow for:
- Skybox/Lighting
- Ground
- Object Palettes
The Skybox/Lighting is a bit obvious... we could have the Impact skybox, Sandbox, Forgeworld, Foundry, Ravine, Erosion, etc. Depending on the skybox you choose the dominant light sources could be drastically different in terms of angle, color, intensity, etc.
And you could potentially get a different backdrop for each. This could be potentially difficult since Halo is such a diverse universe and a skybox can be heavily tied to a particular "style" of environment. So this suggestion needs a lot more work.
In addition to the skybox you could choose the "grounding" of your map... essentially Forgeworld's canyon terrain, or Erosions lagoon, the grifball stadium, the colisseum, asteroids, snowy fields, sand dunes, etc. Obviously some skyboxes wouldn't mesh with some of these... like green grassy hills and a space skybox, but you could have a griffball stadium with a space backdrop through the windows, or a dusk skybox (like on sandbox), etc. Essentially the spaces would be much smaller maps in general except with certain environments that are naturally bigger. The "ground" of your map pretty much denotes the potential size of your map as well. So you could have a ton of sand dunes that is very large, but still build a small map, but the foundry warehouse is going to obviously be used for much smaller maps.
Grounds would also have "skybox decor" which would basically be pasted over the skybox to ensure that the environment fits well with the skybox. Like forerunner islands in the background like Ravine, with a dusk skybox like Sandbox.
Arguably this change does require a jump in storage memory, which sucks. But putting in that initial investment would result in a HUGE jump in potential variety... a lot more win than loss.
And finally you would have a checklist of the objects you would use on that map, which is discussed in the next section:
Object Palettes
Next issue is related to the selection of objects. Right now variety is limited by run-time memory... because you can only store so much to allow for real-time object loading. So instead of offering EVERY object as spawnable in a forge session, you setup the objects into 'packages' and have every map define what packages they are using and have only those packages loaded up at run-time.
Say we have these categories of objects now:
- Blocks
- Bridges and Platforms
- Doors, Windows, and Walls
- Natural Rocks
- Natural Foliage
- Natural Terrain
- Decorative
- Gadgets
- Inclines
- Buildings
- Vehicles
- Weapons
- Objectives
- Spawning
Some of those categories would always be loaded with EVERY map... like spawning, weapons, vehicles, etc. The more aesthetic pieces though would be chosen at map creation through a checklist. Say you only use Blocks, Walls, Inclines, but no Bridges/Walls/Decorative... the map would have built into it "only load these few packages". At map creation you would be limited to selecting say 8 out of 20 categories. That way the hit only comes to storage, not to run-time.
This has a bunch of benefits to it. It allows us to use various palettes for various maps. So say you have the Impact/Ravine palettes, the Erosion palette, and the Forgeworld palette. I could potentially use Erosion Blocks/Inclines, Forgeworld Walls (for the coli-walls), and Impact's unique category all together... and not just for one base map, but any of the base maps (and combinations of skyboxes/grounds from the previous section). It ensures that we don't go over a particular run-time limit. Each category would have a performance budget that it can't surpass to ensure that there is a maximum hit to performance that can be built around and no combination of packages would go above said maximum limit.
Object Limitations
In addition during the development process, each item would have it's own maximum performance budget. This could potentially allow us to remove the category limitations. So instead of only having 100 walls and 12 buildings, the buildings would have to meet the same performance budget as any other piece available allowing us to have 600 objects across the board as the only limit rather than limiting based on category. This is important because there are decorative objects that should be nowhere near the performance budget of other decoratives (see column vs walkway cover). So if I want to build a map with 500 coli, walls or 500 Bunker, Rounds then it is entirely possible because I know that both objects do not surpass the individual object performance limit/budget.
If this results in a lower maximum number of objects on map then that is fine... rather than having a possible 600 objects on a map (which is about the current limit, including spawns/objectives/etc.), 450 objects would be the new limit. This would be fine because as a forger, if I want to bigger map then I use bigger pieces and I can use as many of the bigger pieces as I want (coli walls, brace larges, coli windows, etc.). Right now we have the space for 250 spawns, but less than 1% ever even come close to using that many spawns. Why should those spawns limit how many walls I can place? Let me decide how many spawns I need and use the rest of the object limit for what I want. If I need more spawns, let me budget for the spawns on my own, knowing that more spawns means less structural pieces. This also gets rid of the superfluous budget system and is instead replaced with a current number of objects versus maximum number of objects.
Terrain Creation
Terrain creation has been a HUGE request from many people... but I feel that your typical terrain creation tools don't really fit well in the concept around Forge and would just fight for space in the development process. It would require TOO much work and feel more like a bandaid solution than a truly integrated solution. So I've designed my own solution to terrain creation.
Rather than your typical "let's make our own terrain" toolset, we use a combination of selected "grounds" and object palettes. Say we have a grassy, hilly ground similar to forgeworld's canyons, and most of the ravine's ground. There would be terrain object palettes that fit well with that grassy field. These palettes would be sorted into say hills, caves, foliage, rocks, cliffs etc. Each palette would have premade pieces of terrain that can be phased into the environment to make seamless transitions. We could have the equivalent of coli walls of grass for flat fields, and phase it into a certain spot of the grassy hills, then use small and large hills to phase into the ground to smooth out the transitions. Caves would have a rocky interior and a grassy exterior and all come down to a "base level" allowing you to put it somewhere and then surround it with grass land and hills. Caves would be the equivalent of buildings... large and more detailed, but surrounded by grass in order to be able to be meshed with other terrain hills to seamlessly implement it.
Rocks would match this cave aesthetic and you could use them to mesh with the caves and cliffs to help differentiate them as well as transition them. And you could have potentially mountain size rocks (not surpassing the individual object performance budget of course) that could be used to tie in with these caves and put over the grassy sections of the cave to make it a cave in a mountain.
This method of terrain creation keeps with the modular focus of Forgeworld and is seamless integrated into the systems that already exist rather than creating a whole new system. It allows new forgers to play with terrain without having to learn something new and gives vet forgers the flexibility to mold the terrain that they want. If they want more hills then they can add more hills with the already hilly terrain. If they want flat ground they can make flat ground and then meld it into the terrain with cliffs as transitions or large hills welded into the outskirts of it. The possibilities are endless at that point.
Object Manipulation
I've talked about this before, but I'm going to cover this again. The magnet system has a lot of potential in it. Essentially the magnets could be used to work with objects as groups to allow for a much faster work flow and encourage modular design even more so than before. Now that we have a better understanding of how the magnets work I can talk about it a little bit better.
First of all... right now the magnetic points are set at midpoints on object. The midpoint of edges and the midpoint of a surface. So there are 5 magnetized points on a single side of a block... one in the center, and then one at the top edge in the center, bottom edge centered, and left/right edge centered. In addition to these points there should be magnetized points on the end points/corners... so rather than 5 on one block face, there would be 9 (adding in one for each corner). This addition is definitely important as a lot of building is edge based rather than midpoint based. It is very important a majority of the time to line up the top right corner of a block face with the top left corner of a coli wall. The current magnetized point placement doesn't allow for this. There is the potential for overloading a piece with magnets, but that is what magnet strength is for.
A lower magnet strength means the pull radius is reduced which would be important when dealing with pieces like decoratives.
After making that change, the real fun begins. With the change above there is a good chance that a WHOLE map can be magnetized to at least one other piece, creating a huge magnet "chain". Or at the very least there would be several large groups of these chains. Imagine that you could make a lockout platform where every object is connected to another via a magnetized point. Now when you grab one piece in that chain, EVERY piece in the magnetized chain moves and rotates with it. They become "locked" to the piece you are moving... with that piece that you have acting as a "parent" to the whole temporary group. Only magnets on the parent will work for magnetization to pieces that aren't in the group. And rotations are based on the parent, not the group. So now you can take that lockout platform you built and rotate the whole thing at once, or magnetize it to a piece and rotate the whole thing around it... even rotating it so the whole platform is upside down... thanks to this new magnet group feature.
Going even further into the new features in H4 there is the locking system. In H4 there is also a feature to lock all objects on a map... which is awesome. Also locked objects can't be moved or deleted... even when using the feature to delete everything. This feature would extend into this new magnetized group system. Locked objects do not get added to a magnetized group when an object is grabbed. For example you could set the center window on the lockout platform to be locked so when you move the entire platform, the window doesn't go with it. Locked objects also "break" the magnetic chains. If there is a chain of 10 boxes magnetized together and the 5 one is locked, you can only grab a portion of the chain (4 or 5 boxes long depending on the side you grab).
What's this mean? Say you have a whole map with a bridge in the middle... the whole map is magnetized together, but you don't want to move the whole map. What you would do is lock every object on the map, then unlock every piece of the bridge that you want to move... then you can just grab the bridge and move it to wherever you want... rotating it and moving it to other locations.
Going even deeper into the new features of H4 forge we have duplication. This would be a beauty in conjunction with the magnetized groups and removing category limits (like discussed in a previous section). Essentially when you are holding a whole group, duplicating duplicates EVERY object in the group. With no category limitations and only a max object limit, this is completely feasible. On the HUD when you have hold of the group, there is a spot that tells you how many objects are in the group. If that number + your current object total doesn't go over the maximum object total then you can duplicate, otherwise the number is red and bolded so you know you don't have enough space to duplicate it. Now imagine the previous bridge example... now you can not only move the bridge, you can make multiples of this handmade bridge and put them where you want. Further emphasizing the modular aspect of forge and encouraging the concept of reusability.
With this system you not only get a huge workflow improvement, but this allows for crazy things. Imagine a person who has a favorite structure that they've built, perhaps they could save the temporary group as a "blueprint" to be used in other maps. And when you chose a blueprint it has the number of objects next to it and if you have enough space for it in your object count, then it builds that blueprint as a group. Because blueprints are created based on temporary fully magnetized groups you can easily just grab a piece on the newly made group and move it all together.
Testing Features and Map Options
So like MS and 343i, forgers care about their work and want to understand how people play it just as much as anyone. We already have theater which is great, but a couple of minor modifications would make things sooo much better for testing.
A big thing in my full experience with forge is spawning. Placing spawns and facing them in the right direction is important. A great minor feature would be able to select a spawn and to "simulate" that spawn. Basically it would just kill you and insta-spawn you on that spawn so you can see the exact direction of it. I've spent a lot of time standing on spawns and trying to line up just right to get an idea of where the spawn is facing exactly so I can adjust the direction. Perhaps going a little further and having an "advanced edit" spawn where you spawn on it, but you can't move at all. You can only rotate left and right (not looking up and down) and when you are done you confirm the direction and the spawn is adjusted to that direction you hit confirm on. This would make spawn placement extremely convenient and quick while giving people the ability to be really nitpicky about their spawns.
An minor addition to the theater system would be great. In this video that was posted of Natural Selection, there is an overview camera for the spectator mode:
http://www.youtube.com/watch?v=cJ3q1tdSjfs&t=35m46s. In would be great to have this in theater for forgers to get a good grasp of how their map plays from a top down view. It would have all players on the sides of the screen with their shields, and their primary and secondary weapon below or above it and you would be able to zoom, unzoom, lock to a player, etc. in order to get a better understanding of how someone is moving. They could also have a subtle arrow on them to show their facing direction at all times.
To get this to work seamlessly with forge maps there would need to be a couple things added. First of all a "map extents" object that defines the size of the map so the camera in theater knows exactly what to reset to with the height being determined by the size of the area in order to get it all on the screen. It would be centered on where the map extents position is. In addition this feature doesn't work well with interior spaces, so each object would get an additional option in their advanced options (next to game labels) that says whether or not the object is visible from top down view in theater. It is defaulted to true, but you can set it to false so the object disappears when this top down view is activated... allowing forgers to hide their ceiling while viewing the film.
And finally the map could be tied to a screenshot that has been taken in-game. The screenshot and map would co-exist and be passed along together so that it can be used as the thumbnail and image for that map. It could be an action screenshot, or an overview screenshot... it would be extremely flexible and allow designers to have full control over how players perceive the map prior to playing it.
Conclusion
Again these aren't all of mine ideas, but they are the main gambit that I've been designing and redesigning in my head with input from others over the past half decade. Most of these are entirely feasible to the furthest of my knowledge as an amateur programmer and an aspiring designer. The development time and technical requirements needed for these features can easily result in a tenfold return in capabilities and quality for user created content.