共玩老北投:當文科遇上醫科腦,如何激盪出「長輩故事桌遊」?

共玩老北投:當文科遇上醫科腦,如何激盪出「長輩故事桌遊」?
Photo Credit: 十二道人情味提供

我們想讓你知道的是

「當文科遇上醫科腦,在遊戲設計上是否會有其他可能呢?」這是兩校助理們在一年前對於計畫構思時所做出的提問。是否能將兩校各自擅場的領域,嘗試結合在一起並做一個全新的可能?【共玩老北投】正是在這樣的發想之下誕生!

林智海老師的北投說書人團隊主要負責在地文史的導覽與講解,甚至在第三天的午後將學生分成兩條路線,分別進行五個小時的「路上觀察學」的教學與導覽。「路上觀察學」是日本發明的一種學派說法,主要透過從生活中的蛛絲馬跡去延伸思考,探討每一個現象背後的歷史文化意義。北投說書人團隊帶領學生們深入北投的大街小巷,挖掘老北投的元素及符碼,像是平埔族女巫的傳說、曾經盛極一時的鐵路及風化行業,以及由此衍生出來的「限時專送」乘載服務和溫泉文化,這些專屬於老北投人的歷史地景記憶。

圖6
Photo Credit: 十二道人情味提供
透過「路上觀察學」所蒐集到的北投元素結合在〈我的北投帝國〉上

「和可愛有智慧的長者聊天」、「去聆聽他們的故事」、「瞭解不一樣的北投」,這些是學生們在活動第二天初步與高齡玩家們互動之後,所體悟到的感受。而在透過兩校教師團隊的密集特訓,讓學生們在短短頭兩天的時間內,更知道這個實作營的定位以及接下來將要實作的部分。

「我很喜歡不同領域老師分享延緩老化與北投在地兩部分的專業。」透過陽明和政大老師們的精密授課,雖然每天辛苦操課很累,但是每位學生的回饋還是給予高度評價。實地踏查的部分,「讓我們可以真正的更認識北投文化歷史,也有更多的素材可以做遊戲」,這是在五個小時徒步行走的「路上觀察學」之後,對於北投說書人團隊的高度肯定。「學習不單只是坐在教室裡面,而是到外面走走,聽聽故事,發現一些平常注意不到的東西,我很喜歡這種上課方式」,一名陽明的學生這樣說。透過實際走入老北投的在地社區,也使得同學們總是迸出許多稀奇古怪的好點子。

南瓜妹的生動遊戲教學,不只是玩,更需要腦筋急轉彎,讓在座的學生認知到遊戲背後的設計理論及機制,對於許多愛玩桌遊的同學而言,對於遊戲有更進一步的深度認識。學生們的成果經過多次的互評互玩再重新檢討,最後終於產出了六款敘事遊戲,每一款遊戲都結合了豐富的北投記憶,分別是:〈女巫徵幫手〉、〈轉世北投〉、〈探訪北投〉、〈北投追憶〉、〈我的北投帝國〉、〈北投想不到〉。

每晚爆肝的相互激盪,只為呈現專屬老北投的遊戲作品

在Solo Singer Life Hotel & Cafe的五天時光中,每一天都充滿著熱鬧的吱喳與歡笑聲,那些年輕的聲音迴盪在溫泉街狹小的寧靜巷弄裡,引來街坊鄰居的好奇,每每路過總是帶著關愛的笑意,注視這群充滿活力的大學生們。

來自不同領域專業的兩校學生們,從第一天的彼此陌生到最後的相互熟悉,短短五天時間內的集訓與操演,每組都做出一款豐富精緻的敘事遊戲,這些革命情感與豐富的專業課程,也讓學生們在過程中經常擦出與以往經驗不一樣的火花。

「昨天跟中文系的學生聊天,哇,韓愈啊、孔子啊、司馬遷啊什麼的都跑出來了!這些東西不會在陽明(大學)的日常對話裡出現,那是很自然而然的,人文底蘊就是不一樣!跟他們講話簡直是一種享受啊!」一名陽明大學的學生這樣說著。「能和不同領域的同學,一起體驗不同領域相結合的課程,確實是一次相當難得的經機會」,雙方學校的校園環境與學術氛圍的差異,讓這次醫學與人文的合作,對彼此而言都是打開了另一片天地的視野,而他們每一組的分配協作,也影響了每一組的風格,製作出不一樣的創意敘事遊戲。

圖8
Photo Credit: 十二道人情味提供
透過醫學與人文領域的碰撞,也形塑著每組成員的合作模式與成長

十多位神采奕奕的老北投高齡長輩,在最後一天的上午,一同到北投社大的教室裡,分別試玩了六個小組所做出的敘事遊戲。同學們首先必須要透過彼此熟悉的話語,向高齡玩家們說明遊戲的規則與機制,而在遊戲進行的同時,隨著彼此建立的默契與情誼,也引發了老北投長輩們侃侃而談自己豐富的人生故事與經歷。

「如果想要吃XX,我推薦要到那裡!」幾乎每一位高齡玩家記憶裡,都有著屬於他們自己的美食地圖與口袋名單。關於老北投的美食體驗,同學們在前四天的活動踏查時,就已經探索了不少好吃的小吃,可是對於土生土長的老北投人而言,真正經典的那些美食,則是他們口中一則則伴隨美食的記憶和故事。說到吃,民以食為天,尤其北投市場的傳統小吃更引發兩個世代的玩家們暢談與熱議的話題,光是一碗「滷肉飯」或「排骨酥麵」的美味,就經常惹得大家將遊戲的事情拋到九霄雲外,認真的來評比各個店家的風味與背後隱藏的北投記憶。

邱聰俞長輩就是一個對於生活十分敏銳,又是一位善於說故事的能手,對於〈探訪北投〉這組同學所設計卡牌上的「撥號電話」,就講述了二十幾分鐘關於那個年代撥號電話的趣聞趣事,而這些遊戲所引發的每一則故事記憶,正是此活動五天實作營的最終要旨與目的:讓玩家們透過遊戲的過程一起來「說故事」,而這些故事透過實地踏查所挖掘出來的北投符碼,與老北投人的生命經驗有了重要的連結,兩個世代的族群透過這些深藏在遊戲裡的北投元素,去思考、去回憶、去分享,不但達成老化心理學所期望的大腦活化,也更將各人的生命經驗與本地的歷史記憶,一起傳承到下一代的年輕族群身上,讓這豐厚的文史資源與在地經驗,在北投這個地方繼續生生不息下去。

圖12
Photo Credit: 十二道人情味提供
邱聰俞先生看著〈探訪北投〉中的「撥接電話」卡牌說著記憶中的故事

慢一點變老,透過遊戲來共創兩個世代的故事傳承

在高齡社會中尋找「慢一點變老」的可能,是心理學不斷嘗試的一項目標,而透過遊戲的大腦活化,是一個普遍且容易推廣的方式,然而【共玩老北投】的活動目的並不僅止於此,而在於透過北投記憶的遊戲之中,尋找兩代人之間共處共享的全新方式與可能性。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