CN104703663A - 用于标识保证可解的场景的众包 - Google Patents

Abstract

公开了一种用于使用众包来标识已被用户标识为导致对具有所定义的约束的场景的解答的已知可解数据状态的方法。在其中场景是计算机纸牌游戏的一个示例中，可以向多个用户提供处于特定次序的纸牌形式的初始数据状态。在用户成功完成纸牌游戏至所需解答状态的情况下，纸牌的初始状态可被存储为已知可解数据状态。

Description

用于标识保证可解的场景的众包

背景

游戏系统已经从提供孤立的游戏体验的系统进化成可实时地在朋友和其他玩家之间共享的、提供丰富的交互式体验的联网系统。在具有微软的视频游戏系统和Xbox在线游戏服务的情况下，用户现在能参与各种各样的计算机化的游戏体验。

存在特定游戏、谜题和其他交互式场景，这些场景的结构开始于可能是随机生成的多个可能的初始状态之一。诸如玩家输入等事件根据某一规则集来触发从这些初始状态到多个中间状态的转换，该状态序列以所定义的所需解答状态告终。在特定场景中，某些初始状态不允许至所需解答状态的成功完成，而不管玩家输入如何。例如，在公知的游戏Klondike Solitaire(克朗代克接龙)中，估计所有可能的初始状态中仅仅大约15％允许玩家到达所需解答状态(所有纸牌都按花色从A到K依次排序)。

对于一些这样的游戏和谜题，基于初始和中间状态的排列的纯复杂性和数量或某一其他原因，在算术上确定给定初始状态是否能以所需解答状态结束可能是不切实际或不可能的。因此，找到用于回答游戏或谜题的初始状态是否可通过某一步或步骤序列来解答以及解答到什么程度的替代手段可以是有用的。

概述

本系统的实施例一般涉及一种用于以下操作的系统：生成游戏、谜题、问题或其他场景的初始状态，将该初始状态众包至该场景中的参与者，以及收集关于基于参与者到达的中间和结束状态的初始状态的可解性的数据。实施例还可将已解初始状态与已解数据状态的数据库中的其他已解初始状态进行比较，并且如果该初始状态未被找到，则向数据库添加涉及新解的初始状态的信息。另外，系统的实施例可使用通过记录用户在给定场景中的进度来获取的数据来在质量上或数量上确定对于呈现给用户的初始状态给定场景是否是可解的并将其告知用户。

本技术的实施例涉及一种用于标识可解以到达将被求解的场景中的所需解答状态的一个或多个初始数据状态的子集的方法，该方法包括向用户集合提供初始数据状态的集合，该初始数据状态的集合包括可解的一个或多个初始数据状态的子集，确定正由一个或多个用户求解至所需解答状态的场景的一个或多个实例，以及存储用于标识在所述确定中一个或多个用户已从其解答该场景的一个或多个初始数据状态的子集的信息。

本技术的另一实施例涉及一种用于从较大的数据状态集合中标识已知可解数据状态的方法，该已知可解数据状态是用户可从其到达具有约束集的场景中的所需解答状态的那些数据状态，该方法包括将初始数据状态从服务器提供至用户控制台的集合以供用户控制台的用户从初始数据状态对场景求解，在用户对场景求解的尝试中接收与初始数据状态的用户交互的指示以生成中间数据状态，确定正由一个或多个用户求解至所需解答状态的场景的一个或多个实例，以及存储用于标识在所述确定中一个或多个用户已从其解答该场景的已知可解数据状态的信息。

本技术的另一实施例涉及一种具有计算机可执行指令的计算机可读介质，这些计算机可执行指令用于将处理器编程为执行一种从较大的初始数据状态集合中标识已知可解初始数据状态的方法，初始数据状态是计算机化的纸牌游戏中的向用户显示的纸牌的初始次序，并且已知可解初始数据状态是用户可成功地从其完成纸牌游戏至所需解答状态的初始纸牌排序，该方法包括生成纸牌的初始数据状态，将初始数据状态从服务器提供至用户控制台的集合以供用户控制台的用户从初始数据状态开始玩纸牌游戏，在用户玩纸牌游戏时接收与初始数据状态的用户交互的指示以生成中间数据状态，确定其中一个或多个用户成功地完成纸牌游戏至所需解答状态的一个或多个实例，以及存储用于标识在所述确定中纸牌游戏已成功从其完成至所需解答状态的已知可解初始数据状态的信息。

提供本概述以便以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图简述

图1是示例性游戏和媒体系统的立体图。

图2是图1所示的游戏和媒体系统的组件的示例性功能框图。

图3是用于创建、处理和传递可解性信息的示例性操作环境的框图。

图4是用于与用户一起产生、共享和接收包括可解性的状态数据的示例性方法的流程图。

图5是用于与用户一起产生、共享和接收包括可解性的状态数据以便专门能够记录和保留中间状态的示例性方法的流程图。

图6是用于向用户提供已知是可解的状态以供用户尝试对场景求解的方法的流程图。

图7是用于向用户提供场景的初始状态以学习用户是否能够在这些场景中到达已知是可解的状态的示例性方法的流程图。

图8是用于向用户提供对于场景已知是可解的状态以学习用户是否能够从这些状态采取替代路径来解答这些场景的方法的流程图。

详细描述

