Building houses

Abstract

Concept picture of building created from building blocks (thumbnail). A building is a collection of building blocks (or other items) that may or may not be attached to each other. This definition is broader than just houses. Examples of buildings are a clay hut, a palace, an underground complex with tunnels (tunneling will not neccesarily be implemented in Mason), a fountain, a flower garden, or a stone monolith placed on top of two others to produce a rough gate.

This document describes the steps of the building process, the anatomy of building blocks and how the building blocks fit together.

Document History

VersionDatePersonThings done
0.1.0 2000-07-02 zzorn Initial version.
0.1.1 2000-07-03 zzorn Added flag outline idea by Malcolm, changed the standard material sides, added multiple material graphics and client rendered procedural textures.
0.2 2001-09-15 zzorn Updated the whole document to reflect current status: removed old references to restrictions on rotating blocks, split out some of the template texture lists, added links to related documents, added a picture, and made other updates and fixes.

Related Documents

The following documents contain related information.

Related Discussions

Glossary of Terms

Terms used or defined in this paper, and their definitions.


Build process

The steps involved in creating a building are creating a blueprint, obtaining building material, selecting a location and assembling the building.

Create blueprint

A building is normally created by first making or acquiring a blueprint for it. The blueprint contains information about the placement of building blocks and items used, the material of the building blocks, how the building blocks are attached to each other, in what order different parts of the building should be assembled, where to dig out or fill in land (not neccesarily implemented initially in Mason), and various general information such as a name and description of the blueprint, and comments about various parts of the described building.

Obtain building materials

After a blueprint is available the neccesary building blocks and items need to be obtained and transported to the building site. If ready-made building blocks aren't available they have to be created from raw materials. If the materials described in the blueprint aren't available locally, the blueprint can be edited to substitute them for some other materials.

The game and user interface should offer some easy way to mark some items as building material for the building and calculate what items are still needed.

Select building location

The next step is to decide where the building should be placed. With the blueprint at hand it is possible to se a transparent outline of how the building would look at a given location close to the viewer. It is also possible to rotate the building. When a suitable spot is found it is locked as the building site. This is indicated by a stick with a little flag, pointing in the 'north' direction of the building blueprint and corresponding to the ancor point in the blueprint (the ancor point can be changed in the blueprint). The four corners of a bounding box of the building can optionally be marked with four sticks that have two flags pointing along the edges of the box. In some cases it is not possible to place these flags (for example if they would be in water). More flags might be used to more closely mark out the perimeter of the building.

Assemble building

Finally the building is assembled at the building site from the neccesary building blocks, using the blueprint as a guide. This step can be done by many people if each have a copy of the blueprint or the part of the blueprint they are working on.

During the construction process it may be neccesary to create temporary constructs to lift heavy building blocks or prop up bridges or floors untill the final support is built. This could be supported by the blueprints by making it possible for blueprints to specify the relative order of some parts of the building, and allowing dismounting of structures at some stage during the building.

It is also possible to start building before all needed building blocks for the whole building have been created.

Automating the process

The whole process of material acquirement, material transportation, building block creation and building assembling should be possible to automate and distribute to multiple workers. For Mason at least building assembling has to be possible to do automatically, given a blueprint and the building blocks.

Note that it is also possible to do each step manually, so a blueprint is not actually neccesary. You can just create building blocks and assemble them together by pushing them around and attaching them. However, blueprints offer the benefit of easily testing out different designs, with easy undo. It is a bit like the difference between paper and ink and a text editor.

Summary

  1. Make or obtain a blueprint of the house.
  2. Create building blocks and aquire raw materials for them.
  3. Select building location and orientation.
  4. Assemble building at the selected location using the blueprint and building blocks.

Building blocks

Houses and other buildings are created from building blocks (although it is also possible to include normal items in a building plan, usefull for statues for example). The normal size of a wall building block is about two meters wide, three meters high and 0.25 meters thick. A building block has two important properties, its shape and material.

Shape

The shape is the three dimensional form of the building block. There is a number of standard shapes (around 100). The shapes can be either normal 3D meshes or Parametrized Building Blocks Examples of shapes are walls, floor tiles, slopes, wide walls, low walls, and so on. The standard shapes should be used as much as possible. New shapes can be added if it is clear that the existing shapes are not enough to express some useful and common construct. The requirements of a good shape are:

Material

Each material type has some datastructure that contains the properties of the material. It also contains a reference to the media that is used for the texture of building blocks from the material. There are a number of Texture Templates that define the sizes and purposes of different textures (for example, arcs of small and large diameters have own textures). The 3D meshes making up the building block shapes are textured with these template textures. When a specific building block instance is rendered, the template texture names are replaced with references to the corresponding textures specified by the material.

The media for a material can include texture, height map, alpha map, reflection map and so on for each texture size / type. It is not neccesary to have all of the above maps, it is also possible to just specify one color and alpha value, etc.

Procedural Textures

Instead of a texture the media could also be a reference to a procedural texture description. In that case the description (a small text file) is downloaded to the client and the texture is rendered on the client and cached for future use. This has the advantage that texture downloading times can be very low, and the client can render the texture to any resolution it wants. The downside is that with fast connections this can be slower than downloading a pre-generated texture, but it is an one-time operation per texture so that doesn't matter much. This is something that isn't planned for initial Mason releases, at least.

Material Properties

Here is a list with some of the properties of a material. The material_properties document has the complete and most up to date list, along with more descriptions. [This list will be probably be removed later, when everything relevant from here has been copied to the material properties documentation.]

Creating shapes

The shapes are created in some suitable 3D modeller and saved to some common format. The texturing is done using the standard texture_templates , named for example "front.png", "back.png", "vertical_edge.png" and so on. Before it is rendered in the client the textures are replaced by the ones for the used material.

