Remove ads

Metroidvania Month 7 devlog

Created
Status
Ongoing
Watchers
5
Recent readers
0
So, Metroidvania Month 7 is rolling around again (I missed month 6 for IRL reasons) and I...
Guessmyname

Guessmyname

Tea-Powered Biscuit-Eater Riding A Flamingo
Commission Artist
Location
The Land of Many Bregrets
Pronouns
They/Them
So, Metroidvania Month 7 is rolling around again (I missed month 6 for IRL reasons) and I thought after last time I'd take another crack at it. Also a special shout-out for inspiration from Touhou Jam 5, where one group of madmen made a little mini Windwaker in three sodding days.

Luckily, there's still a day or two before it actually starts, so in the meantime I'd thought I'd offer everyone a chance to pick a theme. Of the following prompts, which most piques your interest?

[ ] Concept 1: Postnuclear Robots On Ice (Third Person Shooter)
- Postnuclear world. You are a robot. Everything else is a robot. All the humans are dead.
- Ice/Ruined Industrial setting; frozen pipes, snow, ruined machinery, wasteland; cyberpunk meets Metro 2033
- Abilities: Torch (melt ice), Grapple-hook, Remote Drone, limited jetpack (hover/double jump), assault rifle
- You are a broken robot
- Your enemies are broken robots
- Goal is to perform the pre-coded tasks you were originally built for even if they are all obviously meaningless now
- Happy Times For All
- It's like, social commentary or something
- Can definitely be done within the timeframe

[ ] Concept 2: 6DOF Space Archaeology (First Person 6DOF Exploration)
- Explore abandoned space stations! In space!
- Player is an astro-archaeologist. You investigate space hulks to piece together what happened, a little like Return of the Obra Dinn without the rewind mechanic
- Must also manage air/power supply (survival elements)
- Rooms can be pressurized / powered / unpowered etc
- Abilities: magnetic grapple (pull-to-surface), RCS pack (6DOF movement), cutting torch, taser
- Must correctly determine sequence-of-events / what happened to wreck the ship
- Can definitely be done within the timeframe

[ ] Concept 3: Shinto Shrinemaiden I-Can't-Believe-It's-Not-Ico Extravaganza (Third-person puzzle/explore/action)
- Mucking about with the Shinto concept of purity and running water; it's a game about water puzzles
- So a sufficiently large fantasy shrine complex has been overrun with youkai; you should probably object to that (and also protect your kami)
- Player has a naginata and a moveset built around knockbacks; your goal is to smack enemies into environmental hazards (ie waterfalls / running water) to leave them open to a finishing strike
- Impurity mechanic; you can cleanse/purify a given thing by washing it; shove it under a waterfall, aim a pipe etc. Water must be flowing.
- We're talking Windwaker / Mario Sunshine levels of 'water mechanics' here; anything involving physical water simulation is right out
- Kami is secondary NPC / your walking savestation / HP regenerator / door unlocker. Movement abilities relate to pulling you to her / her to you. Can be ordered to go to specific locations / stand / follow / etc. Can only move through/over purified areas.
- Basic gameplay progression: enter room -> get water flowing -> clean up enemies -> clear path for kami -> next room
- Other movement abilities: walljump / double-jump / ribbon (swing on hooks / pull things around remotely / dangle over ledges for kami to climb). Naginata can also poke stuff at a distance.
- Maximum weeb making it awkward to show off to family members (<_<)
- Can definitely be prototyped in the timeframe, jank inevitable

