next »

[amasinton]

Very cool. It's starting to remind me of how I love exploring towns in RPGs, but always end up wishing there was more to actually see/find/interact with - especially in natural ways. It seems like this game will have that as one of its core elements!

So in a previous post, you said this macro view won't ever appear in the game itself. What kind of view will the actual gameplay have? How close up will we be getting? How will we be navigating?

That's a good point.  I think I have always wanted some deeper history in some of the places I've visited in games.  Like when I was a kid I used to watch my friend play the original 'Kid Icarus' on the NES and kept bothering him with questions about who built the platforms, and why all the columns were ruined, and just what kept them floating.  Maybe that's what I'm trying to address here.  (Maybe that example betrayed my age.)

The player navigates by clicking and dragging to move across the island and to rotate their view.  The screenshots I posted make it look like an isometric 2.5d game, but it's not really.  It's fully 3d but your perspective is always a bit 'remote', and I've set the camera perspective to be almost isometric but not quite, because I like how that looks.  So, you're working with a kind of 'God' view - the kind of view you get in an XCom, for example.

The macro view will appear in the game (but the blocking-out images I've been sharing are just sketches, the final island model will be more detailed).  The player can zoom from individual parts of buildings all the way out to the full island. 

You've zeroed-in on one of the problems with my design that I'm trying to work out right now.  Most of the time the player will be working at mid-scale - building by building.  For that zoomed-in view, the rest of the landscape gets cut away, so you can see a section through the island and other buildings, giving you the above and below-ground remains at once.  It's fun (also technically difficult to do).  But, this necessarily limits the player's ability to contextualize the part they're rebuilding with other things on the island. 

So, I was thinking of toggling between an 'exploration' mode where you can move around the island at whatever zoom level and nothing is clipped, but when focusing on a particular building, you move into 'rebuliding' mode where the view is clipped and more focused.  This is not set in stone yet, and I think I'm going to end up iterating on this idea a lot.

I need to post gifs of interaction, even if it's clunky.  That might explain more than all my words!

[amasinton]

This looks gorgeous and the premise is very appealing. I'm also curious as to how the player experience will work - do you explore the world in a first-person view? Are there puzzle elements to the rebuilding and time travel?

Thank you!

I explained a little about the player experience - navigation and perspective - in my reply to ChrisLSound a moment ago.  But, I need to post some gifs, because that will really help clarify.

Puzzle elements.  Yes, but light.  Because 1) I'm just not that clever at designing puzzles.  I can appreciate what Jonathan Blow does, but I don't think I can do it myself.  And 2) because I don't want to give the impression that the player is 'getting it wrong' and therefore missing something.  The core idea is conversations with buildings about their past, and whatever way that conversation goes is correct for that playthrough. 

But puzzles are inherent in the design, especially in the time-travel aspect.  As you rebuild buildings you'll uncover fragments and artifacts that link the different sites on the island together - and the artifacts allow you to travel to the time they were made.  As you build you'll also uncover ruins that exist in one time and not another and you'll have to think of ways to maneuver through time to get to the point where you can actually rebuild those ruins.  You may see things at the start of the game that you'll just keep circling around until you finally get an artifact from the right time to travel there to finally rebuild them.  I'm really looking forward to designing these kinds of time puzzles because I think there's some interesting opportunities hiding there in the mechanics!

[PixelDensity]

I am really liking the sound of this game! I love the idea you explore the ruins and discover the history, sounds unique and interesting.

You mentioned the idea of the story being from different branches but you were unsure if the random generation would work or not, I also remember reading someone suggesting having one solid story. I was just thinking you could combine the two, in which there is a overall story but depending on the amount the player discovered results in different endings/knowledge of the world.

