How do I make levels in MED?

1 Introduction

2 Planning

3 Plotting the points

3.1 The hotel

3.1.1 The floor, ceiling, and roof

3.1.2 The luxurious rooms

3.1.2.1 The main walls

3.1.2.2 The closet and bathroom

3.1.2.3 The rest of the luxurious rooms

3.1.3 The cheap rooms

3.1.3.1 The main walls

3.1.3.2 Mass production of the cheap rooms

3.1.4 The pool and hot tub

3.1.5 Fixing the pool tiles

3.1.6 The outer walls

3.2 The outside area

3.2.1 Figuring out what to do next

3.2.2 The main grass

3.2.3 The pathway and base for the lake

3.2.4 Creating hills and terrain

3.2.5 The bridge

3.2.5.1 The bridge plan

3.2.5.2 The planks

3.2.5.3 The stumps

4 Skinning

4.1 Introduction

4.2 Laying out the textures

4.2.1 The plan

• Hotel floor carpet - 256x256;
• Hotel floor pool area - 256x256;
• Hotel ceiling - 256x256;
• Hotel roof - 256x256;
• Hotel outer walls - 256x80; // special!
• Hotel pool floor - 160x240; // special! // walls will use the same texture
• Hotel hot tub floor - 80x80; // special! // walls will use the same texture
• Grass and pathway - 256x256;
• Main grass - 256x256;
• Grass to blue fade - 256x256;
• Underwater dirt texture - 256x256;
• Bridge plank top and bottom - 48x5; // special! // plank sides ignored - too thin
• Bridge stump tops - 4x4 // special!
• Bridge stump sides - 4x256;

4.2.2 Positioning textures on the skin

4.2.3 Dealing with odd sizes

4.2.3.1 Optimizing the skin space

4.2.3.2 Odd sizes using repeat textures

4.3 Applying the textures

4.3.1 Preparing the skin editor

4.3.2 The purpose of the stacks

4.3.2.1 Simple stacks

4.3.2.2 More complicated stacks

4.3.2.3 Very complicated stacks

4.3.2.4 Confusing stacks

4.3.3 Moving stuff to form stacks

4.3.3.1 The stumps

4.3.3.2 The hotel rooms

4.3.3.3 The two pools

4.4 Finalizing the skin

4.4.1 Introduction

4.4.2 Special notes about tiling

5 Finalization

5.1 Putting the pieces together

5.1.1 Putting the hotel together

5.1.1.1 The floor

5.1.1.2 The rooms

5.1.1.2.1 The mass rotation

5.1.1.2.2 Positioning the rooms

5.1.1.2.3 Optimizing the rooms

5.1.1.3 The pools

5.1.1.4 The ceiling and roof

5.1.1.5 The outside walls

5.1.1.5.1 Positioning the walls

5.1.1.5.2 Fixing problems

5.1.2 The outdoor region

5.1.2.1 The path

5.1.2.2 Grass to blue

5.1.2.3 Underwater dirt

5.1.2.4 The grass

5.1.2.5 The bridge

5.2 Finalization

5.2.1 Backup

5.2.2 Changing the heights

5.2.3 Critically important backup and the mass merge

5.3 The model for download

6 The pros and cons

6.1 Introduction

6.2 The pros

6.3 The cons

7 Tips and tricks

7.1 Tips

7.1.1 Introduction

7.1.2 Construction phase

