No one had strong feelings about what to make. But as we refined the basic idea, questions arose. I really like this stage of ideation, as it feels like a backwards argument: First, we allow a conclusion. Then, we think of premises that support that conclusion. These new premises then become conclusions for even more upstream premises. Rinse and repeat to formulate a web of arguments that support that initial conclusion.
I didn't contribute much to the narrative aspect of the idea--piloting and maintaining a mech from the inside. On the mechanical side, however, I raised questions that helped formulate this backwards argument. What do we need for pilot and engineer gameplay to work together? What premises could be true so that this conclusion can follow? It's exciting to see a group slowly construct this backwards argument and slowly come to a shared vision.
I worked on the movement and item pickup part of the demo. I shouldn't have spent so much time on the movement aspect, as any basic movement would do for the demo. But like, I really wanted a solid foundation for good movement. Having played lots of first-person parkour games like Dying Light, I wanted that knowledge to shine through and raise others' standards of what "good movement" is like. Movement is a key gameplay mechanic for the engineers.
It seems like the hardest part is making each person's work work together. It's been difficult to get everyone's ideas on the same page and have a centralized vision.
For this week, I ended up pivoting to more programming role for the player controller. It appeared to us that the movement mechanic of the characters were a bit lackluster considering that parkour is the central activity for the players. We decided to go with a grappling approach and it turned out pretty well. Lots of discussion was required to get the team to head towards discussing the central problems of the game concept.
Lots of tasks built up and I feel like I've done a lot of work. It's been hard to keep track of what exactly I did so past blogs slipped out of existence.
Mech combat is switching to a two-step process of loading and launching. Rewrote the Fighter class and created temporary animations for it.
Got a hand in multiplayer scripting. It's complicated and not very functional. Since most things need to be manually synced, most features are just flat out not working.
Finally, we are approaching a playable build. Band-aid solution to the lack of multiplayer functionality is having four engineers you can switch between. Also added a parameter screen and started getting the Engineer character multiplayer-ready. Hoof.
Pivoting to a construction of the levels such that the levels rotate along with the actual mech movements. Proving to be difficult to address a few things: joints between rooms, clipping levels, player clipping out of levels. Joints need to make mechanical sense and not clip into itself. Some ideas are hinge joints, tube joints, and ball joints, but each have glaring problems. Kinda want to rewrite everything.
Because of the way the physics evaluation of the mechs doesn't constrain the joints (which adds to the goofy nature of the fight), we needed means of traversal that is bendable in all directions. A tube joint makes sense, but it was difficult to figure out what was the best solution. MeshColliders aren't meant to recalculate collision at runtime, there's no built-in softbody simulation, etc. I needed the tube to interact with the physics system, not through C# scripts. I ended up choosing to procedurally generate a tube mesh based on a Hermite curve and moving around colliders and placing them around the tube. One of these scripts is similar to one Engineer movement script performance-wise. That's pretty good?
To add more predictablitity, I converted the Mechs to use Rigidbodies and Character Joints. This way, we can constrain the motion of the limbs and further prevent clipping between levels. Some funky stuff going on with just instantiating the levels onto the limbs, though, as the levels were not built with actually being in the mech limbs in mind. I should communicate this.
The script that builds the mech is completed, but we don't have the levels inside the mech completed. The external appearance of the mech requires parts that align with the bone rotations, so that when they are spawned and parented to the bone, everything just works. It took a while to get these two things ready.
The tube joints also had a problem of twisting when the tangent of its curve approached the reference up vector. I addressed this by using a Rotation Minimizing Frame instead of calculating the normals just by cross products.
The Mech Action class also needed some rework, so I changed them to Scriptable Objects and gave them "modifiers" that are applied to the body part when the action is triggered: e.g., add 5 to the resulting collision damage for the other collider, but reduce collision damage by half for the punching hand collider.
Everything is in place to build the mech on runtime, but we are just waiting on the levels. When I'm writing the code I tell myself that it will never work the first time, so I'm hoping I can get those levels done soon to test the system. I'm also not sure how it will work in multiplayer context.
For the longest time, the arm levels have not been "working" for our game. Spiral staircases fill up the entire level and make horizontal navigation virtually impossible. Straight catwalks are okay, but they have no dynamism when the level turns vertical. I don't think the sensibility of mech levels have been communicated and agreed upon between the level designers.
Spawning the mechs in multiplayer seems like it will have issues. Also, quite a lot of performance cost was happening in the core due to the rotating gears. At this rate, the performance issues has to be addressed or we might not have a stable gameplay.
I thought the dynamic reticles weren't a problem for the longest time, but apparently the reticle appears on objects that are too far away to grab. It seems playtesting is lacking because the builds aren't functional, so small issues have slipped under the rug for a while. Of course, the build won't work the first time. We need more tests of individual functionalities. I think we're trying to playtest the full thing too much, and it's being bottlenecked by level designs. I know Kai is working on a level generator, but it's just taking too long and the arm levels designed by Shahbaaz is not working for the purposes of our game.
The reticles have even more usability problems. I'm not sure if we can perfectly capture the heuristic logic of dynamic reticle placement because our game uses colliders to grapple to, not particular points in space. The solution needed to be smooth (adjusting to a gradient of possible positions on the grappleable collider) instead of being stepped (which point is closest), so a perfectly intuitive solution feels impossible.
I got pretty close by marching the collision detection and overlapping a sphere at each step. This way, the nearest calculated grapple point is closer to the center screen.
Because complex classes can't be sent over the network, I had to make the MechBuilder script read from a FixedString, which can be sent over the network. This FixedString value can store the correct paths to the desired rooms and shells of the mech and thus sync the parts between clients.
The X Ray view has proven useful for playtesters, so I was tasked with reimplementing it. The x-ray was easier to implement because the rooms are inside the mech. I just had to make some objects be duplicated and be rendered on a separate layer, or contain objects already on that layer. Camera culling is very useful for making these kinds of things happen.
One of the big advantages of putting the levels inside the mech was that it allows viewing the outside world easier. However, the issue becomes complex: Some mech shells have mesh that is visible from inside the levels, so we can't allow it to be viewable at all times. The enemy mech's shell should be ideally visible from windows, but it can clip into the levels easily. It would be complicated to put each levels inside their own layers and enable layers of the levels you are not inside--you'd have to turn off shells of adjacent levels as well, since you can see them through the tubes.
The best solution I thought of was defining which parts of the level the player can see the mechs' shells, by manually placing triggers that change the player camera culling layers. Even setting this up in the pilot seat was kind of complicated as the glass was curved out...
The x-ray system is working fine, and the shader transition looks pretty cool. I'm just waiting for art assets to come in so I can place them inside the x-ray and help players get a better bearing of their status.
The arm levels that Shahbaaz made seem like they want the players to fall out of the mech, when we've (especially I) wracked our brains trying to find a solution to not make that happen. The openings of the levels don't make physical sense either, as the tube is just floating at the connection point.
The mech ragdolls are too unstable. I should have known that Unity's Rigidbodies are a bit unstable because they use velocity, so I really had to add manual drag to prevent the ragdolls from flying into the sky like some sort of popped balloon. Tried ArticulatedBody too, but everything is just so... janky.