No announcement yet.

Papyrus (working title) Complete Documentation

  • Filter
  • Time
  • Show
Clear All
new posts

    Papyrus (working title) Complete Documentation

    Papyrus (working title) Complete Documentation




    Papyrus is an Egyptian Science Fiction level. I will be using it to document my entire process I use when starting a new game/level.

    First of all, I like to start every level on paper. Sketching up gameplay ideas, cinematic storyboarding, interesting looking scene, and so on. I try to come up with as many achievable gameplay elements before jumping into UDK. These are all rough sketches of basic concepts to be expanded once in tested in game.

    I'll post this picture later because it's important to understand that drawing skills don't matter. It's about getting ideas down on paper.

    Setting up my test level

    Build a test level you can drop in all the gameplay, test art, etc. into. For these, I like to drop in a few brushes for floor, and go from there.

    After opening UDK, then first thing I setup in a new Package for a project. I do this by creating a placeholder material. Right click in Content Browser, click New Material. Name the package, group and material itself based on your project's naming conventions.

    With the material editor open. Add a constant. It can be found in the Material Expressions list or simply hold 1 and click. The constant to 0.5, and plug it into the Diffuse and Specular. The reason for this is to create a nice, blank material to apply to all placeholder assets. Being 0.5 it's a neutral gray that allow me to see any smoothing errors on meshes.

    With the placeholder material down, I drop in a brush (2048 width/length, height 64, but doesn't matter) it's just a test floor to run around on. Add a Dominate Directional Light (to evenly light the world), and a playerstart.

    Since I don't want the default hud or weapons, check No Default Inventory For Player in world properties, and setup a ToggleHUD in Kismet. I also added console command: setspeed 0.6 because the default run speed in UDK is hilariously fast.

    With these in place, I have a nice, clean area to run around on, build and test things without any of the default UDK assets. We're officially ready to go!

    Next post: Laser Beams!

    Laser Door

    I'll be using Kismet to create a timed laser beam that blocks the user.

    In max, I modeled a door collar with spots where the beams will come out, and the beams themselves as a separate object.

    Once imported to UDK, applied the blank material to the door, and made a new, glowing orange material for the beams themselves. For the material, I plugged in a very bright constant (so it glows) as a Vector Parameter. This way, I can quickly make Instances of this parent with whatever color I choose. In this case, orange.

    Let's place that in the level.

    Everything is looking right, now it's time to make it work. The idea is pretty simple, I want these beams to turn on and off. When they are active if the player touches they are penalized. If the player moves through them quickly enough while deactivated success.

    I don't want to kill the player in the case, simply teleport them back. That's easy enough by setting up a Dynamic Trigger Volume where the beams are that teleports the player back to the spawn spot.

    Next is toggling all of this on/off so the player has a window of opportunity to move through it. This is why I used a Dynamic Trigger Volume before. The beams need to be a InterpActor so they can be hidden. In kismet, I use a combination of Delays and Toggles. With this setup, the beams are active for 2 seconds, then deactivated for 1 second.

    Simple and effective. Now that this gameplay is in place, it can be reused in a huge variety of ways which will be discussed later.

    Video of this in action


      thank you max power..!! keep it up


        Killer Light! aka Searchlight

        This is similar to the Laser door, so I wanted to keep them together. The idea behind this is creating a search light that activates when the player walks into it.

        Setup a Spotlight Moveable however you'd like it to look. I used a Cylinder Brush for the Dynamic Trigger Volume to mimic the spotlight's round shape.

        Matinee is then used to animate the light around the room. With the light selected, hold M and click in kismet to make a Matinee. Double click it to open it

        Right click outside of the track editor and add a new Empty Group, to represent the light. Right click on this new group and add Movement Track. With the movement track selected, move the time slider where ever you want it, move the light around, and hit Enter back in Matinee. This places a keyframe, which is (in this case) basically location/rotation coordinates for an object over time.

        For this light, I wanted it to move to one side of the room, wait a second, return and repeat. So I placed three keys. 1 to move, 2 to wait, 3 to move back and an additional second after that to wait. In the Matinee's properties checked Looping.

        Use an Attach to Actor to attach the Dynamic Trigger Volume to the light. And as before, used a teleport for the trigger. This will most likely be placeholder. As the design progresses into the actual scene where something like this is used, it can be incorporated to a much more elaborate chain of events. The teleport is a placeholder.

        Here's a video of that


          Thankyou so much for doing this, this will help me so much later on


            Great stuff, this will help me and alot of other people too!


              Max Power, thanks for this thread and actual Kismet sequences.
              I already had laser beams implemented via uscript, but your "teleport back" Kismet part is a real blessing for creating checkpoint-based puzzle adventure (with no reloading level).

              Please, keep 'em coming


                Originally posted by merc-ai View Post
                ...your "teleport back" Kismet part is a real blessing for creating checkpoint-based puzzle adventure (with no reloading level).
                That's exactly why I love them.

                Also, if anybody wants to kill the player this teleport can be changed to a Modify Health OR you can replace the trigger with a Dynamic Physics Volume that's pain causing (setup in properties).

                Next up...

                Rotating Physics

                Any interpactor can have it's physics set to rotating in it's properties. The Rotation Rate sets the speed. The pitch, roll and yaw represent rotation on different axis.

                This can be used for all sorts of interesting gameplay and art.

                A basic example is rotating platforms. In max, I modeled three sets of boxes all with the same, center pivot point. Placed in UDK with rotation applied, these all spin around the centerpiece to create a navigation/timing puzzle.

                Let's look at something more complicated. This is an interior hallway that is rotating. It also has laser beams, as above, only rotating instead of toggling. This hall also has three doors on it as well as some KActor sphere to roll around and add to the effect. (The KActors are sphere static meshes, converted to KActors after being placed, and checked to Wake On Level Start in their properties).

                Maintaining the doors in their position was as easy as attaching them to the hall. They open and close, keep collision, etc. This works great for elevators, subways, lifts, etc.

                The Kismet work here is mainly attachments. For now, the doors are set to automatically open after a delay (for show) until their proper activation is setup in the level.



                More to come! Including taking control of a maintenance bot that pushes around these balls.


                  Great.., I like the starting idea, continue and good luck


                    Maintenance Bot

                    This gets a little more advanced.

                    InterpActors (Movers) with collision can push KActors with ease. A block can be too heavy for the player to move, but no problem for movers. The orbs moving around inside the rotating hall are a good example.

                    While experimenting with creating a shield, I noticed this also works with InterpActors attached to the player. In this early example, I attached a box to the front of the player that has collision. The stone is immobile normally, but by pushing it with a mover, this is no problem.

                    Pushing things around is great, but that wasn't the original plan for the maintenance bot so much as a happy accident. The bot's first purpose was to allow the player to traverse tight, compact areas.

                    First, I modeled a simple placeholder robot shape, and built collision around it. In this case, I modeled it to be around the player as though this is a vehicle.

                    The Kismet is pretty simple. Starting by using a changesize and setspeed console commands to shrink the player down so they can fit in small spaces, Attach the bot model and 3rd person camera, set the camera, teleport the player to the bot's location and finally set the bot meshes' rotation just in case it was oddly rotated. I will likely give this more features as the level develops, but this works for now.

                    In the level, I placed the interpactor of the bot, a pathnode to teleport the player to, and a camera to achieve third person view while playing as the maintenance bot. I also placed a trigger to switch between the two forms, and a pathnode to teleport the player back to "normal". It's represented more like remote controlling the bot.

                    The Kismet for switching back starts by setting the location of the maintenance bot mesh. This effectively detaches the model. Teleport the player back, use console commands to reverse size & speed changes, and set the camera back to first person.

                    Using a switch on this trigger allows me to toggle control between the normal player character and the maintenance bot.


                    Screen grab as it appears in the editor. A KActor block falls, blocking the path. The player controls the bot to put it out of the way.

                    Check out the video to see how it all works:


                    Who know's what's next!


                      Thanks so much for this thread. Interesting and very helpful!


                        These are great tutorials. I just want to point out something very minor about your laser door: you don't need to use a DynamicTriggerVolume. A DynamicTriggerVolume can be moved around where a TriggerVolume can't, but the events for either can be toggled on and off just as easily.

                        Here's how I'd do it with a regular, static TriggerVolume:

                        Toggling the event instead of the trigger gives you the same result, but it's (arguably) cleaner and it allows you to use a static TriggerVolume instead of a DynamicTriggerVolume. The difference in cost is probably negligible, but it's good practice nonetheless. Of course, if your beams animated from off to on instead of simply disappearing, a DynamicTriggerVolume might be a good call, since you could move it in Matinee to match the animation of the beam mesh.

                        Speaking of Matinee, you could also use a looping Matinee sequence to implement the same thing as above:

                        It's mostly a matter of personal style, but imo the concept of a looping sequence is clearer as a Matinee sequence than a bunch of daisy-chained delay nodes. It'd also make it easy to add sounds, emitters, animations to that self-contained sequence.

                        Once again, really nice tutorials. Keep up the good work.


                          Thanks for the info, wasabimilkshake. Absolutely applicable.

                          I've been real busy crunching for work, if you're interested in seeing what I do, check out this link

                          To keep things moving forward here, I'm dropping a variation of the laser door, it's the timed laser floor (the floor is lava!)

                          The idea: hallway has a security system the player can't move through. However, using a trigger deactivates it for a short amount of time.


                          Using InterpActors for the beams, a Dynamic Trigger Volume for the teleportation, and some Point Lights Toggleable. I set a trigger to Toggle them, and also a Delay to reactivate them. Simple stuff, but highly effective, especially in a situation you don't want to player to immediately backtrack.




                          Looking forward to getting more time to sink my teeth into some in-depth design and art style documentation.


                            This is a great thread. Thanks for sharing your ideas. I wanted ask if there is a way to tell how one Kismet sequence is more 'expensive' than another when they both do the same thing. Take the example of the laser door and two approaches presented by Max Power and wasabimilkshake (cool nickname BTW ). How can I tell which one costs more processing power, resources etc?


                              wookash_b: afaik, in kismet every active sequence is checked each frame. Some things are going to end up being more expensive than others. As with all features, optimization is important, make sure things aren't running if they don't need to be. etc. The UDK Mobile section has a thread discussion the issue of too many kismet sequences which may give more details on kismet performance.