前言：
在WCF初探-5：WCF消息交换模式之双工通讯(Duplex)博文中，我讲解了双工通信服务的一个应用场景，即订阅和发布模式，这一篇，我将通过一个消息发送的例子讲解一下WCF客户端如何为双工服务创建回调对象。
双工服务指定一个回调协定，客户端应用程序必须实现该协定以便提供一个该服务能够根据协定要求调用的回调对象。虽然回调对象不是完整的服务（例如，您无法使用回调对象启动一个通道），但是为了实现和配置，这些回调对象可以被视为一种服务。
双工服务的客户端必须：
- 实现一个回调协定类。
- 创建回调协定实现类的一个实例，并使用该实例创建传递给 WCF 客户端构造函数的 System.ServiceModel.InstanceContext 对象。
- 调用操作并处理操作回调。
双工 WCF 客户端对象除了会公开支持回调所必需的功能（包括回调服务的配置）以外，其他的功能和它们的非双工对应项相同。
示例说明：
- Service服务契约中定义了一个发送方法Send，采用IsOneWay=true,供客户端调用，向服务端发送消息。Service中还提供了用于双工通信的回调接口IMessageExchangeCallback，该接口中定义了服务端接收消息后向客户端发送消息的方法Receive,此方法就是客户端发送消息到服务端后，服务端调用回调方法，将消息发送到客户端。
- Client需要实现双工协定回调接口的类CallBackHandler，并实现Receive方法。
- 针对双工协定生成的 WCF 客户端需要在构造时提供一个 InstanceContext 类。此 InstanceContext 类用作实现回调接口并处理从服务发送回的消息的对象所在的位置。InstanceContext 类是用 CallbackHandler 类的实例构造的。此对象处理通过回调接口从服务发送到客户端的消息。
WCF客户端为双工服务创建回调对象示例：
- 解决方案如下：
- 工程结构说明：
- Service:类库程序，定义服务契约接口和回调接口，实现服务契约。在IMessageExchange中定义了Send方法，并且还定义了双工服务回调接口 IMessageExchangeCallback。
IMessageExchange.cs的代码如下：
using System.Collections.Generic;
using System.Runtime.Serialization;
namespace Service
{
[ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof(IMessageExchangeCallback))]
public interface IMessageExchange
{
[OperationContract(IsOneWay=true)]
void Send(string message);
}
public interface IMessageExchangeCallback
{
[OperationContract(IsOneWay = true)]
void Receive(string message);
}
}
MessageExchange.cs的代码如下：
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
namespace Service
{
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
public class MessageExchange : IMessageExchange
{
public void Send(string message)
{
Console.WriteLine("服务端监听客户端发出的消息：" + message);
Callback.Receive(message);
}
IMessageExchangeCallback Callback
{
get
{
return OperationContext.Current.GetCallbackChannel<IMessageExchangeCallback>();
}
}
}
}
注意：回调契约接口IMessageExchangeCallback中的Receive方法是在客户端实现的，所以如果需要在服务端调用回调方法就必须通过当前操作的实例上下文来获取，即上面代码中的Callback对象。
2. Host:控制台应用程序。提供服务寄宿程序，添加对Srevice程序集的引用。完成配置文件和代码就可以承载服务。
Program.cs的代码如下：
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Service;
using System.ServiceModel;
namespace Host
{
class Program
{
static void Main(string[] args)
{
using (ServiceHost host = new ServiceHost(typeof(MessageExchange)))
{
host.Opened += delegate { Console.WriteLine("服务已经启动，按任意键终止！"); };
host.Open();
Console.Read();
}
}
}
}
App.config的代码如下：
<configuration>
<system.serviceModel>
<services>
<service name="Service.MessageExchange" behaviorConfiguration="mexBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:1234/MessageExchange/"/>
</baseAddresses>
</host>
<endpoint address="" binding="wsDualHttpBinding" contract="Service.IMessageExchange" />
<endpoint address="mex对弈类游戏的人工智能(5)--2048游戏AI的解读 - mumuxinfei 阅读原文»
前言:
闲得没事, 网上搜"游戏AI", 看到一篇<<2048游戏的最佳算法是？来看看AI版作者的回答>>的文章. 而这篇文章刚好和之前讲的对弈类游戏AI对应上. 于是有了想法, 想把它作为一个实例来进行解读, 从而对之前偏理论的文章做个总结.
承接上四篇博文:
(1). 评估函数+博弈树算法
(2). 学习算法
(3). 博弈树优化
(4). 游戏AI的落地
可能有些人会疑惑? 2048并非对弈类类型? 传统的博弈树模型是否能应用于此? 客官莫急, 让我们来一步步揭开谜底.
导读:
本文是对<<2048游戏的最佳算法是？来看看AI版作者的回答>>文章, 以及原作者提供的AI代码进行解读的文章.
如果有兴趣, 可点击试玩的游戏链接, 可查阅的源代码链接.
建模:
之前的对弈类游戏, 博弈双方的地位都是对等的. 但这边只有游戏者一人, 对手在哪里?
让人脑洞大开的是, 2048游戏AI的设计者, 创造性把棋局环境本身做为了博弈的另一方.
当然双方追求的胜利目标不一样:
• 游戏者(AI): 追求2048及2048以上的方块出现
• 棋局环境: 填满棋局格子, 使得4个方向皆不能移动
游戏模型就演变成了信息完备的对弈问题. 而传统博弈树和技巧就自然有了用武之地.
评估函数:
依据游戏经验, 作者选用了如下评估因素:
(1) 单调性: 指方块从左到右、从上到下均遵从递增或递减.
(2) 平滑性: 指每个方块与其直接相邻方块数值的差，其中差越小越平滑.
(3) 空格数: 局面的空格总数.
(4) 最大数: 当前局面的最大数字, 该特征为积极因子.
采用线性函数, 并添加权重系数:
AI.prototype.eval = function() {
var emptyCells = this.grid.availableCells().length;
var smoothWeight = 0.1,
//monoWeight = 0.0,
//islandWeight = 0.0,
mono2Weight = 1.0,
emptyWeight = 2.7,
maxWeight = 1.0;
return this.grid.smoothness() * smoothWeight
//+ this.grid.monotonicity() * monoWeight
//- this.grid.islands() * islandWeight
+ this.grid.monotonicity2() * mono2Weight
+ Math.log(emptyCells) * emptyWeight
+ this.grid.maxValue() * maxWeight;
};
评: 前3项能衡量一个局面的好坏, 而最大数该项, 则让游戏AI多了一点积极和"冒险". 权重系数设定和特征选择其实是个技术活, 作者在这有他的尝试和权衡.
博弈:
游戏AI的决策过程, 是标准的maxmin search和alpha+beta pruning的实现. 所有的方向(上下左右)都会去尝试.
然而在游戏本身做决策时, 不是每个空格都去尝试填{2, 4}. 而是选择了最坏的局面, 做为搜索分支的剪枝条件. 选择性地丢弃了很多搜索分支.
// with metrics from eval
var candidates = [];
var cells = this.grid.availableCells();
var scores = { 2: [], 4: [] };
for (var value in scores) {
for (var i in cells) {
scores[value].push(null);
var cell = cells;
var tile = new Tile(cell, parseInt(value, 10));
this.grid.insertTile(tile);
scores[value] = -this.grid.smoothness() + this.grid.islands();
this.grid.removeTile(cell);
}
}
// now just pick out the most annoying moves
var maxScore = Math.max(Math.max.apply(null, scores[2]), Math.max.apply(null, scores[4]));
for (var value in scores) { // 2 and 4
for (var i=0; i<scores[value].length; i++) {
if (scores[value] == maxScore) {
candidates.push( { position: cells, value: parseInt(value, 10) } );
}
}
}
对于选择性忽略搜索节点, 其实很有争议. 在某些情况下, 会失去获取最优解的机会. 不过砍掉了很多分支后, 其搜索深度大大加强. 生存能力更强大.
迭代深搜:
不同的javascript引擎其性能差异较大, 若需要限定时间搜索时. 这时迭代深搜就"粉墨登场"了.
AI.prototype.iterativeDeep = function() {
var start = (new Date()).getTime();
var depth = 0;
var best;
do {
var newBest = this.search(depth, -10000, 10000, 0 ,0);
if (newBest.move == -1) {
break;
} else {
best = newBest;
}
depth++;
} while ( (new Date()).getTime() - start < minSearchTime);
return best
}
超时判断在每个深度探索结束后进行, 这未必会精确, 甚至误差很大. 我还是推崇前文谈到过的实现方式.
不管怎样, 作者基本达到了其每100ms决策一步的要求.
总结:
前几篇博文涉及到很多点, 都在该2048游戏AI中有所体现. 2048游戏作为非典型的对弈类游戏, 本不太合适作为具体案例来讲解. 但对于原作者创造性的思维和建模, 我们作为后辈可以学到更多. 把环境拟人化的对弈模型, 也是面对反馈类场景的一种很好的评估决策思路.
本文在编写前, 并没注意该博文<<2048 AI 程序算法分析>>的存在. 编写过程中, 借鉴了该文, 也添加了自己的一些认识.
写在最后：
如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益. 无论多少, 都是对楼主一种由衷的肯定.
本文链接：对弈类游戏的人工智能(5)--2048游戏AI的解读，转载请注明。
没有评论:
发表评论