初步認識MUD
從今天起，我們就要正式踏入用Python制作Mud的大門了！
😉在那之前，讓我們先來簡單的認識一下MUD 所謂Mud，是「Multi-User Dungeon」 多使用者迷宮 的縮寫，不知道你玩沒玩過「放置江湖」一類的文字游戲，這種游戲就被稱為“Mud”
傳統的Mud游戲是這么運作的：
客戶端 發送 指令-->服務端 接收 指令-->服務端 運行 指令-->向客戶端 返回 結果
用人(梗)話說就是：接！化！發！🤔(bushi)
如何做到接發指令？
這個時候，我們就要請出我們的Socket 套接字 了！（如果還不知道什么是套接字的同學可以看這個，轉載自簡書yongfutian）
客戶端
客戶端非常簡單，就直接一個 While True + 發送數據 + 接收數據 +顯示 扔上去就完事兒了，極其沒有技術含量😶（似乎也不算太簡單來着....?)
服務端
服務端的制作才是我們的重點 ~服務器要做的很多很多：
接收數據，執行對應函數，存儲武器、小怪、裝備數據等等，非常滴復雜。
「字典+列表=神器」
這里我要提一個在儲存物品數據時及其好用的玩意兒：字典+列表！。
哇這個東西在儲存單一對應性強的數據時簡直是神器，看一下以下案例：把裝備錄入對應信息
可以看到，字典+列表組合在儲存固定數據時非常強大，而且字典的*.keys()等方法對后期制作背包使用非常有好處滴😉
如果各種東西都用字典配置地非常全面，后面新功能基本上都是讀取字典后執行再修改就完事兒了，可以看看下面示例：
“適配性”
適配性是我自己喜歡的稱呼，正式名稱俺也不知道qwq
在開發前期 一！定！要！做好適配，不然后面直接牽一發而動全身，會使工作量指數級上升，舉個例子：
看起來肥腸簡單對不對？但是怪物和掉落物數量可 遠遠不止三個，這樣看似簡單的代碼只會使程序臃腫，后期維護難度加大，也就是剛才所說的牽一發而動全身
讓我們再來看看更改后的：
這種結構直接將怪物與其掉落物相聯系，從根本上簡化了代碼，且拓展性變強，再多的怪物&掉落物也只需要一句“monster_item[choice][1] += 1”