现在参考附图1-8描述本技术，本技术一般涉及用于使用众包来累积给定场景的已知可解数据状态集的系统和方法。通过众包，可以向众多用户提供诸如游戏或谜题等包括初始数据状态的场景。成功完成场景的那些用户的数据状态可被标识并且在已知可解数据状态的数据库中累积。在各实施例中，所存储的已知可解数据状态可以是初始数据状态，但在其他实施例中可以是中间数据状态。

如此处所使用的，“众包”可以指向一个或多个用户提供将被求解的场景以标识导致一个或多个用户成功完成该场景至所需解答状态的数据状态。如此处所使用的“众包”还可被用来确定与场景的解答相关的其他度量。例如，众包可用于确定用户花费多少交互来从给定初始或中间数据状态到达所需解答。众包还可用于标识用户如何尝试对给定场景求解的模式以及用户将原本可解的场景转变为可能无法从给定中间数据状态解答的场景的点。

在一些实施例中，本技术可以在以下情形中使用：对于给定场景，在可解的初始状态和不可解的那些初始状态之间进行区分对于计算机算法而言是不可能或麻烦的。该困难可能例如由于计算机使用过多的时间来筛选可由给定场景的规则生成的初始状态、转换、中间状态和最终状态的大量排列而引发。然而，应注意，本技术的实施例可用于标识其中通过使用计算机器或流程筛选是可行的可解初始和/或中间状态。

本技术的实施例在上文和下文中用通用术语来阐释，而不被认为是限制性的。在各实施例中，向一个或多个用户呈现将被求解的场景。在各实施例中，向多个不同用户提供一个或多个初始数据状态，目标是在被限于相同的规则或约束集时从这些初始数据状态收敛于相同的解答状态。在许多可能的示例之一中，所讨论的场景可以是计算机游戏，诸如Klondike Solitaire。在KlondikeSolitaire中，纸牌以初始状态排序，并且然后按在游戏开始时呈现给玩家的起始纸牌布局排列。

在一个示例中，Klondike Solitaire的初始状态将会是一副虚拟纸牌(avirtual deck)中的经洗牌的纸牌排列。虚拟纸牌可以排列为具有从零增加(从左到右)的高度(加一)的六叠面朝下纸牌，每一叠上是一张面朝上纸牌。游戏的中间状态是通过被Klondike Solitaire的规则认为是有效的玩家交互而造成的初始状态的变换。一个这样的可能交互可以是用包含K的一叠纸牌来填充空叠。一旦玩家在遵守游戏规则的情况下已经操纵初始和中间状态来获得四叠“基础”纸牌的集合且每一叠从A到K连续排序以使得给定基础堆叠中的纸牌具有相同的花色，就可到达Klondike Solitaire的所需解答状态。本技术的实施例不限于Klondike Solitaire场景。

在Klondike Solitaire游戏或开始于52张纸牌的随机洗牌的一副牌的其他纸牌游戏中，存在纸牌的初始排序(初始状态数据)的52！或8x 1068种不同的排列。用于来回移动纸牌的每一用户交互生成中间状态，从而增加需要计算的排列数量。由此，通过计算机算法来标识能够潜在导致成功地完成游戏至所需解答状态的初始和/或中间状态数据可能是不切实际的。可以理解，本技术可用于其他版本的Solitaire(接龙)，或者其他计算机游戏或谜题或任何种类的游戏或谜题。这些其他游戏和谜题包括但不限于：FreeCell Solitaire(纸牌游戏)、Spider Solitaire(纸牌游戏)、Pyramid Solitaire(纸牌游戏)、TriPeaks Solitaire(纸牌游戏)、Mahjong Solitaire(麻将游戏)、Minesweeper(谜题游戏)、Bridge(纸牌游戏)、Chess(用棋子的游戏)。在其他实施例中，本技术可用于标识除了游戏或谜题之外的场景中的已知可解数据状态。一个这样的附加示例是DNA和其他遗传物质的测序。

本技术的其他实施例可生成场景的任意状态以供用户继续和求解。例如，在国际象棋游戏的场景的情况下，本技术的实施例可以向用户提供国际象棋棋子的棋盘布局(作为状态)，该棋盘布局可以通过游戏过程中玩家之间的可能的、合法的一步或多步的某种模式来从初始布局到达。之前或之后对国际象棋或任何其他特定场景的参考仅仅被引述为是示例性的，不旨在限制本技术的可能实施例的范围。

本技术的可能实施例可以向用户呈现给定场景的初始状态，记录用户在给定场景中的进度(包括唯一地标识在所尝试的求解过程中获取的中间状态的数据)，并且用表示用户进度的数据来更新数据库。在用户求解的给定场景的初始状态的情况下，本技术的实施例可使用中间数据状态来生成与给定场景的初始状态的可解性有关的数据。例如，如果用户用N步从所提供的初始状态完成国际象棋游戏至将死，则本技术的实施例可记录指示所提供的初始状态是在N步内可解的数据。或者，如果用户在N小时的过程中从所提供的初始状态完成国际象棋游戏至将死，则本技术的实施例可记录指示所提供的初始状态是在N小时内可解的数据。本技术的实施例可存储该可解性数据和/或使其对用户可用。

本技术的替代实施例可以向用户提供给定场景的初始状态，记录由于用户的进度而产生的初始和中间数据状态，并且用表示用户进度的数据来更新数据库。如果用户将场景求解至所需解答状态，则初始数据状态和中间数据状态两者都可被存储在解答数据库中。这些中间数据状态可以例如用于向后续用户提供可以从所存储的给定中间状态到达解答状态的保证。还构想未导致成功完成场景至所需解答状态的初始和/或中间数据状态可以向用户提供有用的信息。例如，在后续用户被提供初始数据状态的情况下，可以通知这些用户没有人从该给定初始数据状态解答场景。

