Been homeless since the last update, with most of my time spent moving between temporary accommodations and trying to fix that situation. The problem has, however, very recently been rectified, so now it’s back on Tangiers full time until release.
Things haven’t been entirely static on the Tangiers front though - a fair bit of progress has been made given the circumstances.
A common feeling is wanting to see more in-game footage on these posts, so I've recorded footage walkthroughs of the two main features.
(Edit just before posting: Kickstarter has drastically reduced the quality of the .gifs that I've used in this post. Not sure whether that's because of file size or something else. Will look into it for future updates. Sorry that it's come out so badly)
Some look and feel polish needed, but the introduction of a formal inventory system is now complete. I think I mentioned intentions for this in a past update.
Previously, to keep things sleek, we kept track of everything on an as-needed basis. Mission items, loot, so forth on the objectives screen, health pickups on the main HUD. It worked mechanically, but having everything exist in a wholly passive state felt very shallow and detached from gameplay. To solve this, we have a Dishonored-inspired radial menu.
Accompanying this, I’ve implemented a system for displaying previews of use-x-with-y type interactive items.
The new inventory system allowed for the implementation of containers. A small addition that makes the world a whole lot more interactive. Note the little visual assist of having draws staying open once they’ve been emptied - borrowed this from the new Prey.
The interface for reading documents has also been tightened up.
You’ll also see that different interactions display their own cross-hair overlay. This exists not only as an item of flare, but also to give the player advance differentiation between objects that they’re going to pick up (to throw, use as a distraction, etc) and objects that they’re going to collect (store in inventory, use in some way, etc). The player should be able to know what the character is thinking of doing!
No changes to CCTV cameras, but they’re as good a place as any for introducing the finished hacking system.
I went up close before throwing the brick because the current aiming system is pretty poor. All physics objects use the same throwing calculation. The calculation feels pretty good on bulky and heavy objects (dynamically scaling force based upon size), but it isn’t particularly suited for targeting projectiles (it’s mainly been configured for moving clutter around, from crates to shelves to boulders). Fixing this issue by currently working on a separate force profile for potential projectiles, as well as a gentle aim assist.
Manually taking down a camera is pretty noisy, and still requires you to get fairly close to it. So, as all immersive-sim type games are want to do, we have a hacking system to allow for stealthy disabling of cameras (and unlocking doors, permanently disabling alarm system, so on).
The hacking system is fairly minimal - wanted to avoid a tonally garish pipe mini game or anything too distracting, fiddly and frustrating. I also wanted to account for the level of technology in the setting - it’s assumed that computers are the size of small rooms, so any answers had to have a very analogue feel to them.
With that in mind, I settled on something loosely inspired by Phreaking. When you hack, you tap into a telephony switchboard, interchange or empty socket. Visualized and heard is a test tone - you have to match that tone with your own waveform for long enough to be granted access to the system.
Quite reductive, but I think that it’s adequate enough to do its job and avoid disrupting the tone & flow of the game. A bit of work needs doing to make the player wave-form more distinct from the system’s, but that’s about it I think.
Once access has been gained, you can then view and disable any available cameras.
One small (and needed) update has been to our base concrete shader. For bother larger and more generic objects, rather than expend a huge amount of graphics memory on bespoke texture assets, we’ve always used a blended texture. With this, we assign a colour to each vertex on a model, and the shader blends between different base textures. So, we can give large objects shadow, corner erosion and built up areas of dirt using only a small number of reusable textures.
Before, we just did a smooth blend. Acceptable for distant objects, but far less pleasing for anything up close. With the new shader I’ve made, we modulate the blend to get a far more aesthetically pleasing outcome.
I also took advantage of the new shader to add some performance optimizations. Normally, with this form of rendering, there would be numerous textures providing data - the basic image, an image describing the glossiness of the surface, an occlusion map to assist lighting/shading and a height map to provide the more natural blending. This would make for four separate textures per each of the three textures that we’re blending together - twelve in total. Somewhat heavy going! I realized that because all concrete surfaces in Tangiers are grey, we have a lot of unused colour information. A texture consists of red, green, blue and alpha (transparency) channels. For greyscale, we only need one colour channel, allowing us to embed the information on each texture within each of the spare channels. Thus, our twelve textures are now reduced back down to three. For higher quality, 2k textures, that crunches things down from 32.4mb to 8.1mb of graphics memory. 32.4mb isn’t a huge amount in isolation, but things add up quickly and keeping a tight grip here makes all the difference when it comes to lower-end machines. Really want to avoid the poor performance often found in Unity games.
Not too much to talk about with this one, other than that some new, modular assets have been created for old factory areas in various states of decay. Tend to avoid using modular within the level design workflow given how limiting it is, but for brick structures it serves as an ideal base to build upon.
A lot of other bits and pieces have been finished off and implemented. Improved memory and task management, the save/load system, editor tools for quickly placing hanging cables that sway in the wind (and guide the player to points of interest such as hacking terminals and fuse boxes), various permutations of the texture blend shader, a tile-set for residential crawlspaces and attics, new assets for residential hallways and a wealth of previously static props that are now handled by either the physics or inventory system.
Ending things with a very rough little work-in-progress.
I’ve had various permutations of a teleporting enemy for quite some time. Enemies that teleport towards you as a combat move, enemies that teleport away from you to get help and various assorted weirdness that never really worked.
The current (and probably final) version teleports from light to light on its patrol route, as well as when engaging in combat. The action is always clearly signalled by flickering and ghosting to give the player chance to respond, though situationally this often acts as a wildcard - an the appearance of an enemy, forcing the player to quickly improvise a response.
Because the enemy is only able to use the teleport ability to move between the brightest areas of lights, it acts as a “strong” variation of the basic bipedal foe - playing off the existing hazard of well lit areas (vs. the lazy route of just throwing more hit points or stronger awareness onto a “strong” variation).