Somerville
The Original Somerville Soundtrack - Out now on Steam!
https://store.steampowered.com/app/2698480/Somerville_Original_Soundtrack/
The Original Somerville soundtrack features 14 songs by the talented Matteo Cerquone and Dominique Charpentier, that you will have heard throughout your journey into the game.
~ Jumpship
https://store.steampowered.com/app/1671410/Somerville/
One Year of Somerville! đ
As a thank you for your support, Somerville is now a whopping 50% off on Steam until the 20th of November. It's the perfect time to join or revisit this captivating narrative-driven sci-fi adventure.
Furthermore, the soundtrack of Somerville, featuring 14 songs by the talented Matteo Cerquone and Dominique Charpentier, will hit all major music streaming platforms on the 17th of November, allowing you to listen to the melodies wherever you go.
Thank you for playing and please join us in celebrating the first anniversary of Somerville.
~ Jumpship
https://store.steampowered.com/app/1671410/Somerville/
Somerville - The first two audio tracks are OUT!
The first two Somerville tracks are available on Spotify!
Understanding (feat. Dominique Charpentier) Listen on Spotify
Intro (feat. Dominique Charpentier). Listen on Spotify
Somerville - Patch 4 & PlayStation News
Thank you for the continued support of Somerville and all of your recent reviews. We've been working hard over the last few months on fixing a few bugs and adding additional language support so that more of you around the world can experience Somerville in your native language.
We're very happy to now support a total of 24 different languages in our game! This update adds support for 11 additional languages!
- Arabic
- Turkish
- Russian
- Hungarian
- Czech
- Danish
- Dutch
- Finnish
- Norwegian
- Swedish
- Ukrainian
We also recognised that a lot of you were experiencing problems playing Somerville on foreign keyboards. We worked with a few very helpful people in the community to identify what was happening and have included a change in this patch that will allow all keyboards to work with our game.
Bug Fixes & Changes
- Fixed various audio issues
- Fixed and improved a number of issues with controller vibration
- Various foreign keyboard support changes & improvements
- Support for 11 additional languages (Thanks again for all of the love and support!All the best and stay healthy!)
In other news... Somerville is on Playstation 4 & 5
We are extremely happy to be releasing Somerville on PlayStation 4 & 5. It's got the same features and support the current Steam version has, and for those wondering, we've done a bit of work to make the Dual Sense controllers feel right on Playstation 5 too!
The Somerville Team
https://store.steampowered.com/app/1671410/Somerville/
Building Sediment Part 2: Visuals
We're back with part 2 of our technical breakdown of sediment, this time focusing on the visuals, you can find part 1 here: Building Sediment Part 1: Gameplay Systems
The look of sediment evolved radically over the course of development, while we had a wealth of concept art showing it in different forms, from creatures to ships, and many references giving inspiration for its different states, we didn't have exact key art we needed to recreate. Part of this was due to not knowing what was even possible for such a dynamic material in a real-time game environment, and part was intentional, to allow any interesting ideas from experimenting with rendering techniques to bring about something new and exciting.
Ultimately we wanted sediment to have a fractured surface, that when broken down, revealed a detailed structure of aligned rods, the patterns and structures echoing long forgotten architecture from the Monolithâs early planet based civilisation.
Our experiments ranged from instancing geometry over surfaces, generating meshes and applying subdivision effects at runtime, real-time constructive solid geometry, ray marching, and finally the instancing approach shown here.
There are many layers to the effect, but the core geometry is created by instancing pre-fractured meshes inside the fill area, then scaling and warping their fracture pieces to conform to the shape and add surface detail.
Following are the steps we take to renderâŚ
[table noborder="1" equalcells="1"]
[tr]
[td]
Copy voxel fill data from the CPU array to a 3D texture
[/td]
[td]
Extrapolate border voxels to improve accuracy of the next step
[/td]
[td]
Create a signed distance field (SDF) representing the fill boundary
[/td]
[/tr]
[tr]
[td]
Instance meshes in filled areas, using pre-fractured meshes near the fill boundary
[/td]
[td]
Hide pieces that are in empty areas, and warp them conform to the SDF
[/td]
[td]
Rotate pieces to create a fractured surface, and adjust colour near the melted area
[/td]
[/tr]
[/table]
Generating an SDF
Debug view of a partially melted sediment chunk, showing the signed distance field contoursFrom the voxel data, we get an implicit surface where fill values of 1 are inside, 0 are outside, and 0.5 can be considered on the boundary. We tried generating geometry that matched this surface, however the blocky nature of the data created a lot of artefacts as a chunk melted and the boundary moved, particularly noticeable when we had a low-resolution voxel grid combined with more detailed geometry. This was quite a common scenario as we wanted to keep the two decoupled, so we could balance CPU and GPU resources, and adjust the visuals without breaking carefully tuned gameplay.
Signed distance fields (SDFs) are anything that tell you how far a given position is from the surface of some geometry, positive if you are outside the geometry, negative if you are inside. By processing our fill values and turning them into an accurate SDF, we were able to smooth out discontinuities in the data, and unlock a lot of useful techniques.
For runtime speed, we initially tried using the MIPs of the voxel fill 3D texture as an approximate SDF, but picking a high LOD means you lose detail close to the boundary, and a low LOD doesnât tell you anything far from the boundary. There is probably a solution based on blending LODs, but we didnât pursue this.
We considered the popular jump flood algorithm (JFA), which can extract an accurate SDF after a few iterations, but itâs not very practical for our use case. Weâre working with 3D textures, so weâd need a 3-channel texture; we want inside and outside distances so weâd need to run it twice; and the resolution of our data would require running the algorithm for many iterations per-frame.
After exploring these, we settled on a simpler flood-fill approach. Melting is quite slow, so the SDF does not need to change drastically from frame to frame, allowing us to reuse data from previous frames and update at a slower rate. We focus our effort on making sure the boundary responds quickly to the player, and update areas further away a few frames later.
This worked out much cheaper than JFA in both computation and memory cost, requiring only a single channel texture to work, we had enough accuracy in 16 bits to encode a distance of 8 metres. Ultimately we ended up generating 4 separate SDFs for various effects in parallel using the 4 channels of an RGBA texture.
Hereâs some example code in 2D, the game does the same but in 3D https://www.shadertoy.com/view/NslfWs
Using the same texture size as our CPU voxel data creates some problems at the edges. Our fill data is representative of voxel centres, however our actual geometry needs to fill the entire voxel, corner to corner. For voxels inside the volume, we can get values for corners by interpolating between the centre values of neighbouring voxels, this is done for us by the hardwareâs bilinear texture filtering. For voxels on the edge of the volume, outer corners have no neighbours to interpolate, so the value is clamped, resulting in an inaccurate SDF at the volume edges. We fix this by adding a border of voxels around the original volume and extrapolating their fill values before calculating the SDF.
Placing instances
[table noborder="1" equalcells="1"]
[tr]
[td]
Pre-fractured instance meshes[/td]
[td]
A chunk with the corner melted, just showing instance placement, more detailed meshes are placed near the melted area[/td]
[/tr]
[/table]
We want fill the volume with mesh instances, with a few constraints:
- High-poly meshes with extra fracturing are placed near the fill area boundary
- Low-poly meshes are placed inside the fill area
- We donât place meshes outside the fill area
This step is done in compute, which writes out lists of transforms to buffers used by the instanced draw call later.
Transforming mesh pieces
[table noborder="1" equalcells="1"]
[tr]
[td]
Transformed mesh pieces during melting[/td][td]
Transformed mesh pieces while at rest[/td][/tr]
[/table]
Each pre-fractured piece of the mesh needs to be transformed to alter the surface appearance:
- Scaling and rotating at random to add roughness and fissure lines
- Shrinking pieces on the melt boundary, so they appear to erode
- Hiding pieces outside the boundary
- Twisting pieces near the melt boundary, so the chunk appears to break apart
Initially this was calculated in the vertex stage, which made iteration quick, but became a performance bottleneck. Moving the work to compute, so it could be done per-piece instead of per-vertex, reduced the load by 48x (each piece has 24 vertices, and Unity runs the vertex stage twice when you have a depth prepass enabled). This also allows us to only run this stage while the chunk is being melted, and persist the results for later frames when itâs static.
Smoothing
Applying simple scaling and rotation to the mesh pieces leaves us with a blocky appearance, which we used for quite some time, until the art team started asking how to create curved chunks...
Calculating the gradient of the SDF (the direction to the boundary) gives us a useful tool to achieve this. Given a vertex position, we can look up the direction and distance to the boundary, then move our vertex to that closest point on the boundary. Doing this for all vertices outside the boundary makes the geometry match the SDF. The normal of the triangle surface still represents the old position so shading will still have hard edges, but this is easily fixed by replacing the surface normal with the SDF gradient.
When melting, there's a lot of interesting animation detail that we wanted to preserve, however it was slightly too noisy, and we need the surface to appear as if itâs liquefying. We blend just a little of the SDF gradient into the surface normal to smooth it out, and combine with some sinusoidal vertex motion:
[table noborder="1" equalcells="1"]
[tr]
[td]
Melting state, before pixel smoothing[/td][td]
Melting state, after pixel smoothing[/td][/tr]
[/table]
When at rest, the sediment heals into a smooth hard surface with a few jagged pieces poking out, indicating that it's been disturbed. This is done by randomly selecting a few pieces to remain untouched, and repositioning vertices and replacing vertex normals of the rest:
[table noborder="1" equalcells="1"]
[tr]
[td]
Rest state, before vertex smoothing[/td][td]
Rest state, after vertex smoothing[/td][/tr]
[/table]
Surface shading
Fissure glow
Sediment has an inner glow that seeps out through fissures in the surface. We mask out fissures by comparing the vertex normal with the SDF gradient; wherever they are perpendicular, we add some emission to the surface:
[table noborder="1" equalcells="1"]
[tr]
[td]
[/td][td]
[/td][/tr]
[/table]
Bevels
To help pick out detail in the surface from glancing light, we add a slight bevel to fissured areas. The thickness of the bevel is adjusted depending on how fractured or melted a mesh piece is, so the normal is calculated in shader, rather than using a normal map.
Itâs quite a simple function, taking the face uv, the size of the face, and the bevel thickness we desire https://www.shadertoy.com/view/7ttGWS
[table noborder="1" equalcells="1"]
[tr]
[td]
Without bevels[/td][td]
With bevels[/td][/tr]
[/table]
Instancing and batching
We use instancing to improve the performance of drawing many individual meshes that make up a chunk, but sometimes we have many separate chunks. Separate chunks do not share GPU resources, they use their own data textures and buffers, so they cannot be easily instanced and require separate draw calls. The CPU cost of doing these draw calls really adds up.
To fix this, we bake out static versions of the geometry that don't use any of the dynamic textures or buffers, allowing Unityâs SRP batcher to combine them into optimised draw calls. These static meshes are swapped with the dynamic system whenever the camera gets close enough, or if the player starts interacting with the chunk.
Baking is done in compute at edit time, which generates triangles by taking the instancing and mesh data, and running the same vertex stage transformations against them.
Reality melting
A fairly late addition to the system was the reality melting effect seen in the last few levels. This uses the SDF to blend between a static environment mesh (using alpha testing), and a sediment chunk thatâs sculpted to match the geometry.
Building Sediment Part 1: Gameplay Systems
Hello again,
Following our case study on Somerville's art, we now have a technical breakdown of sediment by our programmer Jay Steen and graphics programmer Thomas Hooper. It's a long and detailed update, so we are publishing it in two parts. The following is part 1 - we hope you enjoy it!
First a quick demonstration; in the game, Earth is invaded by an alien entity known as the Monolith, who embody a strange malleable material we call sediment, deposits of which are left scattered in the environment. Our protagonist gains the ability to control these sediment deposits:
- Melting: by combining your blue power with a light source, you can melt a deposit
- Regrowing: some will regrow back into their original shape
- Solidifying: using your red power, you can create a burst that freezes this regrowth
There are many of these sediment deposits throughout the game, for which we built tools to design and sculpt:
- Simple bounding boxes are placed
- These are sculpted using sphere and box shapes (constructive solid geometry)
- Detail is added to the surface by fracturing the chunks, using the same sculpting tools
Development process
Before diving into the details of how this all works, a few notes on the development process.
There were a lot of expectations for sediment, we knew it was going to be a core part of the gameplay and world, but werenât entirely sure how we wanted it to work or look, so we started with basic functionality and visuals, tried them in-game, and evolved them to fit whatever new requirements fell out. Following are a few parts of the process that worked well:
Building it twice
Initially we wanted two distinct forms of environmental sediment, dead and discarded sediment chunks, and an alive ground-covering sediment web. We built the sediment web first, which shared a lot of functionality with sediment chunks, but was much simpler by virtue of being height-map based, instead of fully volumetric 3D. This version didn't get used in the final game, but gave us a great foundation to work from for chunks, it's always easier to build something the second time!
Parallel development
There were two distinct streams to development, the gameplay systems, and the visuals. These progressed at different rates so we needed to be careful to not break one when updating the other, but also needed the freedom to radically change each part as needs arose. Thankfully, after building the sediment web, we knew that we'd take a voxel based approach for the gameplay systems, and that storing this data in a 3D texture would work well for the rendering technique we had planned. This voxel data structure, and the code that managed it, acted as a contract between the separate systems and was built collaboratively. This, combined with code review and regular testing, meant we rarely introduced new bugs in each system.
How it works
- Artists place volumes of sediment in the level, and sculpt them with box and sphere primitives, we call these volumes 'chunks'.
- The core structure is a 3D grid of nodes containing a fill value; when the player shines light on the chunk, nodes near the surface have their fill amount reduced, exposing more nodes behind.
- A signed distance field (SDF) representing the boundary to the filled area is calculated, and used for rendering.
- To render, the volume is filled with a grid of instanced meshes, which are then deformed to match the SDF.
Gameplay implementation
Melting with Light
The gameplay our designers wanted from sediment was highly varied and specific to each scene. This led us to explore many different options for implementation. We tried using skinned meshes with custom deformations for each situation, but we couldnât make this system flexible enough and we realised it would take too much of our artistsâ time to be viable. We also had a requirement to be able to melt sediment from any angle and have it respond to the type of light hitting it, ie. spotlight or point light. With this in mind, we decided a voxel approach was the best to take.
Each voxel traces paths from their nearest faces to the lightWe started by defining a grid with fixed-size voxels, each having a fill value that can be depleted by light. To respond to light, each voxel traces a ray to the light source when a light is cast on that sediment chunk. If this ray intersects with another voxel that has fill, no melting takes place and the ray tracing stops. The algorithm is based on http://www.cse.yorku.ca/~amana/research/grid.pdf If the ray can trace a path to the light, a small amount of fill is removed. This process is repeated every game frame that a light is cast on the sediment, which is very CPU intensive for anything other than small sediment chunks with low grid resolutions. For this reason, we selected Burst and Unityâs Job system to carry the brunt of the work.
The Job system allowed us to make use of multiple CPU cores and parallel processing, giving us a minimum of a 4x performance increase on our low-end target hardware. It also allowed us to schedule work from the Update() callback, and give it time to process asynchronously until LateUpdate(), where we could access the results on the main thread and feed them back to the rest of the game.
Burst is a Unity technology that compiles a subset of C# into assembly language for the target hardware. It allowed us to write our voxel traversal and other sediment gameplay logic in a high-level language while achieving assembly language performance, which made the whole feature possible! In some tests, large complex arrangements of chunks that were used in game scenes were 100 times faster when compiled with Burst than when using regular C#.
Interaction with the Character
As well as being melted by light, the sediment had to behave as if it were a solid object in the world. This meant the player character could not clip through it, and other interactable objects had to bounce off it and be frozen into it. To achieve this, it was necessary to generate physics colliders for sediment, and update them dynamically when the player interacts by melting. We also wanted to be able to script other gameplay based on melting, such as releasing an object that started out frozen into the sediment. This required us to create a querying system.
Generating Collision
We identified two choices when generating collision - using a grid of pre-existing Unity colliders, or script dynamic collision behaviour for anything that touches sediment. Unity is very flexible when it comes to scripting physics, but it does not as of version 2020.3 allow any custom shapes or access to the collision solver. This would make it difficult to achieve parity with built-in physics behaviour, and we wanted our solution to âjust workâ without having to add components to things we wanted to collide with sediment. For this reason, we chose to generate a grid of colliders.
Box colliders were selected as they are the closest analog to the voxel grid and provide the best fit with the least wasted empty collision. We preferred overfill to underfill as it is better for objects to float slightly over the surface of the sediment than to clip into it. Due to the sheer number of voxels, it was necessary to have fewer box colliders than voxels - anything more than 1024 colliders in a single hierarchy provided unacceptable CPU performance.
To minimise the number of active colliders required, we used an octree data structure to approximate areas of fill and proxy them with a box collider. If all the voxels within a branch of 8 were totally full, it could be proxied with a single box collider, otherwise it would be replaced with 8 and the logic would recurse over each box until a maximum recursion depth was reached. The depth could be specified by designers, so some sediment chunks could have more detail than others, where needed.
Fill Querying
A query volume system was needed to script gameplay based on the sediment system that would give designers the ability to detect how much sediment there is within a given volume, and get notified when it updates. For example, in the opening home scene after the protagonist wakes up, the bookcase cannot be pulled over until the sediment around it has been melted.
In this situation, a sediment query volume is authored around the bookcase. This query volume implements an interface that submits a recurring query request to the sediment system. The sediment system then detects the sediment chunks that overlap the query volume, and submits the query to those chunksâ burst job update chain for processing. Within the burst job chain, the number of filled voxels within the query shape is evaluated for that chunk. When all chunks have finished processing, the results are aggregated for each query and the query volume is notified. This then plugs into other gameplay logic systems to enable and disable objects, change available interactions, notify AI actors, or any other actions available to designers in the gameplay logic system.
Visual Effects Triggering
Visual Effects (VFX) were needed to ground sediment in the world, aid in achieving the artistic vision and give feedback to the player when they are melting or freezing a chunk. To trigger particles, we make use of Particle System Jobs - a Unity interface that allows high performance particle system control on the CPU. These can be chained with regular jobs, allowing us to slot them seamlessly into sedimentâs architecture.
Melting particles require a notification to be generated whenever voxel fill changes. During the chunkâs logical update, a parallel-writable list is populated with entries detailing voxel coordinates and fill change amounts for the voxels that have changed. This list is consumed by (among other things) the melting particle generator job. The generator job keeps track of how many particles should spawn over time for each voxel, then passes particle details to the ParticleSystemJob, generating particles when necessary.
Freeze bursts are triggered when any of the sediment is frozen (preventing its regrowth). A similar architecture is utilised - a list is generated on each frame where a freeze of voxels took place, and this is consumed by the effect jobs to spawn bursts of particles.
Emission rates are defined by the VFX artist to control this behaviour, which are applied per unit volume of voxels to ensure an even emission regardless of the chunk size or density.
Audio Feedback
We wanted to be able to provide directional melting audio feedback that responded to the amount of sediment being melted, sounding like a trickle when only small amounts are being melted and a gooey ooze when larger chunks are melted. The same list that was used to generate melting visual effects was used to achieve this for audio. These fill changes are used to generate a point cloud that is submitted to the audio middleware as a group of playback positions, giving directionality to the sound. The change amounts are totalled and this is sent through as a parameter for the melt sound, allowing sound designers to interpolate playback between smaller and larger-feeling sounds.
Light Occlusion
Chunks do internal occlusion of light when the melting update occurs, however we also need to occlude melt light using other things in the world, to prevent sediment from being meltable through walls, etc. To achieve this, each chunk generates a list of rays from each of its voxels to each of the lights being cast on it. These rays are then submitted to a RaycastBatchJob which executes each frame before the chunkâs melting update. The results of each raycast are used to inform whether a melt operation can take place, and is also used to optimise the update - if a ray is occluded, there is no need to perform the update calculations. Executing these raycasts asynchronously is the only way this feature is possible from a CPU performance perspective, as it often requires hundreds of raycasts a frame.
Editing Experience
From the start of development, we wanted this system to support WYSIWYG editing and rapid iteration. To make this possible, we defined a set of editor handles that could be used to edit the size, shape, scale and density of sediment chunks. Each time a designer interacts with these handles, the chunk is regenerated from scratch. This required the same jobs we use to build the chunk at runtime to be used during editing, so there is not much distinction between what happens during edit mode and play mode. It required a lot of up-front architectural decisions and early optimisation, but it paid off to make sediment a very flexible and easy to iterate system.
Patch 3
Thank you for all of the recent reviews and your continued support of Somerville, it means a lot.
We acknowledge that the âno ropeâ bug that some of you have experienced early on in the Forest level is really annoying and has prevented you from progressing to the end of the game. Weâve been working on finding the cause and weâre pleased to finally release this patch with a fix for it.
Weâd like to thank the community for getting in touch and assisting us with more info and testing various theories while we figured it out.
We hope that those who experienced this bug will come back and give Somerville another go.
Bugs:
- Fixes missing rope issue in the well puzzle early on in the game
Thanks again for all of the love and support!
All the best and stay healthy!
The Somerville Team
The English Countryside: A Case Study on Somerville's Art Side
Hey friends,
Since the release of Somerville, the dust has finally cleared a bit, and we'd like to take this opportunity to tell you more about the background and inspirations with some updates here on Steam. Let's start with the arts and the looks of Somerville.
One of the main goals for the Art team on Somerville was to capture the unique mood and textures of the English Countryside and together with the Design team translate those to a fitting stage for the story we wanted to have the players experience. We set out to achieve this, not so much through itâs most striking and well known features, but through staying true in the depiction of its more subtle qualities, characteristics and elements. To make it not so much recognisable and identifiable at a glance, but felt and experienced in its very particular way.
Below are some sample snapshots of the concept and visual direction process, that we hope will give an idea of where and how a lot of the final in-game visuals, the art team built, originated. This is by no means a complete process log and omits an enormous amount of exploration work or key pieces of concept art and world/story maps that might prove major spoilers to the experience.
Flight over Muddy Fields, a piece of concept art done in the run-up to one of our trailers, that helped solidify the final look, texture and patterns of the fields.
Inspiration & Reference
Lived Experience
Before becoming a mostly remote studio, Jumpship had its start in Guildford amidst the Surrey Hills. It was a natural choice to use that personal experience of the landscape and small town aesthetic elements to serve as a basis for creating a more immersive setting and experience. One that feels close and personal. Together with Guildford and its steeply climbing highstreet, architectural elements and pieces of layout from a few other nearby, small towns were used. Marlowâs bridge, highstreet and cathedral and Godalmingâs distinct church spires served as sources.
Artistic Influence & Inspiration
Early on and at several, progressively deepening, stages throughout the process of development we looked at a wide range of references and sources of inspiration, from life experience, photography and art - past and contemporary, but a few names we kept going back to: George Shaw, Jack Simckock and Maurice Wade. Artists that have perfectly captured the spirit and image of urban, rural and natural England in the present and not so distant past. Masters of minimal realism and graphic composition, often close to classic travel poster art, of subtle natural light and shade, of the understated, yet rich colour palette(Georgi Shaw), of textures abstracted to perfection to not over-explaining, but suggest just enough to create the perfect impression of materiality.
Concept Art & Visual Direction
Early Mood & Setting exploration
Invasion over the English Countryside by Ian McQue
Very early in the process of development on Somerville, alongside extensive world building and mapping of the story progression through the world, a series of concept illustrations and sketches were created by Ian McQue. Those mood pieces helped establish a high baseline for the stylistic direction and the right mix of visual elements, to create the perfect balance of stylisation and authentic realism for our English Countryside setting.
Story Maps, Beats & Speculative Location Thumbnails
The Forest was one of the first we extensively worked on and explored, as one of our early game areas that would establish a lot of the mood and natural setting tying many other locations together. It was planned as a quieter, slower and more gradual introduction to the gameâs mechanics as well and building up hints about main actors in the story and the eventâs that have been happening in the wider world, beyond the family home.
The protagonist and his four legged companion attempt to make their way toward the local town via the forest in the hope to pick up a trail that leads to the other half of their family. The alien craft above and their agents on the ground sweep the forest, collecting dormant sediment from downed allies. Craft debris from the failing defence efforts of human military organisations litter the forest.
Itâs roughly 4am in the morning. Mist and fog sits heavy among the trees, mixed with pockets of burning jet fuel. Thick overcast clouds loom, a storm is brewing. The Forest is an incremental climb to a hill top, where they emerge from the treeline for a moment to observe the devastation wrought, before descending back among the trees.
To capture some of the distinct character of the wooded hills, as well as the mystery and peril of the situation, the protagonist and companion find themselves in a familiar landscape, occupied by a strange presence on the ground and sky above.
We set our story in winter, to help enhance both the beauty, through lighting and simplicity of colour, and the discomfort of the situation, sending the characters on treks through muddy paths, stale ponds and piles of wet, rotten leaves.
Through a bleak landscape that still retains a lot of its harsh beauty in patches of evergreen grass and trees contrasted with the bare dead branches of seasonal ones, and the piles of decomposing leaves, giving the cold ambience a touch of vibrancy. Subte, but rich.
With a lot of this information defined early on, we had a pretty specific idea of where it sat in the storyline and the world and what mechanics/concepts/story elements we wanted to introduce. Based on that we explored a series of potential locations through value thumbnails that we later used to assemble a logical sequence that fit well our narrative and gameplay progression.
Speculative Forest story beats and locations by Georgi Simeonov, 2019
Location/Visual Beat sequence & elevation map by Chris Olsen, 2019
Mood Progression map by Gregor Strnad, 2019
Early Location Key Art
We used the Crossing of the train line as the literal, physical threshold to the Forest and into the unknown, mystery and danger, leaving normality behind. A space at the same familiar, common and evocative of our setting, but at the same time firmly associated with danger, a crossing our protagonist would not have undertaken, if not under the current dire circumstances.
This image served not only as a baseline reference for the gameâs visual style, colour palette and mood, but also to test and demonstrate the fine balance between realism and stylisation.
Crossing the Line, location key art by Georgi Simeonov, 2019
Hill Hiking at Dawn, early mood/style exploration by Georgi Simeonov, 2019
Hilltop, final concept overpaint by Georgi Simeonov, Gregor Strnad & Environment art Team, 2022
Landscape & Vegetation
The use of modular assets allowed the artists to create diverse and detailed environments, as they can be assembled and reassembled in various combinations to create unique clusters and compositions to fit each location. The advantage of modular assets is that they can be used across multiple levels and scenes, reducing the need for individual asset creation, whilst ensuring consistency in the quality and style. Those are also highly customisable allowing for easy and quick adjustment of tint and scale once theyâre placed in an environment.
Landscape Modules, a reusable modular kit
Tree Silhouette Stylisation at various distances
Tree & Shrub stylisation & graphical treatment in 3D
And that's it for Somerville's art side of things. We hope you enjoyed this little peek behind the curtain of Somerville's development. There is more to come, so see you in a bit.
All the best and stay healthy!
The Somerville Team
https://store.steampowered.com/app/1671410/Somerville/
Patch 2
Bugs:
Fixes various player character getting stuck and falling out of the world bugs
Fixes worse offending character animation pops and glitches
Fixes some localisation string bugs
Fixes many other smaller visual bugs and flaws
Improvements:
Tweaks to radius and angle parameters to improve various interaction reliability
Improved environment collision throughout the game to fix and improve snagging and unnatural movement
Adjusting lighting across the game to improve readability of the player path and interactions
Improved visual consistency of interactable objects and removed/subdued non-interactable ones that looked misleading across the game to improve interaction readability
Continued performance improvements
New Feature:
Petting the dog at key moments when the dog is standing or sat still
Weâre ensuring the team gets some well deserved rest over the coming holidays. We'll be back in the New Year to continue our support of Somerville.
Patch 1
Performance:
Adds additional options to allow finer control of optimisations
Improves performance on both high and low end systems
Fixes bug preventing low quality graphics setting from working
Fixes most stalls that were occurring on low end systems
Other:
Adds full screen option
Fixes various vibration controller issues
Fixes various conditional gameplay blockers
Various quality of life and play-experience improvements
Weâre moving onto Patch 02 next.