图1示出了示例性游戏和媒体系统100。对图1的以下讨论旨在提供可在其中实现此处所呈现的概念的合适环境的简要概括描述。可以理解，图1的系统仅仅作为示例。在其他示例中，本系统可以经由驻留在客户机计算系统上并由客户机计算系统执行的浏览器应用或软件应用来在各种客户机计算系统上实现。如图1所示，游戏和媒体系统100包括游戏和媒体控制台(以下统称为“控制台”)102。一般而言，如以下将进一步描述的，控制台102是一种类型的客户机计算系统。控制台102被配置成适应一个或多个无线控制器，如控制器104(1)和104(2)所表示。控制台102配备有内部硬盘驱动器(未示出)和支持如光学存储盘108所表示的各种形式的便携式存储介质的便携式媒体驱动器106。合适的便携式存储介质的示例包括DVD、CD-ROM、游戏盘等。控制台102还包括用于容纳可移动闪存型存储器单元140的两个存储器单元卡插座125(1)和125(2)。控制台102上的命令按钮135启用和禁用无线外围支持。

如图1所示，控制台102还包括用于与一个或多个设备进行无线通信的光学端口130和支持附加控制器或其它外围设备的有线连接的两个USB(通用串行总线)端口110(1)和110(2)。在某些实现中，可修改附加端口的数量和安排。电源按钮112和弹出按钮114也位于游戏控制台102的正面。电源按钮112被选择来对游戏控制台供电，且还可以提供对其它特征和控件的访问，而弹出按钮114交替地打开和关闭便携媒体驱动器106的托盘以允许存储盘108的插入和取出。

控制台102通过A/V接口电缆120连接到电视机或其他显示器(如监视器150)。在一个实现中，控制台102配备有被配置成用于使用A/V电缆120(例如适于耦合到高清晰度监视器150或其他显示设备上的高清晰度多媒体接口“HDMI”端口的A/V电缆)来进行内容受保护的数字通信的专用A/V端口(未示出)。电源电缆122向游戏控制台供电。控制台102可进一步被配置成具有如电缆或调制解调器连接器124所表示的宽带能力以便于访问诸如因特网等网络。还可通过诸如无线保真(Wi-Fi)网络等宽带网络来无线地提供宽带能力。

每一控制器104经由有线或无线的接口耦合到控制台102。在示出的实现中，控制器104是USB兼容的并且通过无线或USB端口110耦合到控制台102。控制台102可配备各种用户交互机制中的任何一种。在图1中示出的示例中，每一控制器104配备两个拇指推柄(thumbstick)132(1)和132(2)、D垫134、按钮136、以及两个触发器138。这些控制器仅为代表性的，且其它已知游戏控制器可代替或被添加到在图1中示出的那些控制器。

在一个实现中，还可以将存储器单元(MU)140插入到控制器104中以提供附加和便携的存储。便携MU允许用户存储游戏参数以供在其它控制台上玩时使用。在此实现中，每一控制器被配置成适应两个MU 140，但是也可采用多于或少于两个MU。

游戏和媒体系统100通常被配置成玩存储在存储器介质上的游戏，以及被配置成下载并玩游戏、和被配置成从电子和硬介质来源再现预先录制的音乐和视频。使用不同的存储供应，可从硬盘驱动器、从光盘介质(例如，108)、从在线源、或从MU 140播放项。游戏和媒体系统100能够播放的媒体的类型的示例包括：

●从CD和DVD盘、从硬盘驱动器、或从在线来源播放的游戏项。

●从便携媒体驱动器106中的CD、从硬盘驱动器上的文件(例如，使用Windows媒体音频(WMA)格式的音乐)、或从在线流送来源播放的数字音乐。

●从便携媒体驱动器106中的DVD盘、从硬盘驱动器上的文件(例如，活动流送格式(Active Streaming Format))、或从在线流传送来源播放的数字音频/视频。

在操作期间，控制台102被配置成接收来自控制器104的输入并在显示器150上显示信息。例如，控制台102可在显示器150上显示用户界面以便允许用户使用控制器104来选择游戏并且显示状态可解性信息，如以下将讨论的。

图2是游戏和媒体系统100的功能框图并更详细地示出游戏和媒体系统100的各功能组件。控制台102具有中央处理单元(CPU)200以及便于处理器访问各种类型的存储器的存储器控制器202，各种类型的存储器包括闪存只读存储器(ROM)204、随机存取存储器(RAM)206、硬盘驱动器208，以及便携式媒体驱动器106。在一种实现中，CPU 200包括1级高速缓存210和2级高速缓存212，这些高速缓存用于临时存储数据并因此减少对硬盘驱动器208进行的存储器访问周期的数量，从而提高了处理速度和吞吐量。

CPU 200、存储器控制器202、以及各种存储器设备经由一个或多个总线(未示出)互连。在此实现中所使用的总线的细节对理解此处所讨论的关注主题不是特别相关。然而，应该理解，这样的总线可以包括串行和并行总线、存储器总线、外围总线、使用各种总线体系结构中的任何一种的处理器或局部总线中的一个或多个。作为示例，这样的体系结构可以包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线、以及也称为夹层总线的外围部件互连(PCI)总线。

