Lunar Assault 64: Difference between revisions

Jump to navigation Jump to search
m
typo fixes
m (typo fixes)
Line 25:
==== 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|alt=|center]]
 
[[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|alt=|center]]
 
[[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.
Line 38 ⟶ 36:
==== 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. They were more or less animated programmatically with interpolation and sine waves.
 
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.
Line 46 ⟶ 44:
==== 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|alt=|center|765x765px]]
 
[[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 awhen the RCP hangwould inhang Blenderup! 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.
84

edits

Cookies help us deliver our services. By using our services, you agree to our use of cookies.

Navigation menu