Complex problem-solving entertaining game, method, system in a distributed computing environment

Description

This application claims priority to Provisional Patent Application No. 60/799,490 filed on May 11, 2006.

BACKGROUND

This invention relates to computer-implemented problem-solving systems involving human agents and more specifically relates to interactive computer games in a distributed computing environment where game play has at least a dual purpose, namely to entertain the human player and to provide useful information to a client for solving the client's real-life problem or problems based on data derived from game play. An optional additional purpose of the described game play is to reward and/or compensate the human game player for skillful or persistent game play. Distributed computing environments for solving problems are known. One of the advantages of distributed computing environments for solving problems is the existence of a large number of agents engaged at any one time in the distributed computing environment. Simulation as a problem-solving technique is also known. U.S. Pat. No. 6,931,365, for example, is directed in part to a computer-implemented method and apparatus for the creation of a synthetic environment for analysis and simulation of a global industrial system where human players are aware that they are engaging in play targeted to simulate and study actual business environments. However, the applicant is not aware of prior art that is a complex problem-solving technique involving an interactive game in a distributed computing environment where players are not told and are not directly aware that the game problem presented is a metaphor (with entertainment value) for the game developer/client's real-life problem where the game client participated in the development of the game and desires to implement in real life solution(s) to the real-life problem informed by and derived from game play.

SUMMARY OF THE INVENTION

The applicant has invented a Client-delimited, player-driven method, system, and apparatus for obtaining information to facilitate identification of solutions to problems owned by a Client via an entertaining interactive computer game, developed by the Client and a Game Developer/Publisher entity, where the human game players are not cognizant of the actual real-life problem whose solution is facilitated via game play. The term Client as used herein refers to an entity that owns a real-life problem for which the entity seeks a solution or an entity that undertakes to solve a real-life problem. Per the disclosed invention, the interactive computer game comprises one or more metaphors. A ‘metaphor’ as the term is used herein refers to a symbolic representation of a Client's real-life problem or element or part of a Client's real-life problem. Per the preferred embodiment of the disclosed invention, the metaphor has an entertainment element such that the player is at least initially engaged in the metaphor for its entertainment value and such that the real-life problem or part of real-life problem is not readily discernible from the metaphor. Thus, a key aspect of the disclosed invention is the provision that the real-life problem to which the game is directed is not readily apparent to the game player. Thus, the game shall deliver both entertainment value to game players and utility (problem-solving) to a client who is not identified to the game player. The disclosed problem-solving method differs from a simulation in that a simulation attempts to mimic real-life conditions of a system or a problem as closely as possible

The disclosed invention is suited for a multitude of complex problems, including but not limited to business problems, scientific problems, the problem of fusion, and socio-economic problems involving a multitude of variables and interactions among variables. The disclosed invention is also suited to address complex problems requiring the input of many human agents from different disciplines.

As an illustration of a metaphor per the disclosed invention, suppose there is a game wherein a player causes an object such as a ball to advance on a path selected by the player among several possible “paths” proposed by the game. For example, there may be one or more paths whereby the ball moves fast, one or more paths where the ball moves more slowly, and one or more paths where the ball does not move at all. The client who participated in the development of the game actually intends the ball to represent a real life object such as a unit of freight and the available paths are representative of various modes of transportation available for the unit of freight. The real-life problem being solved involves optimization of a cost of transportation function for a unit of freight. The objective of the game, i.e., the “game problem,” may be to challenge the player to advance the ball to a pre-set destination within some defined game constraint, perhaps a unit of time. Different players will select different paths based on personal attributes of the player, such as but not limited to the player's inferencing skills, level of focused attention at the time of game play, visual acuity, mathematical skills, and the player's general approach to problem-solving. The client benefits from game play by a large number of players having different skills, interests, and aptitudes.

The disclosed invention comprises a metaphorical game. It is different from a simulation, a known method in the prior art, in that a simulation implies a direct relationship to a referring problem or system. The constraints of a simulation determine the system being solved. For example, if the constraints for a computer flight simulator are modified so that the airplane of the simulator operates more like an automobile, the simulation is no longer a flight simulator—it would be instead a driving simulator. With the disclosed metaphorical game, wherein the apparent metaphor is a dragon egg and the apparent game object is to deliver the dragon egg to a safe hole, the pre-set constraints embedded into the metaphor and other game elements may be modified, even the “referring problem” may be altered to be an altogether different problem, and still the game involves manipulating a “dragon egg” on a path toward a “safe hole.” Unlike in a simulation, in the disclosed metaphorical game, at the point of game play the referring problem is directly and openly disassociated from the referring problem. The resulting game embodiment is independent of the referring problem until such time that the information from game play is extrapolated back to the referring problem.