Thank you!  To branch or not to branch, that seems to be the question.  Like you, I'm leaning towards 'yes, there is and is not branching'.  That seems like a cop-out and maybe it is, we'll see.  The idea is that there is a main story arc, but that the details of that arc and how much of that arc the player experiences is really up to what they discover and their responses in this 'conversations with buildings' idea.  So, perhaps in your playthrough you will see the bombardment of the castle by U-Boats in WWI.  But in my playthrough I will only see the ruins of the castle after the bombardment.  In both playthroughs the castle suffers damage in WWI, but you understand exactly how that happened and I don't.  Just what unlocks that event for you and not for me is the result of what you unlock as you explore the island and as you rebuild.  This has a cumulative effect, meaning that some way you might have responded, some artifact you might have picked up, adds to a chain of locks and unlocks in a sequence that is unique to your playthrough.

Hmm.  Having written all of that out, it sounds very complicated.  And the final 'story' can be.  But the systems behind it aren't that sophisticated.  They're blocks that interact with each other.

Overall, the idea is not to withhold content from players.  I want this to be a true conversation and these conversations can go differently for each player, depending on the choices they make.  They're not missing content, they're just discovering their own path through it.  There isn't a 'right' way through, I guess is what I'm saying.  I'm not trying to lead players to the 'good' or the 'bad' ending. 

The design you have going on at the moment is really interesting and I like it a lot. Are you using any real world references or is this from your experience at work? If you are looking for more ways to combine the different time periods you should look into and research York in England. The city is fascinating and the has a lot of history regarding buildings and how they were recycled over hundreds of years.

Also there are many small places in England that have that mixed old medieval look with modern society, Lincoln & Richmond are two to name off the top of my head.

I shall be following this closely and I wish you all the best. Keep up the great work!   

Ah York!  My adopted hometown!  I lived there for 11 years while I researched and taught at the University.  Yes, pieces of York will show up all over the island.  I can't help it.  I just know the place so well.  You could show me any random stone fragment or detail from the Minster and I could probably tell you what it's from and how old it is.  And then Lincoln!  Did you know for a while Lincoln cathedral was the tallest building in the world?  Had a wood and lead spire on its central tower that brought the building to over 500ft high.  Wind blew it down in the sixteenth century.  I nearly put the Lincoln tower and steeple on my abbey church at the top of the island, but thought that might be a bit much.  And then Richmond!  I was just there in September.  That castle is spectacular.  It's a lovely old town and you're right, a good mix of old and new, dramatically situated.  I keep thinking of this island as Scarborough but cut off entirely from the mainland.  Well, that's where the idea started.  Looks a bit different now.

Thank you so much for your interest and your interesting questions.  They've stimulated a lot of thought.  Keep an eye out for details of existing buildings you might recognize.  They'll pop up everywhere!

Glad I could help. I also love York, just the amount of history and detail in all the historic buildings is fascinating, probably one of my favourite cities to live near. Lincoln I did get the opportunity to live there for 10 years before moving to Richmond.

I look forward to more updates in the near future and like you said, looking out for details of existing buildings I may already recognize.

[amasinton]

Scene navigation, as it exists now.  Translate, rotate, and zoom.  (Sorry for the bad GIF quality!)

[amasinton]

Update time.

Rough couple of weeks, personally.  Was rather unwell, then overwhelmed at work.

However, I still made some progress on the game.

I built a kind of flash of light, or sparkle for uncovered items - artifacts and architectural fragments - so the user will know there is something of interest in the scene they should check out, but without it being overwhelming visually.  Needs some tweaking, like everything, of course.  It's based on the Breath of the Wild sparkle on items you can pick up.  That game has such a clean interface in so many ways.

Also, implemented what I hope is the final key mechanic in the game: Choosing an interpretive word for artifacts.  One thing I really liked about the rebooted Tomb Raider series are the artifacts Lara picks up.  You can examine each one, rotate it, and read its history.  It doesn't do anything in terms of the mechanics of the game, but it's a nice feature that fleshes-out the lore of the world, or at least adds some intimacy or personal touches.  Especially good are when sets of artifacts relate to each other.  I'm thinking of the heartbreaking series of children's toys you find at one point.