• For a single-sided texture (opposite side included (that is, if you have a top side, having a bottom side is okay, but not a front, back, left, or right)), limit stacks to no higher than 1024 high (512 for lower resolutions (below 1152x864)). Too high and it becomes rather difficult to unstack later. For something having multiple sides, such as a crate, limit stacks to no bigger than 256 (128 for lower resolutions (below 1152x864)). If you need more, just build the stacks to the side. When texturing, provided that the group of stacks use the same texture, select ONLY one stack and create the mapping for it. If the mapping's default position doesn't interfere with anything (a vertex too close to an existing one (If this is the case, move the just-created mapping (no selections needed) to a more "hazard-free" spot.)), select the next part of the stack and create a mapping for it (placing it on top of the first one you made), and continue for other stacks sharing the same texture. Then, when done, make a boxed selection on the vertices that were just created and position them as needed. This way, all of them get positioned as if you had one gigantic stack.
• For objects with the same texture, but different sizes (like buildings with varying heights), make a grid on the texture for each of the different possible heights and map all the buildings that way positioning them using the grid as a guide. Sometimes, for improved accuracy and to maintain consistancy, create a simple "dummy" building of the same height of the tallest building you'll have and the same size otherwise (or of your largest one). Position the dummy so it lines up with the rest as if part of the stack, but keep it separated from the main stack to help identify it better. Then, texture it like you would with any other object or stack. When done texturing, line up the dummy buildings and create a mapping for them and delete it after being created to "untexture" them and save disk space (from the skin vertex count; due to a major bug). From there, delete the vertices.
• Use the grid! MED comes with a very handy grid feature, although it's not visible by default. To mimic WED's grid design, do the following:
  
  
  1. Go to file > preferences in the main window (not the skin editor).
  2. Go to the video out tab.
  3. On the 2D view side, make sure all check boxes are checked (the origin is of little use due to it's awfully small size for level creation, so you may uncheck that one if you want).
  4. On the grid lo slider, choose 2 and on the grid hi slider, use 8.
  5. Accept the changes and that's it.
  
  
  The sizing and behavior is exactly the same, except the 16x16 squares are subdivided one step further into 2x2 squares. Otherwise, it's an exact match.
• Always use boxed selections, even for what appears to be just one object! There could very well be two or more vertices "hidden inside" some other vertex that you'll move instead of the one you want.
• Use a large square size, like 512x512 for large, relatively flat areas (sloped areas included if the slope barely changes) and a smaller square size for rougher, more uneven terrain. I wouldn't recommend going finer than 64 though, unless, of course, you have a fairly small level or have extremely rough-looking terrain with a lot of ups and downs and slope changes.
• The polygon count is about 4 times as important as the skin size when it comes to rendering speed. A model with 25,000 polygons will render slowly. A model, with a bigger skin size with 5000 polygons will render much faster. Think carefully about your plan before deciding on how to design the model. However, take into account possible shaders as well. Unlike terrain, you can have varying square sizes.
• When inserting odd objects like pools into floors, holes in the ceiling, etc., have the holes at the edges of the tiles to save some polygons. If centered, it'd take 8 polygons. If placed in a corner, it'd take only 4 polygons instead. Sometimes, however, looks are better, so you decide on how you should arrange it.
• If you are unsure on how many of something you need, you're better off overestimating than underestimating. If you think you need 750 tiles, have 800 or 900 of them. This may cause MED to slow down though, so don't overestimate too much, unless the slow speed doesn't bother you.
• To use copy paste to make a large quantity of objects, first, make 4 of them. Then select those 4 and copy them pasting them three times to get 16. Then copy those 16 and paste them 3 times to get 64 and keep repeating until you get to your desired amount. When the stack gets too high for the best use of doing 4 at once, use 2 instead. That is, once you paste and position a copy, copy the whole group and paste it again, position it, copy it, paste it, etc.. This is one reason why stacks shouldn't get much above 512 or 1024 high. Why 2 and 4 and not 3 or 5? Think of this puzzle:
  
  

  You are given 12 digits. Each digit counts as one point. The points of similar digits can be multiplied to form a grand total. For example, 3 2's, 4 1's, and 2 3's with the rest being singles would yield 3×4×2 or 24 points.

  
  
  123123456456 would yield 2 for each of the 1 through 6 giving 2^6 or 64 points. 121212121212 would yield 6 for each the 1's and 2's and 6^2 is 36 points, nearly half. However, for 123412341234, giving 3 points for 4 objects, 4^3 = 64, the same as you would get for pairs. 3, however, is the best: 123123123123. You have 4 groups of 3's and 3^4 = 81. However, 3 is an unfriendly number to work with in game design. Use it when you need stacks that are a multiple of 3, like the 21 and 24's used in the tutorial.

7.1.3 Skinning phase

• Always use boxed selections in the skin editor no matter what. Extremely often, vertices can be piled 150 high making it take an extremely long time doing them one by one.
• Use face mode to select faces, always using boxed selections, when creating the mappings for them.
• Always allow one pixel of clearance on each side of the textures on the skin image. This will not only help with more seemless tessellation (tiling), but it will also help when you need to reposition a texture on the skin due to moving stuff around to better fit another texture. Otherwise, if the vertices overlap, you'll run into a lot of difficulties when trying to move things around and it'll look screwy in the engine with the haze effect.
• Limit skin sizes to 1024 on any one side. If you were to use a width of 8192 and a height of only 64, there's a very high chance that no system today could run such a thing. Keep skins as square. If you have a 128 MB video card with a maximum texture size of 2048 (on a side), it'd use up only 12 MB out of all that (24-bit texture) and thus you'd have plenty of free space for other things. If you have a 1024x512 skin size, using 1024x1024 is better. Make some of your better-quality textures at a higher resolution to use up more of this space for better detail. Use 512 on any one side if you plan to target very old systems and 2048 for new systems. Avoid using 2048, unless you expect your game to take quite a while to make (like one or two years for example). Use mipmaps to enhance compatibility.
  
• When making levels in MED, skin sizes of up to 4 megapixels (2048x2048) are okay to a limited extent. I wouldn't recommend exceeding 8 megapixels (4096x2048). Take caution when using large skin sizes as some graphics cards can't support it, even if you do use 24-bit color. If you go above 2 megapixels (1024x2048), I suggest splitting your model into separate "components". To estimate video memory usage, take the skin size and multiply by the bit depth in bytes. That is, if you have a 2048x2048 texture in 24-bit color (3 bytes), you'd have 4 megapixels times 3 bytes per pixel or 12 megabytes. The texture in this tutorial is 1 megapixel, acceptable for almost anything. If you target 32 MB video cards, take into account the various objects that you'll have: the beds, nightstands, roof decals, the player and other entities, etc.. 1 megapixel (using 2 or 3 MB) isn't much so there's little trouble with using that.

7.1.4 Finalization phase

• Keep with the very simple textures until the very final version (after the mass-merge). When doing backup using Winzip, the models will compress better, a lot better (like 98% compression versus only 60% at best). This is most effective with large skins (above 256x256).
• If you have too much of something, don't just delete it. Instead, before deleting it, create a mapping for your object and delete it right away. This'll also delete skin vertices saving 8 bytes for each one deleted (and for a typical square as from the tiles, that's 32 bytes and just 32 squares saves 1 KB). After deleting all sides of the skin textures of the unwanted objects, then you can delete the objects. This is due to a bad bug in MED.
• Avoid using copy paste on textured objects. If something has been textured and you really need to use copy paste on it, close MED and reopen it and your file. Select what needs to be copied and use copy paste as you normally would. However, once you copy something, you must paste only what you copied (and as many times as you need to paste it) without using the copy command again. If you need to use copy paste on something else, close MED again and reopen it and your file for each other thing you need to use copy paste on. Again, this is due to a major bug. Failing to do this and if copy paste was used in excess, a skin vertex count of 7 million would be easy to come by using 56 MB of disk space (!) for just that alone, let alone hogging up that much memory plus whatever the rest of the model (and other game objects) uses.
• Use 16-bit color if everything looks fine in that mode without color distortions. If there are strange color distortions, like yellows having greenish hues, use 24-bit color (use a TGA skin without alpha channel) to fix this, but test with 16-bit color first. Avoid using 32-bit color for the majority of the levels. If you need transparent things with the alpha channel, use separate models with smaller skins.

7.1.5 General tips and tricks

• Each time you open MED, right-click on the 3D view and set the view depth (GXL properties) to the maximum - 3800 (the default) isn't anywhere near decent for making levels in MED. MED does not automatically save this setting so you have to set it each time you open MED.
• (all categories) Always use vertex mode when moving stuff. The only exception is when you need to separate a misplaced tile or object from the rest when you make a mistake.
• For things that shouldn't move or can't get a decent LOD system, like buildings, use "my.dynamic = off;" in an action to add to the frame rate and speed up rendering. For animated objects, use a separate model instead. Doing this on 60,000 polies could literally add another 12 frames per second!
• To get true color, add this code in your main function:
  
  

  function main()
  {
     mat_model.ambient_red = 255;
     mat_model.ambient_green = 255;
     mat_model.ambient_blue = 255;
  // ... rest of main function
  }
  

  
  
  For night time scenes, you could use something like 48 for the three values. Dusk or dawn scenes with an orangish hue could use something around 240, 144, and 64 for the values respectively (orangish). The orangish one might look funny though.
• For transparent things, like windows, use a separate model for the transparency and make the spacing as needed.
• Do not animate these large models. If you want something animated, make a separate model of it instead. If you animate the large model, with, say, 20,000 vertices, and 32,000 faces, each frame will use up 240,000 bytes of memory and disk space and is horrible. Animating a smaller model not only will help with the frame rate, but it'll help with memory consumption and disk space usage as well. If you had a fan using 500 polies and 300 vertices, each frame would take only 3600 bytes instead of 240,000. This assumes vertex animation, however, available to all editions (bones animation is only available for commercial and professional editions).

7.2 How to use LOD

7.2.1 How to code it

• -1024, 3840, (128 and 224)
• 1024, 3840, (128 and 224)
• 1024, 3072, (128 and 224)
• -1024, 3072, (128 and 224)

text LOD_warning_message
{
   pos_x = 8; // warning appears near the upper left corner down a ways
   pos_y = 128;
   font = _a4font; // the default font
   layer = 15;
   // string and flags defined through functions
}

action use_some_LOD
{
   /*
   To choose the entity, set the my.skill1 variable to what you'd like.  We'll use 1 for the
   room decorations (the beds, nightstands, lamps, etc.) and 2 for the interior rooms
   (including the interior walls).
   */

   if (my.skill1 == 1) // the room decor
   {
      while(1)
      {
         if (((camera.x < -1024) || (camera.x > 1024)) && ((camera.y > 3840) && (camera.y < 3072)))
         {
            my.invisible = on; // if on the sides outside the building regardless of height
         }

         if (((camera.x > -1024) && (camera.x < 1024)) && ((camera.y < 3840) && (camera.y > 3072)) && (camera.z > 208))
         {
            my.invisible = on; // if above the building on the roof (or directly above it)
         }

         if (((camera.y > 3840) || (camera.y < 3072)) && (camera.z < 208))
         {
            my.invisible = on; // if just outside the entrances (the beds in the big rooms are hidden behind a closed door)
         }

         if (((camera.x > -1024) && (camera.x < 1024)) && ((camera.y < 3840) && (camera.y > 3072)) && (camera.z < 208))
         {
            my.invisible = off; // if inside the building, everything is visible
         }

         wait(1);
      }
   }

   if (my.skill1 == 2) // the interior rooms
   {
      while(1)
      {
         if (((camera.x < -1024) || (camera.x > 1024)) && ((camera.y > 3840) && (camera.y < 3072)))
         {
            my.invisible = on; // if on the sides outside the building regardless of height
         }

         if (((camera.x > -1024) && (camera.x < 1024)) && ((camera.y < 3840) && (camera.y > 3072)) && (camera.z > 208))
         {
            my.invisible = on; // if above the building on the roof (or directly above it)
         }

         if ((camera.y > 3840) && (camera.y < 3072))
         {
            my.invisible = on; // if north or south of the sides regardless of east-west position and height
         }

         if (((camera.x > -1024) && (camera.x < 1024)) && ((camera.y < 3840) && (camera.y > 3072)) && (camera.z < 208))
         {
            my.invisible = off; // if inside the building, everything is visible
         }

         wait(1);
      }
   }

   if (my.skill1 == 0) // if you forgot to change it
   {
      LOD_warning_message.string = "You forgot to specify the entity number (use skill1)!";
      LOD_warning_message.visible = on; // always remain on for a sturdy reminder

      while(1)
      {
         my.pan += 15*time; // rotates the object to give a warning on what object is at fault

         if (my.pan >= 360)
         {
            my.pan -= 360; // if the pan is too high, set it back in range
         }
      }
   }
}

7.2.2 Creative use of the special LOD

   if (my.skill1 == 1) // the room decor
   {
      while(1)
      {
         // other instructions for basic LOD...

         if (((camera.y < 3744) && (camera.y > 3168)) && (camera.z < 208)) // always true if inside the building
         {
            if ((camera.x > -1016) && (camera.x < -760))
            {
               my.x = -888 // assuming your model is centered and mimics the room design
            }

            if ((camera.x > -760) && (camera.x < -504))
            {
               my.x = -632 // exactly 256 quants different
            }

            if ((camera.x > -504) && (camera.x < -248))
            {
               my.x = -376 // exactly 256 quants different
            }

            if ((camera.x > -248) && (camera.x < 8))
            {
               my.x = -120 // exactly 256 quants different
            }

            if ((camera.x > 8) && (camera.x < -264))
            {
               my.x = 136 // exactly 256 quants different
            }
         }

         wait(1);
      }
   }