Teaching History and Languages with a Strategy Computer Game: 0 A.D. in the Classroom

Programming Historian in English has received a proposal for a lesson, 'Teaching History and Languages with a Strategy Computer Game: 0 A.D. in the Classroom' by @historical-theology.

I have circulated this proposal for feedback within the English team. We have considered this proposal for:

Openness: we advocate for use of open source software, open programming languages and open datasets
Global access: we serve a readership working with different operating systems and varying computational resources
Multilingualism: we celebrate methodologies and tools that can be applied or adapted for use in multilingual research-contexts
Sustainability: we're committed to publishing learning resources that can remain useful beyond present-day graphical user interfaces and current software versions

We are pleased to have invited @historical-theology to develop this Proposal into a Submission under the guidance of @scottkleinman as editor.

The Submission package should include:

Lesson text (written in Markdown)
- For guidance, we recommend Sarah Simpkin's lesson Getting Started with Markdown
Figures: images / plots / graphs (if using)
Data assets: codebooks, sample dataset (if using)

@historical-theology has already shared their Submission package with our Publishing team by email, copying in @scottkleinman. Our Publishing team will now process the new lesson materials, and prepare a Preview of the initial draft. They will run any questions by the contributor and post a comment in this Issue to provide the locations of all key files, as well as a link to the Preview where contributors can read the lesson as the draft progresses.

Our dedicated Ombudspersons are Ian Milligan (English), Silvia Gutiérrez De la Torre (español), Hélène Huet (français), and Luis Ferla (português). Please feel free to contact them at any time if you have concerns that you would like addressed by an impartial observer. Contacting the ombudspersons will have no impact on the outcome of any peer review.

Hello @scottkleinman and @historical-theology,

You can find the key files here:

.md: /en/drafts/originals/teach-history-and-languages-with-strategy-game.md
images: /images/teach-history-and-languages-with-strategy-game
assets: [none]

You can review a preview of the lesson here:

http://programminghistorian.github.io/ph-submissions/en/drafts/originals/teach-history-and-languages-with-strategy-game

I noticed a couple things when setting this file up, which I've listed below:

[ ] Figure 1 was very large, so I cropped the top and bottom to be able to size it down to 840 pixels on the longest size, without losing too much of its quality. We try to keep to this size to ensure images load for users using slower internet connections or less powerful devices.
[ ] Figures 4-12 were also very large. Sizing them down to 840 pixels across meant the tab to the left became illegible, so I only sized them down to 1700 pixels. If you think that part of the image is not necessary though, we could crop it out, which would allow us to size the images down even further.
[ ] I noticed you've provided alt text for your images, but it isn't exactly what we're looking for. Ideally, alt text gives a visual description of what a sighted reader would see in the image, in a way which is meaningful to visually impaired readers.

Hello Corey @historical-theology,

I've sent you an invitation to join us as Outside Collaborators here on GitHub. This will give you the Write access you'll need to edit your lesson directly. (There's no need to use the Git Pull Request system in our ph-submissions repository).

What's happening now?

Your lesson has been moved to the next phase of our workflow which is Phase 2: Initial Edit.

In this Phase, your editor Scott @scottkleinman will read your lesson, and provide some initial feedback. Scott will post feedback and suggestions as a comment in this Issue, so that you can revise your draft in the following Phase 3: Revision 1.

%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'themeVariables': {
              'cScale0': '#444444', 'cScaleLabel0': '#ffffff',
              'cScale1': '#882b4f', 'cScaleLabel1': '#ffffff',
              'cScale2': '#444444', 'cScaleLabel2': '#ffffff'
       } } }%%
timeline
Section Phase 1 <br> Submission
Who worked on this? : Publishing Assistant (@charlottejmc) 
All  Phase 1 tasks completed? : Yes
Section Phase 2 <br> Initial Edit
Who's working on this? : Editor (@scottkleinman)  
Expected completion date? : May 5
Section Phase 3 <br> Revision 1
Who's responsible? : Author (@historical-theology) 
Expected timeframe? : ~30 days after feedback is received