One of the reasons that metaphors are useful is that they help to minimize or eliminate biases, paradigms, or the need for prerequisite expertise that are inherent in human approaches to problem-solving and which inhibit the robustness of problem-solving. By helping to minimize or eliminate such biases, paradigms or the need for prerequisite expertise in problem-solving, the disclosed system and method enable fresh approaches to solving complex problems. An example of a problem-solving bias is the phenomenon of ‘group-think’ and the ‘not-invented here syndrome.’ Another bias is the contextual bias which exists whenever a human agent undertakes the solution of a problem within his/her area of expertise or areas of special knowledge. Within a given profession there are established norms for attacking a given problem. Thus, a professional in the field will normally adopt norms of the profession in addressing such problems. That professional may, but not necessarily so, tend to utilize problem-solving norms of his/her profession when confronted with problems outside of his/her profession. The professional is more likely to adopt such norms provided he/she is able to recognize commonalities between problems of his her profession and the presented problem. The disclosed invention exploits the natural tendency of human agents to cross-pollinate problem-solving know-how from problems within the agent's area of expertise to problems outside of the agent's area of expertise. This cross-pollination enables paradigm shifting and fresh problem-solving approaches to complex problems.

Thus, a game player who might, for example, be an expert in aerodynamics may or may not automatically adopt norms for solving aerodynamic problems when engaged in play of an entertaining game whose game problem is to advance an object to a defined destination. If the game player sees (via logic, inferencing, inductive, or deductive reasoning) some commonality between the game problem and problems he/she has addressed within his/her area of expertise, he/she may be more likely to adopt the problem-solving norms of his profession to the game problem. This is so whether or not the game were actually directed (unbeknownst to the player) to a client's real-life problem in aerodynamic design.

Another type of bias in problem-solving is that human agents naturally are averse to tackling complex problems and may even shun them because solving complex problems can be an overwhelming task. Human agents can have an aversion to solving complex problems that, on the surface, appear to be beyond the agents' area of expertise. The disclosed invention eliminates this type of bias by breaking down and disguising a complex problem as one or more smaller, more manageable problems or game metaphors.

The Client, who owns the real life problem, aids the problem-solving process per the disclosed invention by breaking down the real-life complex problem into one or more manageable smaller problems which are then each translated into a game metaphor. For this important step of the disclosed invention, the Client may engage the services of both employees, consultants, industry experts, other subject matter experts, and game developers. An unlimited number of metaphors are possible and the number of metaphors is limited only by the Client's and Game Developer's level of creativity.

During game development, the Client determines how much context teaching, if any at all, is appropriate for any given game. Thus, the Client determines how much context-related information is to be disclosed to the Player. Because problem-solving biases can be introduced in the context teaching step (i.e., biases that may reveal to the game player the true identity of the Client's real-life problem universe), a Client may choose to minimize context teaching to only such context that would be required to explain the game universe.

Per the preferred embodiment game players are not told that they are actually helping a client solve a real-life problem (i.e., game players are not aware of the exact nature of the real-life problem linked to the game). Per an alternative embodiment of the disclosed invention, game players may be informed before starting game play that they are actually helping a Client solve a real-life problem and said real-life problem may or may not be identified.

Via the act of playing the disclosed game, Players generate information or derived knowledge which is compiled (in accordance with certain Client pre-defined rules) by a data compiler, then presented to the Client for review and evaluation. The Client ultimately determines whether the derived information is useful to solve the Client's real-life problems. Thus, the Client ultimately decides whether to implement in real life any given game-derived or game-suggested solution in order to validate such solution. If the game-proposed or game-suggested solution cannot be validated in real life (i.e., its implementation does not result in an actual solution the Client's real-life problem), then the Client may modify the game to include new or revised metaphors, design a new game, or revisit the original analysis of the Client's real-life problem to break it down into new or different sub-problems.

Per the preferred embodiment, the game is a multi-player competitive iterative game. Per an alternative embodiment, the game is a single-player iterative game. The disclosed problem-solving system may comprise more than one Game each addressing an aspect of a Client's single real-life problem.

Per the preferred embodiment of the disclosed problem-solving system, players independently select a game to play from a number of available games published by the Game Developer/Publisher on behalf of a Client. Players freely select a game to play based on personal factors such as the player's mood, disposition, interest, and/or time available for game play. Alternatively, game players may freely select a game based on Client-designed incentives such as compensation given for the game play. Compensation may be in the form of real awards, such as money and/or prizes, or “virtual awards” (i.e., player “points” resembling frequent flyer miles or similar point award systems). Compensation data may be collected by the Client and linked to game players to aid the Client in “profiling” game players possessing certain attributes such as aptitudes for a solving a given type of metaphor.

