WHOOPSERVATORY SCRIPTING

Background

The main reason I made Whoopservatory was to use a gameplay mechanic that I originally wanted to develop into a full-scale mod. I had played a Java game called Cursor*10, where your mouse-movements were recorded as you played and when a timer expired you restarted the level while your previous actions replayed. You were playing coop with yourself! I thought that was neato and I wondered if it could be successfully put into a FPS. Since Source is the game I have the most scripting experience with (coupled with the fact that I don't have any programming experience), it seemed obvious to prototype it in Source.

When I started prototyping I started out with 3 clones. The goals of the tests would require all of these clones to do their job, and eventually the player would get through the test-rooms and proceed through the levels.

Apart from being a complete mess when it came to scripting (it once broke and I got cold sweats and a headache trying to figure out just what had broken), it was also frustrating for the player since if you screwed up clone 3s pattern you could abort, but you would need to redo the movement of clone 1 and 2 as well. So essentially it was a whole lot of repetitive actions and no fun at all. I simplified it to 1 clone, which restricted the actual puzzles themselves, but made it less frustrating for the player.

Implementation

I have no actual programming skills but I do have a solid grasp of Source scripting, so I used what I knew and came up with this setup.

When the player activates the Cloning Machine, he is moved into a ready position. Once there, 7 Scripted_Sequence entities (entities which AI characters use for scripted movement) are parented to the player. The player is released from his ready position and once he moves out of the machine a 7 second timer starts. Each second that passes, a Scripted_Sequence entity is un-parented from the player, staying in whatever position the player was in at the time. This continues until the 7 seconds have passed and all Scripted_Sequence entities are placed in the world.

When the 7 seconds are up, the player is forced back into the ready position. Once back, an invisible NPC character is spawned (with effects and such parented to him), this guy is scripted to follow the 7 Scripted_Sequences in order. Once his movement-sequence is complete, he will be despawned and spawned back at the start-point again and repeat. This sequence can be repeated indefinitely.

This NPC character also has special triggers out in the world, so if the player moves onto an Activator Platform when he is performing his actions, the Clone will trigger events in the world when he follows the players footsteps. This is used to open doors, power buttons or enable environment hazards.

If the player isn't happy with his recorded actions, he can return to the Cloning Machine and re-use it. This will delete all scripted_sequence entities, kill the NPC and reset everything. His new actions are then recorded, and the sequence repeats.

Entity Setup
Pictured: Entites used in one instance

Technical issues

During development several issues popped up. For instance, the players HEV suit had to be taken away each time the player went into the machine, since if he used his Sprint function he would be able to travel further than the NPC would be able run in the same amount of time. This resulted in a cleaner hud while in cloning mode, which was nice.

Another player movement problem was that if the player jumped while in cloning mode the exact second a Scripted_Sequence entity was being dropped, it would end up in the air and the NPC would not understand how to get it, forcing him to stop. This was worked around with disabling the players jump-ability via some console commands while in cloning mode.

Since the clone is supposed to be a "ghost" of the player moving around it didn't make any sense that the (invisible) NPC had collision and could bump into the player. This also interferred with the NPCs AI. Sadly it's impossible to make NPCs non-solid in Source. However, monster_generics CAN be made non-solid, so the NPC had to be exchanged into one of those instead. This made ANOTHER problem apparent...the triggers which all world-interaction depended on did NOT work with a non-solid NPC! Since he was non-solid he could not be detected up by the triggers! So, a workaround had to be made again. Since the NPC under no circumstances could remain solid, but all triggers needed to work I had the bright idea of attaching a solid object to the NPC which would follow him around and trigger stuff. This could of course not interfer with the player either, so it was placed above the players reach. End result, an invisible fuse-prop hovers above the NPC and does the actual triggering of in-game events.

Pictured: Fuse Guy

The last problem was something that couldn't be worked around. Since this whole thing was a extremely cobbled-together hack, the clones movement was not matched 1:1 with the player. It's also quite choppy when he reaches a Scripted_Sequence and starts moving to the next one. This restricted the design of the puzzles quite a bit, and they have to have quite a bit of leeway to compensate for inaccuracy.

End result

Overall I'm happy with the end result, and it was nice to actually do something with the concept. And if you didn't like it then you hopefully liked the singleplayer map which wrapped around it! Thanks for reading.

Return to portfolio