Note: The Mermaid diagram above may not render on GitHub mobile. Please check in via desktop when you have a moment.

Hello, Corey @historical-theology

Here are some initial comments on your tutorial.

I would like to see a short narrative of a game from start to finish: what the players actually do in the course of play. This is to help the reader understand why they should wade through the lengthy setup steps. Historical accuracy is great, but the reader may think it is not worthwhile if game-players are just attacking each other with historically accurate swords whilst hurling insults in Greek. I think the reader needs to get a sense of the game up front, probably in the Tutorial Overview section.
The Tutorial Overview should probably also have a short overview of the software including the fact that it is open source, maybe a short version of its history, and the statement about the tutorial requiring no prior knowledge.
In the Requirements section, I think the point about the smoothest experience can be relegated to a footnote since most users will meet the requirements. If some issues like storage requirements seem particularly important, we can bring them back and highlight them in the body of the tutorial. The licences can also be placed in footnotes.
I'm concerned about the LAN requirement for multiplayer use since it seems to me that that will not suit classroom use. Could you perhaps address this, in case I have misunderstood how easy it would be to deploy them game in this scenario?
I would suggest re-casting the section entitled "A Scholarship-Aware Community Endeavor" to focus more on the strengths and limitations of the game's use for teaching. I think you can make the point about the game's emphasis on historical accuracy more concisely and focus on how this historicity can be used (the subsequent sections).
I am uncertain of the value of the separate "Team Building" section. The issue dovetails with scattered statements about the use of 0 A.D. for both single and multiplayer play. I wonder if when introducing the software you could give examples of both, and, for the latter, emphasise that one of the advantages is team building.
I am also unclear on the role of AI in the game (there are two references in your discussion). Could you clarify that?
I suggest not listing GIMP as a "requirement" and instead introducing it as software for working with topography when importing geographic data. I think that the use of GIMP to modify the data might be a separate subsection from the subsection on editing in Atlas.

Could you please address these issues in a revision before I send the tutorial out to external reviewers? And, of course, let me know if you have any questions.

What's happening now?

Hello Corey @historical-theology. Your lesson has been moved to the next phase of our workflow which is Phase 3: Revision 1.

This Phase is an opportunity for you to revise your draft in response to @scottkleinman's initial feedback. You can make direct commits to your file here: /en/drafts/originals/teach-history-and-languages-with-strategy-game.md. @charlottejmc or I can help if you encounter any practical problems! When you and Scott are both happy with the revised draft, we will move forward to Phase 4: Open Peer Review.

%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'themeVariables': {
              'cScale0': '#444444', 'cScaleLabel0': '#ffffff',
              'cScale1': '#882b4f', 'cScaleLabel1': '#ffffff',
              'cScale2': '#444444', 'cScaleLabel2': '#ffffff'
       } } }%%
timeline
Section Phase 2 <br> Initial Edit
Who worked on this? : Editor (@scottkleinman) 
All  Phase 1 tasks completed? : Yes
Section Phase 3 <br> Revision 1
Who's working on this? : Author (@historical-theology)  
Expected completion date? : May 8
Section Phase 4 <br> Open Peer Review
Who's responsible? : Reviewers (TBC) 
Expected timeframe? : ~60 days after request is accepted

Note: The Mermaid diagram above may not render on GitHub mobile. Please check in via desktop when you have a moment.

@anisa-hawes , @charlottejmc , and @hawc2 , thank you for configuring all of this for us, and @scottkleinman , thank you for your thoughtful, extensive feedback.

I have prepared a thorough revision (ec83e84) in which I have aimed to take seriously everything mentioned thus far in this issue thread. While preparing the revision, I also have made a number of smaller changes throughout the piece to improve its clarity.

@charlottejmc

Figure 1 was very large, so I cropped the top and bottom to be able to size it down to 840 pixels on the longest size, without losing too much of its quality. We try to keep to this size to ensure images load for users using slower internet connections or less powerful devices.

Figures 4-12 were also very large. Sizing them down to 840 pixels across meant the tab to the left became illegible, so I only sized them down to 1700 pixels. If you think that part of the image is not necessary though, we could crop it out, which would allow us to size the images down even further.