在一个实现中，CPU 200、存储器控制器202、ROM 204、以及RAM 206被集成到公用模块214上。在此实现中，ROM 204被配置为通过PCI总线和ROM总线(两者都没有示出)连接到存储器控制器202的闪存ROM。RAM 206被配置为多个双倍数据速率同步动态RAM(DDR SDRAM)模块，它们被存储器控制器202通过分开的总线(未示出)独立地进行控制。硬盘驱动器208和便携式媒体驱动器106被示为通过PCI总线和AT附加(ATA)总线216连接到存储器控制器202。然而，在其他实现中，也可以备选地应用不同类型的专用数据总线结构。

三维图形处理单元220和视频编码器222构成了视频处理流水线，用于进行高速度和高分辨率(例如，高清晰度)图形处理。数据通过数字视频总线(未示出)从图形处理单元220传输到视频编码器222。音频处理单元224和音频编解码器(编码器/解码器)226构成了对应的音频处理流水线，用于对各种数字音频格式进行多通道音频处理。通过通信链路(未示出)在音频处理单元224和音频编解码器226之间传送音频数据。视频和音频处理流水线向A/V(音频/视频)端口228输出数据，以便传输到电视机或其它显示器。在所示出的实现中，视频和音频处理组件220-228安装在模块214上。

图2示出包括USB主控制器230和网络接口232的模块214。USB主控制器230被示为通过总线(例如，PCI总线)与CPU 200和存储器控制器202进行通信，并作为外围控制器104(1)-104(4)的主机。网络接口232提供对网络(例如因特网、家庭网络等)的访问，并且可以是包括以太网卡、调制解调器、无线接入卡、蓝牙模块、电缆调制解调器等各种有线或无线接口组件中的任一种。

在图2中示出的实现中，控制台102包括用于支持四个控制器104(1)-104(4)的控制器支持部件240。控制器支持子部件240包括支持与诸如，例如，媒体和游戏控制器之类的外部控制设备的有线和无线操作的任何硬件和软件组件。前面板I/O子部件242支持电源按钮112、弹出按钮114，以及任何LED(发光二极管)或暴露在控制台102的外表面上的其它指示器等多个功能。子部件240和242通过一个或多个电缆部件244与模块214进行通信。在其它实现中，控制台102可以包括另外的控制器子部件。所示出的实现还示出了被配置成发送和接收可以传递到模块214的信号的光学I/O接口235。

MU 140(1)和140(2)被示为可以分别连接到MU端口“A”130(1)和“B”130(2)。附加的MU(例如，MU 140(3)-140(6))被示为可连接到控制器104(1)和104(3)，即每一个控制器两个MU。控制器104(2)和104(4)也可以被配置成接纳MU(未示出)。每一个MU 140都提供附加存储，在其上面可以存储游戏、游戏参数、及其它数据。在一些实现中，其它数据可以包括数字游戏组件、可执行的游戏应用，用于扩展游戏应用的指令集、以及媒体文件中的任何一种。当被插入到控制台102或控制器中时，MU 140可以被存储器控制器202访问。

系统供电模块250向游戏系统100的组件供电。风扇252冷却控制台102内的电路。

包括机器指令的应用260被存储在硬盘驱动器208上。当控制台102被接通电源时，应用260的各个部分被加载到RAM 206，和/或高速缓存210以及212中以在CPU 200上执行，其中应用260是一个这样的示例。各种应用可以存储在硬盘驱动器208上以用于在CPU 200上执行。

可以通过简单地将系统连接到监视器150(图1)、电视机、视频投影仪、或其他显示设备来将游戏与媒体系统100用作独立系统。在此独立模式下，游戏和媒体系统100允许一个或多个玩家玩游戏或欣赏数字媒体，例如观看电影或欣赏音乐。然而，随着通过网络接口232变得可用的宽带连接的集成，游戏和媒体系统100还可用作较大的网络游戏社区中的参与者，如以下结合图3所讨论的。

图3提供了通过网络306与具有一个或多个服务器304的控制台服务302联网的多个控制台300A-300N的框图。在一个实施例中，网络306包括因特网，但是构想了诸如LAN或WAN之类的其他网络。服务器304还包括能够从控制台300A-N接收信息并将信息传送给控制台300A-N的通信组件，并且提供在控制台300A-N上运行的应用可以调用和利用的服务的集合。作为一个示例，服务器304可以向用户提供多个游戏。这些游戏中的某一些可涉及如此处讨论的场景，其中向控制台300的用户提供游戏，取决于作为游戏的一部分提供给用户的数据的初始状态，该游戏的各个实例可以或无法被成功地完成至所需解答状态。作为游戏应用的一部分，服务器304还能够随机地或以其他方式生成给定场景的初始状态，并且软件应用还能够对照游戏应用中所包含的约束和/或规则来检查和/或确认用户决定以生成中间数据状态。另选地或另外地，服务器304可通过软件应用从解答数据库316中连同可解性数据一起获取已知初始或中间状态，这在后文中解释。服务器304能够经由网络306且然后经由控制台300A-N将不管怎样获取的初始或中间状态连同一些或全部已知可解性数据一起传递至用户。

