Nick's Nest

Devlog Ten

Thu, 05 Dec 2019 00:00:00 +0000

Chatbot

This devlog will be a quick summary of my experience engaging with one of my colleague’s projects, a chatbot called Herr Obermeier by Sabrina Schoch. Her devlogs can be found on her site.

The chatbot itself appears to be a hybrid between a classic chatbot and a choose-your-own-adventure game. Instead of entering your own input and letting the bot attempt to identify it, you are presented several choices which you can choose to progress the bot’s ‘plot’. I’ve never seen a chatbot like this before - I’d been expecting to have to spend most of my time trying to enter input the bot would understand.

The experience itself is relatively quick, lasting only about 5 minutes. Despite its brevity, it does a good job attempting its rather morally ambitious goals: that is, to investigate the horrors that took place within 20th-century Nazi Germany, particularly focusing on women’s concentration camps. You play the role of a woman sent to the Ravensbrück concentration camp on charges of asocial behavior/lesbianism. Initially, you can only question why you’ve been sent to the camp, but soon you are given the choice of whether or not to attempt to escape. In the event you do not attempt to escape, you are informed that you had a ⁵⁰⁄₅₀ chance of surviving the Holocaust - if you do attempt to escape, you are caught, and are offered to choose your own punishment. The options are execution, medical experimentation, and selecting another inmate to suffer - the latter of which has you executed for cowardice.

The game ends with a brief expository explanation of the shaky existence of lesbian women in Nazi Germany, since by law only male homsexuality was officially punished - female homosexuality was often punished under the guise of asocial behavior. It then calls for increased representation of lesbian women who had suffered during the Holocaust.

Overall, the experience - while grim - did inform me much of how lesbianism was treated in Nazi Germany. I had always assumed lesbianism had simply been lumped under the umbrella of homosexual behavior, and had no idea there were specific camps intended for women. The bot has fulfilled its educational purpose, and despite the grim setting, I think an interactive chatbot is a very effective way to engage users with these underanalyzed past histories.

Devlog Nine

Tue, 03 Dec 2019 00:00:00 +0000

Playtesting

The game has undergone some playtesting in the last 24 hours - most of the changed fixed were small balancing tweaks to make more options viable. For example, the price of good food of reduced, and the compassion and social consequences for doing misdeeds was increased - it was far too forgiving to make much of a difference, originally.

It feels strange to say it’s done - though it’s technically met all of its initial goals, there have been various perpiheral features (like images and sounds) that I would have liked to add if I had more time. Furthermore, my creative writing skills tend to focus on characterization and character-building, and I never really got the chance to flex those muscles in this particular narrative. I think this issue arose primarily from my inexperience with non-fiction. I spent a lot of time worrying I wasn’t being accurate enough, which made me reluctant to take any risks with the characters or setting - which may be one of the reasons the characters may seem to come across as ethereal and passive, at least from my perspective.

Hair-Tearing

Funnily enough, most of the time spent on this phase was spent grappling with Hugo, which is the code foundation you are reading this text on. The Academic theme for Hugo, which I am using, does not appreciate it when you date posts in the future. Seeing as I had released Devlog Eight at 1am, attempting to release this Devlog on the same day meant they were listed alphabetically rather than chronologically, since they were on the same date - and Devlog Eight was organized above Devlog Nine. To remedy this, I attempted to set Devlog Nine’s creation date to December 3rd, which is tomorrow. I assumed this would work without error - instead, the devlog refused to upload entirely. After agonizing over this rather simple ‘bug’ for hours, I eventually concluded - after returning to the error after a break - that dating your Hugo posts into the future does not release that post immediately with the future date, but actually holds onto your post, unpublished, and promptly publishes it automatically when the designated date comes to actually pass.

This may seem like a trivial discovery, and it is. But it had aggravated me far more than any part of my actual Twine game - at least then I felt somewhat in control of my own screw-ups. In this case, it seemed (at first) that the software was to blame. I had been experiencing a compiler error on this site for some weeks, which had gone completely unnoticed as it had not adversely effected my ability to post. Upon noticing it while struggling with the date fiasco, however, I started to suspect that this compiler error was the cause of my latest devlog failing to upload. Now that I discovered the more probable cause, I have decided, naturally, to let the compiler continue to throw errors at me - they don’t seem to interfere with my posting, so why bother? This may all seem like a tangent, but it actually reflects something very important in the field of Digital Humanities: it’s okay to struggle with the machine, it’s okay to step away and breathe, and it’s okay to make mistakes. These devlogs are still part of my project, and grappling with them is just as important as grappling with Twine.

