BLOCK LAUNCH
Demo
Screenshots
Description
BLOCK LAUNCH is a first-person sequencer with a custom physics and ray-casting. The player can walk around a platform and click on pads to design a sequence, then launch themselves to the next platform as the sequence plays. The player has control over a variety of parameters:
- tempo (global)
- bpm (local to platform)
- number of pads (local to platform)
- gravity (global)
- launch force (global)
as well as the ability to toggle "chess mode" and the status display.
Instructions and Code
Instructions and code are available on github.
Once you have the repo cloned, and the latest version of ChucK, all you have to do is run chuck block_launch.ck
to start BLOCK LAUNCH.
Reflection
One of my biggest inspirations for this project is a game-mechanic from Minecraft, where the player can launch themselves with a slime block moved by a piston. I always found that mechanic to be very satisfying, and thought it was clever to have the sequencer launch me in the similar manner.
I really loved working on this project, and I'm proud of how it turned out. When I first decided on this idea, I didn't really understand how technically challenging it was going to be, but I managed to get most of the features I wanted working by the deadline (3D physics engine, ray-casting to select pads, collision detection, velocity-fov mapping, and much more). The velocity-to-fov mapping in particular feels really satisfying to me, so I'm glad I put the effort into implementing that.
I'm pretty happy with how I modularized my code (made possible by @import). I created a constants file to store
constants defined by the game designer (e.g. starting number of pads per platform, spacing between platforms, player height, etc.).
This makes it super easy to make game-design tweaks, since its all in one file, that my other classes grab values from. I also
created several of my own GGens (GPlayer, GMenu, GPad, GPlatform, GStar, GPlanet), so that I could refer to these GGens in the main
file (block_launch.ck), but make changes to those GGens in their respective files. For example, if I wanted to change all the stars
in the game into donuts, all I have to do is change a GSphere to a GTorus in my GStar.ck file. Additionally, custom GGens can handle
joint transformations well. For example, the GPlayer consists of 2 spheres, a camera, and a crosshair, that are being transformed in
in unison. I also liked my decision to create a separate PhysicsObject class to handle physics computations (but in retrospect,
I may have been able to make PhysicsObject a subclass of GGen, and GPlayer a subclass of PhysicsObject).
One of biggest challenges was actually getting my player to turn 360 degrees, since setting the rotation of objects is limited to a 180 degree range. I switched from a absolute mouse position approach to a relative mouse delta approach, and manually tracked the y-rotation of the player to address this. There were many more challenges (changing number of pads without resetting platform, using tatums??? for resyncing the platforms, updating menu with correct string information, etc.) but I'll spare you the details. Although it might seem like a pain, all these challenges were so fun to tackle, and have culminated in one of my favorite projects I have ever worked on!
Acknowledgements
Thanks to Kunwoo and Andrew for talking through design choices and implementation details with me. Thanks to EthosLab for inspiring this idea 10 years ago with slime block launchers in episode 344 of your Minecraft lets play. Thanks to Andrew for the drum_machine.ck example, it was a big inspiration for state-tracking in my class designs. Thanks to Hlushka Vitaliy on Turbosquid for the Earth 3D model. Thanks to Mr. Fottrell for being the best high school physics teacher ever -- so great that I was able to write a 3D physics engine with gravity, normal force, friction, and drag forces 5 years after taking his class. FREE-BODY DIAGRAMS!