控制台300A-N可调用用户登录服务308，该用户登录服务用于在控制台300A-N上认证用户。在登录期间，登录服务308获得来自用户的游戏玩家标签(与该用户相关联的唯一标识符)和口令，以及标识用户正在使用的控制台的控制台标识符和到该控制台的网络路径。玩家标签和口令通过将它们与数据库312中的用户记录310相比较来认证，该数据库可位于与用户登录服务308相同的服务器上、或可以分布在不同的服务器上或不同的服务器集合上。一旦被认证，用户登录服务308就将控制台标识符和网络路径存储在用户记录301中，使得可将消息和信息发送给控制台。登录服务308对于本技术而言并不是至关重要的，并且可以在其他实施例中被省略。

用户记录310可包括关于用户的附加信息，诸如游戏记录314。游戏记录314包括关于由玩家标签标识的用户的信息，并且可按需包括关于特定游戏的统计数据、玩家对特定游戏做出的进度和/或其他游戏专用信息。如下文所解释的，在一个示例中，特定用户的进行中的游戏的初始和中间数据状态可以与该用户相关联地存储在游戏记录314中。

用户记录310还包括关于用户的附加信息，包括用户已经下载的游戏和已经发放的用于那些所下载的游戏的许可证包，其中包括与每个许可证包相关联的许可。用户记录310的各部分可存储在单独的控制台上、在数据库312中、或两者。如果单独的控制台保留游戏记录314的部分或全部和/或解答数据库316的部分或全部，则该信息可通过网络306提供给控制台服务302。另外，控制台能够在不具有到控制台服务302的连接的情况下显示与游戏记录314的部分或全部和/或解答数据库316的部分或全部相关联的信息。

在本技术的实施例中，解答数据库316可包括游戏和其他场景的可解性数据。如此处所使用的术语“可解性数据”可以宽泛地指代与游戏或其他场景有关的数据。在一个示例中，可解性数据包括已由控制台300的用户成功完成的场景的已知可解数据状态。这些已知可解数据状态可包括游戏或其他场景的初始或中间数据状态。在其他示例中，可解性数据可包括游戏的特定初始或中间状态是否是可解的，以及在什么条件下游戏的特定初始或中间状态可以是或不是可解的。可以想到解答数据库316将能够与游戏记录314通信，从而获取其中包含的数据以创建或修改可解性数据。

服务器304还包括准许诸如控制台300A的一个控制台向诸如控制台300B的另一控制台发送消息的消息服务320。此类消息可以包括被称为邀请的文本消息、语音消息、专门的游戏中文本消息，其中当使用网络306在两个控制台之间传递游戏数据时，在一个控制台上玩游戏的用户邀请在另一控制台上的用户玩相同游戏，使得两个用户在游戏的同一会话中玩。与一个或多个游戏有关的可解性数据和初始或中间数据状态还可以使用消息服务320在控制台300A-N之间共享。在本技术的其他实施例中，可省略消息服务320。

用于使用众包来标识具有可解结果的初始数据状态的本技术的实施例现在将参考图4的示例性方法400来描述。在一个实施例中，用户通过采用用户登录服务308来开始诸如Klondike Solitaire之类的游戏，并且在被控制台服务302认证后，在控制台300A-N上运行向该用户呈现将被求解的场景的程序。在步骤402中，该系统(可能是服务器304)生成游戏、谜题或其他场景的初始数据状态。系统可采用随机数生成器来生成输入，这些输入进而可被用作初始状态的种子输入。或者，初始状态可通过遵循已编程的试探以便从所存储的某一状态中生成新状态来创建。其他实施例可能不同地工作。

在步骤406中，系统可将初始状态存储在游戏记录314中并且还可经由网络306和控制台300A-N向用户提供初始状态数据以开始场景。另外，本技术的一些实施例可使得步骤406和410由控制台300执行，由此出于接收初始状态和报告场景完成的目的而与控制台服务302交互。

在步骤410中，场景通过用户经由网络306向控制台服务302提供状态转换决定来继续，服务器304配备有根据场景的规则和约束来主动规制状态转换决定的软件。在步骤414中，系统可确定经由用户决定获取的中间状态事实上是否处于结束状态(如通过服务数据库312知晓的)。此处所使用的“结束状态”可以指场景已达到完成并且场景中没有附加步或用户交互是可能(或有用)的的状态。

如果场景未到达结束状态，则在步骤416中系统可以检查用户是希望继续还是终止未完成的场景。如果用户希望终止场景，则系统可转移到步骤428以检查用户是否希望开始新场景，如下所解释的。如果在步骤416中用户不希望终止场景，则该流程返回到步骤410以接收进一步的中间数据状态。

如果步骤414指示场景已经到达结束状态，则在步骤418中该系统可确定该结束状态是否构成所需解答状态。如果不是所需解答状态，则在步骤428中可询问用户他们是否希望开始新场景。另一方面，如果在步骤418中用户已经成功完成了所需解答状态，则可将该已解答场景的初始数据状态存储在解答数据库316中。然而，为了避免存储已解答场景的重复的初始数据状态，服务器304可以向解答数据库316查询该初始状态是否已经存在于游戏记录314中。如果是，则系统移动到步骤428。如果否，则服务器304将该初始状态数据或者唯一地生成该初始状态的种子数据存储在解答数据库316中。

系统然后转移至步骤428，在该步骤询问用户他们是否希望开始新场景。如果否，则过程400终止。如果是，则过程400在步骤402重新开始。

应注意，过程400不限于任何固定数量的用户、控制台300A-N或控制台服务系统302。事实上，当使得许多参与者参与生成关于场景的可解状态的大量数据时，过程400可以是最有用的。