Paradata

Tue, 03 Dec 2019 00:00:00 +0000

This document contains paradata for they’re counting on you.. In it, I hope to summarize the processes that went into the creation of the game over the course of 2-3 months.

Initially came the planning phase. This being a public history project, there were some criteria it had to meet: first, it had to involve the city of Ottawa. Second, it need to incorporate some sort of physicality. As evident in my first Devlog post, I hadn’t even considered the possibility of researching the Shiners at first - mostly because I didn’t know they had even existed. I stumbled onto them when researching Ottawa’s homicide history, which was a concept I had already started researching in earnest as a possible avenue for my project. The shift seemed natural - I wanted to avoid causing harm to any families of homicide victims, and I had been struggling to discover a means to do so without neutering my project. The Shiners presented something of a blank slate, but they were also a tantalizingly interesting topic for me. Ottawa is often perceived as a ‘boring’ city, for better or worse, and the idea that the town was once ruled by a Mad Max-eqsue gang of rampaging gangsters certainly challenges that perception.

At first, I’d planned to make an interactive map, but I soon discovered I was treading too harshly on the toes of my predececssors - Nathalie Picard had done something similar with her project, Ottawa’s First Chinatown, and lacking direction on my own I had begun to take her idea and run with it. I eventually reconsidered. I have a passion for games and creative writing, and I wanted to put those passions to use. Enter Twine, a tool that allows the easy creation of interactive stories. I had some experience with Twine, so using it for my project seemed a natural choice - and it avoided the risks of diving into an application wholly unfamiliar to me. I used Sugarcube, which is a Twine story format that I found suited my needs better than Harlowe. Harlowe, from what I’ve seen, seems to be better for hyperlinked, choose-your-own adventure type stories. Sugarcube is a bit more complex, but allowed me to more readily implement gameplay elements, such as the sidebar in which I could use to list player stats.

I settled on a cyclical game. Essentially, it runs on a loop - using Corktown as a ‘hub’ where the player can work, pray, visit the store, or sleep. The challenge of the game lies in keeping yourself and your family alive despite your mediocre pay. Though I’d initially planned for a ‘family’ stat, I eventually settled on ‘compassion’ instead, since that more reflected the game’s central themes on how desperation can lead naturally to violence. Furthermore, some of the time certain choices are locked out by certain stats - for example, if your compassion is extremely low you won’t even get the option to refuse a profitable job that requires you to murder someone. This means that a lot of the player’s choices are determined by their previous choices, which means events can snowball in a good or bad way. This is intentional.

The actual design of the game would probably have been exceedingly simple for a skilled programmer. I am not a skilled programmer. I did manage to find some shortcuts which kept the final size of the game a manageable size, and thanks to Twine’s GUI you can see the rough size of the finished product here:

The documents towards the left of the window are often repeatable screens that the player will return to over and over, whilst the pages on the right, starting with ‘Choice’, are all the one-time choice events that the player will encounter as they progress on the game. The choices usually don’t have much code as the repeatable pages. I also added a few menus to the left of the screen, always present in Sugarcube, which detail in intentionally vague detail the player’s wealth, health, social standing, compassion, and the health of their family members. There’s also a ‘sources’ menu, always accessible, that provides the reader the option for further reading on the game’s setting.

Ultimately, the goal of the game is to survive until Week 31. Doing so will present you one final choice and end the game. You will then be scored on how well you performed, based on how many of your family members survived, your status, and your compassion. I use the term scoring lightly - I figured a numerical representation of how well you did would cheapen the message, somewhat, so I essentially just let the player know the situation they ended in and let them draw their own conclusions as to how well they did. There is no reward or punishment for doing well or failing - the game is difficult, and the game is less a test of whether the player can survive and more a question of what they would do to survive.

This was my first Public History project, and much time was spent on research. I didn’t want to get things wrong. I hope my efforts bore fruit, and this game might engage players enough that the education it provides sticks. Western society is currently preoccupied with the nature and vectors of oppression, and it is my hope that this simple little game can present insight into an oppressed people’s historical struggles - not by valorizing or villanizing them, but by letting the players empathize with them.