Alternatively, players may be “invited” to play a game based on the players' special knowledge, skills, and experience or because a given player is recognized by the Client as a “preferred player” since his/her game-derived solutions were previously validated by the Client. Additionally, a player may be recognized by the Client as a “preferred player” because that player has accumulated many real awards or virtual awards (points earned in game play). Per an alternative embodiment, players may compete for the privilege to play a game based on a contest designed by the Client. In the latter instance, the Client wishes to be selective in the skills, background, and qualifications of players. Per one embodiment, the client targets a player group comprising individuals possessing one or more of the following attributes: specific skills, knowledge, training, education, work experience, travel experience, awards/achievements, and/or interests. The Client targets a player group in order to help maximize the quality of information derivable from game play as well as the efficiency of deriving useful information from game play. Per the described embodiment, the player group may or may not be aware that it is targeted for play of a particular game.

One embodiment of the disclosed system has the following interfaces: Player Computer—Game/Game Server; Game Server-Data Compiler/Data Compiler Server, and Client Computer-Data Compiler/Data Compiler Server. In addition, there may be an interface between the Client Computer and the Game whereby the Client is able to access the Game to directly observe and/or manipulate Game elements off-line or in real time (e.g., Client may transmit real-time text or audiovisual “messages,” including, but not limited to, rewards earned announcements, to the human game player based on what is happening at any given point in the actual game play). The disclosed game may be launched in a hosted, web-based distributed computing environment or alternatively via an Intranet localized to an entity, not limited to the client entity.

Another aspect of the disclosed invention is the opportunity it presents for identification of a pool of human experts, herein called “preferred players,' whose game play either consistently or frequently results in information or problem solutions useful to the Client. This is an aspect of the learning function feature of the disclosed invention that is made possible via the game play data/player identification data elements capture step of the disclosed system. Thus, the disclosed invention is also directed to a human expert identification system.

DRAWINGS

FIG. 1 is an entity-relationship diagram of the disclosed problem-solving system;

FIG. 2 is a block diagram of the preferred embodiment of the disclosed problem-solving system;

FIG. 3 is a block diagram of the process steps in the preferred embodiment of the disclosed problem-solving method.

FIG. 4 is a detailed block diagram of the disclosed problem-solving system

FIG. 5 depicts a sample user interface screen for one embodiment of a game per the disclosed invention

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts key entities and their interfaces or linkages per the preferred embodiment of the disclosed problem-solving system. The key entities are as follows: Client (also referred to herein as Problem Owner) 100, Game Developer/Publisher 200, human Game Players 300, and the Game 400.

FIG. 2 is a block diagram of the preferred embodiment of the disclosed complex problem-solving system. The system comprises a Client 100, a Game Developer/Publisher 200, an interactive computer Game 400 residing on a Game Server 900, and at least one human Player 300. The Client 100 owns a Problem 500 and defines or casts the Problem 500 (independently or with the help of experts) as an interactive computer game. The Game Developer/Publisher 200 cooperates with the Client 100 to design one or more Games 400 which provided entertainment to the Player 300 and utility to the Client 100. The Game 400 resides on a Game Server 900 and human Players 300 access the Game 400 from Player Computer 800 to play the Game 400. A Data Compiler 700 receives and compiles information or data from game play. The Client 100 and/or Game Developer/Publisher 200 access compiled data via the interface of the Data Compiler 700. The Client 100 reviews the data to determine whether a workable solution for the Problem 500 has been identified. If the data does not yield a workable solution, then the Client 100 and the Game Developer/Publisher 200 make changes to the Game 400 and design or develop a new Game 400 to address the Problem 500.