The adjustments look satisfactory. I am concerned about legibility at the reduced resolutions, but I also think that readers following the body text will not struggle to know what is being depicted in the images.

I noticed you've provided alt text for your images, but it isn't exactly what we're looking for. Ideally, alt text gives a visual description of what a sighted reader would see in the image, in a way which is meaningful to visually impaired readers.

I have expanded the alternative text for every image with greater specificity. Please let me know if the updated alternative texts suffice (and, if not, how they might be improved further). Also, feel free to make direct commits to improve their functional utility for potential readers who might be unable to view the images.

@scottkleinman

I would like to see a short narrative of a game from start to finish: what the players actually do in the course of play. This is to help the reader understand why they should wade through the lengthy setup steps. Historical accuracy is great, but the reader may think it is not worthwhile if game-players are just attacking each other with historically accurate swords whilst hurling insults in Greek. I think the reader needs to get a sense of the game up front, probably in the Tutorial Overview section.

The Tutorial Overview should probably also have a short overview of the software including the fact that it is open source, maybe a short version of its history, and the statement about the tutorial requiring no prior knowledge.

I have overhauled Tutorial Overview to include nearly all of these things. In the process, I have used your encouragement to write a "short narrative" as a way to create a kind of orienting hook or lead-in for the reader.

In the Requirements section, I think the point about the smoothest experience can be relegated to a footnote since most users will meet the requirements. If some issues like storage requirements seem particularly important, we can bring them back and highlight them in the body of the tutorial. The licences can also be placed in footnotes.

I have moved all of these things to the endnotes.

I'm concerned about the LAN requirement for multiplayer use since it seems to me that that will not suit classroom use. Could you perhaps address this, in case I have misunderstood how easy it would be to deploy them game in this scenario?

I have reworked this part of the Requirements section.

I would suggest re-casting the section entitled "A Scholarship-Aware Community Endeavor" to focus more on the strengths and limitations of the game's use for teaching. I think you can make the point about the game's emphasis on historical accuracy more concisely and focus on how this historicity can be used (the subsequent sections).

I am uncertain of the value of the separate "Team Building" section. The issue dovetails with scattered statements about the use of 0 A.D. for both single and multiplayer play. I wonder if when introducing the software you could give examples of both, and, for the latter, emphasise that one of the advantages is team building.

I have overhauled the section entitled "A Scholarship-aware Community Endeavor," partly by combining it with the previous "Team Building" section and condensing the result.

I am also unclear on the role of AI in the game (there are two references in your discussion). Could you clarify that?

It is standard practice for what are often colloquially referred to as "computer players" or "bots" to be labeled formally as artificial intelligence (AI) units/players. Is there something specific that ought to be clarified within the tutorial about this? If not, and I have answered your question, I am comfortable leaving those references to AI as they are.

I suggest not listing GIMP as a "requirement" and instead introducing it as software for working with topography when importing geographic data. I think that the use of GIMP to modify the data might be a separate subsection from the subsection on editing in Atlas.

I have removed all instances in which GIMP is framed as a requirement, instead noting specifically that the reader may use the image editing software of his/her choice. At the same time, I have left in-place the detailed steps in GIMP for the benefit of persons without any background in digital image editing, since performing those digital image editing steps is necessary for successful topographic image importation in Atlas for 0 A.D.

Could you please address these issues in a revision before I send the tutorial out to external reviewers? And, of course, let me know if you have any questions.

The attention to detail that you have shown, @scottkleinman , is laudable, and I appreciate it.

Thus far, I have appreciated how straightforward this GitHub-based approach is for the Programming Historian. While I hope that you will find this revision to be ready to be issued to external reviewers, I will be happy to fulfill any follow-up request(s) for revision that you might have.

@historical-theology Corey

Corey Stephan, Ph.D. coreystephan.com

Thanks for getting back to me @historical-theology. I agree that we should leave the images as they are, to ensure legibility. Thank you very much for your work on the alt-text – I've made some minor edits, but overall it looks great!

Thank you, Corey @historical-theology. We really appreciate your work on this first round of revisions.