Devlog Eight

Mon, 02 Dec 2019 00:00:00 +0000

Finale

The game is done. Well, the first pass, at least - it still needs to be playtested. There are currently three acts to progress through: Act 1 for the Rideau Canal construction phase, Act 2 for when the player is out of work and lacks a reliable source of income, and Act 3 is when the Bytown Shiners come into fruition as a gang - which the player may or may not align themselves with. Now it’s just a matter of playtesting and getting a few more eyes on the project. I’m too close to the project deadline to make any broad, sweeping changes - but tweaks are still very much possible. Bugs are going to be inevitable, unfortunately, but that’s the case with any digital project.

The game now has both a win state and a lose state. You lose the game if you die - simple enough. You win the game if you make it all the way to the end without dying. Also very simple. There’s a slight scoring system included, but I tried to avoid making it overtly ‘gamey’. Instead of mention of numerical scores or the like, I tried to focus on giving descriptive responses to player performance. I’m not particularly sure why this is - I haven’t shied away from describing it as a game, or using gameplay elements like player stats. It simply felt more natural to have a less gamified ending. I’ve also gotten rid of the numerical identifiers in the stats screen to make it less obvious how well the player is doing, and make the algorithm of the game loop less easy to figure out.

Though I haven’t talked about much in this devlog, that’s mostly because things have gone according to plan. I’ve added a whole new chapter, which is also the densest of the three. In all, I’d say this step of progress is second only next to the initial mechanical setup phase of Devlog 5, which involved constructing the foundation for everything that lay ahead.

Devlog Seven

Tue, 19 Nov 2019 00:00:00 +0000

Act 2

I’ve nearly completed Act 2 of the game - the period wherein the player is out of work and might need to fall back on less-than-upstanding means of getting by. At this point, it’s just a matter of chugging through the project plan - I don’t forsee any major twists or turns in the next few weeks, although I might add sound after I’ve completed the main narrative course of the three acts.

This being a Digital Humanities course, I discussed with a classmate of mine (who I’ll name if they request it!) the possible shortfalls of the game narrative I’m creating. The player character is a (presumably) straight male, who starts the game off with a wife and two children - one boy, one girl. To address the central ideas of the game - that is, to encourage reflection on what drives gang violence and its relationship with poverty - I decided that the male role would suit best, since it could more directly result in the player’s character participating in that violence. As for the straight role, it mostly exists to facilitate the family - keeping your family fed and healthy is an important aspect of the game, and removing that feature would likely diminish the impact and desperation the player might feel if their sole goal was simply keeping themselves alive - a much more manageable goal, in the context of the historical time period. Nevertheless, the protagonist having a family does not necessarily exclude them from having a non-majority sexual orientation or even gender identity - these are thinks that bear considering as I continue onto the final act.

Another problem we discussed was objectivication. When I first started this project I underestimated the amount of work that would need to be put into it - and found myself spending hours upon hours chipping away at the mechanical foundations, pulling my time and energy away from the narrative and stylistic elements that I would have liked to focus on. As such, the characters have no real personality of the sort - they serve as mechanical tools, flat characters with only surface-level personality. In fact, the only real, recurring ‘character’ is the protagonist. If I had more time, I’d love to work out their personalities more, and fill the protagonist’s family with people rather than walking, talking health bars - but I think I’ll have to accept these shortfalls, acknowledge them, and move on.

Devlog Six

Sun, 03 Nov 2019 00:00:00 +0000

Physicality Tests and Uploads

I’ve implemented template physicality tests to allow players to answer fill-in-the-blank questions pertaining to Ottawa to give them an edge in gameplay, which should help to more thoroughly interweave the locationality of Ottawa with the game itself. Furthermore, I’ve uploaded the game to a github page that can be found at https://nickmcneilly.github.io/shinersgame/ - though it’s not kept up-to-date with the devlogs, it allows a testing zone to experiment with an early build of the game.

With all the base gameplay out of the way, any further work I make on the game can be sorted into two general categories: narrative and multimedia. Narrative work means adding new choices and new story hooks. I plan to have three acts total. Act one focuses on the building of the canal, where the player has a steady income. The second act takes place after the canal is finished, and without steady work the player will be forced to make some hard choices - this is where the Shiners start to come into play. Finally, the third act will take place during the height of Aylen’s reign where the Shiners are in full swing. I’m currently approaching the end of Act 1 development.

