• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            云海航行Q+偉的幻想鄉

            熱愛探索未知事物的coder 、 writer 、watcher and thinker
            posts - 16, comments - 6, trackbacks - 0, articles - 0

            2012年12月11日

            http://www.qiujiawei.cn/blog/2012/12/08/dongfang-1/

            posted @ 2012-12-11 13:05 Q+偉 閱讀(270) | 評論 (0)編輯 收藏

            http://www.qiujiawei.cn/blog/2012/12/06/mc-1/

            posted @ 2012-12-11 13:05 Q+偉 閱讀(261) | 評論 (0)編輯 收藏

            http://www.qiujiawei.cn/blog/2012/11/23/gdc-1/

            posted @ 2012-12-11 13:04 Q+偉 閱讀(204) | 評論 (0)編輯 收藏

            http://www.qiujiawei.cn/blog/2012/11/06/gea-1/

            posted @ 2012-12-11 13:04 Q+偉 閱讀(241) | 評論 (0)編輯 收藏

            http://www.qiujiawei.cn/blog/2012/11/06/gea-2/

            posted @ 2012-12-11 13:03 Q+偉 閱讀(240) | 評論 (0)編輯 收藏

            2012年10月21日

            http://voyagingmk.github.com/blog/2012/10/20/work-employex/ 

            posted @ 2012-10-21 17:30 Q+偉 閱讀(214) | 評論 (0)編輯 收藏

            voyagingmk.github.com

            posted @ 2012-10-21 16:47 Q+偉 閱讀(232) | 評論 (0)編輯 收藏

            2012年9月19日


                  這兩年對我而言,除去一個男子大學生的日常生活(逃課?打游戲?把妹?),最大的事就是遇到一些人并且一起搞了個獨立游戲工作室,而后風風火火地做起了單機游戲,完全是跟隨己心。因為伙伴表現出來的熱情,使我開始燃起了游戲人之魂,心里多了一個方向:制作出具有時代影響力的游戲,給予玩家純粹的快樂與感動。
                  其實這個方向大一的時候就考慮過了的,但這才是夢想行動的開端。
                  借助個人的興趣和毅力和對未來的盼望,還有各位伙伴的努力,工作室先后制作出了《東方千⑨譚》,《繽紛樂豆》,《C盤保衛戰》(嚴格來說不算工作室出品,但開發的主力確實是工作室的三個元老)。雖然這幾個作品都沒能對游戲行業造成任何沖擊,但是這是我的這兩年時間,唯一值得拿出來顯擺的成就??梢哉f,我這兩年心思都耗在這里了,其他領域沒多少作為。
                  很可惜的是,今天我告訴你我們工作室散伙了。
                  這個結果的產生,不是因為外力或者特別因素(父母反對/沒錢沒資源/成員失蹤了),反而是我們幾個元老一手造就的。
                  但相信我,這一路走來直到崩盤的前一刻,我們都很用心地在往游戲制作這個方向努力著,甚至還有除了游戲開發之外的事情,創業方法學、團隊管理等。
                  要說這個解散最大的原因,就是因為我們太較真了,我呢不斷地跟自己說,“真要創業,真要成為云海航行的技術總監,你現在的實力遠遠不夠!”,然后就不斷地自我進?。晃覀兊膌eader差不多也是,也是給了自己壓力。曾經我們一起去找過一位創業多年的前輩,了解了一堆什么營業額啊、創業證啊等亂七八糟的東西,那個時候才知道創業多么復雜。
                  正是因為我們很努力地去研究游戲,才明白自己的實力所處的層次。
                  正因為我們越去做一些從沒做過的事,才越知道自己真正想要的是什么。
            ----------------
                  老大今年8月份有一天找我聊了一個早上,跟我說了他的很多感受和一些他自己的情況,然后就跟我說,他想解散這個團隊。當他說出這個決定的時候,前面的鋪墊陳詞我都給忘光了,腦海里只剩下一個問號:
               難道就這樣結束了?
                  此后我花了一個月時間來思考很多東西,我們這個團隊、團隊里的每一個人、游戲行業現狀、如何拯救這個團隊、自己的路等,才發現其實我們這個團隊,盡管各個人都很有才華實力都不錯,但其實算不上很同心,有價值觀的問題也有性格不相容的問題。
                  元老里有兩個超級日系控,我呢屬于包容萬貫,會喜歡日本的動漫游戲,但也喜歡歐美的東西,所以我通常對某兩人經常討論某某CV最近擔任什么角色某部動漫怎么樣的深度宅聊,挺反感,3個人走一起都插不進嘴的,后來我就干脆發展到無事不登三寶殿了。這只能算是性格合不太來,沒有誰對誰錯。
                  另外,雖然大家似乎都是認同團隊的核心理念,“帶給玩家更純粹的快樂、感動和盼望”,但在實際的做法上,都有點互不認同。我們一個師弟一直跟我提說,”我對做那啥同人游戲一點都沒興趣”。還好后來團隊不叫同人游戲社團了,變成獨立游戲工作室了,要完全自主設計開發游戲,這樣子大家都同意了。但后來,開始做游戲策劃的時候,又發生分歧,故事設定被說是中二了,這事貌似搞得很別扭,后來一直談不妥,我作為做程序的,懂得也不多,只能看著著急。
                  挺多煩惱的,各種不容易。
                  真要把團隊做到和‘頑皮狗’一樣的扁平結構,不做框框條條,而又良性發展,太不可思議了。
            所以,團隊既然成了這個鳥樣,確實也該整改或者解散了。
            ---------------
                  直到前兩天晚上,我們終于開了一個小會,到場人數不齊,但相談甚歡。老大一來就提了一串問題,“什么是理想?“,”理想化的理想是不是理想“,圍繞這個問題就爭執了一個鐘:
            首先是兩個詞的定義,”理想“和”理想化“。
            假如有一個學生,他每月有1500的零花,然后他說他的理想是買一架250塊的單車,算不算理想?
            假如有一個運動員四肢健全,他說他想成為劉翔,這是理想吧,但是有一天他瘸了,這個理想還是理想嗎?是變成了夢想還是妄想?
                  什么叫理想化?理想化是一個動詞還是形容詞?
                  我的理解是,理想是不能脫離實際的,而且要從當事人出發,考慮實現目標的難易程度;而理想化,可以舉一個例子來解釋,高中物理就會有很多理想化假設,如假設物體間沒有任何摩擦、假設不考慮空氣阻力??梢娎硐牖@個動詞的意思大概就是,忽略妨礙了目標實現的一些因素;理想化應該是一個動詞= =。
                  理想化和理想都搞清楚之后,考慮一個問題,為什么我們小時候我們家長總說,”娃兒啊,你要有理想啊,要光宗耀祖啊“,鄧小平呢說,”希望全國的小朋友,立志做有理想、有道德、有知識、有紀律的人,立志為人民作貢獻,為祖國作貢獻,為人類作貢獻“。
                  然而,當我們大學生了,我們跟父母、跟親人、跟朋友說,”我想讀研讀博當一名科學家“,”我想創業我想成為李開復“,“我想做游戲,成為宮本茂一樣的游戲制作人”,然后他們有一些人會說,“你太理想化了!“。
            這樣子,他們是希望我們不要理想化地去追逐自己的理想?(這里似乎有些陷阱)
            我的最終理解是:
                  理想是一個具體的目標,當一個人在考慮這個目標的實現所涉及到的因素、且認為其中的負面因素遠遠大過正面因素的時候,會判定想完成這個理想的人是理想化了。(注意,下這個判斷的人通常不會考慮那個有理想的人的決心,這個關鍵因素)??陀^來說,一個目標的實現確實有很多因素,而一個人,作為人類,只能考慮到其中的一些方面,所以所謂的理想化并不是客觀的判斷,而是主觀的。而具備理想的那個人其實并不該期許,別人告訴他他的理想可不可行,畢竟兩個具有不同生活經歷的人考慮事情的全面性是不一樣的。
                  再換個角度討論,根據當前物理學,物理規則是確定的,一個物體的下一個狀態是可以從當前狀態推算出來的,理論上。可以判斷,世界的未來是已經確定的,并不存在什么改變未來的事。所謂上帝不擲骰子。
            但很神奇的是,似乎人類確實擁有改變自己命運的權力,勵志的故事也看過不少了,看起來那些成功的人確實是按照自己的想法努力去做,從而獲得成功的。
            這是個有意思的問題,我之前有一篇博文也討論過。
                  唯物地來說,我們的理想是不是可以實現的,已經在物理規則下保證是確定了的,是或不是。而我們現在對理想的實現的可能性的討論,就是因為我們并不能全知全能,只能根據我們有限的認識,去做推論或者是猜測。任何人跟你說,你做事太理想化了,你都可以反駁他,”我們都不是上帝,只有上帝才知道我是不是理想化了"。
            但是,也因此說明,我們唯一能做的,就是盡量考慮到實現目標的所有關聯因素,并且不斷地給自己增加成功的籌碼、提升正面因素的比例。另外,還有一件反而成了唯心的東西是必須重視的,那就是信念,實現理想的信念遠比大部分的因素都關鍵。
                  除此之外,你跟對你的目標的實現毫無關系的人,闡述你的見解、解釋你為什么要這么去做、解釋你為何這么有信心,那都是在浪費口舌。
                  而我確定,那晚坐在那里的幾個人,包括我,都是有理想的。
                  而其中有一個人,他的信念是非常強的。
                  好了,回到我們工作室的最后一次會議上。在我們都覺得討論得很累的時候,boss終于說了,
            他說,
               "我鄭重宣布,
               云海航行從今天開始正式解散。
               不做解釋。“
            --------------

                  對各位支持著我們的兄弟朋友們說聲抱歉了,我們是虎頭蛇尾了。還有進過我們工作室的每一個人,希望能冷靜接受這個決定??赡墁F在我們難以接受,但總有一天會互相理解的。
                  大家也別替我們難過,其實,至始至終,我們每個人對游戲的心都是狂熱的,我們的關系沒有破裂,我們仍然經常一起打游戲聊游戲,以后呢,我確定,我們都會在游戲行業里發光發熱。
                  說不定,今日團隊的解散,正是多年后云海航行王者歸來的一個伏筆。


            posted @ 2012-09-19 20:24 Q+偉 閱讀(276) | 評論 (0)編輯 收藏

            2012年9月6日

            本文主題主要是跟unity3D的一個擴展插件NGUI相關,在我這個版本的NGUI中的一個example:
            Example 7 - Scroll View (Panel)
            演示了如何實現一個可以拖動的panel。步驟就是,在一個普通panel對象添加一個IDraggablePanel組件,進行一些設置后,再在該panel節點下添加一些content,如UISprite,UILabel(可以加多一層UIGrid來自動對齊),這些content對象必須賦予一個組件UIDragPanelContents,和box Collider, 前者是NGUI可拖動面板相關的必要組件,添加即可,不需要設置;后者是用來觸發事件的,如果不添加collider,按住這個content(可能是一張圖片)會無法進行整個Panel的移動,而我們需要的是,再Panel的裁剪范圍里的可見對象,按住它后可以移動整個面板(非常常見的一種功能吧)。

            以上功能的實現還是比較容易的,稍微熟悉NGUI的人都可以按這個步驟做出來。但是會出現一個問題,當一個content移出panel裁剪邊界后,它仍然處于可響應狀態,盡管它已經被裁減、已經隱形了。原因就是,這個content的box collider仍然是active的。雖然看不到該對象,但組件是激活狀態的。

             
            (綠色框就是box collider,那些出界了的、隱形了的方塊仍然是可以被點到的)
            NGUI的這個example對此的解決方案是,在這個panel的軸向上的兩個端點處,加了兩個空的gameobject,并添加box collider,來遮擋本來出界了的content。
             
            (2把1給擋住了= =)
            這真是尼瑪的坑爹?。。。?!

            難道要每實現一個draggable panel都要在兩端加這么一個玩意?而且這兩個box collider可能會擋到其他控件。實在是不可取。 
            不考慮NGUI這個坑爹的方法,第一種解決方案是:
            panel里的content出界后,disable掉它的box collider。這個方案也有問題,因為有可能一個content面積巨大,盡管它的一大片面積已經移出邊界了,但是還有相當一部分面積還在panel里面。這時候我們需要的效果是,按住剩余的可見的那部分,還是可以拖動整個面板的,同時那部分出界的透明的,不可以觸發拖動效果。
            進一步考慮是,讓box collider可以自適應,當content它的一部分出界后,box collider變形,只跟content的可見部分匹配。
            這個也許可以實現,但要做很多編碼工作,而且可能會影響性能。
            博主稍微研究了下draggable panel的相關源代碼后,還是覺得這個自適應的擴展腳本很不好編寫。

            第二種方案:
            苦逼了一段時間后,發現其實可以不需要這種所謂自適應的box collider,可以換一種方法實現這種拖動panel功能:
            1.保留panel里的各個子對象的UIDrag Panel Contents組件,刪除它的box collider組件。 
            2.在draggable panel同層次創建一個空的gameobject,給它增加一個box collider,大小和位置,和draggable panel 的大小和位置對應(就是說,這個game object就是該panel的觸發框了)
            3.關鍵!在該gameobject添加一個組件:NGUI里的UIForward Events

            設置target為目標draggable panel里的任意一個content對象,事件為onPress onDrag

            這樣,這個新的外部box collider會接收到點擊事件,并調用target的回調函數去處理該事件。出來的效果就是,只要在這個新的box collider內的拖曳事件都會正常地觸發。
            but,這樣還是有問題,就是說當這個panel的各個content對象是可以被點擊,觸發某類事件的時候(比如是一堆Button),就點不到啦。
            所以這個解決方案只能解決content是普通靜態對象的時候。比如content是一個或多個UILabel,用來展示一些游戲信息。

            第三種方案:
            這個方案是應付上文說的content是可點選對象的情況的。為了保留各個content的box collider組件,可以采取分頁的方式,即這個draggable panel是分頁的,當你拖曳結束的時候,panel會自動適配到某一頁,而不會說停留在頁與頁的中間。這樣,只要當觸屏事件結束的時候,判斷出當前所屬的是哪一頁,然后把除了該頁面外的所有content對象的box collider控件都disable掉,而當前頁的就enable, 這樣就行了。
            另外樓主也擴展了NGUI,實現了一個分頁腳本,只需要拖到panel對象就可以自動應用上滑頁效果了。不過等把這三種方案實現了,再開源出來。
            ————————————————
            目前博主就做到這個程度,這第二個方案確實解決了一部分問題,目前還是夠用的。
            等以后發現完美解決方案的時候再更新。

            posted @ 2012-09-06 12:54 Q+偉 閱讀(3810) | 評論 (0)編輯 收藏

            2012年7月24日

            這兩周在開發的彈幕引擎遇到了一些性能問題:
            1.同一時刻創建大量子彈會造成卡屏,跑起來就是一頓一頓的,原因是new一個對象很耗CPU。
            2.draw call 和 batch 的問題。

            第一個問題可以使用OT自帶的對象池功能解決:
            1)初始化對象池 PreFabricate(string objectPrototype, int numberOfInstances) 
            objectPrototype 對象必須放在OT prefab的子對象Prototypes下。
            2)要銷毀對象時,必須調用  OT.DestroyObject(xxx),不然對象無法回收到pool中。
            3)當要創建新的對象時調用OT.CreateObject(objectPrototype ) ,剛好對象池里有可以使用的閑置對象時,OT就會自動服用該對象。但是要注意一個問題,被復用的對象已經被初始化過一次并運行過了,可能有一些參數必須重置,這個操作OT不可能幫你完成,因為OT不知道哪些參數需要重置。但OT在 CreateObject 方法內有一行代碼:
            g.SendMessage("StartUp",null,SendMessageOptions.DontRequireReceiver);
            意味著OT在給你一個對象之前,讓這個對象執行了這個StartUp函數,所以可以在對象的各個component里重寫這個函數,必做必要的重置操作。
            除了使用OT自帶的對象池,還可以使用另外一個插件:PoolManager2,不過這個插件蠻貴的也不提供使用版,有米的就入手一個試試吧。

            第二個問題是關于對象材質的問題。
            我在一個彈幕demo中想讓N個彈幕tween到一個顏色,通過改變OTSprite的tintcolor,結果發現幀率掉得很厲害:
            1)彈幕剛生成的時候,Draw Calls只有3次,全部子彈都被batch到一起。

            2)第二個操作是改變各個彈幕OTAnimatingSprite的幀圖片,發現幀率等沒有變化,性能瓶頸不是在切換動畫幀上。

            3)開始隨機tween每一個子彈的tintcolor,發現DrawCall暴增,batched數剩0,幀率掉出翔來了。。


            很顯然,改變tintcolor會導致不能batch,每一個彈幕自己跑了一次渲染管線,超低效。
            下一個操作是把所有子彈tween回同一個顏色,發現參數都恢復了,包括幀率。所以這個tintcolor的改變應該不是給每一個子彈生成了新的材質(Copy On Write寫復制這種機制),只是同一次shader不能有不同的外部參數。
            這個恢復機制反應出Unity和OT還是很智能的。
            這個問題好像沒有什么解決方法,最好的辦法就是不要像我這樣子搞=。=
            做移動平臺游戲,性能相當重要,這種華麗的效果還是放棄吧。

            雖然做了對象池優化,但是幀率還是蠻低,以后加上游戲邏輯、碰撞檢測、游戲場景、特效、GUI后,幀率又會降低,
            所以性能革命這路子還長呀。

            posted @ 2012-07-24 17:06 Q+偉 閱讀(3887) | 評論 (1)編輯 收藏

            日韩久久久久久中文人妻| 国产亚洲精品久久久久秋霞 | 日韩人妻无码精品久久久不卡| 久久久亚洲欧洲日产国码是AV| 精品久久久噜噜噜久久久| 国产成人久久777777| 久久精品国产亚洲AV不卡| 国产91色综合久久免费| 无码人妻久久一区二区三区蜜桃| 一本久久a久久精品vr综合| 亚洲精品高清久久| 无码人妻精品一区二区三区久久| 久久青青草原综合伊人| 无码国内精品久久综合88 | 久久成人精品| 色8久久人人97超碰香蕉987| 久久99亚洲综合精品首页| 久久久久久亚洲精品成人| 久久精品成人欧美大片| 久久A级毛片免费观看| 久久午夜夜伦鲁鲁片免费无码影视 | 成人精品一区二区久久| 久久精品国产亚洲AV蜜臀色欲| 国产精品久久久久久久久久免费| 久久综合香蕉国产蜜臀AV| 91麻豆国产精品91久久久| 色诱久久av| 久久久久女教师免费一区| 99久久免费国产精品| 香蕉久久一区二区不卡无毒影院| 热re99久久精品国99热| 亚洲愉拍99热成人精品热久久| 精品国产青草久久久久福利| 少妇被又大又粗又爽毛片久久黑人 | 国产精品无码久久四虎| 久久精品国产免费| 国产精品久久久久9999高清| 99精品国产在热久久无毒不卡| 久久天天躁狠狠躁夜夜avapp| 日本强好片久久久久久AAA| 无码人妻精品一区二区三区久久|