3. 2D and 3D Rendering
- One month to go
- Same ol' framework
- 2D and 3D Rendering
- Reaching 13k
From the beginning, Infiltration was going to be a 3D game. I already had some ideas for the visuals and that involved dynamic lighting, so WebGL was a natural choice. Since it had been a while since my last 3D development, I went through the documentation to refresh my memory on the topic. I discovered that WebGL2 was out and well supported ... well, almost. Chrome (v76) declined to create a WebGL2 context on my machine, whereas Firefox had no problem to do so. I suspected an issue with my graphics card, but to stay on the safe (and compatible) side, I stuck with WebGL.
Drawing onscreen text, such as messages or heads-up display, in OpenGL applications is a complex operation : one needs to set up a dedicated camera, two triangles to match the viewport, render (usually with Freetype) to an offscreen bitmap buffer, and use it as a texture for the quad.
Fortunately, the browser environment gives us another, more straightforward option : overlaying a 2D canvas on top of the GL canvas. The menus, the AI messages and the status bar are all drawn on this 2D canvas.
In 2013, I designed a car model in Blender, exported its coordinates, discretized them and packed them to a string. Thinking about it, it probably defeated zip compression, so this year I went for another scheme to get nice 3D at a reasonable cost : mathematics !
The ship's hull is made from two paraboloids, cut, scaled and adjusted :
And the reactors are two sections of an ellipsoid, hollowed out through a cylindrical symmetry :
Everything is stored inside a single buffer, and drawn as many GL_TRIANGLE_STRIPS. Lost reactors are skipped during the drawing process. The model contains a fifth reactor, centered at (0,0), and used only to draw freshly detached reactors as they are tumbling down. About 110 lines of code are needed to define a 4960-face spacecraft model, which may be much for 13k, but I hoped that due to its repetitive nature, GL code would compress well.
The initial design called for straight corridors ending in an intersection, where the player would have to choose between directions. All paths lead to Rome, so there would never be a wrong way, only short and long ones, more or less difficult, with the occasional shortcut, a difficult pathway but that would connect way further on the path. The game was initially slow-paced, so turning on the spot in those intersections was possible. Size and time constraints dictated that choice and shortcuts be left out of the final release, so only curves were needed between the corridors. Going up, down or sideways, in an effort to disorient the player.
The 3D model cheats on relative sizes. All those corridors are to large to fit in the Death Cube, however this is (almost) invisible in the intro since the GL far plane cuts most of them from the scene. And the Death Cube itself is a prop : only the front and right-facing sides are drawn !
For the sake of simplicity and code brevity, there is only one texture image, subdivided into 16 subtextures. This is why in the code, texture coordinates feature lots of 0.25, 0.5 and 0.75. Everything is crammed into a 14-color, 256x256 image weighing less than 1 Kb.
I initially envisionned a dynamically lit environment, with light fixtures listed in the corridor description, and their location, color and intensity passed as variables to the fragment shader. With a short code snippet, some lights would then flicker, or turn off as the craft approaches, giving the place a bleak atmosphere. Unfortunately, all that design did not make it into the final release. There is a single light (two in the intro) attached to the craft, illuminating the scenery in front. We will assume the corridors of the Death Cube are entirely in the dark, and that is why spaceships feature headlights.
- One month to go
- Same ol' framework
- 2D and 3D Rendering
- Reaching 13k