Instruction-Driven Game Engine: A Poker Case Study

TL;DR

The initial progress lies in developing an IDGE for Poker, which not only supports a wide range of poker variants but also allows for highly individualized new poker games through natural language inputs.

Abstract

The Instruction-Driven Game Engine (IDGE) project aims to democratize game development by enabling a large language model (LLM) to follow free-form game descriptions and generate game-play processes. The IDGE allows users to create games simply by natural language instructions, which significantly lowers the barrier for game development. We approach the learning process for IDGEs as a Next State Prediction task, wherein the model autoregressively predicts the game states given player actions. The computation of game states must be precise; otherwise, slight errors could corrupt the game-play experience. This is challenging because of the gap between stability and diversity. To address this, we train the IDGE in a curriculum manner that progressively increases its exposure to complex scenarios. Our initial progress lies in developing an IDGE for Poker, which not only supports a wide range of poker variants but also allows for highly individualized new poker games through natural language inputs. This work lays the groundwork for future advancements in transforming how games are created and played.

Figures (4)

• Figure 1: 1: Players were tired of the game's protagonist models. 2, 3: Developers thus created a new mode with dual protagonists. Players still didn't buy it, while they didn't know how to develop games. 4: There were irreconcilable divides between players and developers. 5, 6: Till the advent of the IDGE, it can read the players' mind and let them experience the games immediately.
• Figure 2: Game-play samples for next state prediction. In the lower half, we illustrate the state prediction circle using NSP. The left side is the input text for the engine from a global view, including all parts that are visible to players as well as those that are not. The right side is the diagram of the game from different players' views.
• Figure 3: DSP. In the shuffling case, the IDGE calls "shuffle", which is a predefined core function. In the dealing case, it defines a new "deal" function to deal a number of cards to each player one by one. We use a code interpreter to merge the input state and the output code to obtain the next state.
• Figure 4: System demonstration of our poker IDGE, developed based on Unity.