re: 游戲熱更新雜談 戰魂小筑 2016-08-04 09:49
@獨孤殘云
腳本加密打包了, 其實也很難查. 特別是html本身也是代碼下載, 其實是打臉
re: 游戲熱更新雜談 戰魂小筑 2016-07-23 21:12
@egmkang
自己實現的解釋器, 穩定性和可維護性還是較差
re: 服務器開發語言比較 戰魂小筑 2016-06-15 22:28
@witch
1. 調試不能用斷點。我們使用新版的idea來開發golang程序，但斷點經常失敗。而lite好多人用不習慣。
調試不用斷點是一種基本素質, 要求代碼有一定可分析基礎, 習慣就好
2. 第三方庫偏少，但最重要的是很多都沒有tag或版本，根本不知道獲取下來的是開發版本還是穩定版本，甚至不知道api有哪些改動。有時候需要獲取一個早期版本時不得不從git的log中仔細找。
寫游戲服務器不存在用第三方庫, 我們最多用到mongodb, mysql等的第三方庫. 當時也出現過選擇問題, 但最終還是選到合適的了
3. 沒有熱更新，上線后出了問題不好處理。
這個就是和運營運維的配合, 如果服務器連停下來更新都不允許, 這個也太過了
4. 沒有泛型。
這是個問題, 后期應該會有所改善
5. 指針類型和值類型之間更偏向于值類型的設計對非C++出身的程序員還是容易犯錯。
請更多的使用指針類型
6. 切片有坑！
比起指針來說, 切片的坑算少的了
7. 語法存在一種表述多種含義的模糊性。導致第一眼看代碼時容易看不懂，必須結合上下文來仔細理解。
這是你們編寫問題吧, 我們基本上拿到任何人代碼都能馬上看得懂
re: 一個詭異的Unity3D的網絡問題 戰魂小筑 2016-05-10 11:10
@主席
建議Recv不要用Begin/End系, 否則偶爾會發不出包. iOS和PC都會出此問題
re: 服務器開發語言比較 戰魂小筑 2016-05-10 09:08
@SuperSoar
部署麻煩點, 但語言和開發環境是go的軟肋, C#太方便了
re: 服務器開發語言比較 戰魂小筑 2016-05-05 16:33
@shine
哈哈哈, 被你發現了, 因為我這邊不用Java
Java的分至少也和C#相當
@li
編譯
go get github.com/davyxu/tabtoy
go install github.com/davyxu/tabtoy
release里有編譯好的
@super_huai
真心建議別這樣, 太慢了, 轉來轉去的
@super_huai
除非你注定主做windows, 否則還是全用char+utf8吧
wchar的東西很煩的
@路人
只配置熱更新, 功能熱更新是自尋死路
這種需求多半是MMORPG
公鑰加密也是可以做的, 最后只有按照他們的方法來做, 雖然我們不是太愿意在golang里引入cgo帶openssl公鑰解密
@phantom
lua不能這么玩, 你先查下資料吧, 腳本沒指針, 無法操作內存,只有常用類型
@phantom
engine.CallVoidScript("script_MemBufferWrite",pBuff,(void*)&size,sizeof(int));
你的(void*)&size想表達什么意思? 穿大小就把size傳進去, lua不支持指針!
@phantom
調用lua用luabridge也就是一句話, 干嘛寫個scriptengine又封裝一層...
你把官方的例子照著跑一遍, 別封裝了, 速度慢不說, 經常搞出的錯誤全是自己搞的
代碼能否搞個直接可以編譯的, 給你看代碼比開源代碼都麻煩, 無法編譯
@phantom
我用的非常正常, 沒發現有什么問題
1. 沒改源碼
2. 都參考官方例子使用
碰到問題, 貼出代碼來才是王道, 人家也是測了很久才發的
發現問題就罵庫, 繞半天才發現是自己的問題
@半獸人
我有cnblogs博客. CSDN的也有, 那邊人氣更高
這個無所謂, 靠搜索引擎好了
@Arthur
很給力的建言! 贊!
P.S. 你用的Actor模型是erlang還是其他語言?
re: 大服務器架構討論 戰魂小筑 2015-08-31 09:56
@freeeyes
非常給力的評論!
re: 大服務器架構討論 戰魂小筑 2015-07-22 14:53
@QQ:79039039-8
加我的群討論吧
redis只是兩個服務器間某種邏輯的數據交換. 其實一般這種交換對數據的時效性要求不是那么及時. 鎖沒必要的
re: 大服務器架構討論 戰魂小筑 2015-07-21 10:44
@小強哥
每個區之間會有跨服邏輯, 跨服通過redis交互數據
同步操作都是服務器之間自己完成, 無需中間服務器進行同步
re: 一個詭異的Unity3D的網絡問題 戰魂小筑 2015-07-13 09:49
@Ollydbg
但總不能不用吧, 按你這么說, 確實也是這個道理, 打包出來的沒有這個問題
@小石頭
哥, 看懂了再回好吧, 那不是退出, 是接口和命名引起的誤導
re: 字符串駐留技術 戰魂小筑 2015-06-08 10:39
再申請一次呢@剛
@avi9111
那是很多年前寫的東西了, 現在看來, 由于鮑爾默是一個商人, 無法將微軟這個技術公司做的更好.
納德拉上任后的開源,就是討好開發者的一步
微軟的正版服務是耳聞的, 確實不錯
云風的能力沒必要用cocos2dx, 所以有了ejoy2d. 但cocos2dx能做到普及, 也是借cocos2d的東風.
cocos2dx在2d的地位毋容置疑, 最近3.x版本的很多問題改進的還可以. 但是從整體架構設計, 戰略規劃上就限制這個引擎的發展
package main
import (
"bufio"
"log"
"os"
)
func main() {
go func() {
log.Println("here")
}()
reader := bufio.NewReader(os.Stdin)
data, _, _ := reader.ReadLine()
log.Println("%s", string(data))
}
用調試器掛接這個例子, 是看不到here的
re: 我看過的游戲開發書籍 戰魂小筑 2015-01-30 12:14
@ljb
看了, 但沒買, 都是借的
re: lua調試的工具選擇 戰魂小筑 2014-09-29 11:13
這兩個都是基于遠程調試, 特別是luaIDE的調試性能極為慢( 我是基于官方的hello world測試的 ) @zdhsoft
re: 2013總結 戰魂小筑 2014-01-04 12:36
LZ在哪里做開發啊?
開源的，自己改也沒問題。況且這段時間用下來沒啥問題@力為
我也用過, 但是用過luabridge后, 那貨也就放箱底了@楊粼波
windows下VLD搞定， 還開源， 都不用研究了
@nncelyod
有的，但是設計理念如此，也就不必強求了
re: Lua使用protocolbuf 戰魂小筑 2013-06-25 10:37
@何茂龍
使用bytes 手動解析下, 可以對消息間互相嵌套進行降耦
原來看過你的網絡庫, 這就出書了, 支持你, 馬上下單
@Oliver
正則表達式很High哦, 本來async_read_until就已經很費了
不過對于文本協議, 這也是一個好方法
re: 網頁游戲分線到不分線 戰魂小筑 2012-11-22 15:08
希望看到更多的此類經驗處理, 感覺不錯
re: 網絡游戲不同類型的技術分類 戰魂小筑 2012-07-17 12:09
不錯, 頂起
re: AGG入門（一） - 配置開發環境 戰魂小筑 2012-07-16 09:38
@Shihira
老兄, 用一把vs2010, 你會愛上她的. 超級高效了
不像很多人用過2003后就把之后.net版本VC都否定了, 現在已經改的很好了
re: AGG入門（一） - 配置開發環境 戰魂小筑 2012-07-16 09:22
@Shihira
GCC現在兼容性很好了, VC代碼只要不是特別晦澀的模板都沒問題.
除非做硬件, 否則還是盡量升級版本
VC6怕的就是BUG...當年被折騰慘了