Kobako:COSCUP 2026 演講後,來聊聊為什麼是 Ruby
上週末我在 COSCUP 的演講「讓 AI 接管你的應用,打造微秒級無縫的 Ruby 安全沙盒」分享 Kobako 設計過程中的一些考量,後續的提問被問到在 AI 時代不太需要考慮語言時,為什麼要選 Ruby 呢?
簡單地回答,單純就是「我喜歡用 Ruby 這個語言」然而在 Kobako 的設計,還有很多更深層的考量。
上週末我在 COSCUP 的演講「讓 AI 接管你的應用,打造微秒級無縫的 Ruby 安全沙盒」分享 Kobako 設計過程中的一些考量,後續的提問被問到在 AI 時代不太需要考慮語言時,為什麼要選 Ruby 呢?
簡單地回答,單純就是「我喜歡用 Ruby 這個語言」然而在 Kobako 的設計,還有很多更深層的考量。
雖然是受到 ruby.wasm 的限制才選擇 mruby 來作為沙盒(Sandbox)的語言,但也不代表跟 CRuby 都使用相同的語言標準(ISO/IEC 30170:2012)就讓這個目標輕鬆實現,相比 CRuby 在 mruby 上有很多限制存在。
這是 mruby 為了能夠在嵌入式系統這類環境運作必要的取捨,相對的輕量的特性剛好也是一種 Embedded Sandbox 的優勢,我們把 Ruby 語言沙盒嵌入到任何語言的這種想法,變成可行的選項。
mruby 透過編譯器(Compiler,通常是 mrbc)編譯後,會產生 mrb 格式的二進位檔案,這個檔案的格式被稱作 RITE 如果要運行編譯後的 mruby 程式碼,就需要能夠解析並且讀取。
自從畢製開始與同學開發遊戲後,我就開始喜歡嘗試運用一些工具如 HTML5、Mono、Processing 等來製作一些屬於自己的「遊戲框架」
自從上次嘗試使用 Mono 與 mruby 結合後,這次在與朋友的閒聊中回想起了 Open Frameworks 這套工具。 Open Frameworks 基本上被稱為是 C++ 版本的 Processing 就各方面來說比 Processing 改進不少,至少就我這幾天的體驗來看,以我目前的實力已經可以純熟運用了!
過去曾有一段時間嘗試玩過,但是因為沒有 Project Generator 輔助建構專案,再加上與 C++ 其實不是那麼的熟悉,因而放棄。這次透過 Unreal Engine 的經驗,以及上次 mruby 的整合讓我順利的開始使用 Open Frameworks。
這篇文章主要會分享我使用 Open Frameworks 開啟一個 Ruby 檔案,並且執行裡面的方法在介面中繪製圖像的做法。 目前我認為這個方法其實還不太完善,不過作為初次的嘗試可以算是一個不錯的成果。