Scott @scottkleinman will aim to review your changes within the next fortnight by ~May 31st. After that, we'll confirm the next steps.

@historical-theology, I am just emerging from the end-of-semester crush and finally able to have a look your revisions. They look good. One thing that has been lost, as far as I can tell, is a download link for GIMP, which still seems useful despite GIMP's not being a "requirement". So this is just a note to put that in before we publish.

That said, I think we are ready to present the tutorial to peer reviewers. I'll start on this next week.

Hello Corey @historical-theology,

What's happening now?

Your lesson has been moved to the next phase of our workflow which is Phase 4: Open Peer Review.

This phase will be an opportunity for you to hear feedback from peers in the community.

Scott @scottkleinman will invite two reviewers to read your lesson, test your code, and provide constructive feedback. In the spirit of openness, reviews will be posted as comments in this issue (unless you specifically request a closed review).

After both reviews, Scott will summarise the suggestions to clarify your priorities in Phase 5: Revision 2.

%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'themeVariables': {
              'cScale0': '#444444', 'cScaleLabel0': '#ffffff',
              'cScale1': '#882b4f', 'cScaleLabel1': '#ffffff',
              'cScale2': '#444444', 'cScaleLabel2': '#ffffff'
       } } }%%
timeline
Section Phase 3 <br> Revision 1
Who worked on this? : Author (@historical-theology)
All  Phase 3 tasks completed? : Yes
Section Phase 4 <br> Open Peer Review
Who's working on this? : Reviewers (@adamlporter + TBC)
Expected completion date? : 22 Nov // ~60 days after request is accepted
Section Phase 5 <br> Revision 2
Who's responsible? : Author (@historical-theology)
Expected timeframe? : ~30 days after editor's summary

Note: The Mermaid diagram above may not render on GitHub mobile. Please check in via desktop when you have a moment.

Hello Corey @historical-theology,

Caio Mello @caiocmello will now be taking on editorial responsibilities for this lesson. Caio's first step will be inviting two community peer reviewers to contribute their feedback. Caio will post an update here in the Issue when the reviewers' names are confirmed. I would like to take this opportunity to apologise for the extended delay, and thank you for your patience. Alex @hawc2 will be in touch with you by email in the coming days.

With very best wishes, Anisa

Dear @historical-theology,

Sorry for the delay with your lesson. I've been actively looking for potential reviewers. I will do my best to speed up things from now on. Your lesson is very interesting and I'm happy to be able to help shape it for publication in the PH.

During Phases 2 and 3, Scott Kleinman provided initial feedback on this lesson, then worked with Corey @historical-theology to complete a first round of revisions. I've now taken on editorial responsibilities for this lesson.

In Phase 4 Open Peer Review, we invite feedback from others in our community.

Welcome Adam Porter @adamlporter. By participating in this peer review process, you are contributing to the creation of a useful and sustainable technical resource for the whole community. Thank you. I am still awaiting confirmation of who will join us as a second peer reviewer.

Please read the lesson, test the code, and post your review as a comment in this issue by November 22.

Reviewer Guidelines:

https://programminghistorian.org/en/reviewer-guidelines

A preview of the lesson:

http://programminghistorian.github.io/ph-submissions/en/drafts/originals/teach-history-and-languages-with-strategy-game

-- Notes:

All participants in this discussion are advised to read and be guided by our shared Code of Conduct.
Members of the wider community may also choose to contribute reviews.
All participants must adhere to our anti-harassment policy:

Anti-Harassment Policy

This is a statement of the Programming Historian's principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.

Programming Historian in English is dedicated to providing an open scholarly environment that offers community participants the freedom to thoroughly scrutinize ideas, to ask questions, make suggestions, or request clarification, but also provides a harassment-free space for all contributors to the project, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion, or technical experience. We do not tolerate harassment or ad hominem attacks of community participants in any form. Participants violating these rules may be expelled from the community at the discretion of the editorial board. If anyone witnesses or feels they have been the victim of the above described activity, please contact our ombudsperson Dr Ian Milligan. Thank you for helping us to create a safe space.

programminghistorian / ph-submissions