文章

參加畢業展之設計類展場小心得

圖片
先不論各校展場多大多小,先以展場實際的幾個問題來討論。 作品主要有幾種類型 - 媒體影視動畫、PC機台遊戲、行動裝置遊戲、互動電子書裝置、跨領域混合媒體、建築模型、平面設計、商品設計......諸如此類。 而自己主要是觀察跟『螢幕』『數位裝置』有關係的展場。 這類作品的展場主要會有兩個重點,不過卻會衍伸很多問題 螢幕 (甚至是大螢幕) 裝置 (PC、行動裝置甚至自製互動機構) 螢幕的擺放方式,大多以壁掛或內嵌在牆面,也有部分是直接將螢幕擺放至展示台上。 如果是動畫類、大螢幕,這類螢幕最好是放得比視線高度高一些,讓展場空間足夠讓遊客稍微距離展櫃、版一些距離去觀看、操作。 如果大螢幕搭配遊戲,螢幕盡可能不要用過大的尺寸,或讓遊客不用近距離盯著大螢幕。 例如這屆世新大學擁有較大的展場並將空間充分利用,讓遊客能夠很輕鬆地操作、觀看遊戲畫面。 相對於這屆的台北海院,在展櫃設計上就不太適合遊戲操作,遊客需要貼近展櫃盯著大螢幕,且將身體下壓、雙手下擺才能操作PC遊戲,這樣的遊戲體驗非常累人。 雖然相對其他校系有較大的平台擺放物品、週邊商品,但高度過低,拿取較困難。 在這塊做得最穩定的應該算是南台科大多樂系了,他們的展櫃設計成可重複使用且在平台高度、螢幕高度距離都還算OK,行動裝置遊戲在平板上操控、同步到大螢幕上,就算遊客眾多也不會互相遮擋。 也可以將自己的遊戲形象做在展櫃旁,讓人遠遠就能看到自己的遊戲名稱、形象。 可惜是展櫃擴充性較低,沒辦法在展櫃擺放太多物品,且搬運不易。 另一個問題就是遊客視線與動線問題,實際觀察過遊客的動線與視線,遊客會習慣將視線放在牆邊,也就是一個空間內,遊客主要會往靠牆面的作品看,在中間的作品注目的比例偏低,甚至會忽略。 另一個就是螢幕跟作品形象如果不顯著,沒有展場人員特別介紹或招呼,遊客停留率也會偏低。 雙向展場示意圖 紅色是牆面。遊客通常只會從單邊走進去,不會向回走,觀看藍色區域的作品比例會比綠色比例高許多,尤其愈靠近轉角的作品愈會被忽略。 這個狀況在愈狹窄的展場空間,狀況會愈顯著,除非展場空間非常大,中央的作品用大螢幕等方式特別吸引遊客注目或規劃成影片輪播區等方式,不然遊客邊走邊看會忽略到另一側的作品,尤其路只有一條的狀況下。 或者將展場規劃

關於NGUI與解析度適應(基礎篇)

圖片
通常第一件事情,先確認解析度,大多的裝置都還是800*480,或者主要還是習慣以800*480來做檢視與製作(雖然真正製作UI時還是會開一個1280*800的尺寸去製作UI) 會先將UI Root的縮放方式設定如下圖 然後我們先在角落放滿UI 接著從Game視窗改解析度為1280*800並將畫面最大化...... 這篇最大的問題出來了,原本以為會貼著邊的UI,其實在不同解析度下會出現這樣的狀況,突出去太多、縮進來太少...... 這個問題要怎麼解決呢? 原先我自己是用會整體變形的縮放方式,後來NGUI新版本,不得不改做法。 先在基本的解析度下將UI的Anchor改為Unified,仔細看其實他還有分上下左右跟目標,其實就是將UI的上下左右邊去對齊目標的某個邊界,或者特定的位置。 接著我們可以改變解析度去觀看,調整後視窗需要拉動一下尺寸,或者執行狀態,UI才會重新再適應一次,這點要注意一下。 但是有一些地方需要注意,UI在設計時就要注意到版面問題,盡可能避開適應時會重疊、出現破綻的設計。 或者要多注意這些細節。 而且適應也不是百分之百完美的作法,目前NGUI如果有使用PositionTween,也會因為適應後,位置會偏移,要記得自己用腳本去修正。