If the actual textures are some other size than the standard dummy textures, then the texture coordinates in the shape are adjusted accordingly when a building block is rendered.

Rendering building blocks

The number of possible combinations of materials and shapes is large. This means that pre-rendering buildning blocks for an isometric and other 2D clients might be problematic. With a minimal set of 50 shapes, 4 viewing angles and around 10 materials this would mean 2000 rendered tiles. A more realistic tile set has around 150 tiles, 8 viewing angles and maybe 20 materials, which would result in 24000 rendered tiles. A typical tile is around 15k when saved as png. This would mean 60MB for the minimal collection and 360MB for the large collection. This would fit on a CD, but is a bit much to download, especially as many of these combinations are likely never used (stairs of window glass or doors of hay, for example).

The best solution would be to allow a 2D clients to render building blocks locally and store them on disk in a building block cache. It would be possible to pre-render any amount of them, by asking the server for a list of building blocks used in the world, sorted by frequency (or just caching all encountered building blocks). If a building block is encountered that isn't found in the cache, then the client can render it. If the neccesary textures for a material aren't found, or while teh block renders, the client can use a plain light gray version of the shape (these could come pre-rendered with the game, or be generated when the game is installed). 2D clients could also ask the server for new blocks nearby and render them in the background.

Alternatively the 2D clients could render building blocks on the fly, from the shape and textures in a similar way to the 3D clients. This should not be a problem on modern hardware and 3D cards, especially if the rendering quality can be adjusted to turn off bump mapping and similar features if neccesary. This is just a speed / memory trade off that the client designer has to decide about.

3D clients should not have much problems with rendering the building blocks. They just use the shape and substitute the template textures with the material textures.

Fitting the building blocks together

Coordinate systems

Building blocks should be drawn so that one unit in the 3D file format corresponds to one meter. They should start in the 0..1 m cube and extend outwards along the positive axis's from that if neccesary. Walls and such are drawn adjacent to the X axis, facing outwards towards positive Z: 
Z^
 |
1+      
 |
 | front 
 +------+ <-wall
0+------+---->
 0 back 1   X

Placement in map

Building blocks need not be at tile boundaries, however, for best results it is good to use a tile sized grid for laying out at least the bigger blocks. The blueprint editor should provide grids of at least 2, 1, 0.5, 0.25 and 0.125 units, with optional grid lock features. Walls have an outside and inside. Normally a wall is not placed in the middle of a tile boundary, but wholly on that side that the outside is facing.

In ascii art (slightly exaggerated wall thickness): 
I, i = inside
O, o = outside 
W    = wall

iiiiiiIIIIIIWWWooo
iiiiiiIIIIIIWWWooo
iiiiiiIIIIIIWWWooo
iiiiiiIIIIIIWWWooo
IIIIIIWWWWWWOOOOOO
IIIIIIWWWWWWOOOOOO
IIIIIIooooooOOOOOO
IIIIIIooooooOOOOOO
This means that special blocks are needed for the corners (lower right square in the above picture) and for L corners (if we wanted to continue the wall downwards in the bottom center square above).

Note that there is nothing stopping from turning walls to face inwards, but in that case they will be placed on top of the floor tiles used inside (if any are used) and the edges of the floor tiles will be visible in the outer wall.

Attaching blocks

Building blocks that have two faces that touch may be attached to each other. The attchment may be special, for example a hinge to connect a rotating or moving block, or just a normal attachment. The attachemnt has some strength that depends on technique used in making the attachment, the attached materials, skill of the attacher and the area of the attachment. This is calculated when the attachment is made. If the attachment is exposed to a force that is too much for it to handle, it will break. The way the force is calculated is left for the building_stability module to handle. Initially Mason is probably going to use a simple stub that always uses zero force (this allows interesting structures whose only requirement is that they are connected to the ground. Maybe a similar effect could be achieved later using magic).

Here's an ascii art picture of a cross section of a house with walls, a window, a door, floor tiles, inner walls, a roof, and some inhabitants thrown in to give a sense of, er, proportions: 

                          _  
                       \_(o>
                       (__/ duck
                roof    ||
              /[==][==][==][==][==]\
             //     _\/_spider     \\sloping block
            //      /`´\   trapdoor \\
            [][==][==][][==]----[==][]
      window|   O man []            []short wall piece
            |  /|\    []   _goldfish|
            []  |     []  (_)       |door 
            [] / \    []  / \       |
_\|,_ground_[][==][==][][==][==][==]|___\|,__.|/,_
                      wall   floor
See the concept_illustrations_of_house_building page to get a slighly better idea of what building blocks and completed buildings will look like.

Overlap

Building blocks could be allowed to overlap to some extent, this might be neccesary for example for rotating doors that will overlap adjacent walls sligthly when open. How this is handled, and how much overlap is possible, is determined by the game rules.

Moving Attachments

Doors, windows, drawbridges and trapdoors all need to be able to rotate. This is no problem with a 3D client, but pure 2D clients will have to render different frames for each step of the rotation. The exact number of frames is up to the client developers, but 8 frames describing a full rotation around the X, Y and Z axis is a minimal recomendation.

It is possible to create bigger rotating doors or other objects by attaching several building blocks together, and attaching some part of the group to a doorframe or other place with a hinged attachment.

There are many kind of moving attachments, with different degrees of freedom. Some allow a slight rotation around an axis, some allow full rotation, others have some flexibility, some can glide along a track, or along a plane, and so on. Some joints can be powered by a Machine Part, others are operated manually. Locks and bolts might be used to restrict the movement of building blocks, so they are also a type of attachment. Attachments are discussed more in the item_system documentation.

Summary