In-App Purchasing是Unity提供的跨平台IAP服務
本篇將介紹如何使用In-App Purchasing設定到Google Play Developer Console的商品
本篇教學軟體環境如下:
2020年10月4日 星期日
2017年10月8日 星期日
[Unity]Resources.Load效能測試
儘管官方自己都說不建議使用Resources資料夾, 但是在能取代其便利性的資源載入方案出現前, Resources資料夾仍是我們有快速開發需求時的好朋友
我們使用Resources資料夾內資源, 常用步驟為:
我們使用Resources資料夾內資源, 常用步驟為:
2017年9月9日 星期六
[Unity]物件 顯示/隱藏 之簡易效能評比
我們要在Unity控制物件於畫面中的顯示/隱藏時, 主要方法有:
- 使用GameObject.SetActive直接開關整個GameObject
- 開關GameObject上的Render
- 將GameObject移進/移出畫面
2017年6月4日 星期日
[Unity]Remote Settings 簡介與實作
這篇的Remote Settings不是那個裝置與Unity Editor連線測試的Unity Remote呦, 他是 Unity Analytics Service 底下的一個功能😄
Remote Settings提供開發者一個方便更新數值的管道, 可以不必跟新輸出檔、不必自己架server, 即可實現遊戲數值的熱跟新, 而且目前是免費的
2017年4月27日 星期四
[Unity]AssetBundleManager & AssetBundleGraphTool 之整合使用
AssetBundle Manager是官方提供的bundle管理器, 能夠方便的讀取, 以及模擬測試bundle, 可從Asset Store免費下載(https://www.assetstore.unity3d.com/en/#!/content/45836)
AssetBundleGraphTool 則是Unity日本開發的圖形化打包工具, 能夠很輕鬆的設計自動化打包流程, 也是開源免費(https://bitbucket.org/Unity-Technologies/assetbundlegraphtool)
AssetBundle Manager有附帶快速打包的工具, 但我們必須為要打包的物件設定包名(甚至variants)
2014年8月28日 星期四
[Unity][C#]2 simple ways of load the data form XML // 兩種簡便讀取XML資料的方法
假如今天要讀取路徑為Resources/test.xml 的XML, 內容如下:
For example, the XML data we want read as below, the path is "Resources/test.xml":
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ROOT>
<table wave="1" level="1" name="aaa"/>
<table wave="2" level="1" name="bbb"/>
</ROOT>
我們有兩種簡便讀取的方法:
We have 2 simple ways can use:
For example, the XML data we want read as below, the path is "Resources/test.xml":
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ROOT>
<table wave="1" level="1" name="aaa"/>
<table wave="2" level="1" name="bbb"/>
</ROOT>
我們有兩種簡便讀取的方法:
We have 2 simple ways can use:
2014年4月4日 星期五
[CleanCode]Adjust your if-else//整頓你的if-else
判斷流程複雜時, 我們會需要很多層if-else在程式裡, 最後很容易變成如下又肥又醜的模樣:
We need many if-else struct when the flow is complicated, then the struct of program will become big and ugly, as below:
真是讓人看得眼花撩亂, 不是嗎?
These make us dazzle, isn't it?
其實我們可以換種寫法:
Actually, we can change a way:
程式運作的邏輯一樣, 但看起來是不是好讀多了呢?
The logic program operating is same, but it become much good to read.
這種技巧是把做完可以直接return的判斷式獨立出來; 利用"return後下方的程式碼不會執行"的特性, 使程式的結構脫離if-else必須一層包一層的窘境
This way is separating the statement which process return when operating done; the code struct can be breaking away the dilemma of if-else layer packet layer, by using the feature of "program will not execute the codes after return".
如此, 我們可以在看多層判斷式時不必再辛苦的對照程式碼在哪一層判斷式 , 大大增加了程式的可讀性
So we don't need to look for codes in the multi-layer predicate, it increases the program's readability.
We need many if-else struct when the flow is complicated, then the struct of program will become big and ugly, as below:
if(A)
{
do A-1...
if(B)
{
do B-1...
if(C)
{
do C-1...
}else{
do C-2...
return...
}
}else{
do B-2...
return...
}
}else{
do A-2...
return...
}
真是讓人看得眼花撩亂, 不是嗎?
These make us dazzle, isn't it?
其實我們可以換種寫法:
Actually, we can change a way:
if(!A)
{
do A-2...
return...
}
do A-1...
if(!B)
{
do B-2...
return....
}
do B-1...
if(!C)
{
do C-2...
return...
}
do C-1...
程式運作的邏輯一樣, 但看起來是不是好讀多了呢?
The logic program operating is same, but it become much good to read.
這種技巧是把做完可以直接return的判斷式獨立出來; 利用"return後下方的程式碼不會執行"的特性, 使程式的結構脫離if-else必須一層包一層的窘境
This way is separating the statement which process return when operating done; the code struct can be breaking away the dilemma of if-else layer packet layer, by using the feature of "program will not execute the codes after return".
如此, 我們可以在看多層判斷式時不必再辛苦的對照程式碼在哪一層判斷式 , 大大增加了程式的可讀性
So we don't need to look for codes in the multi-layer predicate, it increases the program's readability.
=======================
希望這對你有幫助，歡迎提供建議
Hope this help you, welcome to advice me.
訂閱：
文章 (Atom)