1/8 Rewrote our camera system last week, from a basic FSM to a stack of behaviour layers with blend weights. I don't know if there's a name for this design pattern, but I've been using it a lot lately, so here's a description: #gamedev#indiedev
2/8 Suppose you have a set of values that can be produced by different behaviours. Usually only one behaviour is dominant, but you want behaviours to transition smoothly and some behaviours should be able to offset the values rather than overwrite them.
3/8 Example: Our camera is mostly player-controlled, but we want to smoothly transition to cut scenes, & screenshakes or skill aim offsets should work on top of the general logic. Other ex: rumble intensity, global time scale (if you have slowdown mechanics), post-processing.
4/8 The way I like to solve this is with a stack/list of behaviours, with associated blend weights and blend modes (normal blend vs. additive). Think of these like Photoshop layers. Each layer can be a self-contained FSM, but could just as well be a basic "state".
5/8 When the stack is evaluated, it blends every layer with the result of the layers below to produce the final output (in the case of our camera, a position and quaternion). The system has base classes for layers that can fade in/out and come with a sort order.
6/8 This lets us do a few cool things: We don't have to process behaviours (or can auto-remove them), if a layer above has 100% "opacity". I can tell the player-controlled layer at the bottom to align itself to the result of the stack, when transitioning out of a cut scene.
7/8 The camera controller also does collision detection after all layers with a sort order <0 have been evaluated. This means cut scene behaviours automatically don't have camera/terrain collisions, whereas user-controlled camera behaviours do.
8/8 But most of all, this makes adding new behaviours a breeze. E.g. a behaviour that makes the camera stand still and follow the player - it's added/removed when the player enters/exits a trigger & fades weights in/out on enter/exit -> smooth transitions to/from player control.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/18 Here’s our second tech art thread on the stylized rendering of “Dungeons of #Hinterberg”. This time, I’ll talk about how we do our outlines!
If an indie mix of Zelda-like/ARPG and Persona-style social sim is your jam, follow us at @MicrobirdGames. #gamedev#indiedev
2/18 Main point of the first thread: we use deferred rendering with a custom gbuffer that stores material IDs, to essentially create a second material system that runs on the GPU. The full thread is here:
3/18 Our main goals for outlines were: resolution independence, good results with minimum tweaking & artistic control. Our material system helps a lot with the latter two, offering control over outline types, colors, width, & a handful of tweak factors that we hardly need to use.
1/x Over the next weeks, I want to post a few threads about the stylized rendering we’ve implemented for our game “Dungeons of #Hinterberg”. I’ll start with an overview, but I'll get pretty technical. Follow @MicrobirdGames, if you think the game looks rad! :) #gamedev#indiedev
2/x #Hinterberg is #MadeWithUnity. We use a completely custom deferred solution, based on the built-in render pipeline. Our standard shader mimics Unity's, but was built from scratch, as were the lighting pass shaders. @catlikecoding's tutorials were an invaluable resource here.
3/x The main secret ingredient is that we store collections of various material properties in a StructuredBuffer on the GPU, and let deferred shaders write their material IDs (i.e. their index into the StructuredBuffer) into the gbuffer.