It’s been a fair few months since my last post on anything in my portfolio. After the Stiletto RP project stagnated, I found myself not wanting to do much of anything for a couple months. Since then, however, I’ve been working on making the Portfolio Model Viewer app quite a bit better, though I’m still bouncing between projects and am not done on that. The other thing I worked on since the start of 2021, which will be covered in detail here, is GPong.
I got back into GPong because, for whatever reason, I really got the urge to start working on a Goal model. From there, it evolved into quite a few more models and finally onto a beta-grade version of the first map for the game mode. More on that later.
The Goal
This was the aforementioned prop that dropped me back into working on GPong. I just sorta had a general idea for it in my head while taking a shower one day, and just decided to go for it, even though I hadn’t done anything for GPong since I setup the initial post on this Portfolio site. I also believe that this is the prop that solidified the aesthetic of GPong in my head; painted white metal, neon stripping, and team paint decals. This is a fair bit removed from the previous models I made, which are more industrial, unpainted, and rusted to hell.
This prop also introduced me to the hell that is doing anything non-basic in Source’s VMT system. I wanted to have the red paint marks be their own map, and have the shader paint an arbitrary team color on it in order to save on download size. This is because I am making materials at rather decently large resolutions (generally, 2048×2048), and there’s a package size cap on the Steam Workshop. However, making the material actually work is another thing entirely.
Turns out, whenever you try to do ANYTHING AT ALL IN SOURCE’S VMT SYSTEM, it will reveal numerous collisions, caveats, incompatibilities, and just outright strange behavior, compounded by the lack of accurate documentation. However, in the end, I was able to generate a similar MatProxy setup (with some amount of guidance from my friend Copper) to that of the Player Skin stuff already present (but, again, not documented) in Garry’s Mod Sandbox. This now works for the most part, but right now requires sv_allowcslua 1 for it to function, which I’m looking into.
Jump Around
This is another prop that emphasizes my reliance on abstract polygonal designs when trying to make models of things that don’t exist outside of my own head. When it comes to stuff I have references for, I’m pretty decent, but when I have to somehow get an idea out on “paper”, it can get a bit strange. Thankfully, that works for the aesthetic here of the aforementioned “white paint, neon strips” look.
The Jump Pad is a staple of FPS games from days of old. They are king when it comes to rapid transitions. So it makes sense that I should throw them into GPong, which is itself a pseudo-remake of a mod from said days of old. This prop, when paired with a trigger brush, serves as a huge mobility tool for both players and the ball. I’ve had quite good luck setting these up around the place in test maps and getting some good movement tech into the mode.
Ball!
Another thing I ended up doing was giving the Ball a proper texture, rather than just using the “Green PCB” material from PHX. I kept a lot of the aesthetic from it, though, going for a glowy green/cyan look for the base, but also adding a lot of other details like the metal bands and whatnot. This and the Jump Pad really worked to solidify the workflow to get PBR-based work out of Substance Painter and into the decidedly non-PBR VMT system. Hell, most of my March was getting the VMTs to cooperate; between this, the jump pad, and the goal with MatProxies, it’s been about 10% art and 90% smashing my face into the wall.
Going forward, I plan to have the capability to register and support multiple different ball materials and models, much like the original QPong did. I wonder how a smiley ball would look in PBR…
Zoom Pad
This was a fun model. Mostly because I spent about 5 minutes on it in Blender and about 2 hours in Substance Painter. The model is precisely 82 triangles, if that reveals anything. This model is to represent the standard booster pad you see in a lot of games but, like the jump pad, also works on the ball. I’m still considering whether or not I need to make my own pusher volume code for it, but for the moment, the built-in trigger_push brush entity seems to be working well enough.
Teleporter Redux
Previously, the Teleporter looked like it was made out of dumpster metal and plastic stickers. Knowing a slight bit more about texturing in Substance Painter now, along with having an actual aesthetic to play to, I decided to redo the entire material for the Teleporter. I actually went a slight bit nuts with the decal painting this time around, and I found out how to reliably paint an iris-like “overlapping” look for the center lens thing. Not too much more to say about this one other than it looking significantly better than before.
Finally, A Map
So after multiple false starts, I finally have a properly put-together map for GPong. This map ended up having a very “dried out waterway” feel to it early on, so I decided to lean into it with the decoration and texturing. It’s significantly smaller than the initial attempt at a map like this, but that’s actually a good thing because the “gp_bunker” attempt was about the size of the map limit and took MUCH too long to run across.
This iteration features all of the above models and features to make sure movement is rapid and smooth. The goal areas are absolutely covered in jump pads and ramps, which sends the ball flying every which way. The bridge in the center of each goal area syncs up with the double-trench structure to prevent long-shot goals from going in too easily.
This map was also an exercise in aggravation, as I ran into yet more poorly documented features. In this case, it was figuring out how “texlights” (emissive textures in other engines) work with the lights.rad file. I eventually got it working, but not before running into a multitude of stupid issues.
As for the midfield, I was going to have it sit at a 45° angle to the goal areas. However, I ended up scrapping this idea because HOLY GOOD GOD DAMN Source/Hammer does not enjoy doing things at non-orthogonal angles. So now it sits at the 90° angle you can see in the overview image at the top of this chapter.
Also to note, I was working on the ball spawn for the midfield on a Discord stream and my sister gave me an idea: make the ball spawn shoot out of a drain pipe. So I did: