next »

[Danton]

UNITY - EDTIOR EXTENSIONS

From time to time I find "missing features" I'd like to see in Unity -- recently I started adding them to github. Feel free to share, clone, etc.

So far I've only got two up there:

o EdgeJoiner for EdgeCollider2D -- I use this all the time when defining ground terrain
o Animation Property remover -- I had to adjust the hero's hand position and used this rather than hand editing 150 animations .

I have a few others that I use, I'll try to find time to get them up as well.

https://github.com/SDanton/UnityHelpers

[Danton]

NO LOADING SCREENS - SCENE VIRTUALIZATION

Our goal is no loading screens -- one seamless world, ala INSIDE.

I took a shortcut and bought a Unity Asset Scene Loader Additive. Had to convert it to work with 2d colliders, but otherwise it's been great and most importantly fast.

I spent the rest of the day optimizing the code. Removing the inspector sugar (which allowed you to define "scenes to be loaded" for each load trigger) and heavy use of lists with a single dictionary which I define up front.

But yea, all done with that side of things. Very happy.

The remaining big rock will be virtualizing NPCs (need to be smart about how we load them and can't have them falling through the world when their scene is unloaded), but I’m going to tackle that later.

[Danton]

PATHFINDING + SCENE VIRTUALIZATION

Pathfinding is coming along well. We're generating the waypoint graph, maintain it across virtualization of scenes, and using Sebastian Lague’s approach to A* I can find a path from A to B.

I managed to get around virtualization by using a global dictionary that is updated whenever a scene is loaded/unloaded by virtualization. The connections between pathways are defined at design time and then “managed” on demand. Connections define a "traversal" type (climb, run, jump, etc) which determines the cost of using a connection.

Next task is to getting an animated NPC moving from one location to another via the path. Assuming that goes well, I’ll work on optimizing things so multiple NCPs can request paths and move towards them at the same time.

Some other scenarios I need to consider:

- Leaders and following said leader, as a group of Woad might do when hunting, rather than each of them finding their own path.
- Need to consider dynamic obstacles e.g. a large troll blocking a path should be avoided when possible. This would be true for a trap or similarly dangerous obstacle.
- Dynamic costing of navigation types (jump, climb, etc) to allow for different traversal means. We’ll want NPCs to sneak up on the the player, hunt animals, etc.

[Danton]

CORDIAL BEHAVIOUR

Got our Woad (Woads sounds wrong from some reason) pathfinding from A to B, and although just roughed in, being respectful enough of their kinsman to step aside (by joining a waiting queue) and then letting the next Woad go by so they can all get to their destination .

BTW, sorry for the stream of boring shitty Unity editor view visuals... we're in "don't loose focus, get the fucking foundation right" mode for the next little bit.

BTW2, if anyone wants more details on implementation or design approach, don't hesitate to fire over questions. Always up for chatting.

[Danton]

RENEGADE FAIR

We spent yesterday at the Renegade Craft Fair in SF -- our first time. So many talented artists, we had a blast and bought a few things.

You realise pretty quickly that all of these people are doing something they really love. Most of them are quiet and humble, standing proudly over work that often represents their life's savings -- not once did we have to weather a deluge of marketese. They're following a passion to create products that represent them, not just as artists, but human beings. They're not in it just for profit, there's something more beautiful at work here.

Uno + Ichi - Ninas y Chicos cup	Naomi Sutton Textiles - Needlepoint Wall Hanging	Post Studio - Coasters

Supporting these makers is a no brainer, after all they're our analog contemporaries. Their passion and pride is exactly the same thing that gets Sara and I out of bed every day. It's what we see in many of the projects on this forum and across the indie landscape. It's what makes indie games so special and us so proud to be a part of a community filled with such fantastically creative people.

[Danton]

PATHFINDING, VIRTUALIZATION & ROUTINES

Our goal for is to give actors the ability to go wherever the player goes. We don't want to box in fights with magical walls or constrain an encounter to a set boundary. Fleeing from a battle should be a viable way to survive. Encounters should range across the landscape, unfolding in unpredictable ways because of the terrain. Like a great action movie, if the hero gets away from a conflict by climbing a ledge and then dropping down into a cave, the actor in pursuit should follow with energy and vigor. It still early days, but here’s how we've tackled it.

Basic Pathing

I used an approach inspired by Sebastian Lague’s excellent A* tutorials. The only real difference is that I give obstacles (cliffs, ramps, jumps, etc) specific costs and use those to weight the different paths from A to B so we can pick the best or worst one -- depending on the situation.

Actor-to-Actor collisions

When pathing as a group two or more actors can get in each other’s way. A simple solution would be to allow actors of the same race e.g. Woad, to simply pass through each other - no collision. And although that would work, it breaks a rule of Unto’s feel: everything has physicality.

(This translates to combat with an actor -- you can’t just run by them. But also when you miss and hit the ground, rock or log, run into a wall, or fall from a cliff. Swing and hit a log and the log will crumble (or if large enough your sword will get stuck), sprint into a brick wall and you’ll knock yourself out, etc.)

So we decided to have acgtors “step aside” (there’s no animation for this yet, it’s just a layer shift for now).

That means when two actors meet the first one to realise the collision steps aside and waits until the other has passed. However, if one of the actors is of a higher rank, then the lower rank actor will give way regardless of which actors realised the collision first. A nice side effect of this is that it allows for scenarios such as having a leader march through a crowd to engage the hero.

Virtualization

We virtualize the world by breaking it down into “rooms”. Each room is contained within a Unity Scene and these Scenes are loaded additively as needed. A simple 2D box collider acts as the load trigger. When we no longer need a room it is unloaded.

We started with ‘Additive Scene Manager’ from the Asset Store, and have since heavily modified it to (1) work with 2D and (2) be more performant.

One of the hurdles we had to clear was ensuring actors can start in one room but move between rooms across virtualization. There were two challenges here:

1, If we load actors with a room, as in they are contained within a specific room, then they will get loaded/unloaded with the room. That means that if the hero encounters an actor in Room4, then runs to Room1 which causes Room4 to be unloaded, then the actor from Room4 may disappear right in the middle of an encounter. Not good.

2, To address (1) we can simple decouple Actors from Rooms -- storing Actors in a Scene that doesn’t get unloaded with the room. As I understand it INSIDE had a separate “Actor Scene” for each room which they managed independently. I considered this, but it felt easier to simply have a global pool of actors and then have them “register” with a new room (and unregister from their former room) as soon as they enter it. (My one worry here is first startup cost of this approach, we'll have to see.)

Here’s how this nets out:
- At design time actors are given a “home room”
- OnStart they register with their home room, then deactivate themselves
- When loaded by virtualization we check for any actors registered to the loading room and activate them.
- As actors move from room to room we register / unregister them with respect to their new / old room.
- When a room is unloaded we deactivate any actors registered with the room. We do this by calling a deactivate function on the actor so they correctly handle "pausing" their current action -- we don’t want a fleeing actor to get stuck halfway to their flee location when their room is unloaded, so we have special code to handle those cases.

Routines

Actors operate under a set of routines. These can be well defined things like a patrol route or something more organic, like “hunt deer” or “follow hero”.

I’m just getting started on these but routines allow actors to behave in all sorts of interesting ways aside from simply standing around waiting for the hero to fight them. Here's how they work.

- Routines have a set of Roles (which can be filled by any eligible actor)
- Each Role has a Routine definition
- Routines allows us to specify different movement or behavior patterns.

Down the road I’ll try to post a more detailed description of routines based on where we land.

Below the Woad is running a Follow Routine. As the father moves the Woad is periodically (every 200ms) recalcing the best path to follow him on. If the father sprints the Woad sprints, if the father sneaks the Woad sneaks. If the Woad was hostile to the father then he’d attack him when close. And so on.

(I still need to do things like speed matching, currently the Woad move faster than the father as they’re more athletic and I want fleeing from a fight with them to be difficult.)

[Danton]

Bit of progress on Woad hit reactions, stamina display (via idle) and death.

[wuuthrer]

Waouw, I like the mood and tone you got there.

For some reason, I'm feeling like there's some kind of valhalla rising vibe going on. Probably less gore and violent, but somehow your trailer reminds me of this movie.

The only thing that bothers me so far, is the (inexistent?) plot. I didn't read all the entries of your devlog, but it seems like you just write something very vague about revenge? I'm a bit worried about this, because when I first glance at your screenshots, I really got the feeling your game may have some narrative intentions. I guess, it's probably because of the fact that you bascially have no UI overlay. For me, this kind of detail communicates that the game isn't focus on ranking, execution or classic gameplay mechanics, which makes me think: Ok, this game really wants me to enjoy the universe and the ambiance. I would love to know what you're thinking about that (and sorry if you already explained in your previous entries).

Anyway, I'm still very curious and would definitely love to try it :]

[2ndStudio]

Hey,

Looks like you are working on some cool stuff. I can't wait to play it 

[Danton]

@wuuthrer Heya, thanks . The Valhalla Rising vibe is pretty on point, although we've been channeling a bit more The Revenant, when it comes to scene composition and mood.

To the meat of your comment though, plot .

This is an aspect of games which I have fairly well worn philosophical beliefs -- apologies up front if this gets a bit too passionate .

In the simplest terms I see games as interactive experiences, as apposed to books, movies, etc, which are passive / consumptive experiences. To be honest, interactive isn't a strong enough word. In games, at least those where you control a single hero, the player isn't just interacting with the hero and their world, the player is the hero living in the world they see on the screen.

This extension of self is something that humans do very naturally. It's what allows us to drive cars with a high degree of efficiency. Even though the car is much larger than our biological form, we are able to fairly quickly create and refine a mental model of the car which is so well realised we have a sense of the car's width, weight, and stance in the same way that we have of our own body when walking, running or standing. The car becomes us -- we can drive it within inches of obstacles and park it in tiny areas, often whilst moving faster than biology allows. This natural extension is also the reason why players  jump back, lean in, or press really hard on a button when playing a game, we see ourselves as the hero to such a degree that we physically mimic their behaviour.

It seems only naturally that we extend this to the game's plot and story. Rather than trying to tell a story through dialog, cinematics, etc, which may or may not represent what the player thinks or feels, shouldn't we get out of the player's way and let them decide their own "story" through their interactions with the world?

That's our goal for Unto. Build a space for an interesting adventure to take place. Give the player motivation to go on that adventure. Then get out of the way.

Admittedly, we don't have the time or resources to build a fully emergent simulation. But what we can do is set up various paths through the world, develop creatures that have unique motivations and personalities, and give the player lots of different tools for getting from A to B. So there's definitely some structure (plot?) to things, but in a way that gives the player a lot of freedom to decide how to feel and act.

If everything comes together like we hope then your experience through the game should be different from mine or your friends. The story, if you want to call it that, should be yours to tell other people, rather than something Sara and I force you to experience just because we thought it was interesting.

Of course, we understand that some people like a more story driven approach, but for Unto at least we want to try and realise an experience that is primarily driven by the player's decisions and actions.

Postscript: Two games in recent memory have scratched a similar itch to what we're going for in Unto: FTL and Rain World.



 

[io3 creations]

Looking good so far.

Having a group follow the leader and not make their own decision is a good idea.  Of course, then you have to consider a few situations:
-What happens if the leader dies?  If the next person in line becomes the leader, then others in the group would have to be notified.


Not sure how far you got with implementing scene and NPC loading/unloading but I wondered about similar things: When should an NPC be disabled and what should happen when the NPC is re-enabled? For example, if the NPC is climbing a ladder, should the NPC continue climbing from exactly the same point when re-enabled?  There might give the impression the NPC was "frozen in time" because it is still doing what they were doing when you last encountered them.

[Danton]

@io3 creations

Thanks . Great notes, appreciated!

What happens if the leader dies?  If the next person in line becomes the leader, then others in the group would have to be notified.

Right now I'm using a stack ranking system for creatures. So rather than the classic Captain with 2 Grunts, I have Rank 2, 1, 0, with 2 being the leader relative to that group. I actually apply this across clans. So a clan (creatures that would work together) with 10 members would have ranks 9 to 0. With the clan elder at rank 9 and the newborn cub at rank 0. When the higher ranked member dies the next in line fills in as the leader -- this happens automatically as the closest highest ranking member is the leader. We also have a revenge system that observes actions by the player or other actors and then determines "reactions" based on the action done (kill, harm, help, etc), relationship to the killed leader, to the hero, etc.

When should an NPC be disabled and what should happen when the NPC is re-enabled? For example, if the NPC is climbing a ladder, should the NPC continue climbing from exactly the same point when re-enabled?  There might give the impression the NPC was "frozen in time" because it is still doing what they were doing when you last encountered them.

For the moment I'm using an "aging function" along with the concept of "null waypoints". So if an actor is going from A to B up a ladder, and B gets virtualized away, then I just warp them to the top of the ladder. If the player returns, loading B back in, then the actor is at the top of the ladder rather than frozen at their unload location. In addition, I factor in the time since the actor was last loaded, if the time is considerable, then there is a chance they have moved on to a different routine. This basically selects from a list of spawn points not ahead of the player, so the actor doesn't seem like it teleported to a location the player doesn't know about, or couldn't also access. In certain cases I cheat, sort of. For instance if there is a route that is ahead of the player and it's plausible that the actor could have taken that route to get there, then I allow that to be a spawn point.

[io3 creations]

Sounds like you have a working plan for those situations.


I had a bit more thorough look at your devlog and have a few more questions if you don't mind.

-Could would there be situations that are "erased" or changed. For example, creatures fight with each other.  Your character passes by but then returns later.  If the creatures are unloaded and then reloaded, could they be doing something very different as your character returns?
-Do the creatures have a "home base" and stop chasing you if you leave that?
-A creature is far away but is chasing you.  You manage to get to a point where the creature with the room is unloaded.  At this point, your character would be help up or you decide to wait for the creature but it "never arrives" as you wait for it?



The "rooms" seem quite small.  (I'm assuming each room is an area with a number).  Does unloading/reloading really make that much of a difference in terms of performance?  Especially, since it seems like that your target machines don't include low-end mobile devices.


> revenge system
Is that based on a specific clan you mentioned?  i.e. if you mean another clan later on, those will not "telepathically" know how you treated previous clan(s).

[Danton]

Great questions, happy to try and answer them.

-Could would there be situations that are "erased" or changed. For example, creatures fight with each other.  Your character passes by but then returns later.  If the creatures are unloaded and then reloaded, could they be doing something very different as your character returns?

Yes, that's definitely possible. It all depends what routines we give them, how we want the player to experience them, etc.

-Do the creatures have a "home base" and stop chasing you if you leave that?

Yes, creatures understand the concept of home and territory. For instance, a Woad has a home and then their hunting territory. If you encounter them in their home they will react differently (often more aggressively) than if you encounter them in open territory.

-A creature is far away but is chasing you.  You manage to get to a point where the creature with the room is unloaded.  At this point, your character would be help up or you decide to wait for the creature but it "never arrives" as you wait for it?

We handle this by always loading at least two (but up to eight, basically a max 9-grid of rooms, with the hero's room in the middle) off screen rooms, if a pursuing character is unloaded then they are warped to the next offscreen room and then they continue chasing the hero, eventually arriving at them if he's waiting.

The "rooms" seem quite small.  (I'm assuming each room is an area with a number).  Does unloading/reloading really make that much of a difference in terms of performance?  Especially, since it seems like that your target machines don't include low-end mobile devices.

A room is about a screen and a half in size and we'll have hundreds of them when the game is all done, so it will definitely help with performance: load time, overall memory pressure, overall CPU pressure, etc. Unto has no levels, no loading screens, no breaks in gameplay (e.g. no separate UI or menu screens that unload the world), so we need to virtualize everything or stuff will grind to a halt pretty quickly. FWIW, the world in the GIF you note is at "blocked out" fidelity, real rooms have multiple background and foreground layers, hundreds of doodads (many animated and interactive), weather fx, local fx, etc, etc.

> revenge system
Is that based on a specific clan you mentioned?  i.e. if you mean another clan later on, those will not "telepathically" know how you treated previous clan(s).

We use a believable model of sharing information. So if you kill 3 creatures in the woods and then encounter 2 more, the 2 new ones will not magically know about the other 3. However, if one of the 3 creatures in the first encounter got away, then he would more than likely tell the other 2, and more importantly set up an ambush for the hero.

[MantraTeam]

This looks fantastic, the animation is great and the art style is really atmospheric and beautiful. It really reminds me of the work of Scott Wills. He made the painted backgrounds for shows like Samurai Jack and Star Wars: Clone Wars.

Looking forward to seeing more of the development!

[io3 creations]

Great questions, happy to try and answer them.

Thanks!

We handle this by always loading at least two (but up to eight, basically a max 9-grid of rooms, with the hero's room in the middle)

Ah, I see.  I was assuming based on the image you posted that at most there are only three rooms and not more.  With that many, chances are pursuing characters won't be unloaded (unless a lot slower than you).  But just in case, it's good to be prepared.    Of course, it makes sense from an optimization point of view to limit the number of rooms - but if having only 2 or 3 rooms could effect gameplay more than the benefit that comes from optimization then it may not be worth it.  Also, I probably assumed that there would be multiple "levels" with rooms but now I see you did mention "one seamless world" with no loading screens. 

If you have a seamless world, how do you handle saving the game?  My first guess is that check

I saw your post about accessibility.  Of course, in some every game is created for a certain target audience.  Given the current direction, the game looks like it would be suitable for those that prefer a "campaign mode".  Would those who prefer rogue/random type or "replayable" games also enjoy it?  That is, if you start game again, other than varying your gameplay, are characters placed in the same (or nearby) location.  It's not a necessity, but chances are it'll come up in questions.

However, if one of the 3 creatures in the first encounter got away, then he would more than likely tell the other 2, and more importantly set up an ambush for the hero.

That should be interesting!  

I see you mentioned "trap or similarly dangerous obstacle".  Have you considered traps that would capture the player and the player would have to escape before enemies arrive.  For example, some kind of rope would tie around the foot and would pull the trapped character up.  Escape would happen by the player pulling themselves up and with a knife or sword cutting the rope.  That could take some time to increase tension as the character(s) who placed the trap arrive.

[Danton]

@MantraTeam

Ah man, thanks so much. Huge fan of Scott Wills' work, means a lot that we're reminding you of his stuff!

[Danton]

I saw your post about accessibility.  Of course, in some every game is created for a certain target audience.  Given the current direction, the game looks like it would be suitable for those that prefer a "campaign mode".  Would those who prefer rogue/random type or "replayable" games also enjoy it?  That is, if you start game again, other than varying your gameplay, are characters placed in the same (or nearby) location.  It's not a necessity, but chances are it'll come up in questions.

It's definitely something we've thought a lot about, but the most important thing for Sara and I is to create one experience we're really proud of. Realising that through a single mode is hard enough, for us at least .

If you have a seamless world, how do you handle saving the game?

The obvious approach is a similar model to INSIDE, and so far we've gone with that b/c it's easy to build and very "fair" to the player. But we have other ideas that are more ambitious. We'll see how some of the other systems pan out and then make a final call. I know that's a bit vague .

I see you mentioned "trap or similarly dangerous obstacle".  Have you considered traps that would capture the player and the player would have to escape before enemies arrive.  For example, some kind of rope would tie around the foot and would pull the trapped character up.  Escape would happen by the player pulling themselves up and with a knife or sword cutting the rope.  That could take some time to increase tension as the character(s) who placed the trap arrive.

We do. There are a bunch of different situations like that, some built out and some still on paper. They are some of my favorite things to design, but they can suck up a lot of time and resources: animation, mechanics, art, AI, etc... so we apply them sparingly.

[io3 creations]

It's definitely something we've thought a lot about, but the most important thing for Sara and I is to create one experience we're really proud of. Realising that through a single mode is hard enough, for us at least .

Yes, I agree that it's better to follow your original vision first.  

Sometimes though, coming up with random generators (levels, enemy locations, etc) can be useful for creating lots of levels and then picking the ones that can be useful.  Also, might generate some thing that you haven't thought of.  Also, it can be useful for breaking down your level into "core pieces": some that always need to be present (e.g. house, field) and those that can be placed randomly (e.g. paths, cliffs).  Just wanted to mention that in case you find that kind of approach useful.

The obvious approach is a similar model to INSIDE, and so far we've gone with that b/c it's easy to build and very "fair" to the player. But we have other ideas that are more ambitious. We'll see how some of the other systems pan out and then make a final call. I know that's a bit vague .

Yes, that is a bit vague.

I've only skimmed a few parts, but is it mentioned in this talk about Inside?

We do. There are a bunch of different situations like that, some built out and some still on paper. They are some of my favorite things to design, but they can suck up a lot of time and resources: animation, mechanics, art, AI, etc... so we apply them sparingly.

... and those moments tend to be very memorable as well.   But I know what you mean. 

[Danton]

ANIMATOR ORGANIZATION - ANY STATE TRIGGER PATTERN

Just read Will Armstrong’s excellent post about Animator organization http://response.unity3d.com/animator-controllers. If you've ever worked on Unity game that is heavy on animation you realise pretty quickly how bat shit nuts your animator organization can get.

A pattern I didn’t see there was the one we use for Unto, I’ll call it “Any State Triggers”. It looks like this…

(Credit goes to Scott Watson for coming up with this pattern while he and I worked on a procedurally generated space adventure game -- that we never finished . Scott and I have lost touch since that project, hope you're doing well mate.)

Before we came across this pattern we had an insane number of crisscrossing connections between states, he's an example I threw together -- I can't find the original.

The Any State pattern is pretty simple.

- Leverage "Any State" to make a one directional hub, allowing transitions from State A to State B regardless of the current state or dependencies between states.
- Remove all state to state transitions.
- Choose a single uber default state for the entire animator (e.g. Idle) and make it the only state that other states can transition to directly.

The main idea is to wire all cross state connections (Any State --> State X) using the Trigger transition pattern. This means if I'm in the Running State and get hit by a sword, I can switch to the Hit Reaction state just by firing Trigger_Hit.

Because this is wired to Any State I can do this from... any state , Run, Jump, Climb, whatever and I don't need the other states to know about the "wiring" to Hit Reaction.

If you're not familiar with triggers, they are single-fire, set and then reset, boolean flags that the animator can use to perform a transition.

Code:

// fire trigger
_animator.SetTrigger ("Trigger_Hit");

Unlike Bool, Int or Float properties which need to be set then manually reset, a trigger's state is automatically managed by the animator. It fires, setting a transition to true, and then once the transition has completed the trigger is set to false, so it doesn't fire again.

When we fire a trigger we make sure to set up the animator properties for the new state. We do this to so we don't accidentally reenter a state "in flight". In theory, because we can interrupt at any time, from any state, then we could do something weird like interrupt Run during RunEnd, do a Hit Reaction and then reenter Run with the run state at RunEnd.

Inside each state we have "back to Idle" conditions. Idle is our default state for all other states.

Ttransitions to the Base Layer always point to the Idle state which is the animator's overall default state.

Instances where we need to transition from one state to another state, other than Idle are all handled through the Any State pattern.

If you have any questions let me know.