2009-01-15 88 views
0

我必須爲Java大學任務編寫一個Java多人pacman遊戲,而且我已經對我的設計進行了一些反饋。吃豆子游戲課程設計

所以我想下去了MVC的風格和this is what I've sketched out

我從來沒有設計過任何使用MVC的東西,所以我的知識實際上只來自實用的程序員和一個簡短的講座,所以很可能我會誤解或誤解它。

而且,大部分的教程我已經看到了設計簡單的遊戲,不要提MVC在所有所以這是地方MVC是不使用的良好格局的情況下?

我的想法到目前爲止,遊戲邦類將成爲數據存儲的主要來源,並且會使用2d數組來存儲遊戲的狀態,鬼在哪裏,pacman是等

遊戲類將是主控制器類,將包含主遊戲循環和控制所有的數據之間的相互作用(遊戲狀態)和視圖(可能是一個GUI表示 - 我只是添加了基於文本的文本)。

我有工作,我不得不出來拆分爲客戶端/服務器之後的比賽。在我看來,通過使用這種模式,將大部分數據和處理保留在服務器上並讓客戶端與控制器進行交互並繪製自己的視圖並不難。我還不知道這是如何影響遊戲在網絡上的表現,所以一旦單人遊戲版本完成,我就不得不進一步研究。

任何提示或建議的基礎上,我的設計到目前爲止,將不勝感激 - 還銘記它最終必須是一個多人遊戲。

乾杯,

亞當

+0

企業防火牆背後的很多人將無法關注您的鏈接。你能發佈一個鏈接到實際的網址嗎? – 2009-01-15 15:37:13

+0

鏈接不起作用。 – bzlm 2009-10-11 15:26:34

回答

2

相反:MVC實際上是在支持它使用這種類型的問題,Swing的框架做了非常好的工作是非常好的事情。

你或許應該先對MVC讀了。就像概述一樣,你將試圖分離遊戲在內部(模型)的表現方式,它如何繪製(視圖)以及如何改變狀態(控制器)。

首先想想你需要的一切來建模遊戲的當前狀態。有一個實體定義了一些基本的行爲,並像你一樣爲PacMan和Ghost進行子類化,這可能是一個很好的開始方式,但你可能想要將你的Map調用一個GameBoard或類似的東西(給出與圖書館同名的東西類通常是一個壞主意:你不想把它與java.util.Map混淆)。爲了結束模型部分,您可能想要將它們全部包裝在一個「知道」整個遊戲狀態的課程中。既然這是你的GameState類,你可能想要重繪你的箭頭。

由於確定視圖可能相當容易,您可以去那裏。你可以給你的GameState一個draw(Graphics)方法,並從你的視圖中調用它(你將在後面決定)。這可能會依次委託執行每個實體,而實體又可能將其委派給它們擁有的Sprite或Image對象。現在,您的視圖可能是JPanel或類似的,可以使用其paintComponent()方法內自己的Graphics對象調用draw()。

現在你仍然需要一個控制器來實際發生。這可能是一個KeyListener掛鉤到視圖中的對象,以及一個InputStream和一個OutputStream來處理與其他玩家的通信(它可能也需要是擔心同步遊戲狀態的人)。它還需要有一個定時器,以便它可以告訴設備定期更新。您需要決定是否決定這些舉動是否合法:控制器可以這樣做,GameState可以,或者它可以給實體提供他們需要的信息,讓他們自己做。

一旦你擁有了所有這些部分,你可以將它們包裝在一個知道所有事情的最後一個類中,並完成所有設置等。我還有更多的事情要做,還有幾個你必須做出的決定,但它應該讓你走。

1

我完全同意詹姆斯的觀點,並且想補充一點,你可能還想確保你的遊戲狀態的這個二維數組可以處理一些邊緣情況,比如佔據瓦片,pacman和鬼魂的多個鬼魂相同的瓷磚(取決於你如何在你的代碼中處理它),pacman的食物點等。

良好的規劃往往不是最好的方案,我很高興看到你已經開始了一個圖。