图5描绘了本技术的替代示例500。示例500可出于许多可能的原因而采用，其中之一可以是生成场景的共同初始状态的大量可能的解答路径。在步骤502中，该过程可通过服务器304或许使用某种类型的状态生成软件引擎来为参与该系统的一个或多个用户生成共同初始状态来开始。步骤502之后是步骤506，其中可将该初始状态数据存储在游戏记录314中并通过网络306、控制台300和显示器150将该初始状态数据传送至用户。

在步骤506后，当用户可以尝试从由步骤506呈现的初始状态对场景求解时，与场景中的通过用户交互到达的中间状态有关的数据可由服务器304在步骤510中收集并在步骤512中存储在游戏记录314中。在该实施例和其他实施例中，所收集和存储的数据能够唯一地标识场景的当前状态。该数据还可包括给定用户到目前为止花费的步数。

在步骤514中，服务器304可确定场景是否已经达到完成(即没有其他有意义的步是可能的)。例如，数据的结束状态可匹配存储在服务数据库312中的已知结束状态。或者，系统可标识没有其他用户交互是可能的。可能发生以下情形：进一步的用户交互是可能的，但将不会被用来使场景前进超过其当前状态。作为Klondike solitaire中的一个示例，用户可能无法在降序纸牌的现有各列之间来回移动任何纸牌，或者将任何纸牌从该副纸牌添加到各列上。在这种情况下，系统可将其识别为场景已经达到完成，即使用户仍然可以在不使得游戏进一步前进的情况下无穷尽地在该副纸牌中循环。一旦场景被确定为已经达到完成，系统就可转移至步骤518。否则，系统转移至步骤516。在步骤516中，系统询问用户是否继续场景。如果用户希望继续，则系统在步骤510中恢复场景。否则，系统转移至步骤520。

如果在步骤518中场景未被成功地完成到解答状态，则系统可以在步骤520中将包括但不限于场景的当前数据状态的信息存储到解答数据库316。的确，各实施例还可存储用户从初始状态到当前状态所采取的中间状态。其他实施例可包括与用户在场景中的表现有关的统计数据作为所存储的数据，诸如到当前状态的状态转换的数量、所有用户中的在初始状态和当前状态之间进行的状态转换的最小数量、以及该数量的最大值、均值、中位数和方差。如同本文提及的其他数据，本技术的实施例可将该数据存储在服务数据库312中的他处或某一其他数据库中。

如果在步骤518中场景已被成功完成到解答状态，则系统转移到步骤524，其中该系统可存储包括初始状态和所需解答状态之间用户到达的的中间状态的信息。此外，该系统可将所存储的状态指定为可解以供将来尝试解答场景时参考。除了数据状态本身之外，系统还可使用解答数据库316来存储关于该解答的更多数据，包括与用户在场景中的表现有关的统计数据。这些统计数据可包括诸如以下数据：到解答状态的状态转换的数量、所有用户中的在初始状态和解答状态之间进行的状态转换的最小数量、以及该数量的最大值、均值、中位数和方差。从步骤524，系统转移到步骤528。

在步骤528中，服务器304询问用户(通过网络306、控制台300和显示器150)他或她是否希望尝试另一场景。如果用户的确希望尝试另一场景，则场景在步骤502重新开始。否则，场景终止。

图4和5阐述了用诸如已知可解初始数据状态、已知可解中间数据状态和关于已解和/或未解场景的其他统计数据来构建解答数据库316的示例。图6-8阐述解答数据库在一旦其包括上述数据中的至少某一些时的某些应用。

图6表示可用于向用户提出从已知可解数据状态解答场景的挑战的示例性方法600。在步骤602中，解答数据库316可以用任何数量的已知可解状态和/或其他信息来填充。这可以例如如上文参考图4和5所描述的那样实现。

在步骤604中，系统可以从解答数据库316中获取已知可解状态。然后，在步骤608中，系统可以在用户帐户记录310中检查是否之前已经向该用户呈现所选状态。在各实施例中，如果是，则系统可返回到步骤304并且循环继续直到找到对于用户是新的状态。如果状态对于用户是新的，则系统在步骤610中将该状态传递至用户。在其他实施例中，步骤608可被省略，并且用户的确可以不止一次地接收和尝试相同的状态。

在步骤610后，用户可通过在给定步骤610所提供的已知可解状态的情况下尝试解答场景来与系统交互。在步骤612中，服务器接收与通过用户尝试所到达的状态有关的数据。在步骤614中，系统然后可确定该场景是否被完成。如果所到达的状态不是结束状态，则系统到达步骤616。如果确定场景已经达到结束状态，则系统改为到达步骤618。

在步骤616中，用户可决定是否继续尝试解答所呈现的场景。如果用户决定继续，则系统返回到步骤612。否则，系统到达步骤620。

在步骤618中，系统可确定通过该场景处的用户尝试来到达的结束状态是否是所需解答状态。如果是，则系统移动到步骤620。本技术的替代实施例可添加用关于用户在到解答的路径中到达的中间状态的数据来更新解答数据库316的步骤。这一步骤可有助于系统对已知可解状态的知晓。如果用户到达的状态不是所需解答状态，则系统移至步骤624。

在步骤620中，系统可询问用户是否用新的初始状态数据来开始新场景。如果用户同意，则在步骤604呈现新场景。否则，场景终止。