In my game there is a similar artifact viewer, but with more direct relevance to game play.  Artifacts are the key to time travel.  The player can choose to travel to the time when the artifact was made.  They are also key story elements, and as such, are an opportunity to influence how the player interprets the story.  This week I implemented a system which asks the player to choose one of three words to describe the artifact.  There is no correct or incorrect word, it's just which one the player feels is most suitable.  The player's choice influences an invisible 'World Mood Score'.  Systems such as weather, time of day, vegetation, and ghosts (I'll get to those eventually) are influenced by this score, which will, in turn influence the player's understanding of the story.

Vague?  Of course.  We'll see how well it works as development progresses.  Here's a screenshot - super ugly, but functional.

Also, this means that I should really focus on content now, since the key mechanics and systems are in place.  I could distract myself for a little while with building the save system (ouch!), but I really should concentrate on creating the island.  That's quite exciting!

[isaaktual]

I love the way you're building the architecture.  It's almost like you're unearthing the ruins yourself as you're making the game!

I'm getting a really contemplative mood from this.  It'll be like a personal journey through other people's lives, using what they left behind to find your way through the environment.

Very cool!

> : D

[ChrisLSound]

So, so cool.

In a way, it sounds like sets of related artifacts could be an alternate implementation of side quests. Are there any "side stories", or is it all relevant to the "main story"? Maybe another way to frame that question: what is the end-game like? What determines when you're done?

Can't wait to see more content! (and learn about the ghosts you mentioned)
I hope your personal situation improves soon as well.

[nova++]

I really do look forward to losing myself in this game.

[amasinton]

I love the way you're building the architecture.  It's almost like you're unearthing the ruins yourself as you're making the game!

I'm getting a really contemplative mood from this.  It'll be like a personal journey through other people's lives, using what they left behind to find your way through the environment.

Very cool!

> : D

Thank you!

I am discovering the ruins while I build the game, you're right.  I have the general shape and feeling of the island, but the specific details resolve themselves while I work.  Since that's one of the core principles of the game, I think that's a good thing. (I think a lot of people do this as part of their process across mediums - Tolkien described something like this in his short story 'Leaf, by Niggle', for example.)

It is meant to be contemplative, or at least, self-paced.  You could race through it, but it rewards exploring and making connections. 

You're absolutely right that you are using what people left behind to find your way through the game.  Very perceptive!

[amasinton]

So, so cool.

In a way, it sounds like sets of related artifacts could be an alternate implementation of side quests. Are there any "side stories", or is it all relevant to the "main story"? Maybe another way to frame that question: what is the end-game like? What determines when you're done?

Can't wait to see more content! (and learn about the ghosts you mentioned)
I hope your personal situation improves soon as well.

Ooooh.  That's a good idea!  I think that's one of my goals - stringing together the more personal stories through collections of artifacts.  But I've never consciously expressed that.  I think you've got it exactly.  Thank you.

Endgame:  another very good question.  The simple answer is the game ends when you're rebuilt everything on the island, but I would like to shape that moment a little more deliberately.  I would like to tie the consequences of a single moment across the full depth of time represented by the ruins.  The game is divided into eras with each era punctuated by this common moment.  When you've experienced these moments, you'll have the full story of the island and the game will finish.  I have seen a specific end moment in my mind's eye from the very beginning of work on this project, so I suspect that's where we're headed.

We'll get to the ghosts.  I just saw a post on Gamasutra about how they made the player character for 'Recompile' and now I'm obsessed with making my ghosts look similar.  It might be a bit out of my league, technically, but it's something to aspire to!

(And thanks for the kind thoughts about the rough times.  They are improving, I think.  Life, you know!)

[amasinton]

I really do look forward to losing myself in this game.

Thank you!  I hope it will not disappoint!

Thanks for the motivation, too!

[amasinton]

I've been building the parish church.  It's a good testbed for trying out the various interlocking systems I've built up and provides a nice vertical slice of the core mechanics and loop (can you have a vertical slice of a core?).

One of the technical problems with the game is scale.  There are very very many gameobjects each with varying levels of physics and interaction attached.  This makes the game both resource-intensive as well as fragile.  Here's an illustration of the problem:

These are just the basic components of just one building of mild complexity - the parish church.  There are hundreds of separate fragments here, each its own gameobject, and each with their own mesh colliders.  This is obviously inefficient and doesn't scale well.  The reason they're set up like this at present is because one of my early design goals was to be able to dynamically vary the way parts of buildings rebuilt themselves, meaning I can't just bake a rebuild animation because I'm randomly drawing from a pool of fragments each time a rebuild sequence is triggered.  The individual mesh colliders are also necessary because this is how I tell if an object is within the clipping volume of the scene.  So, I think I need to ditch the idea of either the random rebuild or the clipping volume triggers.  I think the triggers are the easiest and perhaps least performant part of the problem, so I'll start there when it comes to optimizing.  But all in good time.

I'm excited to see the entire church come together, though.  It's a complicated but interesting little building.

[nova++]

Mesh colliders are eeeeevil. They're one of the slowest things in Unity, annoyingly. If you can approximate the shapes with any of the primitive, colliders, for the love of god do it. It sounds like you aren't using it for anything that needs the collision to match the geometry, if I understand you right?

I must ask also, are you assigning the mesh colliders via script, or just in prefabs? Assigning them via script has a few gotchas, as far as I've found. If you add a mesh collider to an object with a visual mesh on it, it will automatically process that mesh on the same instant that the collider is added. If you then assign a new mesh to the collider (even if it's the next line in the script), it will discard all the work it just did and then re-process the new mesh you just gave it I never did post a bug report, I really should sometime...

