遊戲好友系統

最近實現了遊戲好友系統。第一次按照自己的方法實現，覺得**有些冗餘，估計是思路問題。特在此記錄，一是為了以後維護，二是向和我一樣沒有啥經驗的程式設計師提供乙個思路，更希望大家不吝賜教提供更好的設計思路。

需求：新增好友

a)根據當前玩家等級獲取10個正負20級其他玩家列表

b) 獲取的其他玩家最近一次登入時間不得大於1天

c)當其他玩家列表內玩家數量<10，則放鬆篩選條件

d)獲取其他玩家列表，推送至玩家新增好友ui

e)玩家點選申請向申請玩家傳送新增好友請求

f) 玩家可以對列表內其他玩家1鍵全部申請新增

g)被申請玩家同意後該好友新增成功，若對方拒絕不返回資訊

h)每個玩家應有1個id

i)a玩家知道b玩家id，a玩家可通過id直接向b玩家傳送新增好友請求

申請列表

a)當其他玩家申請與當前玩家成為好友時，該玩家資訊出現至申請列表

b)同意與該玩家成為好友，則該玩家移至當前玩家好友列表且申請列表內清除該玩家資訊

c)拒絕與該玩家成為好友，則申請列表內清除該玩家資訊

d)玩家可以對申請列表內玩家1鍵全部同意新增

e)玩家可以對申請列表內玩家1鍵全部拒絕新增

好友列表

a)與當前玩家已成為好友的其他玩家重新整理在此列表

b) 好友之間可以送心

c)玩家a向玩家b送心則玩家b可在好友列表內領取玩家a送的心

d)當前玩家可以向其擁有的所有好友1鍵送心

e)當前玩家可以1鍵收取其好友送的心

f)每日可領取的心數量有上限

我的設計思路:

我是按照"請求-回答"的形式設計，將使用者的操作分為請求和對請求的回答。

請求：新增好友回答：接受，拒絕

請求：好友送心回答：領取，不領取（過時心自動消失）

每種請求被設計成乙個訊息，例如：a 在某時向 b 傳送了一條申請好友的請求，這時，當伺服器收到這個協議後，封裝一封訊息，並插入到資料庫,資料庫字段如下:

表項: id , fromid , toid , msgtype , isread , srecvtime. ( msgtype:我將每個操作分類,如1就是申請好友 , isread:表示申請的物件是否對此作出了回應,無論是同意或是拒絕都會對此作出回應，即將isread 置為1，

srecvtime:伺服器收到的時間 )

例如： id 為 1 的使用者向 2傳送了申請好友請求 , 則會記錄 1 , 1 , 2 , 1 (申請) , 0(還未被確認) , 1446454554(收到訊息的時間)

這種方式下，當我需要好友列表的時候，直接搜尋u_friend 中 friendid( id , uid , friendid , ... ) 欄位便可，當需要申請列表時，搜尋u_friendmsg中"toid"為當前使用者id並且"isread"欄位為0(未處理)的記錄即可。

由於目前在使用 "skynet"(當前階段，僅限使用，慚愧) ，簡單說一下申請好友，拒絕或同意的過程:

由於操作不一定實時，因此很可能出現a申請好友，b在幾天後才看到，所以伺服器傳送給客戶端的資料中有個專門的時間字段（srecvtime）來標示記錄，也就是，這個欄位由伺服器下發，當b接受申請的時候，向伺服器傳送資料時要把這個時間標識再傳回來，我不清楚這樣做是否合適。請高手指教。

思路是這樣，**感覺還需優化，過幾天再貼，希望能對像我這樣的新手帶來幫助。待續。。。。