FIG. 3 is a block diagram of steps in the disclosed problem solving method. The Problem Definition Step 10 comprises several steps. A Client identifies a real-life problem to solve. The Client, with the aid of internal and third party resources, which may or may not include a Game Developer/Publisher, defines the problem in terms of one or more sub-problems. The sub-problems may, but do not need to be defined in terms of elements and relationships between elements. In the Game Development Step 20, a Game Developer/Publisher, aided by the Client, develops an entertaining computer game suitable for one or more players wherein each sub-problem is recast as one or more game metaphors such that the Client's real-life problem is not readily discerned from the game metaphors. As part of the Game Development Step 20, game physics algorithms or GPA's are developed as well as routines for the capture and analysis of data collected during game play. Also as part of the Game Development Step 20, decisions are made with respect to how much context teaching will be provided to players as a precursor to game play to educate players about the “game universe.” In the Game Launch Step 30, the game and associated data mining modules are placed on a Game Server to make the game accessible to players on-line in a distributed computing environment. Also per the Game Launch Step 30, the Client may or may not implement contests or promotions targeting to attract a specific type of player or specific group of players. During Game Play 40, one or more players engage in game play and data from game play is captured and stored on the Game Server. Also during Game Play 40, players may or may not receive awards or incentives for their game play. In the Game-Derived Data Compilation Step 50, data captured from game play are compiled and formatted per modules developed in the Game Development Step 20. In the Game-Derived Data Evaluation Step 60, the Client accesses the data captured from game play (via the Client Computer-Data Compiler Interface) and analyzes the data. Per the Solution Validation Step 70, from the pool of game-proposed, game-derived solutions, the Client selects one or more solutions to implement in real-life for purposes of validation. Per the Closure Step 80, the Client removes the game from the distributed computing environment and may or may not distribute awards and incentives to players at that time. Also per the Closure Step 80, the Client evaluates the player-identification data gathered during game play to identify one or more promising players to be placed in a pool of preferred players for future game play. Per Step 81, the Client asks the question whether or not the Client's problem has been adequately solved and/or has resulted in a viable solution to the Client's problem. If the answer to that question is no, then, per the Game Modification/New Game Development Step 90, the Client and the Game Developer/Publisher tweak (e.g., modify metaphors or create new metaphors) the previously-launched game and re-launch the modified game, or alternatively develop a new game with a new game universe.

FIG. 4 is a detailed block diagram of the disclosed problem-solving system. The discussion below referencing FIG. 4 illustrates one embodiment of the disclosed invention and is offered for illustration purposes only and not by way of limitation.

100 Problem Owner

The Problem Owner (or Client entity) owns a real-life problem for which he/it seeks a solution using the disclosed invention.

500 Problem Disclosure

Out of desire to find a solution to a real-life complex problem, Problem Owner/Client 100 discloses owned problem to Game Developer/Publisher 200. The envisioned Problem Disclosure Step 500 might be transacted as follows:

Problem Owner/Client 100

• • “My company has a problem. We manufacture high-grade sand from recycled glass. Our research is showing that demand for our product meets our capacity to produce it. Our shareholders are demanding higher profits, but we are unable to find the best method of distribution for our product. Transportation costs are killing us. On top of this, because demand is seasonal, we aren't operating our manufacturing plant year round, and when we have demand in the summer, we can't produce enough. Storage is more expensive than shutting down production in the off-peak season, but in peak we can't produce enough to meet demand.”

Game Developer/Publisher 200

• • “I think we might be able to help. I'm sure that you have already tried the standard distribution models. Why do you think that this problem you have with distribution can't be solved using standard maximization models?”

Problem Owner/Client 100

• • “Sand is not an easily packaged item. It is heave and requires a large amount of space. It is a specialty product and has national demand, but to get it from our manufacturing plant in New Jersey to prospective clients in Southern California is too expensive. Also, there are seasonal constraints. Our production can be year-round, but our demand is typically in the warmer months. There is not adequate space to store it locally, and we really don't want to have to ship the product twice.

Game Developer 200

• • “Okay. So, you have a lot of variables to consider. From what I'm hearing, it sounds like your problem might just work well with our method of finding solutions. I don't know if there is a perfect, zero-sum solution, but I am sure we can provide you with some helpful insights into your distribution problem. I will need to get from you a specific request stating the problem you need solved, and any information you have regarding solutions you have tried in the past or are currently considering.

Problem Owner 100

• • “Okay, I'll talk with the Board. How exactly do you intend to find a solution to this problem?”

Game Developer 200

• • “In short, we simply convert your problem into a game.”

Problem Owner 100

• • “A simulation?”

Game Developer 200

• • “No. Simulations require a degree of pre-requisite knowledge for game players to interact, but by using the information you provide us, along with research we will do in-house, we convert your problem into metaphors that most people can understand. These metaphors are then used to make a game that most people can play . . . and in the process, solve your problem.”

Problem Owner 100

• • “Interesting. I will be in touch after I talk to the Board.”

200 Game Developer

An individual or entity facilitating the use of the envisioned art, who takes a problem as presented by the Problem Owner 100, converts it into a metaphorical game, presents the game to Game Player(s) 300 in a distributed computing environment, and compiles the results into a solution set for delivery to the Problem Owner/Client.

10/90 Problem Defined/Delimited

