Hana Project 介紹 - 第一集

-

簡介

Hana Project 主要目標是讓小說家，或想要做文字冒險遊戲的人比吉里吉里更簡單更容易跨平台的 java 的galgame（目前目標是windows + Linux + Mac）
Hana 計畫目前有兩個正在執行的內容，分別是: Hana 腳本語言跟 Hana 引擎。
由於腳本語言是單純的設定好，沒有架構之類的需解釋內容，因此在這邊先說明。

hana腳本語言：

目前只能存在一個main.hana檔案，所有文本都只能在一個檔案裡。 一個服務於hana引擎的腳本，主要目標讓使用者不用寫到太多像程式碼的東西 其實我個人覺得五種有點多了，但這已經是壓到極限了 這五個分別是：

  • background （背景圖片）
  • backgroundMusic （背景音樂）
  • 立繪
    • role1 （立繪1）：畫面左邊的人
    • role2 （立繪2）：畫面中間的人
    • role3 （立繪3）：畫面右邊的人
  • sound （音效）
  • system （系統）

如果系統不算且不須特效的話基本上所有的東西一個叫fileName的東西而已，需要用到腳本的話前面加上"hana."，一般文本的話直接打字上去就好了 下面直接給個例子：

在這個世界上不存在著希望。
為什麼你會這樣想阿？
突然一個聲音從前方傳到我耳邊。
我抬起低著的頭。
hana.background.fileName("頂樓夜景.png")
hana.role1.fileName("女主角1.png")
hana.backgroundMusic.fileName("背景音樂1.wav")
一名少女出現在我眼前。

留言

張貼留言

這個網誌中的熱門文章

基本 Spring security 快速入門

-
圖片
基本 Spring security 快速入門 最近學了 spring security 遇到一些 6 版和舊版的一些差異，所以想說寫一下快速入門，但有些前情提要: 這個入門不包含 spring security 的使用概念，關於這部分相當推薦閱讀 spring security 實戰這本書 本快速入門不包含 OAuth2 和權限控管，只會使用 Basic 驗證，但建議先學會入門之後再加深． 由於個人專案有使用到 swagge ，因此也會有相對的教學 主要使用到的 spring security 元件： org.springframework.security.authentication.AuthenticationProvider org.springframework.security.crypto.password.PasswordEncoder org.springframework.security.core.userdetails.UserDetailsService org.springframework.security.core.userdetails.UserDetails 撰寫 UserDetailsService 首先先在 service 新增 class 並且 implements UserDetailsService 實作的時候會發現需要實作: UserDetails loadUserByUsername ( String username ) throws UsernameNotFoundException ; 依照 function name 可以知道要實現的功能是去 DB 或 redis 之類的地方取得使用者資訊，並且將資料放進 UserDetails 後 return 出去，因此在開始寫 loadUserByUsername 方法之前需要先實作 UserDetails 實作 UserDetails 實作的時候會發現我們需要實作 getAuthorities getPassword getUsername isAccountNonExpired isAccountNonLocked isCredentialsNonExpired isEnabled 基本上依照 functio...
閱讀完整內容

記帳專案說明