另一方面，如果在步骤618中场景未被完成到所需解答状态，则在步骤624中，系统可询问用户是否尝试从步骤610中呈现的相同的已知可解状态对场景求解。如果用户同意，则系统移至步骤628，其中可将场景的状态重置为步骤610中呈现的相同状态。从那里，在该过程的步骤612用户可恢复对该场景求解的尝试。如果用户不同意，则系统移至步骤620且如上所述地继续。

在图6的实施例中，向用户提供已知可解初始状态。然而，在本技术的其他实施例中，可以向用户提供可以是或不是可解的初始状态，但在尝试解答场景期间的某一点，用户到达已知可解的中间状态。为此，图7表示本技术的另一示例性方法700。使用该示例性方法可能可以包括通过检查用户是否能够从这些初始状态到达已知可解中间状态来发现新的可解初始状态。在步骤701中，使用可能但不一定如针对方法600的步骤602描述的方法，可以用给定场景的任何数量的已知可解状态来填充解答数据库316。系统然后可继续至生成(步骤702)和提供(步骤704)场景的随机初始状态，分别基本如同方法400的步骤402和406。

在步骤710中，用户可以与系统交互以便在场景的中间状态之间移动。这些中间状态然后可被服务器304接收并且通过游戏记录314来存储。

在步骤711中，系统可对照诸如在步骤701中存储的那些状态之类的填充解答数据库316的已知可解状态来检查接收到的状态。如果找到匹配，则系统继续至步骤712，在该步骤系统可将迄今为止存储在游戏记录314中的状态移至解答数据库316中，从而将这些状态标记为可解。可任选地，系统还可告知用户他们已经到达已知从该点是可解的状态，并且可任选地进一步将从当前已知可解状态到实际所需解答状态的已知最少步数告知用户。本技术的其他实施例可使用户能够获悉关于从当前状态的已知解答的更多统计信息。

在步骤716中，系统可询问用户是否继续当前场景。如果用户希望继续，则场景在步骤710继续。否则，系统可移至步骤728。

如果在步骤711中当前中间状态不是已知可解的，则系统继续至步骤714，在该步骤可以确定经由用户决定获取的中间状态事实上是否是结束状态。如果所获取的状态不构成结束状态，则系统转移至步骤716。否则，系统转移至步骤718。

在步骤718中，服务器304可将从步骤714传递的状态与存储在服务数据库312中的已知解答状态进行对比。如果由此接收到的状态不是所需解答状态，则系统可通知用户场景未被成功解答，并且可以步骤728中提示用户他们是否想要开始新游戏或场景。

如果在步骤718中结束状态是所需解答状态，则在步骤720中，服务器304可以向解答数据库316查询在当前尝试之前是否已经标识和存储游戏记录314中的初始状态和中间状态。如果是，则系统移动到步骤728。如果否，则服务器304可将该初始状态数据或者唯一地生成该初始状态的种子数据存储在解答数据库316中。同样，系统可将唯一地标识先前未解答的中间状态的任何数据存储在解答数据库316中。本技术的其他实施例还可存储关于为了从初始状态到达所需解答状态而采取的中间状态的次序的信息。系统然后可转移至步骤728。

在步骤728中，系统询问用户是否要开始新场景。如果否，则过程700终止。如果是，则过程700在步骤702重新开始。

诸如参考图6和7描述的实施例利用可使用如例如参考图4和5描述的众包来构建的解答数据库316。然而，在其中使用解答数据库的图6和7的实施例中，解答数据库可以在标识新的已知解答状态时被继续扩充。因此，本技术的另一示例性实现是如图8所示的过程800。方法800的众多潜在应用之一可以是向用户提出用已知解答路径来快速完成场景的挑战，并沿路可能地收集关于新解答路径的数据。在步骤801中，可以通过使用先前用户尝试的结果、使用计算均值、使用其某种组合或使用某一其他方法来填充解答数据库316。

在用户参与时，在步骤802中服务器304可以从解答数据库316获取给定场景的已知可解状态。在步骤806中，服务器然后可以向用户呈现该状态以供求解，以及将标识该状态的数据存储到游戏记录314以发起和跟踪解答该场景的用户尝试。

在步骤810中，服务器可接收与用户到达的中间状态有关的数据。然后将该数据存储在游戏记录314中。

在步骤811中，系统可检查步骤810中的用户最近到达的状态是否是已知可解的或者如上定义的结束状态。如果既不是已知可解状态也不是结束状态，则该系统转移至步骤813。如果这些可能性中的任一个为真，则该系统转移至步骤814。

在步骤813中，场景尚未被完成，且当前状态不是已知可解的。由此，系统可将该状态存储在游戏记录314中，将其标记为可能的新可解状态，并警告用户他或她已偏离已知的解答路径。当这样做时，系统转移至步骤816。

在步骤814中，当前状态是已知可解的或者是结束状态。如果当前状态是结束状态，则系统转移至步骤818。否则，系统转移至步骤815。

在步骤815中，已知当前状态是可解状态。系统由此可确定用户可藉此到达所需解答状态的已知最小步数。为了计算该数量，系统可使用针对来自解答状态的最少已知交互数的计数函数、来自解答数据库316的数据或某一其他手段。系统然后可将该值传递给用户。在本技术的其他实施例中，用户可访问关于场景的已知可解数据状态的各种统计数据。这些统计数据可包括遇到过给定状态的先前用户的解答成功率，或者可能从当前状态到解答所采取的最大已知步数。在计算该数据时，系统将其中继给用户并转移至步骤816。