The Problem Defined/Delimited Step 10/90 is where human experts on the problem are consulted. Game Developer 200 could moderate a group discussion in this step to clarify the problem and ease its transition to the most appropriate Metaphor 600. In the group discussion to define/delimit problem there may be representatives of the Problem Owner 100, Game Developer 200, Game Player(s) 300, and other human experts who might help to distill the problem to its essential components.

A common heuristic model for such a group discussion is as follows:

• I. Define and Limit
  • a. Problem Stated As Concisely as Possible
    • i. Set of Limitations
• II. Analysis
  • a. Is it a problem?
  • b. What is the problem . . . restated?
  • c. What are the causes of the problem?
  • d. What is the history of the problem?
• III. Criteria/Standards With Which To Evaluate Possible Solutions
• IV. Criteria/Formulas Required To Be Included In Game Development 20/90

The envisioned Problem Defined/Delimited Step 10/90 would produce a document referencing the heuristic procedure outlined (above), and said document would look like this:

• I. Define and Limit
  • a. Given Problem: How can Problem Owner/Client maximize distribution of its product (sand) while minimizing transportation and storage costs.
    • i. Set of Limitations
      • 1. Product distribution limited to United States
      • 2. Product will be manufactured year-round
      • 3. Distribution channels limited to truck, rail and barge
• II. Analysis
  • b. (Is it a problem?) Yes. There is a problem with distribution. The suggestion was made to use a simple distribution optimization model, but Problem Owner/Client 100 wanted something that would yield more dynamic results than would be available in a standard static mathematical formula.
  • c. (What is the problem . . . restated?) It is costly to distribute and/store a product.
  • d. What are the causes of the problem?
    • i. Product is not easily packaged
    • ii. Demand for product is high, but seasonally sporadic
    • iii. The cost of storage for product is high
  • e. (What is the history of the problem?) When the product was initially marketed, demand was local, and now, to meet sales requirements demanded by shareholders, the product must be marketed/distributed to a broader customer base, thus increasing transportation costs.
• III. Criteria/Standards With Which To Evaluate Possible Solutions
  • a. Must be profitable
  • b. Must be practical
  • c. Must be independent of manufacturing constraints
  • d. Must be able to implement immediately without investment in infrastructure or real estate.
• IV Criteria/Formulas Required To Be Included In Game Development 20/90
  • a. Production capacity of manufacturing plant
  • b. Cost per mile to distribute product by truck rail and barge.
    • i. Truck Distribution Cost (1 Truckload)=0.35 times the number of miles
    • ii. Rail Distribution Cost (1 Rail carload)=$0.15 times the number of miles
    • iii. Barge Distribution Cost (1 Bargeload)=$0.07 times the number of nautical miles
  • c. Storage cost
    • i. Storage (1 truckload)=$15 times the number of days
  • d. Transportation time tables for transportation by truck, rail and barge
  • e. Projected regions of highest demand.

600 Metaphor

Using the information derived from the Problem Definition Step 10/90, at least one metaphor will be adopted to represent the problem. Certain criteria should be considered in choosing an appropriate metaphor.

• • I. The metaphor should be simple enough for-a game playing community to intuitively understand.
  • II. The metaphor should match well with the problem.
    • a. All formulas should correspond with game elements.
  • III. The metaphor should be interesting in theme and content so to have an entertainment value.

The Metaphor Step 600 is a creative step wherein the Problem Owner/Client's real-life problem with all of its complexities is distilled into its component parts and matched to an appropriate metaphor. Game players are not told how the final metaphor object(s) were developed, nor the functional purpose of the metaphor(s). The design objective is that at the point of game play, the metaphor becomes primary in relation to the referent problem thus creating an interactive environment where human game players interact with metaphors in a computer environment free from biases typically associated with a simulation problem-solving technique. The Metaphor Step might occur as follows:

Creative Team Member A

• • “Okay. So we are working with moving things over a distance. Any suggestions?”

Creative Team Member B

• • “How about a ball? It is a simple machine that most people are familiar with. Maybe moving a ball along a track?”

Creative Team Member A

• • “I like the ball idea, but how can we incorporate the different speeds?”

Creative Team Member B

• • “Maybe different sized balls?”

Creative Team Member A

• • “Maybe . . . but I think it would be easier to have one standard size of ball. If we made all of the ball sizes equal to, let's say, one truckload, it would really make the coding of this much easier, and I don't think we would lose any of the problem by this simple restatement.”

Creative Team Member B

• • “I see what you are saying. So if we don't change the ball, maybe we can change the track that the ball is traveling on. Fast track could be truck routes on the highway. Slow track could be by barge.”

Creative Team Member A

• • “I like it. Also, we can make the tracks similar in scale to roads, rails and water routes already in use. But is playing with a ball on a track really that interesting?”

