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.