Unity 以Collider+Rigdbody達成物件偵測攻擊判斷

圖片
範本使用腳本 本範例用委託事件監聽的方式,監聽攻擊判斷區域,該判斷物件加入Collider+Rigdbody。 在開啟物件用來判斷時,只送出一次進入區域的物件,在關閉時則清除開啟時的紀錄,在下次開啟判斷時重新紀錄。 自己是打算在AnimationEvent處理攻擊判斷區域的開關,用以送出攻擊資訊到進入區域的敵人物件。 邏輯與功能不夠純熟,有待加強之處還請前輩們指正。

遊戲案例分析 : WonderFlick

圖片
開發商: LEVEL-5 發行商:LEVEL-5 遊戲類型:RPG冒險 遊戲目標: 隨著故事劇情前往不同的地方與魔物戰鬥,於地圖行走時可能遭域其它魔物進入戰鬥並消後體力值。 以拖拉硬幣的方式選擇戰鬥方式,於戰鬥中擊敗魔物。 硬幣有分:物理攻擊、技能攻擊、特技攻擊、使用物品、輪盤特殊效果以及Combo模式六種。 可以於城鎮中雇請其它隊員幫忙戰鬥,並於戰鬥中每人三次動作,輪流進行攻擊,進行途中魔物會自行攻擊、施放技能甚至防禦。 在Combo模式下,可放上三個硬幣來進行Combo,不同的組合有不同的效果。 並於怒氣值滿時,可以進行連續打擊模式來連續攻擊。 戰鬥畫面: 於野外遭遇怪物時,會有鏡頭模糊縮放的效果後進入讀取畫面,讀取完後出現怪物的種類、等級。 野外場景基本上是前中景3D製作,遠景使用半球 or SkyBox 的方式處理,標題畫面基本上也是類似方式。 角色會依照不同的攻擊狀態移動位置,並改變鏡頭角度,攻擊、打擊時會有相對應的攻擊魔法特效,或狀聲詞字體呈現。 戰鬥結束後會隨機選擇一位角色展示勝利動作,並跳出計算經驗值的介面。 並顯示或得獎賞方式,有直接取得或擲骰子。

製作無接縫3D方塊貼圖

圖片

以委託的方式使用簡易手勢與加速規控制

參考文章: C# 事件和Unity3D - http://zijan.iteye.com/blog/871207 以兩點座標求其角度與連線之垂直向量方向 - http://blog.happybean.tw/blog/2012/07/04/javascript-yi-liang-dian-zuo-biao-qiu-qi-jiao-du-yu-lian-xian-zhi-chui-zhi-xiang-liang-fang-xiang NGUI研究院之三种方式监听NGUI的事件方法(七) - http://www.xuanyusong.com/archives/2390 觸控數量 - http://game.ceeger.com/Script/Input/Input.touchCount.html 觸控狀態 - http://game.ceeger.com/Script/Enumerations/TouchPhase/TouchPhase.html 觸控列表 - http://game.ceeger.com/Script/Input/Input.touches.html 獲取觸控 - http://game.ceeger.com/Script/Input/Input.GetTouch.html 不知道該怎麼解釋內容,寫得不是很理想,也不是很懂為什麼這樣用、是不是該這樣理解,感覺有些細節還是沒調整好,反正主要請翻閱『C# 事件和Unity3D』、『NGUI研究院之三种方式监听NGUI的事件方法(七) 』 總之大概是在A腳本內放一些方式去,再到B腳本去監聽A腳本有設定好的函數,不過因為我想有多種控制方式,所以在B腳本可能有可能同時有2.3個函數呼叫同一個函數來控制移動、跳躍、攻擊。 如果理解錯或者寫的不夠好,還請前輩們指正。

以 Rotorz tile system 建構關卡,並製做LightMaping

圖片
1. 於Project將FBX檔案 Generates Lightmaps UVs 勾選