Behind the scenes of the Customization Menu and 265
SamusDroid
Colorado Join Date: 2013-05-13 Member: 185219Members, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Gold, Subnautica Playtester, NS2 Community Developer, Pistachionauts
Colorado Join Date: 2013-05-13 Member: 185219Members, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Gold, Subnautica Playtester, NS2 Community Developer, Pistachionauts
About 2 months ago I was asked to make my menu poses mod a reality. After first creation of the mod many months ago, I quickly realized that cinematics would not do, and I would need to do it in code. This sounds easy, but turned out to be one of the most daunting tasks I've done in Natural Selection 2. In premise, it sounds easy, a player standing on a level with lights, but due to near endless limitations, quickly turned into a complicated mess.
First I decided to start with GUI's so I could at least access the menu. Had a fully working GUI in only a few hours, going smoothly so far.
Next I started working on getting a model in front of your screen. After many crashes and experimenting, I figured out that this needed to be done on the Server.
In order to place a model in front of the player, it needs to first be precached. Now under common assumptions this just means "oh load it before it is needed" but actually it does a lot more. Precaching assigns a model index to the model, so that the server can sync the bones of the model and play animations. Unfortunately this can not be done in the menu before you connect to a server. This is just the start of the limitations.
The customization menu is all created in the View Model render scene, this allows models to be created in front of the player without walls or players going through the menu. We arrived at the conclusion that there needed to be an effect when switching models, this simple sounding task was one of the more complicated pieces of the menu. when the model is switched it changes the opacity of the model and uses the Tweener functions to do so. A cinematic level used as a background contains lights and props to make it look the same always. This was also another source of many limitations. The cinematic editor is not perfect, it is pretty good but it has many limitations. For whatever reason certain entities are not dynamic with the creation of the cinematic. In order to make the customization menu work, I needed to find a way to make a background. Of course it turns out that levels are static to where they were created, meaning they don't follow the creation of the cinematic. This wouldn't work, so I turned to using props. Thankfully, props are dynamic, then came the lights. Another limitation is that spotlights are static, meaning I could not use them, so I had to use point lights. This is all great except that shadows are not cast in the view model render scene, and that I could not have atmospherics. It also turns out that your FOV affects where the lights are in the level, but not props. After a long time experimenting that it took me to figure that out, it was already too late and the build was ready to be released. It would be dark for players with full FOV, and really ugly and bright for minimum FOV. I then went about finding a way to hide the GUIs, a very complex process that is not as ideal as I would like, but it works. Of course, I could not hide all the GUIs in the time I was given to create the menu by the time I got to this part. I also needed to find a way to make outside lights not cause inwards and not see highlighted players. Mendasp gave me a hackish but clever solution to move the players camera up really high, 10000 units high above the map, this worked great minus a few bugs which I worked out quickly.
Once finally getting the backend working, I then started polishing the menu up. I ended up finding a perfect sound effect when switching the menu, the sound used for Vortex. the customization menu is a lot more than people would first see, and one of the most challenging, and educational tasks I have needed to do. I am finally glad to get it out to the public, and with mostly positive feedback about it so far.
I then needed to make the skins. which was a very interesting and efficient way to change textures on models, using the new awesome skins that Rantology had made. I explained this more in the public post.
Exo and Rifle skins were also a very complicated, but in theory simple task. I decided texture atlasing like the shoulder patches could work. It ended up working very well without much work needed. However, getting them to actually work was another story. I began by copying what is currently done with Marine models, which worked pretty well but introduced quite a few bugs. One of the weirdest bugs I have encountered in NS2 was with first person view model textures. There were 2 bugs where one player on the server, at random, would be able to control everyone else's view model variant. After nearly 2 weeks of experimenting and testing, I ended up with a solution of verifying by Steam ID who made the request to change the skin, so only your request affected you.
2 weeks before the patch was released, we began having double playtests, EUPT and NAPT Monday - Thursday, constantly tweaking and trying to fix. Eventually I decided that I needed a faster way to update and test. thankfully Gibs was able to host a listen server I could connect to, and I created a mod that I could quickly update, and then shortly I fixed the problems that were caused by the many bugs that first started out with. The last 2 weeks before release were very exhausting, but worth it, as I now have a way to display variants in a complicated, but simple to use menu, and a way to have weapon variants, well worth the time and energy made to make them. Due to what I needed to have in order to have this function properly, I ended up also fixing some very very old bugs, like visors and decals not fading with a dead marine, a bug reported almost 500 days ago, and Fade and Onos view models being outlined.
First I decided to start with GUI's so I could at least access the menu. Had a fully working GUI in only a few hours, going smoothly so far.
Next I started working on getting a model in front of your screen. After many crashes and experimenting, I figured out that this needed to be done on the Server.
In order to place a model in front of the player, it needs to first be precached. Now under common assumptions this just means "oh load it before it is needed" but actually it does a lot more. Precaching assigns a model index to the model, so that the server can sync the bones of the model and play animations. Unfortunately this can not be done in the menu before you connect to a server. This is just the start of the limitations.
The customization menu is all created in the View Model render scene, this allows models to be created in front of the player without walls or players going through the menu. We arrived at the conclusion that there needed to be an effect when switching models, this simple sounding task was one of the more complicated pieces of the menu. when the model is switched it changes the opacity of the model and uses the Tweener functions to do so. A cinematic level used as a background contains lights and props to make it look the same always. This was also another source of many limitations. The cinematic editor is not perfect, it is pretty good but it has many limitations. For whatever reason certain entities are not dynamic with the creation of the cinematic. In order to make the customization menu work, I needed to find a way to make a background. Of course it turns out that levels are static to where they were created, meaning they don't follow the creation of the cinematic. This wouldn't work, so I turned to using props. Thankfully, props are dynamic, then came the lights. Another limitation is that spotlights are static, meaning I could not use them, so I had to use point lights. This is all great except that shadows are not cast in the view model render scene, and that I could not have atmospherics. It also turns out that your FOV affects where the lights are in the level, but not props. After a long time experimenting that it took me to figure that out, it was already too late and the build was ready to be released. It would be dark for players with full FOV, and really ugly and bright for minimum FOV. I then went about finding a way to hide the GUIs, a very complex process that is not as ideal as I would like, but it works. Of course, I could not hide all the GUIs in the time I was given to create the menu by the time I got to this part. I also needed to find a way to make outside lights not cause inwards and not see highlighted players. Mendasp gave me a hackish but clever solution to move the players camera up really high, 10000 units high above the map, this worked great minus a few bugs which I worked out quickly.
Once finally getting the backend working, I then started polishing the menu up. I ended up finding a perfect sound effect when switching the menu, the sound used for Vortex. the customization menu is a lot more than people would first see, and one of the most challenging, and educational tasks I have needed to do. I am finally glad to get it out to the public, and with mostly positive feedback about it so far.
I then needed to make the skins. which was a very interesting and efficient way to change textures on models, using the new awesome skins that Rantology had made. I explained this more in the public post.
Exo and Rifle skins were also a very complicated, but in theory simple task. I decided texture atlasing like the shoulder patches could work. It ended up working very well without much work needed. However, getting them to actually work was another story. I began by copying what is currently done with Marine models, which worked pretty well but introduced quite a few bugs. One of the weirdest bugs I have encountered in NS2 was with first person view model textures. There were 2 bugs where one player on the server, at random, would be able to control everyone else's view model variant. After nearly 2 weeks of experimenting and testing, I ended up with a solution of verifying by Steam ID who made the request to change the skin, so only your request affected you.
2 weeks before the patch was released, we began having double playtests, EUPT and NAPT Monday - Thursday, constantly tweaking and trying to fix. Eventually I decided that I needed a faster way to update and test. thankfully Gibs was able to host a listen server I could connect to, and I created a mod that I could quickly update, and then shortly I fixed the problems that were caused by the many bugs that first started out with. The last 2 weeks before release were very exhausting, but worth it, as I now have a way to display variants in a complicated, but simple to use menu, and a way to have weapon variants, well worth the time and energy made to make them. Due to what I needed to have in order to have this function properly, I ended up also fixing some very very old bugs, like visors and decals not fading with a dead marine, a bug reported almost 500 days ago, and Fade and Onos view models being outlined.
Comments
Now make the SamusDroid DLC so we can send some your way. :P
Sounds like you did some awesome work there B-)
Awesome work. This is the kinda thing that seems like it should be simple but turns out to be a huge pain. Hopefully for our future games, the architecture will be a lot more clear to prevent these. The view model FOV thing is probably an oversight that we just never noticed before, since most view model lights are quick muzzle flushes I guess.
How about having those two menu points showing up in non-ingame menu aswell, but beeing greyed-out and / or at another position on the screen?
So madness permitting whats the chances we can customize to this extent down the road? :P
Could give a negative impression with the preorder skins, though.
How so?
"Here's the awesome black armor. You can't get it, but we show it to you anyway so you know what you miss."
Ok, I see your point. How about excluding the black armor and show all of the other ones that can be bought?
Sounds better, but is inconsistent and could raise questions if someone sees a black armor ingame for the first time.
We can have models in the main menu, as this has been done before. They can also do movement right? We even have/had a mod lying around which showed models like gorge, lerk and marine so we could see the skin we selected.
Then what is the engine limitation which prevents this, or am I not understanding something fundamental?
Not trying to nag or anything, I just do not understand.
The menu is a animation loop made with the cinematic editor.
So ( as @SamusDroid explained somewhere else before ) to make the costumization menu compatible with the main menu you would have to create such a animation loop for every existing skin variant.
Which is a lot of work if you want to add easily new skins and models and may want to change the main menu background itself.
I wanted to do more in depth customization however it would require models to be charged in order to have a smaller texture for visors and lights. It's something in will be investigating though, as I can now edit the source models.