Prop Randomization Tutorial

Discussion in 'PropHunt' started by Geit, 21 Nov 2009.

  1. Geit Coding wizard!

    Prop Randomization Tutorial

    So, a few of you have been asking me how the randomization in warehouse is done, most of the people who have tried to copy it by decompiling have failed (Maze) or have just given up on getting it to work.

    The randomiser in Warehouse uses a system called DiceMod by |ÅΩ| Blue From Alpha-Omega Clan which he kindly gave me permission to use(and now, to describe/redistribute), the system allows a pre-made layout for each section (Warehouse does it by quarters) of the map to be chosen and rendered. The system supports as many layouts and sections as you can fit within the entity data limit.

    Attached is a copy of Warehouse (for educational purposes ONLY), and an example map to highlight the mechanic and to use as a reference.


    In this tutorial/overview I will be using Warehouse as a reference, bear in mind though, that most of the rules still apply if you are doing your map by sections rather than quarters.

    Setting up for the randomiser

    First you will want to split your map into quarters, I did this by placing 4 Lx32xH brushes (Textured with toolsinvisible) to divide the map, if there are any props inside these brushes, they shoud be moved closer to the center of that quarter to avoid overlapping with other layouts that may be hidden by visgroups at a later stage.

    View attachment 1840

    You then want to import the entities from the example map I've provided below (4x logic_case, 1x logic_auto, 1x logic_relay)

    Mapping for the Randomiser:
    When mapping for the Randomiser, it is easiest to just re-detail the whole map as 1 PropSet by hiding all the other PropSets via VisGroups. When detailing, avoid crossing the brushes you have established as the edges of the quarters to avoid overlapping props.
    View attachment 1841

    Be careful when making a new PropSet, ensure that there is enough space left in the entity data BSP lump (The size and % full of each lump is shown during VRAD during compile) to make an entirely new one. (The entity data lump CAN be larger than 100%, but may cause crashes if it exponentially larger.)
    View attachment 1842

    Compiling the Randomiser:


    • Make sure that there are no overlapping props from different quarters
    • Make sure all prop visgroups are ON
    • Have a cookie because you just finished your map.
    Summary:
    The Randomiser can be used to create diverse and fun maps that are hard to memorise while being easy to understand, it may also be used to randomise the complete layout of the level via func_brushes or enable/disable the execution of special events such as traps. But, Going too far with the randomiser will result in an inconsistent player experience, or just a huge mess.

    Enjoy!
     

    Attached Files:

  2. Geit Coding wizard!

    Bump/Sticky.
     
  3. ... I have absolutely no idea what you just said. Or at least, I think I do, but to borrow from another source, I understand what all those words mean individually, but in that particular sequence...
     
  4. Geit Coding wizard!

    My intention was not to guide you though the whole process of 'Making a map' only to cover some ground rules on the randomiser and give you two examples and let you work from there.
     
  5. Yes, but you didn't explain what's going on. From the description I must have four quadrants on my map, and it's required to have everything set up this particular way, but there's nothing here that'd really help someone understand what they're doing.

    If I'm understanding things right, looking at dice_mechanic.vmf, it works this way:

    the Logic_auto entity activates at the start of each round, thanks to the OnMultiNewRound part, and it then proceeds to trigger the logic_relay and each logic_case.

    The logic_relay (labeled "hide") wipes the map clean, removing all props, collision meshes, and shadows. This keeps the props from one round showing up in the next, which could cause overlap and general messiness.

    The logic_case entities (labeled "case_1" through "case_4") each pick a random case from up to 16 possibilities. Depending on which case they choose, a given group of props (such as "PropSet1_1") is enabled along with the collision mesh and shadows. Once all of the logic_case entities have been triggered, you have your randomized map layout.

    So long as none of the possibilities from case_1 overlap with any of the possibilities from case_2, they're fine. So if you made sure all of the possible layouts from case_1 were in the same quadrant and didn't overlap into other quadrants, you'd know case_1 was a 'safe' setup. You just have to make sure that no props that are in that quadrant and in the same group (i.e., everything in "PropSet1_1") overlap- which is no different than usual for mapmaking.

    You'd probably want to handle the layout for each prop set separately, and then move them to the map once they're done, just to keep track of what's in which set. It could be helpful to create a mock-up of the quadrant you're creating each set for, much the same way that copying and scaling down your map helps plan out a 3D Skybox. That way you don't have to guess at distances and such.
     

Users Viewing Thread (Users: 0, Guests: 0)

Users found this page by searching for:

  1. overlapping props tf2

    ,
  2. cookie randomisers

    ,
  3. I understand all those words individually