[ ] Concept 4: Procedural Bloodborne-esque dungeon-crawler (Third-person Stab-Dodge-Stab-Crap-"You Died")
- TL;DR 'make the Chalice Dungeons not shit'
- Have been working on a procedural dungeon generator for a while now; this is basically an excuse to put it to work
- The Kingdom Dungeon is an infamous Dungeon in the wider world; one where an ancient heretical kingdom attempted to control the Gods themselves. It ended poorly for everyone, and even now, centuries later, it's still causing problems and raising the dead to haunt the living.
- You control the Redgrave Mansion, originally built by the Redgrave Family, tasked with containing the Kingdom Dungeon until they went insane and were purged by the Church, replaced by the Genoire Family, who went insane were purged by the Church, replaced by the Delmont Family, who etc...
- Typical Bloodborne-esque third-person dodge-heavy action; the focus is more on generating level layouts that aren't catastrophically awful to play through. See cyclic dungeon generation, graph grammars, these two talks on modular level design (1, 2) for the asset-side of things
- Metroidvania abilities: swinging hook, mist-form (improved dodge / dodge through grates and bars), time-slow, time-stop
- Delve into the dungeon for artefacts / curios / to assassinate troublesome bosses, bring stuff back to your mansion ('If Darkest Dungeon Wasn't Turn-based')
- More abilities you get, more likely the Church will start getting paranoid
- Fixed seed per game (ie it doesn't regenerate every time you delve) so metroidvania exploration aspects remain intact
- Get purged/family-wiped generate a new family name, new family installed, ball keeps rolling
- Can definitely be prototyped in the timeframe, but likely to be missing features (priority is on dungeon generation over the mansion side of things)
 
Last edited:
[X] Concept 3: Shinto Shrinemaiden I-Can't-Believe-It's-Not-Ico Extravaganza (Third-person puzzle/explore/action)

Extremely this! :V

I want this so much it's practically one of the things I've thought about making and never made myself! :V

EDIT: I want this so much that if you put it on a private github and PMed it to me with implementation requests I would do my very best :V
 
Last edited:
[X] Concept 2: 6DOF Space Archaeology (First Person 6DOF Exploration)

Definitely has my name interest this.
 
As I recall it, I wanted to make a game like Ico basically the moment I had finished playing Ico. Shocking, I know. :V

I spent some time sketching out ideas for what you could do that wouldn't just be a total hackjob ripoff, and I actually wrote out some design pages on a procedurally generated 2p game that I toyed with as both a tabletop RPG system and as a video game. This was years ago (4-5ish, I think) and the idea kinda faded, but when you say Ico and you then also say shrine maiden I'm like

YES

There's a huge dearth of games where the protagonist is a miko and if Japan won't make them clearly we must rise up! :p

While probably somewhat outside scope, I think Japanese mountains in general are also somewhat suited for being somewhat metroidvania-ish. Obviously the shrine itself has advantages in being possibly quite large, but as Sekiro demonstrates you can go a long way with the Japanese mountain aesthetic. Likewise, having actually climbed to halfway up the Inari shrine in Kyoto, that place is like 50% there to being a video game level in real life. Kyoto in general is a wealth of aesthetic inspiration.

For some other aesthetic suggestions, miko are often seen of course with their gohei wands with zigzagging paper streamers, but additionally there is also a tradition of bows, sometimes even used as one-stringed instruments. Check out Azusa Yumi. You can even have different types of ritual arrows... :V

(oh yeah and if you go for this and want mostly-authentic Japanese text anywhere, just poke me)
 
Mikovania? :p

Well, a more serious title probably needs some more details on what is going on, I guess? Like, what kind of god is enshrined, what youkai are responsible for the issues... maybe some more clear idea of where the shrine is placed?

Since it's water themed, going further with that the shrine might be for a river god - which would often (but not necessarily) imply a dragon - and that might suggest that some central issue is that the river is being polluted or blocked?

There exist way too many youkai to easily narrow it down, but oni are a staple, and jorogumo are at least also often associated with water. Spiders might be a bit tough due to too many parts tho. Probably various forms of hopping youkai might be really useful since they seem easy to make while also allowing for as much visual variety as you can manage. Tsukumogami seem really useful for mooks - umbrella and lantern in particular?
 
Shrinevania if all else fails :V

I had the idea that the Shrine would on/around the top of a mountain, with the miko/kami trying to ascend it, so the kami would be of the mountain, I'd assumed. (Also, animating dragons is terrifying; was hoping for a humanoid figure so we can do the Ico 'pull them around by the hand' thing)

We also need to make very clear what is/isn't "Impure" visually, so they'd need a consistent visual theme (thinking blacks/purples)

I'm not going to go overboard for Youkai due to the time constraints; my current ideas were:
A 'simple' youkai that just moves back and forth along pre-determined lines, trailing Impurity, because they'd be useful in puzzles
An 'aggressive' youkai of some sort that actively attacks the player; like a dripping black/purple figure with an oni mask or something

Combat is more puzzle-oriented than a straight up HP slapfight; you have to get them into a stunned state via water / environmental hazards, then strike.
 
Dragons are well known for taking human form! But a mountain god works just as well, and are also often in human form. If ascending a mountain though, I super recommended spending some time looking at images of Fushimi Inari in Kyoto.

Black/purple sounds good - maybe some red highlights if necessary on the black? I think Okami did something similar and it was very clear.

For the simple, I think an umbrella youkai could be good then - at least I can't offhand think of something visually more iconic that is as simple. Easy to justify pallette swaps too!
 
Quick Day 1 build to smoketest the unity project: everything seems to be working.

Bare-bones player movement and camera is in, and you can invert the camera controls in an options menu / adjust mouse sensitivity / save those settings to a file (this was a problem with my previous Metroidvania Month entry, so I wanted to kick that out the door early).

Otherwise yeah, not much to actually see beyond a quick testlevel.



Tomorrow's tasks include player rotation, an AI character that follows you as an early kami prototype, then experimenting with how to implement water.

Action and Interaction systems also need to built in early/soon (Action = 'do a thing involving an animation' like 'start a jump' or 'do an attack' or 'play a hitstun response'; can only be in one Action at a time. Interaction is for... interacting, ie pulling a lever to open a sluice gate so that water fills the channel)
 
Day 3 Build.

Player rotation is in, and there's a kami NPC who follows you about. Interaction system prototype is also in along with a very early implementation of water.

I mucked around a lot trying different things for the water animation. One fun experiment involved using a high density quad mesh and a texture to describe how the volume should 'fill up' once opened. Unfortunately, all these fancy approaches had the same problems: inconsistencies between visible meshes and collision meshes, and camera frustum culling.

Camera culling is just the game being smart: if something's not on screen, don't render it. It checks for this using the camera frustum (basically, a box cone representing the volume of space the camera can see) and the 'bounds' of the meshes in the scene (another simple box shape that's quick and cheap to perform intersection tests with). If a model's bounds don't intersect the frustum, it doesn't get rendered. These tests are done on the CPU, as a part of deciding what gets sent to the GPU to get actually rendered on screen.

Unfortunately, all my fancy effect prototypes were done in vertex shaders, which is on the GPU, after the culling process. So depending on how exactly I tried to set things up... yeah, the water kept getting culled even when on screen, because its bounds no longer reflected the actual space visibly occupied by the model. There are ways around this, but add the collision mesh problem on top and... yeah.

The final result we see in the build is almost hilariously simple. It's literally just a flat plane. I rotate it a bit at the start of the gate opening animation so it looks like it's flowing outwards (also ensuring it can't z-fight the floor) but... yeah. That's it. It works, and it keeps the collision in synch. It's a keeper. I'll spruce it up with more sfx and sounds later.

Currently the water is 'solid'. You can stand on it. This is actually deliberate: I'm looking to implement it akin to Windwaker where you move around on the water surface but don't dive. It's a loooot simpler to code that way. The player would be submerged visually simply by dint of their swimming animations, which we quite obviously don't have yet.

Speaking of animations! I'm at the point where I need to implement the player jump... which involves the action system. Which involves animation. So yeah, I'm going to be quickly prototyping the miko over tomorrow.

Amusingly, because how nav meshes work, the kami actually can 'cross' the water... because the navmesh can navigate down into the originally empty channel. She has to use the ramp to follow you. Not 100% sure how I'll handle water's effects on navigation / kami yet.

My original thought was that the kami can't swim and so won't follow you into water (mmmmostly for simplicity's sake, because it means the AI navigation doesn't need to know about stuff like water currents). Add bridges and things like that and the navigation mesh is going to have to change quite a bit at runtime. Will have to do some experiments / investigation as to the best ways of handling that. It should be a case of having multiple nav meshes and just toggling them on/off. Hopefully baking all the different cases (ie 'with bridge', 'without bridge', 'without water' etc) won't be too complicated. Or maybe I can bake the navmesh assuming the bridge is in place, then block it with a navmesh obstacle when the bridge isn't down. There's a variety of approaches.

Oh, and the kami's movement can be a little jerky since the current ground movement logic maps input onto velocity directly. I'll improve on that.
 
Last edited:
:S

So apparently the day 3 built "might" be violating Google's terms of service; that's why it's locked. Sod it, next builds go on itch.io.

Leila Hann said:
Is the water-walking going to be an ability you get via exploration, or do you start with it?
Click to expand...
Click to shrink...

It's not a water-walking ability, it's going to be just 'swimming'; it looks like water-walking at the moment because there's no animations.

(Though I say all that, it is quite literally water-walking right now because there's no water detection / 'swimming' state at current)
 
Hoookay, sorry for going dark, had a lot to chew through:

Base character model is now in place (for the player). Needs important stuff like clothes, textures and hair but I'll get to that.
Player is animated, and has animations for running/swimming/falling etc.
Action system is implemented, so the player can actually jump now.
Initial test level is more-or-less complete: a bridge can be lowered on the opposite side, which you can now reach.

Next on the todo list:
- Cleanup kami navigation to be less jerky
- Sort out how changes to the environment like the water/bridge affect AI navigation

Goal is to make it possible to bring the kami to the opposite side.

I think I'll make the current test level the first puzzle room of the game: it introduces you to water and interacting with stuff and the importance of bringing the kami along with you.

Next room should feature Impurity in some manner to intro that, so once the above is solved, I'll get room transitions in followed by prototyping Impurity mechanics.

Day 7 build can be found here (pass is SufficientlyEnshrined)

 
Looking good, I think! :p

I got it to run after Windows reluctantly accepted that I have a right to run strange .exe files I've picked up from who knows where. Not 100% sure if that was the cause of it taking so long to start up or just Unity funkiness, but eh, it's fine. :V

Moving, jumping, camera movement was all fine. It tripped me up a bit that the "invert" options were on by default, but I fixed that. Camera pitch got really sensitive with just a little increase on the slider, I felt, but I don't know if it's worth feeling concerned about.

The puzzle triggers worked and I got the bridge to drop down. However the bridge itself had some issues. From the other side, if you're trying to go back without jumping, you can get "stuck" trying to just walk onto the bridge, trapping the character in some weird animation and not getting anywhere. You can easily circumvent this by jumping, but it's presumably preferable to not have this kind of funky :V



Basically you're stuck like you can see in this screenshot, except kinda twitching from side to side. Collision issue with the bridge is my guess?

The other problem, as you mentioned, is that you can't actually bring the kami along to the other side. :V

The poor thing just stands there, staring soulfully at me.

 
Yeah, the navmesh currently has no idea the bridge exists. I'll definitely be reworking how the bridge collision is handled as part of fixing that.

Ground/Water/Air state logic is very barebones right now. It's part of why jumping seems to cramp your velocity. That 'ledge-hang' bug is a fairly common symptom of that; the short version is that the ground contact normal is coming out at an angle because it's right on the edge, so it thinks it's a slope. Tl;dr blame the fact the player collision object is a capsule. You generally either write a more complicated and smarter ground detection script (which is a pain in the arse) or just design to minimise short ledges/steps like that by putting invisible ramps in instead.

(the even quicker tl;dr is that the ground slope normal is too high to 'stand on', so it goes to the air state, but speaking physically there's nowhere for the player to actually fall and the air state logic is overriding the velocity, so you don't slide off. The fix I haven't implemented yet is to basically have the air state push you away along the contact normals if you've got a contact you can't stand on)

Currently, the bridge's collider is quite literally tied to its visual model (it's on the same gameobject) so it rotates and moves as it visually rotates and moves. This is definitely standin; it makes it a pain to bake navmeshes for and it invites problems later down the line should anything happen to be standing under it when it drops. In future it'll probably be two different collision meshes that get toggled on/off. I'm not really too fussed at the moment since it's a temporary asset to begin with; I'll probably go with bridges that either rise from the floor or extend from walls rather than dropping down like that one; getting trapped under a rotating collision mesh is a very good way to make a player glitch through the floor.
 
Last edited:
Interesting! That's pretty good to know about this kind of movement. Hopefully I'll remember it for That Day I Finally Do Something Interesting In Unity which as we all know is sure to be any day now

On an unrelated note, I quite liked the naginata! I spent a few seconds forlornly tapping Mouse 1 and hoping I would swing it :p

If I were to make a suggestion, with your no doubt oceans of extra time to add in unnecessary details, a tassel on the butt-end of the naginata could be pretty cool. I also vaguely feel like she should be holding it further back so she can grab it with her other hand when she swings, but I guess it might get too much in the way, poking out like that.

EDIT: actually, on that note, would you be interested in some art from Asahinagu? It's a sports manga about girls practicing naganata, and it has some pretty cool images depicting some of the strikes and stuff. I have the entire batch of tankobon so I could run through and find some of them for reference images if you'd like?

EDIT2: I actually put up a few of the images in this post, though I guess those don't really show off the technical movements so well lol
 
Last edited:
Usandru said:
EDIT: actually, on that note, would you be interested in some art from Asahinagu? It's a sports manga about girls practicing naganata, and it has some pretty cool images depicting some of the strikes and stuff. I have the entire batch of tankobon so I could run through and find some of them for reference images if you'd like?

EDIT2: I actually put up a few of the images in this post, though I guess those don't really show off the technical movements so well lol
Click to expand...
Click to shrink...

That would help a lot!

Though in all honestly I'll probably be either looking up videos on youtube or making moves up entirely when it comes to swinging it around; since combat is focused on knockbacks the idea is to have a lot of large, sweeping movements and a long-ranged stab. IRL martial arts, be they eastern or western, never tend to map well to videogames and movies; you want your animations to be distinctive and readable, which means paying a lot of attention to poses and silhouette, and your timings will be completely off from a proper martial artist trying to everything as quick/efficiently as possible. New Frame Plus' video dissecting Link's animations in Super Smash Bros is an excellent example, and Skallagrim's dissection of Dark Souls' animation to get the view from the opposite side.

I should hopefully be able to work in some poses from it at least.

Oddly enough, adding a dynamic tassel on the end was something I was planning to do anyway and is something I can set up super-easily (I have an addon called Dynamic Bone for doing exactly that sort of thing). I was also contemplating sticking a lantern on there as a light-source in dark areas.

(Random amusing technical aside, even though I said the Action system involves animations so I needed to built/implement player animations.... currently, it actually doesn't. There is no jump animation implemented as of yet. One of the bigger pains in the arse where Unity is involved is determining when animation has been completed, which is rather important for judging when a given Action is completed)

Also writing this down as a note to future me:
Update the Interaction system to check if the Interact button has been pressed within the past few frames when an interactable object's trigger is entered. Had numerous cases of hitting the Interact key a few frames too early.

(The jump actually already does something similar to this; you can run off a ledge for a few frames and still 'airjump' to make it easier to control; it's a common technique)
 
Guessmyname said:
That would help a lot!

Though in all honestly I'll probably be either looking up videos on youtube or making moves up entirely when it comes to swinging it around; since combat is focused on knockbacks the idea is to have a lot of large, sweeping movements and a long-ranged stab. IRL martial arts, be they eastern or western, never tend to map well to videogames and movies; you want your animations to be distinctive and readable, which means paying a lot of attention to poses and silhouette, and your timings will be completely off from a proper martial artist trying to everything as quick/efficiently as possible. New Frame Plus' video dissecting Link's animations in Super Smash Bros is an excellent example, and Skallagrim's dissection of Dark Souls' animation to get the view from the opposite side.

I should hopefully be able to work in some poses from it at least.
Click to expand...
Click to shrink...

I pretty much expected this yeah, but hey, I have 6000 pages of naginata sports manga, so why not :V

Anyway it's gonna take me a bit to collate, but then I'll drop you an imgur album, maybe with a few annotations for what's going on since you can't read the text. Probably the "resting" poses are the most interesting, but I'm sure you can figure out what's useful much better than me once I get it into your hands lol
 
Day 8 Build, aka the Navigation Update, is up. Same pass as before.



After a lot of experimental wrangling trying out different approaches, I've finally settled on a combination of multiple navmesh surfaces I can toggle on/off. Ordinarily a navmesh agent cannot actually switch between meshes, but they can with the aid of objects called 'off-mesh links'. Mostly, these are used to mark areas where agents can drop down or jump gaps, but you can also use them to handle doors or, as in this case, cross between completely separate navmeshes.

There are four different navmesh surfaces in this test environment:
1. The navmesh for the 'developer gym' you can see in the screenshot, mostly used to test how the movement system handles various slopes etc
2. The navmesh for the upper half of the bridge room, including the bridge itself in its 'down' position. The bridge navmesh is blocked by a navmesh obstacle until the bridge is actually deployed, to prevent agents just walking off the side.
3. Two navmeshes for the river channel: one for when it's drained and you can run around the bottom, one for when it's full and you can move on the water's surface. The kami won't cross water, but it's important for them to still know where they are if they happen to wind up in it, f.ex because someone flooded the channel with the kami down there.

I'll note the player cannot actually do that currently, because the kami always follows them, but I'm planning to add 'go there' / 'follow me' commands so it's a plausible scenario the navigation system needs to be capable of handling. That's actually next on my todo list for that exact reason.

One big issue I'm seeing is that it's possible for the kami's navmesh agent and their actual physics object to get out of synch... and making matters worse, because of how offmesh links work their being out-of-synch is not always a bad thing; offmesh links basically teleport the navmesh agent to their end position and then wait for the rest of her to catch up. This mostly amounts to careful offmesh link placement which can get very... finnicky.

It's an awkward problem, and one I'm not 100% certain how to resolve. The alternative solution is to have all AI character positions controlled exclusively by the navmesh system (ie agent position = actual position, and all my custom movement code applies only to the player), but this can complicate some other things and make physics interactions in particular something of a challenge.

In any case, the kami can cross to the other side now. Yaaay.

~~~

One design issue I'm starting to notice is that areas designed for the kami to cross != areas the player can cross, or rather, the player has a lot more freedom of movement.

I'm thinking of reworking some of the mechanics to reflect this.

The original idea was that the kami was with you at all times, but this is better suited to a puzzle game setup similar to Portal over a Metroidvania. Instead I'm thinking of making the kami your savepoint / healing station; you can save your game / heal up with her whenever she's enshrined in a... shrine, where Shrines are special objects scattered around the world (think Save Stations in Metroid). So your goal is still to get the kami around the place from Shrine A to Shrine B, but you have freedom to wander off and explore without trying to drag the kami along with you at all times. The player's intermediate goal then becomes figuring out how to get/unlock a route to bring the kami to the next shrine. For sanity's sake, the player should be able to teleport the kami between shrines they've already visited.

Thoughts?

EDIT: also fair warning if you fall off the map in the developer gym area you'll have to quit out; I haven't implemented a respawn system yet
 
Last edited:
To my deep regret, it looks like I'll have to actually test the build tomorrow!

Regarding navmeshes and the kami, if I understand the problem correct, the issue is that if you have an offmesh link - say, for instance, the bridge - then the moment the kami reaches the bridge (and thus the edge of their current navmesh), their navmesh agent is teleported to the other side of the bridge, and the "physical" object is instructed to move over to where the agent is, correct?

However the other problem is that if the player can give instructions to the kami, and these instructions - due to the kami actually obeying the general movement rules - allows the kami to go "off-mesh" in even more cases, effectively leaving behind the navmesh agent. So you end up with two classes of out-of-synch problems where one case is just normal expected behaviour due to some edge case issues in how navmeshes work, and the other is sometimes intended behaviour and sometimes risks the kami getting stuck somewhere it can't navigate due to being off-mesh, and its agent is uselessly left behind?

I'm not sure I understand the issue properly, but as a possible workaround, maybe have an instruction where the kami teleports to the nearest active shrine?

...

For the design question, I of course can't help but think back to Ico and... yeah, separation is important, I think. But ideally the player should prefer being with the kami, since that's part of what encourages the emotional connection. It might be fine with something as simple as a buff aura though?

I'm getting kind of an image of the kami doing the Ico equivalent of holding hands by hovering behind the miko and holding on to her shoulders. If you jump or go into the water she detaches, but for normal movement she follows along like that? Maybe make her model a head or so smaller than the miko? Though I suppose that might make the animation hellish...

Anyway my thought is that there should be some significant but non-critical advantage to dragging along the kami, so that ditching her to do something feels more like "I have to solve this problem so we can get back together ASAP" rather than "why do i have to go back and pick her up every time i try to make progress, ugh".

Hmm... but having to account for the kami definitely makes the design more complex.

idk, maybe I'll have some more thoughts tomorrow when I try out the build.

(status on the Asahinagu images - I've skimmed through to vol 10, but 6000 pages of manga take a while to get through apparently - who could have guessed :V - and I haven't transferred any of them anywhere yet, so expect 1-2 more days, depending)
 
So there's two ways you have can have a character move around in Unity1​: using the physics engine via the Rigidbody component and using the navigation engine via the NavmeshAgent component. In both cases, you have a position and can optionally set a velocity to directly move it about. They both make changes to the character's Transform, which is the component actually responsible for declaring where it is in the world.

With the physics engine approach, your character... obeys physics. Shocking, I know. You set the velocity per frame, the physics engine ensures you don't fall through the floor, tada. This is simple to implement, and lets you do all the fun stuff like jumping and wallslides... but it can't navigate or plot out paths. Excellent for a player-controlled character, terrible for AI.

There is, however, an option to mark a rigidbody 'Kinesmatic', whereby it is present in the physics engine but not controlled by it (which mostly means other physics objects can still hit and react to it).

With the navmesh engine approach, your character is tied directly to the navmesh. Quite literally; no jumping, no walking off of cliffs, you go where the navmesh is and nowhere else. Give it a destination and it can traverse offmesh links if they're along the way, but without one you can't. But: 'you can only go where you can navigate to' means you cannot wind up in illegal locations. You cannot try to get from Point A to Point B and accidentally fall off a cliff along the way. Terrible for player-controlled characters, excellent for AI.

There is, however, an option to have the Agent not control position/rotation. In this case you will have to apply the desired velocity to move down paths via custom scripts, and keep the Agent up to date on where it actually is at the start of every frame.

Only one of these systems can control the character's position at a given time. If both the AI and physics engine are trying to control the transform simultaneously, they conflict; the Unity manual very endearingly calls it 'undefined behaviour'. You have the Agent in control and the Physics kinematic, or the Physics in control and the Agent relegated to pathfinding only. Either or.

Currently, the game exclusively uses the Active Physics approach, with the Agent only doing pathfinding. This is where the problems with the kami navigation come in: where the kami physically is and where the kami's Agent thinks it is can fall out of synch, and where offmesh links are concerned I can't just 'warp' the kami's Agent back to where it physically is because that will prevent it from crossing the link at all. Handing the kami completely over to the Agent might work, but it could also cause other problems when the navmesh needs to make major changes like the channel flooding with water.

1: Technically there are five methods, but the other three are a pain. Root Animation requires... animations, making it hell for prototyping, the stock Character Controller is a godawful, unsupported mess that not even Unity's official examples make use of anymore, and managing a character's transform component directly with custom collision checks and handling is how you get checked into an insane asylum for your own good. Believe me, I've been there.
 
You must login or register to reply here.
Remove ads
Back
Top