Concept Development

Concept development for arcologies is formalized through objectives that capture the needs of the inhabitants.

Goals of SimCity

At first glance, the goal of a city (at least as envisioned in Maxis's SimCity $^{\small {TM}}$) ought to be to grow and prosper. Unfortunately, this viewpoint overlooks the city's primary responsibility to fulfill the needs and look after the well being of its inhabitants. These concerns can be captured by looking at the problem from an individual level, on par with the scale of Maxis's The Sims $^{\small {TM}}$: The Sims $^{\small {TM}}$ offers 8 needs for each of their simulated characters: ``Hunger'', ``Energy'', ``Comfort'', ``Fun'', ``Hygiene'', ``Social'', ``Bladder'', and ``Room'', indicated by the green bars at the bottom of the user interface screen shot shown in Figure 2.4.

Figure: The Sims$^{\small{TM}}$ Entity Requirements Model

The model proposed in this chapter takes an even simpler approach:

Shelter: Where people live and sleep (accounts for ``Energy'', ``Comfort'', and ``Room'' from The Sims $^{\small {TM}}$ model)

Food/Air/Water: The raw materials people need to consume to live, or at least not starve to death (accounts for ``Hunger'') and adds a ventilation requirement necessary in building design.

Health: Maintenance factors, such as cleanliness, waste, (accounts for Hygiene and Bladder)

Work: Most people need something productive to do when they aren't attending to their other needs. This could take the form of working for money, or being educated to increase their knowledge bank of information.

Entertainment: If people aren't doing something productive, they're probably doing something fun to while away their time (accounts for ``Fun'' and ``Social'')

In order to fulfill these needs for all of the city's inhabitants efficiently, what they are really looking at is developing infrastructure to move resources around. Accordingly, the high-level model developed in this chapter takes an abstract view of these resources and the transportation networks that move them around. This allows us to quantitatively measure the ability of the system to fulfill these individual goals.

Objectives

An organization responsible for running an arcology might track multiple composite performance variables and strive to pursue multiple goals. These objectives might include:

• Continuous improvement of the quality of life of the inhabitants
• Acceleration of research, development, and contributions to the educational body of knowledge.
• Optimization of resource consumption to achieve balance with interchanges with the outside environment.
• Maximization of productivity and economic performance.
• Achieving fairness by avoiding optimization of the whole at the expense of the few. Add structure to the system by providing opportunities and alternatives, not imposing restrictions on who gets to utilize available resources and transit capacity.

To be useful, each of these objectives need to be represented as a measurable quantity. The simulation model should be capable of collecting and assembling composite metrics representing these objectives, and computing their values (or valid estimates) based on simulation inputs. For example, a ``quality of life'' metric might be a composite of several measurable outputs, including the length of required commutes, the number and duration of times they are hit with a hunger event that can't immediately be serviced by the resource delivery system, amount of leisure time afforded after the optimal quota of daily work is done, and so forth.

Figure 2.5: ``Live'' use case diagram.

Use Case Diagrams

Use cases are high-level representations of system functionality that do not reveal the details of implementation. Use case diagrams are a convenient way in which a real world actor (i.e., entities that are external to the system) will interact with the system, the use cases with which they are involved, and the boundary of the application.

The arcology use cases simply represent a few major activities engaged by individual residents. For details, see Figure 2.5 and Tables 2.1 and 2.2.

Table 2.1: Actors in ``Live'' Use Case Diagram
Table 2.2: Individual Use Cases in ``Live'' Use Case Diagram

The system boundary is provided by the living quarters, which, contrary to its name, extend beyond an individual's residence and encompass all of the locations where they go about their business. The arcology simulation model will need to be flexible enough to model these types of activities in order to be used for design. The one new activity introduced by Figure 2.5 is the ``Travel'' interaction. Not all of these use cases occur in one location, so the Travel case takes care of moving the individual from one location to another. This interaction is performed through one of the Transportation Infrastructure classes, which will be detailed in the System Structure.