Deciding on the building task

The first matter builders attend to while preparing for in-game building is to decide on the building task they are going to work on. Three distinct cases are unpacked here, each of which has its own characteristics:

1. Resuming a building task;

2. Collaboratively deciding on the building task;

3. Choosing a building task by checking the commission’s specifications.

5.3.1.1 Resuming a building task

Builders can resume a building task they or members of their team left incomplete in their previous building sessions. This draws upon: (1) recollecting what has to be done; (2) checking the specifications of the build in order to make sure nothing is missing; or (3) using ad-hoc systems for keeping track of unfinished or future work. One such system is presented in Figure 25, in which case the depicted pink blocks delineate where roads need to be placed (a task that the involved team had not yet accomplished).

John: “We’ve tried various systems to make it easier for one

person to pick up where another left off. Cid and I have agreed on a process for expanding pink lines into real roads.” [Observation material.]

105

Figure 25 Example of demarcation for future work; annotating the placement of roads

Another matter relevant to resuming a building task is the occasional briefing that takes place when more than one builders work on a project. In that case, it is possible for those involved in the commission to brief each other on the work they had conducted in the absence of others, either via Skype or in-game

John: “I wake up in the morning for a Skype that[‘s] saying

‘John, go check out on the workshop map ; I’ve messed around something new, I am curious what you think about it.’” [Observation material.]

5.3.1.2 Collaboratively deciding on a building task

It is also possible for builders to assign building tasks to each other in real-time while being logged in and working on the same server. This is initiated either by an individual (the requester) who wants to work on a particular task or by any of the available team members, who suggest a task to the rest of the team. Part of this job of work draws upon establishing the specifications for the suggested task. These two activities are further discussed below.

Suggesting a task. Such a case is exhibited in the following sequence (Vignette

5), where the requester (Cid) states that he wants to perform a specific type of job (terraforming). His request is then picked up by one of the two logged-in team members (Roy), who replies positively by saying that he does have a task that meets his request (“something to terraform”). The actual delegation however is carried out by both Roy and John (the third team member), who establishes whether Roy’s suggested task warrants further work. All three of

106

them were part of the same building team, which, as was previously stated (see Vignette 4 on 101), had the goal of creating a realistically looking world with diverse landscapes and cities.

Part of suggesting a task is providing a reason for the necessity of carrying out this task. This can become a collaborative matter when the suggested task was initiated or was part of the work someone else conducted. Drawing upon the same sequence (Vignette 5), John states his belief that “that was not a bad looking cliff,” without objecting to further terraforming it. On the contrary, he acknowledges the lacking characteristics of the existing landscape by accounting for his own terraforming work (demonstrated through the reference to height-maps; he was the one who terraformed the existing landscape through World Machine and World Painter).

Vignette 5 Receiving a building task from a teammate

Cid: “I need something to terraform.”

Roy: “I’ve got something for you to terraform.” Cid: “Show it to me.”

Roy: “This way.”

Cid: “Yeah, I can be productive again.” John: Follows them.

Roy: “Can you make this cliff like actually look like a cliff instead of

like a gradual sloping hill, but not by scrapping the houses?”

John: “I do think that was not a bad looking cliff, but alright.” Roy: “I do not like it. It’s… It needs at least a little bit overhang.”

107

John: “Okay.”

Roy: “It just looks like a… hill.”

John: “The constraints of height-maps I am afraid.”

Establishing the specifications for the task. The work of delegating a task

does not stop when the builders are assigned with one. Those that provide them with something to build can also engage in pinning down the specifications for the task. The following extract exhibits such a case, where the Roy and John collaboratively establish what Cid should do in terms of fixing a hill. It is evident that they raise:

 The functional characteristics for the job; the hill looks very simplistic, which becomes problematic due to the fact that it sits in a very prominent position in the overall build (“right in the middle of the town”). Due to its visibility, it is considered necessary to change it.  The aesthetic characteristics; the hill “needs at least a little bit of

overhang and the inclusion of “spruce” leaves.

 Exact steps in dealing with this task (“sculpt it out of rock”).

Vignette 6 Establishing task specifications

Roy: “Yeah, I know, I know. But I mean it is right in the middle of the

town; it needs to be at least a little bit prettier than the average.”

John: “It needs sprucing up.” Roy: “Yes, it needs sprucing up.”

Cid: “You sure you want me to spruce it up?” John: “Actually, if you could keep it simple.”

John: “Sculpt it out of rock and then just paint it with spruce leaves.” Cid: “How like sheer do you want this thing to be?”

Roy: “It doesn’t have to be super sheer; just a little bit of underhang

would be nice.”

5.3.1.3 Choosing a building task by checking commission’s specifications

One of the main approaches in deciding on what to work on is performed by crosschecking with the commission’s specifications (see documenting the

108

commission under contracting) in order to establish whether further work needs to be made. The resources employed in storing these details vary depending on the organisation the builder is part of and the already established systems for documenting commissions and accounting for progress. Trello, for instance, is one such system, where members use check-lists for coordinating what needs to be done (or what has already been done).

The accomplishment of this step can be twofold:  Determining what is missing from the build;

 Deciding on what to work on next (in which case, another building cycle is initiated).

An instance of checking commission’s specifications was witnessed happening during an in-game building session, which is exhibited in Vignette 7. Whilst the exact resources the builder was using at that point in time were not shared, he elaborates on the fact that he was indeed looking into the client’s “wish-list” of the things that need to be integrated into the game (which is part of the specifications of the commission). He then expands on the exact details that are missing from the build: a few functional characteristics regarding the map’s gameplay affordances (“crates… a place where there is a bunch of chests that people can open,” “place for people to do forging, enchantment and crafting”), accompanied by aesthetic elements (the placement of trees).

Vignette 7 Crosschecking for remaining requirements

Georg: “I’m just looking for some information on what stuff I need to

implement next.”

Panos: “What do you mean by that?”

Georg: “The client has a wish-list that I need in order to…. He needs to

have a certain amount of requirements. For example, he needs a place for crates and that’s one that I need to do. Like, a place where there is a bunch of chests that people can open and then get [in-game items]. I need to build that. And then I need to make some kind of place for people to do forging, enchantment and

109

crafting. Some trees. That’s what I’m going to do next: trying to figure out where I am going to place those.”