原创 《網絡是怎樣連接的》讀書筆記

第一章 瀏覽器生成消息 一.對url進行解析。url的格式:協議+域名+端口號+數據源(文件)的路徑名。 二.生成http消息。1.http協議定義了客戶端和服務器之間交互的額消息內容和步驟。客戶端向服務器發送請求小時。請求消息包含的內容是

原创 arpg遊戲的技能系統和buff系統的一種實現

一.技能技能可分爲主動技能和被動技能。先討論下主動技能。對於主動技能,我們首先要清楚以下這些東西。1.技能釋放的流程:1.1發出施放請求。1.2驗證是否滿足使用技能條件。1.3返回失敗結果或者選擇目標。1.4對目標開始執行技能同時開始動作、

原创 關於手機遊戲客戶端中mvc框架的討論

這裏的mvc特指手遊中的mvc。本文將從以下方面討論手遊客戶端中mvc:分工,事件機制,依賴關係,實現細節,例子。一 、分工這裏的mvc,m代表model(數據模型),v代表view(界面),c代表control(控制業務邏輯)。除此之外,

原创 Laya學習筆記

 1.光照貼圖是場景中3D模型產生的投影、陰影過渡、燈光氛圍、模型材質與材質之間的顏色影響等。 2.很少有3D手遊場景是靠燈光與模型即時渲染產生投影及顏色影響,這是非常耗性能的方式,特別又是手機手遊,手機的顯卡功能並不強大,全部用即時光影手

原创 設計模式-行爲型

一. 責任鏈模式 這種模式中,有發送者和接收者。通常,每個接收者都包含對另一個接收者的引用,形成一條鏈,如果一個接收者不能處理該請求,那麼它會把相同的請求傳給下一個接收者,依次類推。 這種模式將請求的發送者和接收者解耦,但是不能保證請求一

原创 設計模式-結構型

一. 適配器模式 配器模式(Adapter Pattern)是作爲兩個不兼容的接口之間的橋樑。這種類型的設計模式屬於結構型模式,它結合了兩個獨立接口的功能。這個模式將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由於接口不兼

原创 設計模式-創建型

一、 工廠模式:1.1爲什麼要用工廠模式 a. 解耦 :把對象的創建和使用的過程分開。 b. 降低代碼重複: 如果創建某個對象的過程都很複雜,需要一定的代碼量,而且很多地方都要用到,那麼就會有很多的重複代碼。 c. 降低維護成本 :由於創

原创 ARPG遊戲的技能系統和buff系統的一種實現

《龍與地下城》是由TSR開發的一款桌上角色扮演遊戲,於1974年發行第一版。該款遊戲對角色扮演遊戲也有很大的影響,後來的許多相同類型的遊戲都受到了它的影響。簡單看了一遍該遊戲的玩家手冊,再對比某個遊戲的技能系統,和玩家手冊描述的很相像。 這

原创 RPG遊戲中Bresenham算法推導以及應用

Bresenham算法是一開始用於圖形學中繪製直線。無論屏幕的分辨率多麼的大,它始終都是由一個個的方形像素點組成的。在屏幕上繪製一條有角度的直線時,像素點並不會都落在直線上。對於直線上的點,需要一種算法算出最接近直線上的點或者說最適合的點。

原创 python學習筆記

python是一種解釋型、面向對象、動態數據類型的高級程序設計語言。學習 Python 與其他語言最大的區別就是,Python 的代碼塊不使用大括號 {} 來控制類,函數以及其他邏輯判斷。python 最具特色的就是用縮進來寫模塊。pyth

原创 面向對象6大原則之里氏替換原則

         這是我之前對於面向對象6大原則的學習筆記,其中對里氏替換原則的理解不夠深刻,https://blog.51cto.com/zhangzhao/2396810。         根據百度百科的資料,里氏替換原則的定義爲:Li

原创 程序員的修養--讀書筆記

第一章 溫故而知新 -- cpu、內存、顯示設備、io設備早期都鏈接在一個總線上。後來出現了北橋芯片使得cpu,內存和高速的圖形設備能夠高速的交換數據。南橋芯片處理低速設備,比如磁盤,usb,鍵盤,鼠標等設備。--名言 計算機科學領域的任何

原创 js的__proto__、constructor和prototype屬性

__proto__和constructor屬性是對象所獨有的;prototype屬性是函數所獨有的。但是由於JS中函數也是一種對象,所以函數也擁有__proto__和constructor屬性。 先來看下面這段代碼:function foo

原创 js中的bind、call、apply

1.作用:call、apply和bind是Function對象自帶的三個方法,都是爲了改變函數體內部 this 的指向,區別是call()和apply()在調用函數之後會立即執行,而bind()方法調用並改變函數運行時上下文後,返回一個新的

原创 面向對象6大原則

1.單一原則。一個類應該有且只有一個變化的原因。單一職責原則將不同的職責分離到單獨的類,每一個職責都是一個變化的中心。需求變化時,將通過更改職責相關的類來體現。如果一個類擁有多於一個的職責,則多個職責耦合在一起,會有多於一個原因來導致這個類