Creative and hardworking Java Software Developer specialized in game development, crafting scalable and efficient frameworks. Background generating entertaining experiences through innovative game design. Result focused and passionate, with strengths facing technological challenges and delivering technical solutions. Enthusiastic about working in teams and thriving in collaborative environments.
Contact Me
Transformers Revival
One of the key components in Transformers Revival is, as the name suggests, transformations. Not only between robot mode and vehicle mode, but also between robot arm and various weapons. The transformations work in a special way that makes them fully seamless:
All modes use the exact same 3D model, only difference being the rotations and offsets of each cube; all other properties, such as dimensions, UV mappings, and names stay the same. For each mode, a “snapshot” is first taken of the model, and its rotation and offset data is saved. With the cubes sharing the same names across snapshots, the model can easily be morphed between snapshot states using linear interpolation.
Spider Man
Spider-Man’s web swinging took a lot of tweaking and fine-tuning to get right, but is ultimately pretty straight-forward:
After the player shoots a web rope and that rope attaches to a surface, the rope stays a fixed length (ignoring elasticity). Whenever the player’s distance from the attachment point (point A) exceeds the established fixed length, their position in the world (point B) is offset to close that gap, while still maintaining the angle between the two points. A tangent vector can then be created by making a line between them, the direction of which is then applied to the player as motion, thus creating the “swing” motion.
Doctor Octopus
For Doctor Octopus’ tentacle arms, the first problem I tackled was rendering. They needed to be dynamic, able to reach virtually any surface around the player, all the while avoiding intersecting with the player model. This would be especially important, considering the fact that they also needed to stick out through the player’s back, meaning that any conventional approach would result in them instead sticking out of the player’s abdomen whenever the arms reached for something in front; they needed to curve around the player.
My first attempts involved inverse kinematics. In the end though, what I ended up going with was quadratic Bézier curves. Already having points A and B, I used some simple vector math to calculate the position of a third control point C. Using these points, I could now draw a 2D line through 3D space, curving around the player like desired. The rest was simple, all I had to do was tile a repeating arm “segment” model across the length of this curve, telescoping it to reach any desired length.
The rest of the project involved making the physics for the arms, the main function of which was climbing. I wanted the action to feel as fluent as possible, requiring minimal input from the player, which meant that the locating of and attaching to viable points for the arms had to be handled autonomously. Additionally, the arms had to move in a way that made sense, i.e. not criss-cross when grabbing terrain; an arm closer to the right of the player should attach mostly to points to the right of the player.
The latter was achieved by assigning “preferential zones” to each arm, meaning that they would prioritize points closer to their point of origin. To actually locate viable points, a small radius of blocks is scanned around the player and the coordinates of solid blocks within that area are added to a list. The list is then iterated over in “preferential” order, and a simple ray trace check is performed to determine if the arm could in theory reach that point. If it passes the checks, move the end of the arm to that point.