Multimedia work involves audio and images. This is rather low on my priorities list, at the moment, but if I find the time to work on them they could really help involve the player immerse themselves into the game experience.

Devlog Five

Wed, 23 Oct 2019 00:00:00 +0000

Busywork

It’s been a productive week. I’ve been focusing on getting the core gameplay loop implemented, as well as all the required features. You can see the overall gametree below:

Currently I’ve implemented: Player stats (wealth, health, family, social, state), family stats (hunger, health), a day/night cycle, working for money, a store where you can buy food and medicine, custom names for yourself and your family, a player home, disease & medicine, a church where you can pray against disease, family death, and player death.

To get a sense of what the code within these passages looks like, here’s the current code in the ‘Sleep’ passage that handles disease:

<<nobr>>
/* Disease */
<<set _pDiseaseHit to random(100)>> <<set _wDiseaseHit to random(100)>> <<set _sDiseaseHit to random(100)>> <<set _dDiseaseHit to random(100)>>
<<switch $medQuality>>
<<case 8>>
<<set _medPower to 45>>
<<case 7>>
<<set _medPower to 40>>
<<case 5>>
<<set _medPower to 25>>
<<case 4>>
<<set _medPower to 20>>
<<case 2>>
<<set _medPower to 5>>
<<case 1>>
<<set _medPower to 0>>
<</switch>>
/* PLAYER ILLNESS */
<<if _pDiseaseHit <= 10 and $illness is false>>
You have fallen ill. <<set $famSick += 1>> <<set $illness to true>>
<<elseif _pDiseaseHit >= (95 - (_medPower / 2)) and $illness is true>> <<set $illness to false>> You are no longer sick. <<set $famSick -= 1>><</if>>
/* WIFE ILLNESS */
<<if $wAlive and _wDiseaseHit <= 10 and $wHealth is 3>>
$wife has fallen ill. <<set $famSick += 1>> <<set $wHealthDis -= 10>>
<<elseif $wAlive and _wDiseaseHit <= (10 - (_medPower / 5))>> $wife's condition worsens. <<set $wHealthDis -= 5>>
<<elseif $wAlive and _wDiseaseHit >= (95 - _medPower) and $wHealth isnot 3>> <<set $wHealthDis += 10>> <<if $wHealthDis > 20>> $wife is no longer sick. <<set $famSick -= 1>> <<else>> $wife's condition improves. <</if>> <</if>>
/* SON ILLNESS */
<<if $sAlive and _sDiseaseHit <= 10 and $sHealth is 3>>
$son has fallen ill. <<set $famSick += 1>> <<set $sHealthDis -= 10>>
<<elseif $sAlive and _sDiseaseHit <= (10 - (_medPower / 5))>> $son's condition worsens. <<set $sHealthDis -= 5>>
<<elseif $sAlive and _sDiseaseHit >= (95 - _medPower) and $sHealth isnot 3>> <<set $sHealthDis += 10>> <<if $sHealthDis > 20>> $son is no longer sick. <<set $famSick -= 1>> <<else>> $son's condition improves. <</if>> <</if>>
/* DAUGHTER ILLNESS */
<<if $dAlive and _dDiseaseHit <= 10 and $dHealth is 3>>
$daughter has fallen ill. <<set $famSick += 1>> <<set $dHealthDis -= 10>>
<<elseif $dAlive and _dDiseaseHit <= (10 - (_medPower / 5))>> $daughter's condition worsens. <<set $dHealthDis -= 5>>
<<elseif $dAlive and _dDiseaseHit >= (95 - _medPower) and $dHealth isnot 3>> <<set $dHealthDis += 10>> <<if $dHealthDis > 20>> $daughter is no longer sick. <<set $famSick -= 1>> <<else>> $daughter's condition improves. <</if>> <</if>>
<<if $famSick is 0>> Everyone's health remains stable. <<elseif $famSick is 1>> $famSick of you is sick. <<else>> $famSick of you are sick. <</if>>
<<if $illness>> <<set $health -= 10>> <</if>>

I’m not a coder by trade, so I apologize to any programmers out there who find themselves in dire need of a barf bag after reading that mess. Simplifying the code above into layman’s terms, I can describe what is happening here roughly as follows:

