Lunar Assault 64: Difference between revisions
Jump to navigation
Jump to search
→Making the Game
Danielface (talk | contribs) m (Update images) |
Danielface (talk | contribs) |
||
Line 20:
File:Crime Crackers gameplay.gif|Crime Crackers
</gallery>
=== Implementing the Game ===
// Image of my progress sticky notes
==== The Environment ====
The game's levels are a 128x128 array of unsigned bytes. Each byte represents a height. Upon game start, the map iterates the heights and generates display lists of quads for the heights. The ground height is smoothed out for the four corners of the quds via bilinear interpolation.
[[File:Lunar Assault 64 test map.gif]]
I had some experience with three.js and Phaser in the past, so I wrote a small level editor in JavaScript that mimicked the display list generation. I was able to paint and shape with the mouse and then save them as a binary file to be included in the ROM. The "tiles" that make up the map also have an index of 0 to 15, which determine what section of a 32x32 texture to use. Only one load into TMEM happens for rendering the environment and actors. Wren and the Lunarbeasts are drawn with vertex colouring.
[[File:Level Editor for Lunar Assault 64 .gif]]
The environment has a lot of quads, so to improve performance z-buffering is disabled. The level was divided into 4x4 tile sections, where each tile has the vertices and rendering commands for an area. We don't sort the quads by position on render, but rather loop through rendering them based on the direction the player is facing. This isn't perfect and produces strange artifacts, but I think it contributes to a unique look for a Nintendo 64 game which normally would have a "clean" 3D look that matched the coming decade of games.
Wren, the satellite laser, and Lunarbeasts are all rendered with Z-buffering enabled. The display commands switch between two cameras for precision purposes. A small, close one for z-buffered objects, and a larger, far one for the environment.
==== The Satellite Laser Attack ====
The Lunarbeasts and their limbs are made up of a display list, [https://en.wikipedia.org/wiki/Transformation_matrix a transform], and a [https://en.wikipedia.org/wiki/Signed_distance_function signed-distance field]. Limbs could be parented onto other limbs and inherit their transform.
Checking if the player had correctly struck a weak spot involved [https://en.wikipedia.org/wiki/Volume_ray_casting raymarching] from the scope across the environment. Since limbs and hitboxes were transformed, the rays would be computed against a hitbox's inverse matrix as well as the inverses of its parents. This didn't always work right and and some precision problems, but overall I felt the gameplay was compelling enough.
The game applies a slight amount of noise to all the colours in the environment, and that noise amount gets cranked up for a moment if the player is able to strike a weak spot. I did this to help give a "pop" feeling and imply that the player is looking through some sort of electronic display. The only downside of this effect is that it breaks a lot of Nintendo 64 emulators.
==== FMV Playback ====
FMV playback was expensive for Nintendo 64 games and wasn't very common. I knew that the SDK supplied a library to help implement this, and I wanted to try including it to introduce the premise of the game and help make it feel more unique. I quickly wrote out a premise for a minute's worth of dialogue in a text editor.
[[File:Lunar Assault 64 Blender Screenshot.png]]
I blocked out an animation for the game's intro in Blender. It was a lot more fun than debugging a RCP hang in Blender! Since the final video was going to be rendered at 240p, I didn't really have to worry about too much detail.
I don't exactly have the strongest voice for a narrator, so I called my Dad and asked him to record lines with a microphone from his home. It was a fun remote thing to do as the both of us were mostly indoors during the COVID-19 pandemic. After applying a little bit of reverb to his lines, they fit in with the video very nicely.
When I was a young child, the [https://www.youtube.com/watch?v=lhwM3ZMTCR0 content of video games was a contentious issue] and something my parents were conscious and worried about. It felt oddly satisfying to have a recording of my Dad saying the word "shitty" immortalized into a Nintendo 64 ROM.
I attempted initially have the video play back at 24 frames-per-second, but I found it tended to stress the decoder too much. CrashOverride was helpful in re-encoding and helping me understand the HVQM tools better.
== External Links ==
| |||