[ChrisLSound]

Ooooh.  That's a good idea!  I think that's one of my goals - stringing together the more personal stories through collections of artifacts.  But I've never consciously expressed that.  I think you've got it exactly.  Thank you.

I absolutely love finding seemingly-insignificant things that, when followed, tell beautiful stories even if not directly relevant to the main goal. Certainly like what you previously described from Tomb Raider. Even in the simple/janky Elder Scrolls games, it's nice. Anything that adds new perspective to the world.

It seems like your game could use this to even greater effect. If you're stuck on a piece of the ruins and just can't figure out what it's saying, perhaps following one of the smaller stories from artifacts will shed light on the situation, giving new perspective to the ruins you hadn't considered.

Your game seems to really be capturing my imagination

[amasinton]

Mesh colliders are eeeeevil. They're one of the slowest things in Unity, annoyingly. If you can approximate the shapes with any of the primitive, colliders, for the love of god do it. It sounds like you aren't using it for anything that needs the collision to match the geometry, if I understand you right?

I must ask also, are you assigning the mesh colliders via script, or just in prefabs? Assigning them via script has a few gotchas, as far as I've found. If you add a mesh collider to an object with a visual mesh on it, it will automatically process that mesh on the same instant that the collider is added. If you then assign a new mesh to the collider (even if it's the next line in the script), it will discard all the work it just did and then re-process the new mesh you just gave it I never did post a bug report, I really should sometime...

I'm using the mesh colliders to tell me when an object - even a part of an object - is within the bounds of the box I use to clip the visibility of meshes via shader.  I think for some, large meshes I'll need to stay with a mesh collider, but perhaps for all of these small fragments of buildings I could get away with box colliders.  The whole clipping business is still janky and I don't think there's any way around that, so I might have to do a rethink anyway.

Also, I had no idea that runtime mesh colliders had the potential to push the engine to do twice the work.  Fortunately, I'm not assigning mesh colliders at runtime.  It's all being done in editor when the objects are first set up.  So hopefully that's a tiny bit more efficient(?).  I'll try to avoid assigning mesh colliders at runtime from now on.  I've just thought of a place in the code where I do build a mesh at runtime and I bet I assign a mesh collider there.  I'll have to take a look.  Thanks again!

[amasinton]