Recovery power (called _medPower) is determined by the quality of purchased medicine as well as if they player has prayed for health that week.
Prayer gives a much smaller bonus to recovery power than both low-quality and high-quality medicine.
Then, each family member rolls a random number from 0 - 100.
Several things can happen, here:
- If they are healthy and roll 10 or higher, they stay healthy.
- If they are healthy and roll under 10, they become sick.
- If the player is sick and rolls above 95*, they are cured.
- If non-player family members are sick and roll under 10*, their health gets even worse.
- If non-player family members are sick and roll over 95*, their condition improves. If this improvement results in their health rising above a certain point, they are cured.
- If the player is still sick after all these calculations, are applied their health stat degrades.
*These values are reduced to varying degrees by recovery power. A higher recovery power makes it easier to recover from disease and harder for a disease to worsen.

All these numbers are still being tweaked for difficulty, but what this essentially results in is a functioning health system. As you and your family become ill, you are encouraged to buy medicine - which is expensive - to help them recover. Failure to do this is likely to result in their illnesses getting worse, leading up to their death. It’s rough and unforgiving, as intended.

Devlog Four

Wed, 16 Oct 2019 00:00:00 +0000

Research Update

Work has been going well, with no major hiccups so far. Doing some research, I’ve discovered that the wages for canal labourers at the time of the game was only enough for a labourer and his wife at best - no children. With that in mind, I’ve pared down the family size from six to four to ensure the task of feeding everyone is simply monumental, rather than downright impossible. Furthermore, seeing that cholera was a prevalent killer of the labourers of the time, I’ve decided to add the disease as one of the key ‘antagonists’ of the game - though it will be much easier to cure in-game than it was for actual eighteenth-century labourers, in the interest of keeping the game playable.

I’ve elected to use the Sugarcube framework for Twine instead of Harlowe. Sugarcube already comes packaged with a GUI, whereas Harlowe is much more minimalist. This would be good for an interactive novel, but I think I’ve decided by now that this project is going to result in something more easily called a game than a novel. Furthermore, the Sugarcube documentation is very well-written: https://www.motoslave.net/sugarcube/2/docs/

DIGH Open Journal

Tue, 15 Oct 2019 00:00:00 +0000

DIGH 5000 Open Journal

Archives and Databases

There was a lot of uncertainty in my readings for this week. I thought the ‘Ghosts in the Machine’ article was fascinating and well thought-out, in addition to self-reflective. Most of my concerns stemmed from Bethany Nowviskie’s article on ‘Spectra for Speculative Knowledge Design’, which seemed to advocate for the creation of ‘imagined’ documents that would express what we believe, or even just wish, would exhibit stories of the past and present that were suppressed, lost, or damaged. It’s a topic I’ll definitely have to warm up to, to say the least.

Digital Storytelling

This week’s readings were super relevant to my interests. I’m an avid writer and gamer both, and the subject of storytelling in digital mediums would probably be the topic of my research paper if I wasn’t taking the coursework stream. There’s some disturbing stuff in these readings, too - particularly in relation to Gamergate, the history of which is a ‘story’ in its own way - but the rest was encouraging.Natalia Martinsson’s presentation was especially useful.

Sound

This was a fun one, since it gave me a lot of inspiration for my February ‘Computational Creativity’ presentation. In the interests of preventing overlap, I’ll try to focus on the subject of sound itself. Sound has always seemed to be somewhat underrepresented in humanities work, but (in my limited experience) it seems to significantly more attention in digital circles. Is this because audio and sound are so closely linked to the digital these days that they become part and parcel of DH merely by association, or is the additional focus more a result of the interdisciplinary nature of DH? Is it neither of these things, and DH scholars simply find audio a useful medium for expressing or investigating their subjects of interest?

Devlog Three

Wed, 09 Oct 2019 00:00:00 +0000

Blueprinting

Before I start working on the game in earnest, there are a few things I’ve needed to consider relating to how the game will function both mechanically and thematically. I also have to consider the societal implications of my work. Do I think the conditions of Irish immigrants in the 19th century is a controversial, hot-button issue? No. But I do think a lot of the questions I intend to address are - such as race, class, immigration, revolution, and violence. I don’t intend to make a didactic experience that beats its participants over the head with any overt message, and while I don’t intend to condone the Shiner’s historical actions I do think that the experience is going to be at least sympathetic towards them.