Creative Team Member B

• • “Not really. What is like a ball?”

Creative Team Member A

• • “Remember those illustrations with crazy inventions that Rube Goldberg did? It seems like there was always something with an egg rolling down a ramp. How about an egg instead of a ball?”

Creative Team Member B

• • “I like that! But the shape is kind of funny and might be distracting is there something like an egg, but not shaped so oblong?”

Creative Team Member A

• • “A lizard egg, maybe?”

Creative Team Member B

• • “Or a dragon egg?!!”

Creative Team Member A

• • “Yeah! A dragon lays eggs while she is sleeping If the eggs are put somewhere safe soon, they begin to make noise. If too much noise is made, the dragon wakes up and the player loses the game.

Creative Team Member B

• • “There could be a cave, with caverns and an underground river. The object of the game can be simply to help put away as many dragon eggs as possible.”

Creative Team Member A

• • “And since we don't really know what the destinations will be, we can use the information we have to create random “safe holes” adjacent to one of the pre-existing routes. We can really sink our teeth into the interface, too. We can use lots of animation and sound. That noise idea was brilliant.”

Creative Team Member B

• • “Dragon eggs. I think we have a metaphor.”

20/90 Game Development

Using the Metaphor 600 and the corresponding formula-matched elements, a game is designed. The game also requires built-in data gathering and transmission capabilities.

Development Team Leader

• • “Okay. We have the formulas and a general game design. Let's put this thing together. We need artwork for the different elements. Any suggestions for a platform?”

Development Team Member

• • “I was thinking a Flash . . . . Something Shockwave maybe?”

Development Team Leader

• • “I was thinking that, as well.”

Development Team Member

• • “Well, we have to create a database back end. For now we should just keep it in Perl. We can have the variables store game play information and upload automatically to the database.”

Development Team Leader

