“遊戲結束了，要幹點什麼呢？當然就是棋盤複位了，按鈕重置了，如果還有棋譜之類的，全都得重置。這些，我們留下到另一節優化處理吧。”
是以，本節就做這些手尾工作了。
我們本節又要用到了：我們需要統籌全局的Index來做這件事：
我們在EventButton.xaml.cs裡，那裡有遊戲結束通知：
我們添加一個代理，兩行代碼，這裡我們多了個參數，傳遞Player：
public partial class EventButton : UserControl
{
public delegate void HelpSetGameEnd(Player player);
public event HelpSetGameEnd HelpSetGameEndEvent;
public EventButton()
{
//...省略N行...
}
//...省略N行...
}
有了代理了，遊戲結束時，隻管調就是了：
void client_NotifyEndGameReceived(object sender, GameService.NotifyEndGameReceivedEventArgs e)
//接收遊戲結束消息
switch (e.player.AttachInfo)
{
//...省略N行...
}
case "0"://使用者主動認輸，遊戲結束
case "1"://将軍被吃，遊戲結束
case "2"://雙方同意平手,遊戲結束
HelpSetGameEndEvent(e.player);
break;
咦！怎麼兩個switch，是不是寫錯了還是寫多了？不是了，這裡多加的switch，隻是把遊戲結束的标志都抽出來，單獨的執行一下遊戲結束重置而已。
好了，這裡的事情況就做完了，然後該Index出手了。
public partial class Index : UserControl
//...省略N行...
EventButton eventButtonControl;
public Index()
eventButtonControl = new EventButton();
eventButtonBoard.Child = eventButtonControl;
//下面為委托事件 ...省略1行...
eventButtonControl.HelpSetGameEndEvent += new EventButton.HelpSetGameEnd(eventButtonControl_HelpSetGameEndEvent);
void eventButtonControl_HelpSetGameEndEvent(GameService.Player player)
//這裡實作遊戲結束後所有的複位
}
好了，接下來，我們要為一些控件做一些“重置”工作：
我們先為Chess象棋類增加一個Reset方法，用于把所有象棋相關參數重置為初始狀态：
/// <summary>
/// 象棋 by 路過秋天
/// http://cyq1162.cnblogs.com
/// </summary>
public class Chess
//...省略N多行...
public void Reset()
container.Children.Clear();//棋盤和棋子一并清掉了
InitBoard();//隻好重新初始棋盤了
InitChessman();//隻好重新初始棋子了
IsCanMove = false;//設定狀态不能移動了
IsGaming = false;//這個差點忘了
}
//...省略N多行...
OK，有了這個方法，我們的Index就首先可以添加一行了：
void eventButtonControl_HelpSetGameEndEvent(GameService.Player player)
App.chess.Reset();
接着要複位事件區的按鈕，先為事件區控件添加一個Reset方法[以後的控件基本上都添加一個]：
public partial class EventButton : UserControl
//...省略2行...
//...省略N行...
btnGameDeuce.IsEnabled = false;
btnGameLose.IsEnabled = false;
btnGameStart.IsEnabled = false;
//...省略N行...
}
OK，我們可以實作總複位方法了：
eventButtonControl.Reset();
if (App.player.ColorValue == player.ColorValue)
eventButtonControl.btnGameStart.IsEnabled = true;
最後一個，總得有一個人的“開始按鈕”得激活的吧，不然怎麼重新開始遊戲呢？
OK，現在如果回頭看看上面的結束标志，那個：
case "1"://将軍被吃，遊戲結束
這個怎麼産生的？哪産生的呢？其實很容易了，回到棋子“GoToDead"的地方，我們添加N行語句判斷一下：
if (Name == "将" || Name == "帥")
{
//發送遊戲結束到伺服器
}
可是，棋子并不能自己發送消息，是以，正常思維就是添加代理了。可是呢，如果一個棋子一個代理，36顆子不就要産生36個代理了？
是以，代理的位置要移動一下了，一開始呢，我是在Chess類裡添加一個代理，然後在棋子GoToDead裡調用一個Chess的代理方法。
不過呢！剛想到了，直接在ChessAction的吃子動作裡加代理和判斷就行了，說動就動。
/// <summary>
/// 棋子動作類 by 路過秋天
public class ChessAction
public delegate void GameEndDelegate(int colorValue);
public event GameEndDelegate HelpSetGameEndEvent;
//...省略N多行
public void SetIsGameEnd(Chessman man)
if (man.Name == "将" || man.Name == "帥")
GameEndEvent(man.Color == Colors.Red ? 1 : 2);
public void EatChessman(Chessman moveChessman, Chessman eatChessman)
if (MoveTo(moveChessman, eatChessman.MovePoint))
SetIsGameEnd(eatChessman);
eatChessman.GoToDead();
/// <summary>
/// 系統自動移動棋子
/// </summary>
public void AutoMoveTo(Point from, Point to)
Chessman chessman = Parent.FindChessman(from);
Chessman eatChessman = Parent.FindChessman(to);
if (chessman != null)
PlayMove(chessman, to);
chessman.MovePoint = to;
if (eatChessman != null)
{
SetIsGameEnd(eatChessman);
eatChessman.GoToDead();
}
}
我們添加了一個代理，由于，除了我們人為移動，還有系統自己移動，是以我們添加了一個公共方法，在吃子前都SetIsGameEnd來看看是不是遊戲結束了，由于棋子誰輸誰赢，是以要傳遞一個Color用于說明誰的将/帥被吃了。
OK，接着我們回到Chess.xaml.cs裡，實作一下這個代理方法：
public partial class Chess : UserControl
ChessNewInstance.Chess chess;//這裡我們同時把它提到全局對象
public Chess()
chess.Action.HelpSetGameEndEvent += new ChessNewInstance.ChessAction.GameEndDelegate(Action_HelpSetGameEndEvent);
//...省略N行...
void Action_HelpSetGameEndEvent(int colorValue)
//将帥被吃，遊戲結束
if (App.player.ColorValue + colorValue == 3)
App.player.AttachInfo = "1";
App.client.EndGameAsync(App.player);
顔色值相加=3就是對手了。由于将帥被吃，無論是棋手還是看棋者，都會産生這個事件，是以要過濾判斷。
OK，至此，我們F5看下效果了：
再走一步，吃将軍：
狀态重置成功了，可是一點提示都沒有，于是，我們回到遊戲結束EventButton.xaml.cs那裡，添加一下結束通知彈出消息了：
//...省略N行...
case "1":
MessageBox.Show(e.player.NickName+" 赢了!", "遊戲結果通知", MessageBoxButton.OK);
繼續F5運作看下效果：
吃掉對方将軍時，終于有提示了：
确認後，遊戲重置所有狀态：看按鈕，也重置了：
OK，本節點到為止了。
版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：
http://www.cnblogs.com/cyq1162/archive/2010/08/06/1794242.html