Creating a new NPC and Level Design By A Newb
I've decided to share exactly what I'm trying to do, stage by stage, so you guys can see the decision making process as I scale some things down, alter others, and just generally try to get as close to my original concept as possible without having to make a full-blown mod.
Thus, the retitling of this thread. Who knows? Maybe documenting my learning process will help others in the future?
As I make alterations to my plans, some things will be removed for one reason or another, and others will be added. New additions will be in italics, and removals will be struck through, so the decision making process can be seen. Reasons for removals will be explained at the end of the class post.
The Original Concept
The Story
A whole lot of blather here. If you don't care about this part, or want to experience it if/when you play the level(s), then do not click this button-->
In her explorations, she noticed a familiar logo, leading her to a very poorly placed storefront in a ruined city. This is where the level begins: In an Aperture Technologies store that is, for unknown reasons (I find it amusing personally) stuck down a back alley in a large city.
In her exploration of the store, she finds little that hasn't already been looted. A few packaged turrets, some detritus from previous scavengers, a few "some assembly required" ASHPD boxes, and a portal gun. Unfortunately, the door is locked, and the window surprisingly intact, making portaling out of the store impossible. Despite having achieved her goal, she must continue on.
Behind the counter, she finds a jolly, candy-like button, which opens a hidden panel in the back wall. Exploring this area takes her down a hallway to a distinctively Aperture Science elevator (Portal 1 style design). As the only way out is through (a running theme in her life), she takes the elevator down to a seemingly disused testing facility.
This area, in extreme disrepair, houses a disposal facility with a bin full of defective personality cores, two of which are still active. One core is a useless byproduct of a failed marketing scheme in which Aperture attempted to make memetic advertising. All it does is spout memes uselessly and constantly. The other (whom I've now decided to call "Dave" as a reference to 2001) begs her to take him with her.
[s]Dave informs Chell that the portal gun she's carrying is defective, and invites her to prove it by having her attempt to attach a portal to a nearby wall. As soon as the portal is established, it vanishes and the gun begins sparking and fizzling. Chell discards the gun, and[/s] Dave tells her he can help her get her hands on a portal gun if she'll help him get away from the recycle bin.
From there, Dave has her attach him to a wall panel, which he uses to unlock a door and attach himself to a Management Rail and lead her to a testing facility.
In the testing facility, they see Atlas and P-Body participating in the Cooperative Testing Initiative from behind the scenes -- after being killed in a test, the two are deposited in an equipment room, issued portal guns, and taken back to the test by Pneumatic Diversity Vent.
Dave positions a Management Rail so that he can knock into Atlas and send him into a conveniently placed wall grinder, then urges Chell to step up and take Atlas's portal gun.
In doing so, Chell finds herself dragged by the conveyor belt into the vent and from there into the testing facility itself. Dave promises to meet up with her in the test chamber, where they can make a break for it.
In the test chamber, Chell must make her way through a simple set of puzzles before her solo track comes in sight of P-Body's. He indicates to her that he needs her help setting up a fling to get him to the exit, where he can open the path for her to get through.
If the player chooses, once P-Body has stepped onto the Aerial Faith Plate that launches him into the Fling, they can change the destination portal to one whose sole purpose is for one test subject to sabotage the other for laughs. Doing so nets an "achievement" which will be shown in the end-of-level elevator lobby. Doing so bypasses a quick interlude at the end of this area, as Dave opens a wall panel and ushers the player out of the level area.
If the player clears the level with P-Body, Dave opens a panel in the ending chamber, urging the player not to step into the disassembler. Doing so [s]nets a different "achivement" and[/s] kills the player.
Everything up to this point is introductory to the real level, which follows:
Upon following Dave behind the scenes, the player enters an area with a long climb punctuated by puzzles in which they must use him as an Edgeless Safety Cube and attach him to various docking stations to switch various devices (stairs, platforms, doors, etc, the usual mishmash of Portal paraphernalia) on and off. The pressure in this area comes from a slowly rising column of goo which automated announcements declare to be due to a malfunction in a pressure control relay and Dave claims is clearly a trap because "she's onto us." At the end, the player attaches Dave to a docking station to activate the elevator out of this level.
Technical Details
What's been done so far:
- Basic layout of the store and planning (lots of planning).
- Implementation (and subsequent removal) of the malfunctioning portal gun.
- Modeling of Dave (about 75% done)
- A dummy texture for Dave, which is serving as a placeholder for now because it's hideous.
Things that have worked:
- The malfunctioning portal gun: A func_portal_detector wrapped around the entire area triggers an env_spark and a command_console (which is used to fizzle the portals) after a half second delay, just enough time for the portal to form and for the player to attempt to place a second portal before the portal vanishes. I added a counter which would keep track of how many attempts to place a portal were made, then, instead of just triggering SparkOnce, just enable the trigger.
- The hidden panel. Well, come on, it's just a func_movelinear on a wall with a piston behind it for decoration.
- Fun with lighting -- making the lights flicker and either come on or die was more fun than it should be.
- Testing the use of env_instructor_hint for later use as P-Body's pings.
Things that have failed me utterly:
- Did you know there is no way to take away the portal gun once it's been given? Nothing I've tried works. This defeats the entire purpose of the malfunctioning portal gun bit. At least it frees up a couple of entities for use in other parts of the level.
- Linked Portal Doors. I knew that sticking a linked portal door behind a func_door would cause it to disappear. Apparently, the same holds true for func_movelinear? Or the linked portal door has to be in a space connected to the player directly, and the fact that my func_movelinear is, in the level design, already in the "closed" position is killing it? In any case, my reason for using it in the first place (to make keeping my level from leaking easier) was pure laziness on my part. I went through the level, tracking down every possible leak instead of enclosing it in a giant skybox like a lazy bastard.
- NPCs. Oh my GOD NPCs. I've tried aiscripted_schedule and scheduled_script (or whatever the hell it's called) and neither one functions properly. I've decided to go the puppetry route and parent the "NPC"s to brushes with func_movelinear and func_door_rotating. It's going to be a hella-ugly heirarchy, but it should work. Fingers crossed.
Other changes:
- I removed the disable turrets because (a) it's mentioned in the commentaries that they never actually shipped them out, only sent them to another part of Aperture Science to be unboxed and disassembled, perpetually. Also, they're entities and I want to run out of entities because of the meat of the level, not because I wanted a bit of scenery. On that note, I may replace the entities I have stuck on the shelves (food cans and water bottles) with brushes textured with some fake Aperture Science Food-Substitute Products (I'm envisioning PORTAL-Os, an inedible Cheerios knock-off featuring a friendly cartoon turret on the box) and free up even more.
Learning Experiences:
- I learned the hard way that displacement maps' lack of visible surfaces on the backside causes leaks. I made a cave area as an experiment, and everything connected to that area leaked until I enclosed the cave in a box. So, yeah, knowledge for the future, yay!
- A lot of the sounds in the sound browser don't work. Ah, well, live and learn.
- Some textures show through other textures. I have no idea why this is, but it's true of a few of the Aperture Laboratories logo textures. Specifically the ones that have transparent parts.
This forced a redesign of the store area, at least until I get around to making some new textures for it.
Plans for the Future
- Dave will consist of a prop_dynamic or a prop_dynamic_override with collisions disabled, parented to a sphere, which will be inside of him. To help keep him from rolling away when he's set down, the sphere will have a couple of invisible brushes parented to it overlapping his handles.
- The NPCs are still in. If I can't make them at least pretend to behave like NPCs, I will keep bashing my face against the keyboard in the hopes of magic happening... or out of frustration.
Use a trigger_weapon_strip then you can just spawn a model of the portal gun that the player drops or gets fizzled.
Use a trigger_weapon_strip then you can just spawn a model of the portal gun that the player drops or gets fizzled.
YOU ARE MY HERO.
Why did this trigger not show up when I searched using the term "strip weapon"?!
And now it does...
Wait... I didn't use the term "strip" when searching the wiki, I used "remove". I used "strip" when google searching.
Although I think I'm going to try to use the point entity instead (assuming it works in Portal 2) as I won't have to wrap half my map in it, and it will help keep my map tidy. (I'm going to be reorganizing soon, moving all my logics and similar point entities to a single location where I can easily sort through them. I may graph out their relationships with brushes, too, like a flowchart.
Make a small weapon strip, parent it to the player, SetParentAttachment forward, now it'll always be covering the player.
I'm seeing a pattern here... Is there a reason you guys prefer using brush triggers to point entities? My understanding was that both count as entities, so I would prefer to use a point entity for consistency, personally. However, that's just me, and if you guys have a reason I should use the brush instead, I'll definitely listen.
I'm seeing a pattern here... Is there a reason you guys prefer using brush triggers to point entities? My understanding was that both count as entities, so I would prefer to use a point entity for consistency, personally. However, that's just me, and if you guys have a reason I should use the brush instead, I'll definitely listen.
From my experience with custom tank based weapons, a point entity of it just puts down the portalgun, but still allows you to shoot.
Aperture Science: We do our science asbestos we can!
The brush version works consistently, and I have experience with it. If you find a way to do it with a single point entity, by all means go ahead. 
Player Strip point entity worked like a charm! Hooooowever.... For some weird reason, the OnFirePortal2 output of my portalgun isn't triggering. I can work around that either by making it a single portal gun or by putting the Portal Detector brush back on the map again (ugh, big ugly box around part of my level)... Or just have the portal-gun misfire only on primary fire, which is fun. I can use prop_portals to cause it to fizzle either the blue or orange portal, so you can set up a set of portals, but attempting to move the first one causes the second one to fizzle...
Another learning experience: Did you know prop_dynamic_override doesn't disable the weight of the model? I parented a personality sphere to a ball as a test, and the darn thing was too heavy for the portal gun to lift above eye level.
Really? Children shouldn't affect their parents as far as physics is concerned. Try setting its collisions to Not Solid, sometimes the portalgun decides it doesn't have LoE to the object and drops it if you have a parented model.
And try a logic_playerproxy or a game_ui. The OnFire... inputs are only for weapon_portalguns, which don't exist once the player grabs them.
It already was set to Not Solid. Also, the personality_core.mdl is slightly smaller than the ball.mdl, so nothing was visible anyway. Still muddling through on that one... I may be able to use my custom core as a generic_actor and just use SetParentAttachmentMaintainOffset to pick him up and ClearParent to put him down. Actually, I'll try that with Wheatley right now...
That's really weird, because the primary fire worked like a charm. So the OnFire routines are supposed to trigger when (for example) a mounted portalgun is fired by a trigger (like the ones in Portal 1)?