next »

[amasinton]

Let’s talk about rocks
I’ve spent my dev time over the past few weeks (how has it taken so long?) teaching myself how to create rocks.  From the beginning I’ve had a scene in my mind of a hermitage clinging to the cliff face of the island.  It all seemed so simple.

Turns out, rocks are hard (I’m allowed puns, I’m a dad).

Reference
Geology is important for my island.  I want geology which emphasizes verticality through strong layering and jointing – like the Oregon coast or the slate islands of the Skelligs.  But I want to avoid the polyhedral basalt columnar jointing of places like the Giant’s Causeway.

Cannon Beach, Oregon (image: Tjflex2)

Skellig Michael, Ireland (image: chb1848)

Giant’s Causeway, Northern Ireland (image: Shawn Harquail)

I deeply respect the art style of The Witness, forged by Luis Antonio (http://www.artofluis.com), Eric Anderson (http://www.edoublea.com), Orsi Spanyol (http://www.orsispanyol.com), and Jonathan Blow.  It’s impressionistic, but not in the sense that it is blurry or ill-defined.  Very much the opposite.  The rendering is crystal-clear, dazzling in the eternal daylight of the game, every detail sharp and defined.  In Impressionist paintings individual brush strokes speak volumes, describing not surfaces but how light falls on surfaces in fleeting instants.  In The Witness the brush strokes are individual polygons.  There are very few textures.  It’s breathtaking.  And also, really, really hard to do well.

Symmetry Island, The Witness (image: Screenshot, author’s pc, taken 30 April 2019)

I have been avoiding rocks because I’ve never done them before.  I can model architecture and most manmade things.  But natural things - not so much.  That’s part of the fun of developing this game, picking up new skills.  Also, like many 3d artists, I’m more comfortable with fine detail and realism than impressionism.  So, rocks a la The Witness.

Learning
Luis Antonio discussed rock and process (http://www.artofluis.com/3d-work/the-art-of-the-witness/soon-symmetry-island-and-glass-factory/ - scroll down to the ‘Cliff Path’ section).  And Eric Anderson wrote in-depth about his process ‘finding’ the rocks in The Witness (http://www.edoublea.com/2016/01/20/on-the-rocks/).  Both artists began with hi-res sculpts and then decimated down to low-poly.  Anderson posted a render of his practice model, so, that’s where I started, copying him.  His work:

Rock face by Eric Anderson (image: Eric Anderson)

My work (two attempts, hi-res on the left, low-res on the right):

Okay?

I have Zbrush and like it (that interface, tho) but I wanted to challenge myself to use modelling tools I have available and useabale on-the-go, without my drawing tablet.  I use Cinema4D for most of my normal modelling, and it has (okay) sculpting tools.  I did the test blocks above with it and moved on to individual boulders:

(Base model, Sculpted, Decimated)

The models seemed too visually “noisy”, though – something which The Witness team talk a lot about in their own work.  I really wanted something more “railway poster”.  And then I stumbled across Polybox’s “Stylized Cliffs” on the Unity Asset Store.  The effect is closer to what I am looking for – less noisy, simpler, and, maybe, possible to do without sculpting.  And I like the way they layer up when grouped together at different scales.

“Stylized Cliffs” by Polybox. (Image: Polybox)

So, I gave it a try myself:

(God bless C4D’s Voronoi Fracture object!  The game’s art wouldn’t be possible without it.  I use it heavily in the buildings, too.)

So, I had something of a starter-set for cliff-building.  Now, to build that lonely hermitage.

The Hermitage
I based the hermitage on two medieval cliff hermitages I know personally: Knaresborough and Cratcliffe Tor.  They’re very different, but they kind of go together in my mind because they feature a rock-cut chapel and evidence for associated structures.  My imagination has always been engaged by these places, so I thought I’d blend them and add a dash of the Greek cliff-hermitage tradition for fun.  Easy, right?

Our Lady of the Crag, Knaresborough (Image: deadmanjones)

Crucifix, Cratcliffe Tor, Derbyshire, England (Image: Chris Morriss{/url])

Kepina Monastery, Greece (Image: peppi9)

So, I began assembling cliff faces with hollows for hermits:

Three tries…

Even these tests are too noisy in some places.  And the hollows don’t feel right.  I threw away many attempts. 

What I was lacking was a story for the hermitage.  None of the cliff faces I built leant themselves to narrative.  Eventually, by pushing around various vague house-shapes I discovered a story – or the remains of one – enough to move forward.

Grayboxing

So, this is where I’m at right now.

Ta-da!

I’m still not happy with it (that bridge – it looks like it came from a willow ware teacup!).  But, I do feel a little more confident about rocks and cliffs – which was the point.  And, I do need a cliff face to test out camera clipping and movement constraints on vertical surfaces, so this will have to do until more of the story reveals itself.

Or, until I realize that ‘good enough’ is okay and move on.  There’s an island to build and many more stories to discover.

[amasinton]

And here's an Andy Warhol take on that hermitage and those cliffs in-engine at four times of day.  Just for fun.

Happy Friday!

[JobLeonard]

Nice! I like the comparison collage - do a timelapse gif of light changes during the day next! :p

[ChrisLSound]

Awesome! The end result has a great feel to it.

[amasinton]

Nice! I like the comparison collage - do a timelapse gif of light changes during the day next! :p

Thank you!

I think I've designed look for the game which makes it un-GIF-able (yikes!) because of the heavy reliance on smooth gradient backgrounds.  I do have a time-lapse video on Youtube (and even that is compressed enough to make the banding obvious).  It's here, if you're interested:



Any ideas on how to embed an actual video on the forums here?  BBCode does have a Youtube tag, but it doesn't seem implemented here...

[JobLeonard]

It auto-embeds youtube links. Even if it is inside of a url-tag, annoyingly enough.

But that means you don't have to do anything, it's already embedded!

Looks great, even with the banding!

[amasinton]

Let’s talk about time travel – part 1
The project is getting close to what I hear is that inevitable but terrible time in a dev’s journey in which they experience a strong desire to throw away all of the code and start again.  They know what the game is trying to achieve now – mostly.  They know how the game is going to achieve it – mostly.  They are certain that they could write everything far more efficiently and in an easier-to-understand way – mostly.

I know the devil is in the ‘mostly’, so I’m giving in to temptation only a little.  I am on a journey to master one of the game’s more problematic systems: time travel.

Easy.

Here it is:

I’m making graphs again.  (Click the image for a larger, legible version.)

This is still a rough system.  I don’t think the final version will be so redundantly baroque.  But, boy, has this helped clarify my thinking!  There are a lot of interlocking bits of script in the codebase now, a lot of spaghetti, but much of it has to grapple with the time travel system, and making this graph has been a good way of mapping out how they are going to have to do it.  (I don’t expect the graph to mean anything to anyone but myself.)

Time travel mechanics
Time travel, in this game, is tethered to two ends of a wormhole (I read a theoretical physics book of some sort about it once).  The player can switch between ends at any point.  The dates of each end are determined by the artifacts the player finds while they rebuild the ruins on the island.  It’s visually interesting to toggle between two points in time, to observe the changes.  (A lot of games do this sort of thing – Dishonored 2 does it particularly well, for example.). In this game, there is a kind of ‘conservation of matter’ rule which means that your inventory of artifacts will change every time you time travel, because objects cannot be duplicated (you can’t collect a coin in one time, then go back to an earlier point in the coin’s history and collect that version of it too).  The changing inventory means your time travel options will vary every time you jump to a new end of the wormhole.  This offers the potential for interesting navigation through the game as there is the chance that, for a while, at least, you can become ‘lost’ in time – or you will have to go hunt down the location of an earlier version of an artifact you lost in the jump (thereby encouraging you to continue to explore and rebuild).

So, in terms of the game code, it means that EVERY object that exists in the scene must have a lifespan.  Every object.  From rocks to ruins.  Even the topsoil and the dirt beneath it.  Every object.  (I hadn’t quite appreciated that fact back when I began working on this.). Some objects evolve over time, so they must also have a set of time-specific alternate states.  And some of these objects must allow the user to influence which group of alternate states will exist and which will never be realized.  I got into a muddle fairly quickly.

But I think, doing the above graph, my thoughts on exactly how I’ll pull this off are much clearer, and so, I’m rewriting my codebase.  But just this portion of it.  Giving into temptation one method call at a time…

[ChrisLSound]

This all sounds so interesting!

How do the artifacts affect the dates of the wormhole? Is it something like (earliest possible date from any artifact) - (latest possible date from any artifact), or is it possibly something more dynamic?

Regarding the 'conservation of matter' rule: Is there some predictable behavior with what will disappear from/remain in your inventory? It has lots of potential for interesting puzzles and exploration incentive, but I suspect it could be frustrating to the player without some level of predictability.

[nova++]

The project is getting close to what I hear is that inevitable but terrible time in a dev’s journey in which they experience a strong desire to throw away all of the code and start again.  They know what the game is trying to achieve now – mostly.  They know how the game is going to achieve it – mostly.  They are certain that they could write everything far more efficiently and in an easier-to-understand way – mostly.

This might be an unwise thing to say, but I have had quite good results from the "build initial implementation -> refine requirements -> rebuild to fit requirements better" sequence, so I wouldn't be toooooo afraid of it.

[JobLeonard]

Yeah, just don't hyperfocus on one bit of polish - that's where the biggest loss ends up coming from once you kill your darlings again in the future

[amasinton]

Let’s talk about time travel (Part 2)
The first post is here.

The player can jump between two ends of a wormhole using the dates of the artifacts they discover.  How does this work in the game (at least, at this stage of development)?

Artifacts have a start date and an end date.  The artifact start date sets the time at one end of the wormhole.  The player’s current date – whenever they are in the game’s timespan – sets the time at the other end.  Let’s say the player is currently exploring the year 1345 and they discover an Abbasid dirham from 890.  The player can now jump to the year 890.  When in 890 they can jump back to 1345, the place they started.  In fact, they can toggle between the two ends of the wormhole as often as they like, since both ends are now set at specific dates.  While in 890 they find a Roman ring with a start date of 275.  Now, they have a choice.  They can jump to 275, but lose access to 1345 (the ‘chained’ strategy).

Or, assuming the Roman ring did not exist by 1345, they can jump back to 1345 and then to 275, but risk losing access to 890 (the ‘hub and spokes’ strategy).

The player risks losing access to one of the dates at the ends of the wormhole.  This is because there is a ‘conservation of matter’ mechanic where artifacts in the player’s inventory can’t travel to times in which they already exist.  Also, the act of setting a new date for one end of the wormhole always destroys the artifact used to set that date.

The game’s inventory system will indicate to the player the artifact’s lifespan so players will know what artifacts they would lose with each jump.  And, I’m thinking, there should be a ‘caching’ feature which will allow the player to store artifacts at their current date before they jump, thereby allowing the player to eventually create a series of bookmarks throughout time.

So, referring to our previous example, in 1345 the player found a dirham from 890.  In fact, it was part of a small hoard of dirhams, all from about the same time.  The player only added one of the dirhams to their active inventory, and cached the others from the hoard in 1345.  The player then used their one dirham to travel to 890, thereby destroying that dirham.  When in 890, they found the Roman ring from 275.  The inventory indicates that that ring no longer existed by 1345, so it’s safe to take back there (and no inventory item is burned in the jump, because that end of the wormhole is already set).  Now, in 1345, the player could take another dirham from the hoard and then jump to 275, using the ring.  The dirham would remain in their active inventory because it did not exist until 890.  So, now in 275, the player has the option of traveling back to 1345, or to 890.  If they travel to 890, they will lose access to 1345, but retain access to 275.  If they jump from 275 back to 1345, they will lose their dirham, but can draw another from the hoard in 1345.

My head hurts, how about yours?

Nevertheless, I think this ‘conservation of matter’ approach has the potential to offer the player multiple paths through the game’s timespan, but with checks that will encourage the player to explore each period thoroughly.

But I also think it has the potential to all go horribly wrong, or worse, to simply be a grind.  (Worse yet, it’s a darling I have to kill.)

So, more thinking required!

Here’s a pretty picture of the portal in the game.

[amasinton]

This might be an unwise thing to say, but I have had quite good results from the "build initial implementation -> refine requirements -> rebuild to fit requirements better" sequence, so I wouldn't be toooooo afraid of it.

That's what I've been thinking.  The whole codebase could use a good clear-out and so could my thinking!  But, of course, it should be tempered with this:

Yeah, just don't hyperfocus on one bit of polish - that's where the biggest loss ends up coming from once you kill your darlings again in the future

I really do tend to get focused on the details and my darlings and, you're absolutely right, I do have to kill some of them later (probably should kill all of them).  This week, in addition to working on the time travel code and logic, I figured out how to scatter daisies in the grass and put stars in the sky in the game world.  Procrastination maybe?

And ...

This all sounds so interesting!

Thanks - and I hope it plays interesting, too!  And hopefully the above post answered some of your questions about the mechanics of how this works in-game.

[JobLeonard]

I would try to stick to rough-but-functional prototypes and write down ideas for polish for each, and try to integrate the prototypes so you get a more "holistic" feeling for the game

[amasinton]

I would try to stick to rough-but-functional prototypes and write down ideas for polish for each, and try to integrate the prototypes so you get a more "holistic" feeling for the game

Sterling advice!  You're so right.  I get easily distracted - I see the game visually far more than I understand the game systemically, so prototyping tends to go off on flights of visual fancy.  But I am starting to see the game holistically and that's very encouraging.

On flights of visual fancy, see the long post below...

[amasinton]

Procrastination #1: The Heavens

Development is at a stage now where there’s a lot of technical debt to be paid.  The rotten fruit of lots of sketching ideas and then building more on top of those thin foundations than they were meant to bear.  Also, I have a much clearer idea of what the game is now, and that means shedding a lot of what it isn’t.  (I think this is a good and natural part of game development.)

That means hard work gluing all of these kind-of separate systems and sketches together, refactoring, trimming, patching.  I think the long, tiresome ‘middle part’ of development has begun.

To celebrate, I have moved the completeness meter on this dev log to 20%.

This week I set a destination and drew a rough road map of how I’m getting there.  The destination is a vertical slice demo.  I’m making myself work on one part of the map at a time – starting with getting the save system actually functional.  Like all of the systems in the game right now, it works about 60%.  I’ve started with the save system because further development relies on me being able to load up the game in any state I choose and moving forward from there.

Ready, set … oooh, what’s that over there?
Naturally, last week, I procrastinated.  I decided to add stars to the night portion of the day/night cycle.  I thought they would help with a sense of depth and hint at something dynamic (even if they are just static for now) during the long nights.  During the day, the colors are constantly changing and the shadows moving, but so far there’s nothing at night.  Except the ghosts.  So, I thought, the stars.  And not just some silly starfield texture on a dome.  No.  The positions of the actual stars as seen from earth.  As a mesh.  No alpha masking transparency issues, no fragile shaders mucking the whole thing up.

(Image: Wikimedia Commons, John Goodricke)

Years ago (close to ten now) I began a project with an astronomer to model the conditions under which John Goodricke observed the period variation of the star Algol (among others), ‘thereby laying the foundations of modern measurement of the Universe’ (as the plaque in York says).  Goodricke is a fascinating character in 18th century science.  Deaf, a boy genius (elected to the Royal Society when he was just 21), died tragically far too soon.  He lived with his family in rented rooms in the Treasurer’s House in York – a magnificent, rambling mansion with a medieval core and centuries of wings, storeys, hallways, and cellars added to it (I might have to put a version of it in the game).  In Goodricke’s time it had been divided into many separate apartments owned by several individuals. 

(Image: Wikimedia Commons, The Treasurer’s House)

No one is 100% certain exactly which rooms were the Goodrickes’ nor which window it was that John used for his nightly observations.  This matters because John used the same window every night and measured the periods of variable stars based on what time they passed behind a certain spire or pinnacle on York Minster, the massive cathedral next door.  The only way to solve this mystery is to make an accurate model of the house, and of the east end of the Minster, and of all the visible stars (and of their motion through the sky) and then virtually sit in window after window and try to recreate the observations he left in his notes. 

You can see why I never finished the project.  Regrets, I’ve had a few.

I got about 2/3 of the data – a photogrammetric model of the house (I was an early adopter of photogrammetry as a modelling technique – back then the software cost £9,000 (and that was an educational discount!)), the data for an accurate model of the east end of the Minster based on a recent survey one of my students had made of that part of the cathedral, David Nash had just made the HYG Database of stars available (http://www.astronexus.com/hyg), and I had bought a book of algorithms – Astronomical Algorithms by Jean Meeus - for computer modeling all sorts of celestial motion.

I just didn’t have the time (this was not my regular job, even though it was buildings archaeology) – and probably the technical chops to put it all together.  A shame.

Fast forward to last week and I’m thinking of modelling the stars and old buildings again.  And this time, I figure I can at least get the stars in the sky.  Nash’s HYG database is still available and it was in a format I could use.  The star coordinates are in XYZ from the center of the earth, though, and I was really just interested in getting them as little polygons on a sphere.  So, I went through a tortured process to import his coordinates, (going by orders of magnitude for the first 5 magnitudes (about 180 stars)), project them onto a sphere, and then import them into Unity.  (I know, I could use a particle system, but I’m not so good with particle systems.)  There, I adapted an unlit, emissive shader I had written ages ago to fade out based on UV position (but I really want to do it by world coordinates, so I can rotate the star dome and have the stars fade in and out at the notional horizon as they move across the sky).

And voila!  I was watching Orion come into view as twilight fell on the ruins of my parish church.

Will this make it into the final version of the game?  Who knows?  Is it essential in any way to the gameplay, the story, or the mechanics?  Not in the least.  Was it worth it?  Absolutely.  I owed it to John Goodricke and to myself, and that’s enough.

Enjoy.

[ChrisLSound]

I love it!

[JobLeonard]

The positions of the actual stars as seen from earth.  As a mesh.  No alpha masking transparency issues, no fragile shaders mucking the whole thing up.

Oooh, like how the Homeworld games did sky boxes?

Years ago (close to ten now) I began a project with an astronomer to model the conditions under which John Goodricke observed the period variation of the star Algol (among others), ‘thereby laying the foundations of modern measurement of the Universe’ (as the plaque in York says).  

Just indy game dev things

(that whole anecdote could be a narration in the game hahaha)

[oahda]

Wow, a lot of updates since I last saw this thread. Really cool stuff!!

[amasinton]

Oooh, like how the Homeworld games did sky boxes?

That's amazing!  I had no idea.  What a fascinating solution to a design problem.  I love vertex colors.  They're useful for so much - beyond colors, too, of course.
My stars are just disconnected tris projected onto a sphere, facing its center, with vertex colors just to keep it simple - so, not much like the Homeworld skyboxes, right now.
Almost everything you see in the game, though, is purely vertex colors.  I kind of find texturing tedious, and I do genuinely like the look of flat-shaded and some low-poly art.  So, I thought I'd give it a try myself.  It hasn't saved me much time so far, but once I get into the art production, it really should help. 
The only thing that makes major use of textures is the background sky gradient.  I tried it with just vertex colors but it was slow.  The current setup uses a set of four, two-pixel textures and blends between them.  I rather like it and I don't think it taxes the GPU too much.

(that whole anecdote could be a narration in the game hahaha)

I'm starting to come round to your idea of having some narration - perhaps for a trailer, as you once noted.  Perhaps in the game itself.  I do like to tell stories!

[amasinton]

I love it!

Thanks, I love it, too!

Wow, a lot of updates since I last saw this thread. Really cool stuff!!

Thanks for checking-in. 
LOVE the time bubbles in AO, by the way.  I'm curious to see how you're going to deal with different geometry in different bubbles.