March comes, March goes. Lion, lamb, all the usual stuff.
March is always a busy month, what with GDC and sundry work-related conferences and travels. And this year, of course, there was PAX East. Man, how I wanted to be there for that. It was, by still rare accounts, an amazing show of force by the IF community, and from what I can tell a great time was had by all. It sounds like there was a groundswell of new or renewed interest in IF, which can only be a Good Thing. And, of course, GET LAMP. I can’t help but feel like I missed a significant event in IF and the opportunity to meet some great folks, but at the same time I am excited that it occurred and grateful that there are those who could make something like that happen.
Making things happen is a good theme to maintain, so let’s do that.
The last of the six NPCs we are bringing to life is Cecilia, the girl who suddenly appears at the monastery and…well, you either know what happens next or you don’t, and that’s not about to change now. There’s a reason I had saved her for last, though, and it’s not because she’s the easiest.
The main problem with Cecilia is that she doesn’t conform to the usual NPC implementation pattern. For most NPCs, each Act (mostly) consists of a simple set of idle animations and an extended set of conversation animations. The character typically stays in one location (Matteo in the tower, Constantin in his room, etc.), doing his own thing, and responding to the occasional player question. Pretty straightforward.
Cecilia, of course, makes things far more difficult and challenging. (I could mention at this point that this is partly why we made her a redhead, but I know far better than to do that.)
The main reason is that there is a portion of Act I where Cecilia acts like an object rather than an NPC per se. Without giving too much away, the idea is that, after she collapses at the front door, the player is supposed to pick her up and carry her to the locutory to be placed on the bed there. That means I have to implement her in two additional forms that are different than the usual NPC: as an inventory object (so she shows up in the visual inventory while being carried), and as an object that Torque calls a “ShapeBaseImage” – an object that mounts to the player and is displayed as part of the HUD in first-person mode, the same way a gun would appear in the camera view in an FPS game.
Cool, but what happens when you hit the "fire" button?
Neither of these is particularly challenging, though; just time consuming, and the implementation requires special code coordination to make sure it handles each of those correctly.
The real challenge occurs when you consider that, while being carried, she should be handled just like any other inventory object. Which means she should be able to be dropped at any time.
Dropping creates all kind of issues in a 3D first-person game. When you drop something, where do you drop it? In front of the player? Directly at the player’s feet? Do you want to show the object falling to the ground, or just make it appear on the ground immediately? What happens if the player is standing right in front of another object, and there is no room to drop it? What if the player is standing directly in front of a wall? What if the player wants to drop the object on the bed, but isn’t facing the bed at that time?
A closeup of Cecilia as "inventory object". It's dehumanizing, I know.
Another part of the equation is that NPC objects have collision boxes, just like the Player’s object has. So when you drop the girl, her collision box immediately interacts with the player’s collision box, causing all kinds of havoc. That requires all sorts of workarounds to make sure the collision boxes don’t interact, but that, in turn, tends to complicate other matters.
On top of that, rather than just teleporting her static body immediately to the ground near the player (or the bed), I’d like to give the whole process a bit of life by including an animation that shows her hitting the surface and coming to rest in her idle position. That means timing the whole process of dropping, starting the animation, and hitting the floor.
So in the end, we’ve taken the relatively simple process in IF of dropping an inventory item and proceeded to make it horrendously complicated. Go team!
More on Cecilia to come.
Enjoyed this article? Subscribe to The Monk's Brew RSS feed.
5 Comments
I assume you are implementing her as (at least) two different objects – there’s the Celia NPC AI character and a Celia inventory object? With some magic transition between the two?
Correct — actually, there are three forms: the AIPlayer object, the StaticShape object (for the inventory object), and the ShapeBaseImage object (for the mounted image displayed in the HUD as above).
Basically, when she is picked up, I hide the AIPlayer object, mount the ShapeBaseImage object to the player, and activate the StaticShape as an inventory object. When she is dropped, I just do the reverse, but I also have to move the AIPlayer object to the correct new position before un-hiding her.
I added another screenie showing a closeup of the StaticShape used in the visual inventory.
Why let the player drop her anywhere but the bed?
Orthogonally, why not implement the verb drop as “gently put down” in this one case? Meaning, the viewpoint suddenly dips down, and pauses while the carried_model vanishes and the lying_down_model appears right in front of you, then lifts up and gives the player back control? Would that reduce your animation concerns?
That’s a fair question. One reason is that I want to implement the game the same way it was originally implemented in text; so since the original allows the player to drop the girl, I’d like to follow that. A second reason is that the game tries to give you the impression that you can’t carry her for long – if you try to do certain actions, such as “inventory”, you’ll get the following: “Your knees are beginning to buckle. You had better do something with her before trying anything else.” Even though you’re never actually forced to drop her, it essentially conveys a sense of urgency that might cause players to want to drop her so they can, in effect, take a moment to figure out what to do.
Not great reasons, I’ll admit. I may end up doing that if it proves to be too difficult to allow dropping.
As to your last point, I think that’s a valid idea. I can look into the idea of implementing a “crouch” type of animation to provide that, but there are still the issues with collision and how to deal with the situation if, for instance, the player tries to do that while standing right in front of a wall.
Thanks for the ideas…
And what about make an “virtual” fake bed in each room where the player could drop safely the girl. That could save a lot of hassle. Oh! I forget, you don’t have paths so the main character could walk automaticly… a pity.
Well, maybe something like: you can`t drop the girl safely here. Try near the centre of the room.
It is a pity example, but maybe it could trigger a good idea in your mind.
Regards,
PD: The screen-shots looks awesome.