區塊鏈能為電競帶來什麼幫助?

到底區塊鏈在電競產業可以怎麼搞?先來瞭解一下電競產業生態圈的模樣。
評論
評論

原文刊於 Medium,INSIDE 獲授權轉載。原文標題為 〈電競+區塊鏈=?〉 關於作者 Justine Lu 如果活在遊戲裡就會是名狩魔獵人;抹茶是她的恢復藥水。

在本文開始前,首先恭喜台灣電競國手 Nice 在 2018 年雅加達巨港亞運奪下《星海爭霸 II》銀牌,台灣代表隊在《傳說對決》項目獲銀,《英雄聯盟》項目奪銅!雖然每次電競比賽台灣有選手拿下冠軍,就會號稱「電競元年」,既然今年區塊鏈項目開始火熱,也號稱「區塊鏈元年」,不如就摻在一起做撒尿牛丸吧。

到底區塊鏈在電競產業可以怎麼搞?先來瞭解一下電競產業生態圈的模樣。

電競產業生態圈

 2017 年,全球電競市場已帶來 6.96 億美金的營收,相比於 2016 年的 5 億美金,增長了 39.2 %,而 2020 年預計將達到 19.04 億美金。根據推估, 2018 年電競賽事全球總觀賽人口將高達 3 億 8 千萬,觀看時數將增至 66 億小時,這幾年成長趨勢並無減緩。事實上,所謂的電競產業生態系,大致上也和所有的運動產業生態系並無二致。

從上圖可以快速瞭解,賽事獎金多靠遊戲商及贊助廠商提供。而賽事製播的費用也需仰賴遊戲商和贊助商。以下約略列出幾個業內人士提到都想掉淚的痛處:

對遊戲商來說

  • 遊戲商必須開發出適合比賽的遊戲,光是調整平衡就耗時費力
  • 就算該遊戲適合比賽,可能很難符合大眾口味。最佳電競遊戲應該要「易於上手,難於精通
  • 遊戲商必須持續花費行銷費用維持遊戲熱度,培養玩家觀看賽事的興趣

對贊助商來說

  • 贊助廠商不太願意贊助電競賽事,原因是難以評估賽事觀看所帶來的廣告效益能否帶動產品銷售,除非贊助商樂於推廣品牌和電競賽事連結(多為電腦硬體廠商)
  • 由於對於遊戲的刻板印象,遊戲也有年齡分級限制的緣故,大部份贊助商多還是硬體廠商、機能飲料(我個人是談過電信公司、碳酸汽水、零食啦)。近年開始出現銀行等行業

對戰隊/選手來說

  • 電競戰隊所能獲得的獎金分潤或贊助金不足,養不出明星,或甚至養不活選手
  • 戰隊養不活選手,隊伍數不足,難以形成賽事聯盟
  • 選手的職涯壽命較短(黃金年齡為 16–22 歲),退役後除了戰隊教練、賽評主播、賽事企劃等也苦無其他出路。若是產業鏈發展不健全,或是遊戲已退燒,轉行不易
  • 戰隊和選手或多或少還是會被貼上傳統社會認為「打電動就是歹囝仔」的標籤
  • 如果遊戲火紅,戰隊還得付錢給賽事組織購買參賽入場券;若是遊戲不紅,遊戲廠商可能還得自己貼錢請人出隊伍

對賽事組織/製播單位來說

  • 遊戲本身先天不足(不夠紅吸引不了觀眾),賽事聯盟成不了氣候。即使遊戲廠商自掏腰包投注大把行銷費用舉辦賽事,也只是像放了場華麗的煙火
  • 要是宣傳不足,觀賽人數不夠,吸引不了贊助商 ←→ 贊助金額或是遊戲廠商給的製播費用不夠,賽事組織及製播單位缺乏製播費用做出更吸引人的內容,就更難滿足觀眾
  • 通常最終決賽偏好實體賽事,製播費用高昂

對直播網路平台/電視台來說

  • 如果賽事精彩可期,網路平台或是電視台都還可以再賣出破口廣告,獲取額外收入(除了贊助商廣告播出以外);反之,若是賽事乏人問津,別說是廣告收入,就連贊助金都變得格外難獲得
  • 為爭取獨家轉播權,有時也需要商業和政治力的運作

只要幻想一下今天我們講的是世足盃,都能更幫助理解上述這些利益關係人。綜合以上各點,可以看出最大的癥結點就是必須擔心遊戲夠不夠紅(關注度=可能轉化潛在收視族群),以及觀看人數夠不夠多(紮實的流量=錢)

區塊鏈能為電競做什麼?

雖然區塊鏈不是萬靈丹,但是已被廣泛應用的特點也許能在某些方面幫助推動電競產業,增加關注:

金流透明公開:

過去遊戲商透過販售賽事限量虛寶或是門票分潤,營收再納入獎金池,但是玩家們只能選擇全然相信廠商公佈的數據。透過智能合約,不管是向玩家或贊助商募得的贊助金、獎金、門票收入、博彩彩金等流向一清二楚,規則怎麼訂,該怎麼分就怎麼分,沒得竄改或拖延

虛寶交易:

像是 FirstBlood ,透過區塊鏈發送虛寶獎賞平台上參賽獲勝的玩家,虛寶可再換成真實的貨幣。「當虛寶和真實資產掛上關係,勢必將吸引部分玩家加入」

博彩競猜:

雖然在某些國家還算灰色地帶,但不可否認博彩競猜絕對是造成賽事受到關注的一大原因(今年的世足盃你有沒有下注呢?)。一旦投注上鏈,賭博商無法做手腳,賽事公平公正,彩金發送也簡單迅速,甚至也能設定分潤給戰隊及關係人,增加額外收入。國外已備受矚目的平台有:Unikrm、HEROCoin、Playkey.io 等。想特別提的是 Augur ,由於開放玩家自己創建競猜題目,不僅限於賽事競猜,前陣子還有人開出「川普在年底前會不會被刺殺」的題目

粉絲經濟:

電競選手能設計自己的 NFT(我們就姑且理解它是一種虛寶),可透過智能合約賣給支持的粉絲。或是電競選手開直播/比賽時,粉絲能夠用虛擬貨幣贊助自己支持的隊伍。這兩者皆可設定合理的分潤給戰隊或經紀人(有些選手根本沒有戰隊),而不需再透過平台抽一手

結語

當然,以上這些應用都還是能以中心化的形式存在,只是因為區塊鏈的特性讓這些過往只有熟悉內幕者才知道的資訊,現金流動向變得清楚透明,電競產業鏈的每個利益關係人都將有機會能獲得公平的利潤分配。而在激勵機制帶動關注的情況下,電競產業將變得更熱門,大家都有錢賺。一旦帶進收視人口,剩下的就是比拼遊戲紅不紅了。

我無意將電競說得那麼銅臭,但不可否認的是,生態圈每個利益節點環環相扣,是不是真的使用區塊鏈技術其實不那麼重要,能不能讓生態系統自給自足,才是長久存活的真理。

參考文章:

電競+區塊鏈,玩家的 4 大入局方式

WILL MONETIZATION BE THE DOWNFALL OF ESPORTS

The Fast-Growing Esports Market and Blockchain: What It Mean for Startups

 


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 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 部可以獲得以下三大好處。

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

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。

了解 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。

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