Been looking around in the Building Generator discussions trying to tie together all that's been laid down so far. Having some ideas that I want to lay down about I see a Building Generator functioning. Hopefully this will give us a better idea of what we can shoot for here.

First of all, there are a couple of key elements to the BG.

1. Ease of use(as everything should be when you're talking about a game)
2. Independence from any grid like system
3. Procedural Generation(basically means it can be generated by code on the fly without any presets)
4. Use of templates
5. Speed(and I mean speed, Slick's been hinting at five seconds for a Space Mountain:icon_eek:)
6. Ease of template creation(for the user made templates)
   

All of this can be boiled down to the template. And that is where I should begin, there's not really much discussion on what the template does or what comprises a template.

A template for the BG should be more like a guide for the BG. It should help the generator along with the procedural process. A BG will not be able to decide what architectural features to include in a theme without a template guiding it. While a general floor plan and layout should be governed by the player to his wishes, the BG will look towards the template for some instruction on keeping the building to it's theme. To keep the template simple, it should just be a handful of guidelines that the BG follows, such as in an oriental theme where excessive roof trim should be used, along with an arched roof in most cases. Here I must point out that these guidelines are not constants, and can be removed by the user. These guidelines though should help the BG create a structure quickly and effectively and meet the 5 second rate that Slick mentioned. In essence, the guidelines are more like a default set of rules for that template.

It will be up to the template creator to create a set of guidelines for the BG to follow that will fit the theme. These should be kept in a text file stored in a folder along with the rest of the template. Certain values could be a default baseboard style, a style of table to use, default layout for a restaurant.

For example, let's say the user is building a restaurant. He chooses the New Orleans template for the restaurant. He also chooses an outdoor style(an option that could be selected from a drop down box). The player creates a general layout for the restaurant and the code goes to work to procedurally generate the restaurant. It starts by creating a mesh to fence off the restaurant, since it will be outdoors. To do this, it looks to the template and finds something like "fencestyledefault= xxxx" then looks up the texture file for the fence and rings that texture around the layout of the restaurant. The template says to put a lamp on the fence every seven feet, so that's exactly what the BG does, again referencing the template on what style lamp to use. And since the template creator is smart, he lined up the distances between the lamps with the fence texture so that the lamps line up with lamp posts in the fence texture. The player has set an entrance along the fence line, so the template again guides the BG in setting up an entrance. The BG then switches tasks and decides to place the tables. The template will have a value like "radiusofspacearoundtable= 5" which the BG will use to space the tables apart from each other to allow ample room for the model and walking space between the tables. The code then uses the places the default table model for the theme around the restaurant automatically, adds some finishing touches indicated by the template, and tada! You have just procedurally created a restaurant!


Pic taken at Disneyland in New Orleans Square, this place has good food by the way, anybody who hasn't been to this restaurant should check it out.


Of course, this is just a preliminary design created by the code, the player now has the chance of modifying this design. The next part of the process is actually very simple in design terms, and rests mostly on the hands of the interface. The player uses the alignment manager to shift the tables and other objects such as trees, canopies, and the fence line around in their own image a little more, this is where the template's job changes. The guidelines that were used in the procedural generation process to quickly create a pleasing design that fits the theme gets thrown out the window. Those rules mean nothing to the player. Of course, simple mesh collision detection will still keep the player from doing certain things to the design.

The player now gets to tweak the design to more of their liking. Besides the default models and textures that the template uses, the template also comes with other models and textures that can be exchanged with the default ones. Noticed when I said that when the BG was looking for a fence style, it was a default style. Within the BG template, there will be other styles of objects that fit the theme, allowing the player to mix and match table style's and wall designs, even to the point of picking a different style of layout, say a layout that points most seats in a configuration surrounding a center buffet rack, in which case the BG will go back and re-engineer the layout using the same procedural method as above with new guidelines. The template guidelines will list other models for objects in that template, but the player can also reference other templates for their models, or simply pull from the general scenery library not associated with any templates at all.

Now, buildings will have to be divided into rooms and floors obviously. Some rooms will have a different style attached to them, while some will have different function all together. That's where zoning comes in. Zoning allows the player to apply the same quick, fast, procedural method to small sections of a structure. The simplest zone of course is between separate floors of a building. These zones will be tagged automatically but can be combined together if the player wishes obviously. Zones can also separate individual rooms or half of a room as divided and labeled by the player.

Now what is a zone good for anyway? Zones, from a coding perspective, separate a building into separate areas where different options can be set by the player so each room is different. It basically makes the procedural generation code run itself multiple times, one for each zone, and the player can set different stylizing options for each zone.

Let's look at an example, in my Cafe Orleans example up there, a player could separate that outdoor restaurant area into two zones, which the game treats as two separate areas acting as one restaurant. On one zone, the player leaves alone and keeps that area as an outdoor patio. For the other zone, the player decides he wants an indoor seating section for those colder days or just to keep guests dry during a rain. Since they have split the restaurant into two zones, they simply modify the one zone and choose an indoor style from the BG template. The BG immediately generates a brand new indoor section and the player makes minor tweaks to the design before adding doors between the two areas and closing the BG. Tada! The player has just remodeled half of his restaurant almost immediately. Of course the player could have done it all manually by adding in all the walls himself and exchanging tables, reorganizing the layout, but it's a lot faster with zoning that lets the BG script do the same process almost instantly.

Now of course models are going to have to be downloaded along with the template text that describes the actions the BG will take when generating a building. Templates will also have to include wall and fence textures, models for different pieces of furniture and decoration, and all of this will have to be stored in the template, so the actual template will be a folder on your hard drive. In the folder will be a text file with all the guidelines set by the template creator and any models and textures and even particles that the text file will reference or that the player will choose to include in their model.

The advantages of a text file is that it's easy to create, almost anyone can make a text file and fill it with variables, then load it up in their own games and test the template within minutes. Piece of cake.:cola:(sorry, no cake smiley)

Of course I've only been talking about restaurants for now but with similar variables in the template text, you can have templates for ride covers, theaters, scenic buildings, even whole outdoor plazas and vistas for the guests to stare at.

Let's look at an example of a ride cover. Slick keeps bringing up about how a Space Mountain will be built in 5 seconds or less. Well, this is how it should work within this system. The player downloads a Space Mountain template made by the community and makes the track using the TRCS. Then the player applies the ride cover and assigns the Space Mountain template. The game then looks up the text file within the template and gets to work on generating a Space Mountain. The text file directs the BG as it measures a safe radius around the track and examines any collisions(I just realized that I haven't mentioned collision detection anywhere up above, another challenge we have is how to deal with a situation where the template guides the BG into building something that collides with another building or structure) it might come upon, then applies a roof cover for the mountain from the template folder that was downloaded as well. The BG scales it to fit around the ride and places it. On the interior walls, the template references a custom texture to place there that simulates the stars flying around the RL mountain. Other projections like the meteors and galaxies may have to be placed manually, but that's okay. The player then assigns a zone around part of the queue and track, which is then assigned by the player as the station, the the template uses a sub-style within the same text to lay out a station. Same procedure goes for the rest of the queue and outdoor sections. Maybe not five seconds, but way faster than TORCG.

There's a lot of coding challenges such as guest flow between zones and around obstacles in a building, and how to draw a building like this in real time, and what happens when a design intersects another structure, but before those can be solved, we need to know what the building generator is supposed to do, which is why I typed this up, a rudimentary plan for the BG.

Eagle, what an awesome write up.
This almost matches what I want to do with the BG.

The templates can be scripted so that changes can be made the same as what is being done with the FRCS.
Its text based allowing easy changes to build a template. The BG runs a controlled test on the scripts to ensure it has the needed parameters met to build and detail the building. The BG I propose is a parametric system that keeps a live model active so that other systems can interact with it. Parametric means that data is presented in the form of parameters and the tool converts those directly to structural elements. This also means if you adjust the ground level around the building or place a door for a coaster to enter it changes the parameters and so does the structure. The building will not fall apart. Where this ultimately goes is that we achieve a system of generics where a lot of other parts fit together well and people are allowed to get creative.

Glad to see this discussion going. Other things to also consider the BG can auto stretch the structure length, width and height wise as well. In addition it can provide auto-queues as well and themed ones at that. Like space mountain would essentially be a shell, provide auto-queing from the rides entry and exit platform and even generate the auto paths between the ride platform and the outside paths.

The Bg can also have a mountain cover for like a log ride perhaps like the flume ride in a mountain at Knott's/ Auto tunneling entry and exits themed, auto-caverns for the mountain cover, add pine trees on the mountain too. The flume in this case is first established then the BG applies a mountain cover. Where you need to, you can expand or shrink the mountain area around the ride.

[evid]http://www.youtube.com/watch?v=IAWSgjRlM00&hd=1[/evid]

Yes, the BG will allow you to stretch the structure and reform it. I don't have the details yet on how it will work but the BG will redetail the elements to make the structure hold true to the form while allowing the expansion. Validation code will be tricky because the existing openings have to stay put when a wall moves or stretches. Track and Ride parts as well as clearances will be involved complicating the number of variables involved. Yes think generics where themeing and will provide the uniqueness of the structure.

Many models such as burger stands and ATMs will be modeled structures.

Well, it took nearly half a year to get a reply, I think everyone may have glanced at it on the new post page, then forgot it or something, but I'm glad someone likes it. I may have to read back over it to remember what I said! LOL

Now where's that edit button when you need it?

Yes, I typed this back up in September, back when I was the assigned the Wild West theme moderator. Seeing as I was going to be involved in directing Wild West templates, I started down a train of thought of just how could we achieve something like this. Unfortunately, a lot of posts on the BG were just what people wanted to do, and not a lot of how the thing would actually be like. So I took the brainstorming and placed it here.

When I get a chance I want to use this post to write up the TDD on the BG subject.
Eagle Eye, would you be willing to post this into the amendments to the Game Docs?

Building the FRCS engine this morning I thought about the how BG would use similar code to handle walls, floors, roofs and door the same as rides do bases, arms, hubs and cars. The coaster tracking already uses similar techniques to build it's sections. Also the stations, gates, queues, accessories and paths will follow the same convention. This will make building code faster for the rest of the park once one part is done.

I think most of this has been said but it's worth repeating.

• Start up the BG and select a basic layout from the geometry or stored/downloaded templates.
  Reconfigure the shape using the shaping tool. You may want a longer rectangle or 5 sided building that is shaped like an ice cream cone or 10 sides crooked star. Just move the points or sides to reshape. Choose options if you want to place like sucking walls for haunted houses and other dark rides.
• Switch to wall mode, select the base and lift all walls or one wall at a time. Elevate then to height you want, meter/feet stick should assist here for guided construction.
• The last thing is to choose the roof and adjust the pitch with a slider. I'm thinking these controls will just be provided by the graphics engine which is much more intuitive and clean than the dialog system.
• Select doors and windows options from the walls menu and the BG system breaks out the saw, cuts the hole and places the window. Resize the window as needed. Use dark glass in the haunted mansion or add shutters that can rattle later.
• We also want roof accessories also including dormers, holes and busted sections that allow coasters to breach (see the Flying Broom coaster in Europe).
  

Automated doors - yes
Windows and Shutters that respond to moving rides - yes
Dark interiors - yes ( global lighting shuts off inside allowing illumination control). Slick has been begging for this one.

You want me to post this into the GDD amendments? I'll put it on my to-do list to rewrite a couple sections of this write up then post it.