在步骤816中，系统可询问用户是否继续场景。如果用户同意继续，则系统返回到步骤810。否则，系统移至步骤828。

如果在步骤814中场景已经达到完成，则系统可以在步骤818中决定用户是否已经到达所需解答状态。如果是，则系统转移到步骤820。否则，系统转移到步骤828，并且在其他实施例中系统可采用服务数据库312来存储指示当前尝试所到达的部分或全部状态可导致结束状态的信息。

在步骤820中，用户已经到达场景的所需解答状态并且场景被认为是已解答的。系统然后可检查用户在对场景求解的过程中是否到达过先前不知道是可解的任何状态，诸如步骤813标记的那些状态。系统可以有可能通过检查存储在游戏记录314中的任何这样的状态是否已经被存储在解答数据库316中来执行上述操作。如果存在任何这样的新状态，则系统转移至步骤824。如果否，则系统转移到步骤828。

在步骤824中，在当前尝试之前或期间，系统不知道用户在对场景求解的过程达到过的一个或多个状态是可解的。系统由此可将这些状态或唯一地标识这些状态的数据添加到解答数据库316，由此将这些状态更新为已知可解状态。本技术的实施例还可包括关于用户所采取的从步骤806所提供的状态到所需解答状态的路径的数据。当这样做时，系统移至步骤828。

在步骤828中，系统可询问用户是否要再次尝试场景。如果用户指示希望再次尝试，则系统返回到步骤802。否则，场景终止。

本发明系统的前述详细描述是出于说明和描述的目的而提供的。这并不旨在穷举本发明系统或将本发明系统限于所公开的精确形式。鉴于上述教导，许多修改和变型都是可能的。选择所述实施例以最好地解释本发明系统的原理及其实践应用，从而允许本领域技术人员能够在各种实施例中并采用各种适于所构想的特定用途的修改来最好地利用本发明系统。本发明系统的范围旨在由所附权利要求书来定义。

Claims (10)

1.一种标识能被解答以到达将被求解的场景中的所需解答状态的一个或多个初始数据状态的子集的方法，所述方法包括：

(a)向用户集合提供初始数据状态的集合，所述初始数据状态的集合包括可解的一个或多个初始数据状态的子集；

(b)确定正被一个或多个用户解答至所述所需解答状态的所述场景的一个或多个实例；以及

(c)存储用于标识在所述步骤(b)中所述一个或多个用户已从其解答所述场景的一个或多个初始数据状态的子集的信息。

2.如权利要求1所述的方法，其特征在于，还包括随机生成所述步骤(a)中的所述初始数据状态的集合的步骤(g)。

3.如权利要求1所述的方法，其特征在于，还包括按程序生成所述步骤(a)中的所述初始数据状态的集合的步骤(h)。

4.如权利要求1所述的方法，其特征在于，将被求解的所述场景是计算机化的纸牌游戏，并且提供给所述用户集合的所述初始状态的集合是向所述用户集合显示的纸牌的初始状态。

5.一种从较大的数据状态集合中标识已知可解数据状态的方法，所述已知可解数据状态是用户能从其到达具有约束集的场景中的所需解答状态的那些数据状态，所述方法包括：

(a)将初始数据状态从服务器提供至用户控制台的集合以供所述用户控制台的用户从所述初始数据状态对所述场景求解；

(b)在所述用户对所述场景求解的尝试中接收与所述初始数据状态的用户交互的指示以生成中间数据状态；

(c)确定正被一个或多个用户解答至所述所需解答状态的所述场景的一个或多个实例；以及

(d)存储用于标识在所述步骤(c)中所述一个或多个用户已从其解答所述场景的已知可解数据状态的信息。

6.如权利要求5所述的方法，其特征在于，已知可解数据状态是被提供给客户机计算系统的初始数据状态。

7.如权利要求5所述的方法，其特征在于，已知可解数据状态是通过与初始数据状态的用户交互生成的中间数据状态。

8.如权利要求5所述的方法，其特征在于，还包括存储从所述已知可解数据状态到所述所需解答状态所花费的用户交互的数量的步骤。

9.一种具有计算机可执行指令的计算机可读介质，所述计算机可执行指令用于将处理器编程为执行一种从较大的初始数据状态集合中标识已知可解初始数据状态的方法，所述初始数据状态是计算机化的纸牌游戏中的向用户显示的纸牌的初始次序，并且所述已知可解初始数据状态是用户能成功地从其完成所述纸牌游戏至所需解答状态的初始纸牌排序，所述方法包括：

(a)生成纸牌的所述初始数据状态；

(b)将所述初始数据状态从服务器提供至用户控制台的集合以供所述用户控制台的用户从所述初始数据状态开始玩所述纸牌游戏；

(c)在用户玩所述纸牌游戏时接收与所述初始数据状态的用户交互的指示以生成中间数据状态；

(d)确定其中一个或多个用户成功地完成所述纸牌游戏至所述所需解答状态的一个或多个实例；以及

(e)存储用于标识在所述步骤(d)中所述纸牌游戏已成功从其完成至所述所需解答状态的已知可解初始数据状态的信息。

10.如权利要求9所述的计算机可读介质，其特征在于，还包括以下步骤：检查用于标识特定已知可解初始数据状态的信息是否存在于在所述步骤(e)中存储的所述信息的数据库中，并且不存储与已经被存储在所述数据库中的重复的已知可解初始状态有关的信息。