o, Part II of the Locate learning game challenge to illustrate how I approach the project as I gradually build it.
Before that, however, a brief segue into the whys and wherefores of the project. After all, it seems strange to be doing something like this in the vacuum. Originally this was a part of the L.E.A.R.N. Online project, but more broadly it has been folded into a larger project that I’ve had up my sleeve for some time: to design an introductory course to the archaeological discipline to replace one found in a traditional four-year college, as well as offer a scaling level of detail in each section. The first course, however, would act as a 101-level course with the design theme of “forensics as archaeology,” and then go in depth from there.
The primary assets for this course will come from my experiences as an archaeologist at James Madison’s Montpelier. There are two reasons for this:
- It’s easier to create scenario-based learning with content that you’re familiar with; and
- The data has been made available by Dr. Matthew Reeves of the Montpelier Archaeology Department. Thanks, Matt!
After all, Familiarity Breeds Content.
A section of the Montpelier property in the woods where most of the initial survey work by metal detectorists were performed. While a great deal of survey has also been done around the main house of Montpelier itself, the woods will allow the learning game to blend together artefacts from different time periods (rather than primarily the early 19th century).
Other than a fist full of databases and Adobe products, the next steps are variable design, storyboard, and mapping the two together.
If you’ve ever tried creating a scenario-based learning game organically and on-the-fly, you will have found that things quickly get out-of-hand. There’s a huge difference between realising that you have to introduce a new variable rather than having to create everything out of cloth from the get-go.
In the previous post, I mentioned that I wanted this to be a resource-limited game. In archaeological projects, the main variables at play that lend themselves to a game are time, budget, coverage, and assemblage type. So let’s get specific about these variables—these “vars” as I tend to call them.
The budget is the primary resource in this learning game and comes with a fixed value that is decreased by each survey type selected by the learner. You don’t have to spend the budget, and you can always come back and spend more, but ultimately your explorations are limited by the bottom line.
- vbudget – This is the current level of the budget, which starts at ‘0’ and increases depending on the selections of the learner.
- vbudget_threshold – There are three thresholds. The first is a challenge level that, if achieved, would show up as an unlocked achievement. The second is an ‘acceptable’ level that if you don’t surpass it you’re doing great. The third level, on the other hand, is the danger level. If you get up to this then you’re Board of Directors is going to be very unhappy with you.
- It’s more than likely that there are going to have to be numerous ‘temporary’ budget levels that allow learners to “walk back” their selections if they realise that they’re over-spending their budget or spending too much time on the project.
The time taken for the survey is primarily an illustrative value that is meant to show the learner how fast, or slow, the various surveys tend to be.
- vtime_current – This is a value that starts at zero (0) and then is merely added to by each survey type employed during the game. With that said, I’m looking at this now and thinking that it might be useful to make a statement out of this. This will probably be a range, i.e., IF vtime_current > x > y, THEN report this statement. (The way that e-learning authoring software works, there’s probably an AND statement that needs to be thrown in there.)
- vtime_threshold – While time can just accrue, it would be more challenging if there were one or more limits or, at least, thresholds. At the moment I’m tinkering around with two threshold values: (1) a preferred value, such as one set by the Board of Directors; and (2) a hard-cap that is set by an external force, e.g., a funding body like the National Endowment for the Humanities (NEH) or, well, just your board of directors. Haha. Just. Anyway, moving on.
Ultimately, the survey area is going to be divided into a manageable grid of 5×5, which would account for around 100x100m. While it might not sound like a big area, in terms of the learning game there are going to be a large number of variables at play, here. Each grid square will:
- Have specific ‘data’ associated with it depending on what type of survey is applied, which means that 25 tiles/grid squares are going to be associated with data from multiple survey types. These types are going to be:
- g(n1-25)_stp – An archaeological shovel test-pit survey. This is relatively slow but produces artefacts across the material range (glass, ceramics, metals, stones etc.).
- g(n1-25)_wo – A walk-over (or pedestrian) survey is relatively fast but only tends to produce results if the feature in question is obvious—a pit or mound (or a series of the two), or a concentrated scatter of artefacts.
- g(n1-25)_mds – A metal detector survey that utilizes experienced avocational metal detectorists to explore the area using grid-based survey. Finds will be limited to metal artefacts, but may include the occasional “special find” of non-metal artefacts.
- g(n1-25)_lidar – While usually an expensive technique to employ at a site, the US government and associated companies have been building a LiDAR database for some time. This is actually very cheap, but interpreting the data is hard.
THE TWILIGHT ZONE (READ: MYSTERY FIND)
I cannot help it. I’m playful. I like there to be curveballs. How this plays out in this context is that one of the grid-squares needs there to be some weird and fantastic find in it depending on what type of survey you use. I’m thinking “Ancient Astronauts,” here, or something that might show up in archaeological pseudoscience such as suggesting that Khufu’s pyramid is actually simultaneously a prison for the Babylonian god, Marduk, and a gas exchange powerplant for… something.