I absolutely love finding seemingly-insignificant things that, when followed, tell beautiful stories even if not directly relevant to the main goal. Certainly like what you previously described from Tomb Raider. Even in the simple/janky Elder Scrolls games, it's nice. Anything that adds new perspective to the world.

I love those moments, too.  I've often wanted to play (or build) a game where the real game is actually finding all of these little side and secret moments, but the whole thing is wrapped up in what looks like a standard genre-game.  So, perceptive players would 'fall through the cracks' of the 'official' game and into the 'hidden' game.  Like that moment in Portal when you go behind the scenes fo the test chambers and then the story of the game takes a twist and becomes much more interesting...  I think there are already some games that do this.  I remember reading about one maybe six months ago, but I can't remember its name.

It seems like your game could use this to even greater effect. If you're stuck on a piece of the ruins and just can't figure out what it's saying, perhaps following one of the smaller stories from artifacts will shed light on the situation, giving new perspective to the ruins you hadn't considered.

Your game seems to really be capturing my imagination

I'm hoping that's how these systems will work.  The artifacts and fragments you find will help give meaning to the ruins.  Also, they will help you to open up 'deeper' conversations with the ruins.  For a long time I've had in mind an artifact-based side-story concerning a series of small pits that line the outer edge of the churchyard, for example...

Thanks again for sharing your ideas.  They're very welcome!

[nova++]

Also, I had no idea that runtime mesh colliders had the potential to push the engine to do twice the work.  Fortunately, I'm not assigning mesh colliders at runtime.  It's all being done in editor when the objects are first set up.  So hopefully that's a tiny bit more efficient(?).  I'll try to avoid assigning mesh colliders at runtime from now on.  I've just thought of a place in the code where I do build a mesh at runtime and I bet I assign a mesh collider there.  I'll have to take a look.  Thanks again!

The important thing is that you don't add mesh colliders at runtime to an object that already has a MeshFilter on it. It seems to try to be helpful and auto-process that. Maybe it's been fixed by now, or maybe it only happens in the editor, but still - if I'm ever making mesh colliders at runtime (which I am doing a lot, yay procedural terrain...), I make a child gameobject that exists solely to hold the collider

[amasinton]

The important thing is that you don't add mesh colliders at runtime to an object that already has a MeshFilter on it. It seems to try to be helpful and auto-process that. Maybe it's been fixed by now, or maybe it only happens in the editor, but still - if I'm ever making mesh colliders at runtime (which I am doing a lot, yay procedural terrain...), I make a child gameobject that exists solely to hold the collider

So, you assign the mesh collider to the child GO and then you assign that collider the mesh from the MeshFilter on the parent?  I think I can see how that would save some calculations.  Thanks for the tip!

[nova++]

The important thing is that you don't add mesh colliders at runtime to an object that already has a MeshFilter on it. It seems to try to be helpful and auto-process that. Maybe it's been fixed by now, or maybe it only happens in the editor, but still - if I'm ever making mesh colliders at runtime (which I am doing a lot, yay procedural terrain...), I make a child gameobject that exists solely to hold the collider

So, you assign the mesh collider to the child GO and then you assign that collider the mesh from the MeshFilter on the parent?  I think I can see how that would save some calculations.  Thanks for the tip!

The mesh collider component goes on the child gameobject, and its mesh is set to whatever collision mesh you want. Ideally you would have a very simplified collision mesh for every object but I understand that's a lot of work for the number of objects you have.

[amasinton]

The mesh collider component goes on the child gameobject, and its mesh is set to whatever collision mesh you want. Ideally you would have a very simplified collision mesh for every object but I understand that's a lot of work for the number of objects you have.

That seems reasonable.  I have a lot of objects, but they're only around temporarily and then stored elsewhere.  The dynamically-created meshes are done one at a time, and I might be able to create a simplified collision mesh on the fly.  (He says as though he knew how to do this sort of thing.)

ZSpace is fascinating, by the way.  And such a well-organized and presented devlog, too!