-
圖片
新專案說明 最近開新的專案，目前專案的系統架構和後端處理的差不多了，剩下前端的部分正在一邊學 react 一邊完成中，考慮到最近要開始找工作了，所以想說寫個部落格一邊介紹目前專案的架構與紀錄目前的狀態。 專案整體架構 在開始之前我們先發一張架構圖吧，接下來請把架構圖當成地圖開始冒險吧。 這次的專案主要是走雲原生的概念，下述我們分成基礎設施、前端、後端來聊吧 基礎建置 雲端服務廠商選擇: AWS 這個專案從剛開始設計就是預計上雲且使用的是 aws，主要有兩個點 我們家並沒有固定 IP ，如果要走地端的話勢必要使用到 DDNS ，那牽涉的範圍就會更廣了，因此決定直接上雲 根據網路上查到的資料，目前 aws 市佔 33% ，考慮到將來要找工作與方便尋找資料因此決定直接使用 aws 用到的 AWS 服務 接下來先概覽一下用到的服務與相關功能，下面會以使用者接觸到服務的順序來說明： 服務名稱 用途 router53 DNS, 用於將 domain 轉換成 IP, 我的 domain 也是在該服務購買的 彈性 IP 當我們租了 AWS 的伺服器時是沒有對外 IP 的，因此我們需要透過彈性 IP 申請並且綁定到我們的 EC2 安全群組 連到伺服器的防火牆，可以設定每個 port 是否要開啟，並且設定白名單等 EC2 這個就是我租伺服器的本體，所有的服務與反向代理等都是放在這裡 EC2 建置了哪些服務 這邊會講一下我安裝與使用到哪些非我開發的服務 資料庫： 資料庫的部分我使用的是 mariaDB, 會選擇 mariaDB 的原因除了他是 MySQL 的分支之外，他的社群很活躍、穩定性也很高 catch: catch 的部分我使用 redis ，主要適用於處理會需要經常取得資料或者不需要持久化的資料，目前我主要用於記錄使用者登入後的 token，由於採取的是前後端分離的架構，後端會需要頻繁的驗證 token 和透過 token 取得用者資訊，因此這部分得資料就放在 redis，更詳細的使用邏輯將會在後面提到後端的時候說明。 SSL: 這個專案的 SSL 主要用於 https 連線，這部分是使用 Let's Encrypt 家的憑證。 會用 Let's Encrypt 的原因最主要是免費和自動化申請，如果考慮到...
閱讀完整內容

JMSTemplate 的教學

-
前言（一堆廢話） 嘿，大家好久不見！我發現距離上次在 Blogger 發文，竟然已經過了快半年了。想想還真有點不好意思，不過這次我可是帶著新東西來跟大家分享的！ 這次要聊的是 Java JMSTemplate。為什麼突然要學這個呢？主要是因為我最近換了新公司，而他們那邊剛好需要用到 訊息佇列 (Message Queue) 的技術，所以我就趁這個機會好好學了一下。 (老實說，我其實都工作六年了，這東西早就該會了啦！) Message Queue 是什麼和目的 這部分我覺得我讀的書的寫的很棒，因此想說直接引用過來。 假設現在是星期五 16:55 ，在幾分鐘就可以開始期待已久的休假了。再過幾分鐘你的飛機就要起飛了，但是在這幾分鐘你需要先確定主管和同事了解你的工作進度，這樣他們才有機會於下週一接續你的工作。這時候該怎麼辦？ 這時候避免打擾到他們最好的做法就是留紙條或發送 E-mail ，如此一來他們就可以在下週一或有空的時候看到 E-mail 接續工作。 這段很完美的解釋了 Message Queue，的概念，將訊息傳到佇列，之後根據佇列的先進先出讓服務吸收消化，最後調整服務一次接收多少 Message 。 如此一來可以帶來以下幾個好處： 解耦合： 發送者可以完全不管接收者狀態與是否可以承受，只需要將訊息丟到 Queue 就好了 系統不同的區塊可以獨立開發（其實就跟現今流行的微服務類似概念） 非同步處理：發送者可以完全不需要等待另一方處理就可以繼續處理下一個 request。這樣講有點抽象，可以想像麥當勞點餐系統，櫃檯的人員不需要完全確認廚房是否收到單就可以接下一個客人了。 提高可靠性：很多提供 Message Queue 的元件會提供持久化的功能，他會將 message 存起來，這樣一來就算遇到某個 Message 處理有問題，也可以很快查到並且做後續 support。 水平擴展：我們可以很輕易地增加消費 Message 的處理人員，這樣就可以提高 Queue 的消化速度，已應付高流量又要快速處理的需求。 等等 上述只有放我自己認為很重要的優點，但其實還有很多的優點。 名詞 那優點介紹完之後我們來聊一下在 Message Queue 常會用到的名詞， 佇列(Queue)：就像是排隊一樣，先進先出。 生產者(Producer)：就是指生成 Message 的服務 消費者(...
閱讀完整內容