The May Update
May went by rather quickly. It’s the season when the tourists all flock back into town and my day-job gets a lot busier. After last year, when the only people on Main St were a couple of teens on skateboards, it’s nice to have things a little more active.
So, what got done in May?
Lots – but lots of the same sort of thing, so there’s not much obvious progress. But that’s okay.
Same great looks, half the verts!In the last update I mentioned that I discovered that Macs
can do normal reconstruction using partial derivatives. This is good, because it provides flat, low-poly shading without having to duplicate (or triplicate or quadruple, etc) vertices. Since all of my meshes rely only on vertex colors for color, the meshes themselves only have to use two vertex streams: position and color. No normals, no UVs, no tangents.
Cube composed of 24 verts (left). Cube composed of 8 verts (right).The catch, though, is that I need to reimport all of my meshes and sometimes that requires a little manual labor on my part. That process took about two weeks (there were a lot of very old meshes with all sorts of superfluous data baked in).
I reduced the combined vertex count of all of my architectural assets by several hundred thousand vertices without any loss in visual quality. However, there are still several hundred thousand vertices too many. I could not figure out where all of these vertices were hiding. So, I built a little editor script that outputs a report on every mesh in the scene and orders them according to the number of vertices. Turns out that the majority of my vertex count comes from vegetation. The problem with this is that I do, in fact, need normals for this because the leaves take advantage of bent normals to produce soft shading on crossed quads. I have a lot of crossed quads in some of my trees and bushes. So, I either stream in vegetation as-needed, or I live with high vertex count. (I even tried to work with GPU Instancing using the excellent GPU Instancer asset
. The system is heavily camera-dependent and that’s a problem for this game where the time travel system is also camera-dependent. So, it looks like instancing is a no-go – which is a shame because it’s proper magic when it works.)
Addressing Addressables, again.I don’t really know how to efficiently stream in the vegetation just when I need it, but I finally found a
straightforward tutorial on Unity’s Addressables (I played with this system a few months ago, but the tutorial I was using was too difficult for me). Last time, I created a system that streamed in cubes in a grid based on camera view. It was super slow. Using GameDev Resources’ tutorial, though, I see that the good old test cubes are popping in very quickly. I’m starting to suspect that the slowness was based on my own code for determining which cubes in the grid were visible to the camera rather than the Addressables system on its own. But, the very early results this time are encouraging. This might work for the vegetation?
The tutorial comes now?I also built a rudimentary tutorial system which shows screen-prompts to help teach the player how to interact with the game. It’s not much, but it’s something and I’m mostly happy with it. Sometimes it gets in its own way, but that’s okay for now.
Smashing up old stuff.The rest of the month has been spent fracturing architecture. The Roman and Norman periods contain a few buildings which need to be broken up to prepare them for their rebuilding animations. (Come to think of it, so does the Iron Age…) I built a lot of this stuff a long time ago so, again, it needs to be updated. I have also added an early medieval monumental cross, as this is a critical feature of the early church site and kind-of bridges the transition from the spring/holy well of the prehistoric and Roman periods into the late antique/medieval and beyond. That was a tedious slog – one that I’m not quite finished with. Part of what makes it tedious is thinking about how the fracturing and rebuilding works with the larger game design.
Which brings us to…
A fragment of the early medieval cross, based on a cross at Clonmacnoise (I know, I know, right period, wrong place, but I had the photogrammetry to-hand). If you find this you might change the course of in-game history…RuinsThe core mechanic of the game is rebuilding ruins. Simple, right? See some ruins, rebuild some ruins. That’s how this all started.
Decline and FallBut here’s the thing: buildings are in a perpetual
“Ship of Theseus” situation. When would you say that a building is “complete”? Most buildings undergo modification almost immediately after their first phase of construction. Occupants block up windows, punch through walls, extend rooms, add storeys, etc. Every new occupant makes their mark. A building that lasts for centuries can undergo so many modifications that its original structure is lost.
For example, the fine Roman amphitheater you can visit today in Arles, France, was built in the 1st century but by the 5th or 6th century had been turned into a fortress with a town inside, complete with defensive towers and parish churches. The arches of the amphitheater were filled in with houses, shops, and storage, transforming this Roman civic building into a hodge-podge medieval village. The building you see today is a restoration of whatever “original” fabric survived the overbuilding and adaptation of the succeeding centuries. In Lucca, Itally, the amphitheater is preserved in the circular layout in the town’s street pattern and central piazza, and in some standing fabric embedded in the walls of the later houses.
The amphitheater at Arles today (left). The amphitheater in the 18th century (right). (Source: (Left) Rolf Süssbrich. (Right) J.B. (Jean Baptiste?) Guibert).
The amphitheater at Lucca today. The circular plaza is just visible on the right. (Source: (Left) Barrett-Small (Right) James Manners)The
when of a building is one of the core design problems of this game. When the player rebuilds the parish church, they rebuild the church as it existed
when?
It should come as no surprise that this is one of the core problems in archaeological illustration of sites as they may have been in the past. Normally, you would commission a series of illustrations, showing the site in several developmental phases. But even this is somewhat arbitrary. The archaeologist must make a decision about the
when or
whens they are choosing to depict. Because the illustrations are normally single-image snapshots, the archaeologist is usually afforded some leeway as to exact dates, and so has some wiggle-room. In a game like
The Resurrection there is less wiggle room because the totality of the history of a site is being displayed. At least, that’s the goal.
So, how to choose the
When of a building?
It’s arbitrary, but I have chosen to concentrate on reconstructing buildings at their “fullest extent”. Whatever that means. So, it may mean that some parts of the fully reconstructed building are from different period prior to the player’s point in time. Some reconstructed portions may even be reconstructed as ruinous.
…Back to this past month and me breaking apart the Roman and Norman buildings. I needed to think about when these buildings began and when they ended, and how they met their ends. That started to get difficult to illustrate very quickly, especially if the end of one building – such as the Roman temple tomb – contributed to the beginning of another – the building of the Norman chancel.
The ruined Preconquest church on the left, with the ruins of the Roman temple tomb on the right. Which one the player chooses to rebuild will affect how they time travel.And what if a player travels to a time period in which a building exists but they haven’t reconstructed that building yet?
Sometime over the past year I built a feature where a player would time travel when they completed a building, or part of a building. This feature helped me out of one design pinch, but it wasn’t until this month that I realized it would help me get through this core design problem of
When. A player can rebuild a building the first time they encounter it, regardless of what period that is in. When the building is rebuilt, the player automatically time travels to the “fullest extent” period that particular rebuilding represents. The player gets a baseline point-of-entry to that building’s story to which they can relate every other time – in the past or future - that they encounter the building.
Also, for special cases, I can just present the player with un-rebuildable ruins that flash the message “More Data Needed” when moused-over.
Having this problem better understood makes it easier for me to continue to craft content for the game. It’s just the way I design, I guess, but if I don’t have a strong grasp of solutions to design problems I often find I can’t make progress in other areas of development. The
When questions is one of those problems. So, it’s nice to have it out of the way – at least until it returns in another form later on when I run into the unintended consequences of this “solution”!
Which is fitting for a game called
The Resurrection.
I’m keeping to my unrealistically optimistic goal of getting a playable demo out by August. Two months left …
Community