Foundations

I’m intending to make a text game, which leaves me a lot of options. I’ve chosen Twine. It’s software I’m familiar with, and the fact it exports as raw HTML means that it’s both compatible with all sorts of devices and is not reliant on a service provider for upkeep. Furthermore, it can be saved and downloaded as a local file, which makes it extremely easy to disseminate and maintain.

The course requires some sort of focus on the interconnectivity of physical and digital space, and after some trial-and-error this has left me with a couple options: either implement geolocation into the game, or implement visual cues that need to be obtained from the real-world environment in the style of a scavenger hunt. For example, to be able to perform a certain action, they could either physically place themselves inside the space which was once Corktown and use geolocation to confirm their presence, or they could input textual cues (such as a street name or the last words of a memorial plaque) to confirm their presence. The latter is more ‘fun’, and opens up options for people without data plans and who may be living outside Ottawa, and avoids the use of Twine’s geolocation, which is reportedly lacking in percision.

Mechanics

I already have a pretty solid idea for how I want the game to play out. The player is going to start as an Irish immigrant in Bytown, 1830, as work is finishing on the Rideau Canal. I find myself quickly running up against the issue of gender. From my research the Shiners were overwhelmingly male - and while they may have had support and encouragement from the Irish community’s women, there are no reports of them taking any into their ranks. In order to ensure that the players can directly participate in the escalating acts of violence committed by the Shiners, it makes most sense to allow the player to exclusively play a man - due to the strict social conventions at the time, choosing to play as a woman would likely delegate the player to being an outside observer of this violence rather than an active participant. Of course, that’s only if I honestly portray the strict gender roles of the past - I could always play a little fast and loose with history. I’m going to bring this up in class and perhaps seek some outside input.

The player is going to have several needs that influence their overall mood, or stress: Wealth, Health, Family, Social, Fervor. As these stats deteriorate, so will the player’s overall state. When all these needs are well-maintained, the player character will be in a good mindset, and will generally prefer kinder, less violent solutions to their problems. However, as these needs deteriorate, the player character’s mood state will decrease. They will become progressively more desperate, which will result in their actions becoming increasingly drastic and violent. Traditional text adventures allow players to choose for their characters - but in this case, I’m only going to let players choose what the character does in their off time - how they manage their needs. When it comes to the hard decisions - whether to join a riot or stay home with the kids - the character is going to make the choice for the player, depending on their stress levels. I think this is an interesting twist on the traditional mechanics of a choose-your-own-adventure, and helps develop my theme of what drives communities to violence.

Devlog Two

Wed, 02 Oct 2019 00:00:00 +0000

Project Plan

I’ve settled on both a subject and a method for my class project. I’ll be making a game in Twine exploring the Shiners in Ottawa, a gang of Irish immigrants that allegedly terrorized the early city of Bytown (now Ottawa) in the mid-nineteenth century. A graphic novel on the subject was released in 2018 year, but there has otherwise been little in the way of popular knowledge that these old gangsters even existed. To that end, I decided that a text-based game would be a great idea to raise awareness of not just the Shiners and their war, but question that can be applied to the modern era: questions of immigration, rebellion, revolution, policing, violence, and coexistance.

A fully-fledged, three-dimensional game is far outside the scope of what I’m capable of completing in the ~2 months I have to work on this project, since the visual assets, images, and graphics would take far too long for me to cobble together, and the end results wouldn’t exactly be pretty. Instead, I’ll put my English degree to use, and make a text-based game. Despite being focused on actual, factual events that occured in Ottawa almost two hundred years ago, the story will be fiction - this should allow me to use my background in Creative Writing to its fullest and lighten the research load, allowing me to focus on writing and fleshing out the game itself.

Devlog One

Tue, 17 Sep 2019 00:00:00 +0000

Project Ideas

I have a few ideas for a potential project focusing on Ottawa.

Ottawa’s disasters
Parliament’s visual history
Ottawa’s amalgamations of rural communities
Skylines & light pollution

Methodologies to explore:

Twine narratives (Twine cookbook)
TaleBlazer
Unity AR
Sound & Audio
Projection Mapping
Mozilla hubs

This being my first history project, I’ll need to acquaint myself with the research resources available to me.