• • “Okay . . . Let's get to work. Let's get the design schematics and start putting this thing together.”
    (Definitions: Adobe® Flash, or simply Flash, refers to both the Adobe Flash Player, and to the Adobe Flash Professional multimedia authoring program. Adobe Flash Professional is used to create content for the Adobe Engagement Platform (such as web applications, games and movies, and content for mobile phones and other embedded devices). The Flash Player, developed and distributed by Adobe Systems, is a client application available in most common web browsers. It features support for vector and raster graphics, a scripting language called ActionScript and bi-directional streaming of audio and video. (source: http://www.Wikipedia.org). ActionScript is a scripting language based on ECMAScript, primarily used to develop software for the Adobe Flash. Applications developed using Adobe Flash or Adobe Flex will often use ActionScript for runtime manipulation of data and content. Other platforms, such as ColdFusion also support scripting with-the ActionScript language. (source: http://www.Wikipedia.org)
  • Perl (an open source software) is widely favored for database applications. Its text handling facilities are good for generating SQL queries; arrays, hashes and automatic memory management make it easy to collect and process the returned data.

Sample Design Schematic: ©Levi Gwaltney

Metaphor	Name	Representation	Variable	Function
	“Sleeping	Manufacturing	NONE	This metaphor
	Dragon”	Plant		is thematic in
				function.
	“Dirt Road”	Distribution	$TCK	(0.35 times the
		by Truck		number of
				miles)/truckload)
				Travel Velocity
				($TCK)
	“Fancy	Distribution	$TRN	$0.15 times the
	Road”	by Railcar		number of miles
				Travel Velocity
				($TRN)
	“Waterway”	Distribution	$TUG	$0.07 times the
		by Barge		number of nautical
				miles
				Travel Velocity
				($TUG)
	“Dragon Egg”	One Unit of	Static	This is the object to
		Product	(Not Variable)	be manipulated
				during game play.
	“Safe Hole”	Product	Random	The “Safe Hole”
		Distribution		appears at random
		Destination		locations on the
				game map, and
				players have to
				choose the most
				efficient route.
	“Pointer”	Player	Player	Method by which
		Interface	Controlled	game player
				executes decisions.
	“Snooze-O-	Relative cost	$SNZ	If $Snz =< 0 Then
	Meter”	for		dragon wakes up
		Transporting		and player loses.
		Product.		$Snz = $Snz-(cost
				factor) based on
				distance and length
				of time “Dragon
				Egg is our of “Save
				Hole”.
	“The Clock”	Length of	$TIM	Storage variable for
		Time A Player		player and game
		is Able to Play		play evaluation.
		Within the		Also . . . important
		Constraints of		interface element
		the Game		adding to challenge
				of game and
				playability.
	“Egg Counter”	Number of	$CNT	Storage variable for
		Eggs reaching		player and game
		“Safe Hole”		play evaluation.
				Also . . . important
				interface element
				adding to challenge
				of game and
				playability.

400 The Game

The product of Game Development Step 20/90, integrating all aspects of game play: Game play Interface 40 and Data Input 900.

65 Game Marketing

Using known channels of persuasion and information gathered from the Player Data 61, Game Player(s) 300 is invited to play The Game 400.

300 Game Players

Individuals or groups of individuals who play The Game 400 for enjoyment derived from The Game 400, marketing factors from Game Marketing Step 65, and rewards earned in the Player Reward Step 64. Through game play, the Game Player(s) 300 solve the real problem owned by Problem Owner 100. The Game Player(s) 300 may or may not be aware of the real problem owned by Problem Owner 100.

Game play Interface

The Game play Interface Step 40 is the part of The Game 400 that engages the Game Player(s) 300, accepting input from Game Player(s) 300 and supplying engaging action to Game Player(s) 300. The Game Player(s) 300 use a mouse to manipulate a pointer to affect game play in The Game 400. This interface between Game 400 and the Game Player(s) 300 is vital, as The Game 400 does not act to solve the problem without guidance from the Game Player(s) 300. The Game Player(s) make their choices in Game 400 and those choices are recorded in variables that are then uploaded from Game 400 to Data Compilation/Storage 700 through the Data Input Step 900. Also, the Game 400 returns information and stimulus to the Game Player(s) 300.

900 Data Input

The Data Input Step 900 is where data are collected from The Game 400 and transmitted to Data Storage 700. This step is facilitated by computer code that uploads relevant variable values to a central server that acts in the capacity of Data Compilation/Storage 700.

700 Data Compilation/Storage

Data Compilation/Storage 700 is where game play data are collected and organized on a central server computer. Data received through the Data Input Step 900 are saved into a database file using a standard, comma-delimited, text data file. Each iteration of Game 400 generates another entry to the data file. Within each game-level data file is a step-level data file. The data hierarchy may be as follows:

Game-Level Data: At the beginning of each entry within the data file are the Game-Level Data. The data are aggregate in terms of the game iteration played.

• • I. $PLAYERNAME—This variable is the name information for the Game Player(s) 300 for each iteration of the game played.
  • II. $PLAYERINFO—This variable is other identifying information for the Game Player(s) 300 for each iteration of the game played.
  • III. $TIM—This variable is the aggregate time spent playing a particular iteration
  • IV. $CNT—This variable is the number of “Dragon Eggs” safely placed during game play by the particular game player.
  • V. $HOLELOC—This variable records all locations of “Safe Holes” placed during the game
  • VI. $HOLETIME—This variable records the times at which new “Safe Holes” are created

Step-Level Data: Following the Game-Level Data, data are saved for each step taken during game play. In the case of the specific game embodiment presented herein, each step is demarcated by each new “Dragon Egg” introduced to the Game Player 300, and, for each “Dragon Egg”, actions taken by Game Player 300 is recorded. This data is specific and listed as a subset within each entry into the data file.

• • VII. $EGGNUMBER—This variable identifies for which “Dragon Egg” data step-level data is being stored
  • VIII. $TCK—This variable records the length of time in which the “Dragon Egg” spent on the “Dirt Road”
  • IX. $TRN—This variable records the length of time in which the “Dragon Egg” spent on the “Fancy Road”
  • X. $TUG—Th$TUG—This variable records the length of time in which the “Dragon Egg” spent on the “Waterway”
  • XI. $SNZCOST—This variable records the amount of “noise” generated by a particular “Dragon Egg”.
    All data may be stored sequentially in the text data file with each variable separated by a comma, and each entry separated by a carriage return, as follows:
  • $PLAYERNAME, $PLAYERINFO, $TIM, $CNT, $HOLELOC, $HOLETIME, $EGGNUMBER, $TCK, $TRN, $TUG, $SNZCOST

The name of the file into which all information is saved is “GAMEDATA.TXT”.

70/80 Solution Validation/Closure

Game play data are compiled and organized for final presentation to Problem Owner 100. Per the Solution Validation/Closure Step 70/80, all relevant information is compiled to be used in creating the Solution Document 1000. Validation/Closure Step 70/80. If “NO,” the results are presented to the Game Developer 200 to begin the design process anew. Revisiting the criteria for solution as determined in the Problem Defined/Delimited Step 10/90, the solutions offered must meet the following criteria:

Criteria/Standards With Which To Evaluate Possible Solutions:

• • I. Must be profitable
  • II. Must be practical
  • III. Must be independent of manufacturing constraints
  • IV Must be able to implement immediately without investment in infrastructure or real estate.

1000 Solution Document

Document created to present findings to Problem Owner 100. Once created, Solution Document is presented to Problem Owner in fulfillment of agreement made in Problem Disclosure Step 500.

61 Data Output

Data Output 61 is data from Data Compilation/Storage 700 showing how well Game Player(s) 300 performed while playing The Game 400. Player-specific information is loaded from Data Compilation/Storage 700 by porting the “GAMEDATA.TXT” data file into FileMaker, or some other commercially-available database software.

62 Player Evaluation

Once the data from Data Compilation/Storage 700 (GAMEDATA.TXT) have been imported to a commercially available database software package as indicated in Data Output (Player) Step 61. Data can be sorted by any number of criteria. In the case of the specific game embodiment presented herein, three Game Players 300 with the highest value of time playing a particular iteration of a game ($TIM), and 3 Game Players 300 the highest number of “Dragon Eggs” safely placed ($CNT) may receive a monetary prize.

63 Play Warrants Reward? (Y/N)

This decision step determines whether a reward will be given to Game Player(s) 300. If “YES”, the process proceeds to the Player Reward Step 64. If “NO”, the process proceeds to the Game Marketing Step 65 to help increase interest in additional and new game play. In the case of the specific game embodiment presented herein, player information might be sorted in descending order from the highest to the lowest. So, for example, the three highest scoring Game Players would be eligible to receive a monetary prize for their successful game play. All other Game Player(s) 300 would receive no prize; however, information would be forwarded to Game Marketing 65 to help maintain in the creation and perpetuation of the Game Marketing Step 65.

64 Player Reward

If a reward is warranted according to criteria defined in Player Evaluation Step 62, reward will be given to Game Player(s) 300. In the case of the specific game embodiment presented herein, the three Game Players 300 who played for the longest period of time during a particular iteration of a game (the three with the highest $TIM values) would receive a monetary prize, as would the three Game Players who played a particular iteration of a game and safely placed the most “Dragon Eggs” into a “Safe Hole” (the three with the highest $CNT values).

60 Data Output (Game Play)

The Data Output (Game play) Step 60 is where data from Data Compilation/Storage 700 are matched to the criteria established for solution to the problem as defined in the Problem Defined/Delimited Step 10/90. Data Output (Game play) 60 is data from Data Compilation/Storage 700 showing what happened during each iteration of game play of The Game 400. Game play-specific information is loaded from Data Compilation/Storage 700 by porting the “GAMEDATA.TXT” data file into FileMaker, or some other commercially available database software. Once ported, all game play information can be sorted and examined based on any set of relevant criteria. In the case of the specific game embodiment, data can be examined to determine the correlation between high playing times ($TIM) and specific game playing strategies. By using data mining, sorting and statistical analysis, answers can be derived from the data regarding, but not limited to, the following questions:

• • I. Among the highest $TIM values, was there a common strategy in game play?
    • a. What was it?
    • b. How do these strategies translate from metaphor back into the original problem?
  • II. Among the highest $CNT values, was there a common strategy in game play?
    • a. What was it?
    • b. How do these strategies translate from metaphor back into the original problem?

For Example:

• • Game Player(s) 300 who consistently recorded high $TIM and high $CNT values also exhibited higher $TUG values. This, would indicate that these players preferred moving “Dragon Eggs” by choosing the “Waterway” route. Upon closer examination of the data, Game Player(s) 300 demonstrated, through game play of The Game 400, that by moving “Dragon Eggs” via the waterway minimized the cost of storing “Dragon Eggs” by placing them on the “Waterway” route. While the “Waterway” route took much more time, but in anticipating distant “Safe Holes”, Game Player(s) were able to place their! “Dragon Eggs” on the “Waterway” and simultaneously store the “Dragon Eggs” while moving them, albeit slowly, toward distant destinations at a minimal cost. Roughly translated in relation to the real problem, Problem Owner/Client could ship its product by barge in the slower off-season to California. The time it would take for a barge of sand to reach California via the Panama Canal could take up to 2 months. The cost would be less than if it were transported by rail, and it alleviates the need to store the sand for that two-month period that it is in transit.

81 Acceptable Solution? (Y/N)

Does the Data Output 60 meet the criteria for solution set forth in the Problem Defined/Delimited Step 10/90. If “YES”, the process proceeds to the Solution Validation/Closure Step 70/80. If “NO”, the results are presented to the Game Developer 200 to begin the design process anew.

FIG. 5 depicts a sample user interface computer screen for the game embodiment described herein for the “Dragon Egg” metaphor.