Applications of AI Literacy to GenAI-Assisted Game Development

Slide 1: Applications of AI literacy to game development

This guest lecture connects a question from discrete mathematics teaching with software development: how do we examine an AI system’s contribution closely enough to decide whether to use it? The examples come from browser tools and games I built.

Slide 2: The route through the lecture

We begin with the projects and their design constraints, then examine procedures for checking chatbot reasoning. We apply those procedures to coding-agent work before looking at multiplayer simulation and game AI.

Slide 3: Why these projects belong together

The research tools and games gave me concrete cases to inspect. A working interface can hide a mistaken assumption, just as a plausible proof can hide an invalid step. In both settings, I want a check that makes the problem specific.

Slide 4: Working with teachers and developers

The lecture describes a six-week ClassChat development setting. Developers spent the first two weeks learning the system; teachers then joined them to build classroom tools. The timeline records that project setting, rather than an evaluation of its effects.

Slide 5: Choosing a home for a classroom tool

The proposed tools addressed help-seeking, course-file activities, feedback, analytics, and collaboration. They shared a ClassChat implementation setting. That makes the architecture choice worth examining: which features benefit from shared accounts and records, and which could work independently?

Slide 6: Concerns raised during development

The slide records concerns about debugging, testing, access controls, classroom readiness, privacy, and support. These are project-specific concerns. They give us questions to ask about a design rather than a general verdict on teacher or developer behavior.

Slide 7: Designing around the constraints

For the research tools, I chose to separate testable core logic from the browser interface and to process documents locally. Static hosting can simplify deployment, but it does not guarantee district approval, universal device compatibility, or an absence of local storage. Each project’s data behavior needs to be described on its own.

Slide 8: Separating logic from the interface

The architecture separates a Rust core, a WebAssembly interface, and the browser page. The core implements the relevant rules; the page displays state and accepts input. That separation can make logic easier to test. It does not mean the JavaScript layer has no behavior worth checking.

Slide 9: PDF Redactor

PDF Redactor finds candidate identifiers, lets the reviewer inspect boxes, and rebuilds the exported PDF. Searchable exports also include a filtered text layer. The tool’s checks cover selected terms and document structure; a person still needs to inspect the pages and exported file. About PDF Redactor.

Slide 10: Perturbation Workbench

The workbench records an instructor’s assignment tests. A question meets the study’s resistance criterion when the specified model scores below the threshold on three attempts. The instructor runs the queries and grades the responses. Hashes identify recorded text; they do not independently prove its source or correctness. About the workbench.

Slide 11: From research tools to games

The projects share implementation practices, but they serve different purposes. PDF Redactor supports document review; Perturbation Workbench supports assignment testing. Gear Master, Gear Master 2D, and Floodline explore equipment assembly, world traversal, and multiplayer simulation. Their existence demonstrates a development practice, rather than a controlled comparison of agent-assisted development.

Slide 12: AI literacy in this setting

For this lecture, AI literacy includes examining the output, using the tool deliberately, and questioning the system behind it. The next procedures give those aims concrete actions. Their usefulness as teaching routines still needs to be distinguished from evidence of their effectiveness.

Slide 13: How an autoregressive model produces text

In autoregressive generation, a model predicts a distribution over the next token from the available context, and a decoding method selects a token. The growing output becomes part of the context for later predictions. A token is not necessarily a whole word. This process can produce useful reasoning, but it is not itself a formal proof checker. Systems may add tools or verification steps, so claims about checking must specify the system being used. See Brown et al. (2020).

Slide 14: Training can change behavior and performance

Pretraining and post-training have different objectives, and there is no single three-stage recipe shared by every model. Instruction tuning and reinforcement learning can change instruction following, truthfulness, and reasoning performance as well as tone. Ouyang and colleagues note that InstructGPT “still makes simple mistakes”. That limit is compatible with improved performance; it does not imply that training affects only presentation. See Ouyang et al. (2022) and the DeepSeek-R1 paper.

Slide 15: Familiar patterns and unfamiliar questions

A response may apply a familiar formula to a question that has different conditions. We can observe that mismatch in the text. We usually cannot infer the frequency of the problem in a proprietary training corpus or establish the internal cause from the response alone. The frequency curve in the original deck is an illustration, not a measurement.

Slide 16: Three errors to look for

The teaching materials use three example labels. Axiom reversion substitutes a familiar result for the stated one. An invalid syntactic shortcut uses a step whose rule does not apply. A spatial or counting miscount misses, duplicates, or includes forbidden configurations. These examples are not an exhaustive taxonomy, and a check should target the actual error.

Slide 17: Procedure A: Check the proof

Use the hallucination autopsy procedure to state the claim, examine the response’s rule, locate a divergence, and test it. A counterexample can refute a general claim; successful small-case checks do not prove it. A proposed explanation for the model’s error should be labeled as a hypothesis.

Slide 18: A worked mismatch

The claim is 5 + 9 + 13 + … + (4n + 1) = n(2n + 3), for integers n ≥ 1. The example response substitutes k(k + 1)/2 where the inductive hypothesis requires k(2k + 3). At n = 2, the stated sum is 14 and the substituted expression gives 3. The mismatch is visible without claiming to know what the model saw during training.

Slide 19: Procedure B: Specify the help you want

Context, justification, assumptions, and a planned correction make the request more explicit. The chatbot’s explanation and self-check remain claims to examine.

Slide 20: A prompt that makes the task explicit

“Solve this” leaves the kind of help unspecified. For this induction example, I would use the following request:

I’m working on induction. The claim is 1×2 + 2×3 + … + n(n+1) = n(n+1)(n+2)/3 for integers n ≥ 1. Help me work through the proof one step at a time. Name the rule or earlier line supporting each step, state the assumptions you use, and wait for me to check the step before continuing.

If the response changes the formula, I can quote that line and ask how it follows from the stated hypothesis. The prompt makes the checking easier to organize; it does not guarantee a valid proof.

Slide 21: Procedure C: Keep responsibility for the reasoning

Ask for a next step, inspect its justification, and explain your eventual solution yourself. Hand-computed cases can expose an error, but a general proof still needs a valid argument.

Slide 22: Start with a game idea

What game would you like to make? Describe what the player does and what would make the smallest playable version worth trying.

Slide 23: Define a feasible prototype

Which part of that idea could you prototype for the class project? What decisions would an AI-controlled entity make, and how would you recognize whether its behavior worked?

Slide 24: Decide where generative AI belongs

Would you use generative AI while making this game? Identify a task where it might help and the check you would use before accepting its output.

Slide 25: Explain the decision

If you would use generative AI, explain what you would ask it to do and what you would keep responsibility for. If you would leave it out, explain which constraints or concerns inform that choice.

Slide 26: Applying the procedures to prototyping

A coding agent can produce a plan, implementation, and tests. Each is something to review. The development workflow below applies the same habit as proof checking: identify the claim, examine its basis, and compare it with observable behavior.

Slide 27: A workflow for agent-assisted development

The workflow alternates agent contributions with human review and use. These stages describe my practice in the projects shown here.

Slide 28: Documents that support the workflow

PLANNING-BRIEF.md states the goal and completion criteria. PLAN.md records decisions and reasons. CLAUDE.md and TONE.md record project rules. SECOND-ORDER-Mn.md records assumptions and unexpected effects. PLAYTEST and TRIAGE capture observed problems. HANDOFF.md gives the next contributor the context needed to continue. These filenames are conventions used in the projects, rather than requirements of the procedure.

Slide 29: Check behavior at several levels

Core tests examine the logic. Content checks examine relationships among data and text. Save round-trips check whether recorded state can be restored. Browser checks examine the user-facing build. A check also needs evidence that it can detect the failure it targets; a test that passes because it examined nothing gives little confidence.

Slide 30: Gear Master: preparation and automatic combat

The player arranges components into items before a fight. Completed recipes provide item effects, and those effects activate during automatic combat. This separates the player’s preparation decisions from the simulation used to evaluate the build.

Slide 31: Gear Master 2D: a world around the build

Gear Master 2D adds travel, encounters, towns, and other activities around the equipment system. It also makes save and restoration behavior important: the resumed world should agree with the state the player recorded.

Slide 32: Read the plan before the build

I ask the agent to write a plan before implementing a milestone. Reading it gives me a chance to correct the goal, resolve a tradeoff, or identify an assumption before that assumption becomes code.

Slide 33: Give the agent a checkable request

The example prompt specifies a reading order, a concrete change, reconnaissance before implementation, and a record of findings. It also asks for unexpected effects to be logged as they arise. The useful feature is that a reviewer can compare the request with what was actually done.

Slide 34: Record assumptions as they arise

A notebook row should state the assumption, the observation, and what follows from their disagreement. Some rows describe an error to fix; others identify a decision that needs a person. Keeping those distinctions visible is more useful than treating every surprise as the same kind of problem.

Slide 35: A mismatch between units

The example compares nine stake pulls with 36 card reads. Those numbers describe different events, so their disagreement cannot be resolved by choosing whichever number looks more plausible. The fix is to define the units and check each count against the event it measures.

Slide 36: A test count needs a reproducible method

Interleaved terminal output made an informal test count unreliable in the example. The project added a script that enumerated tests from the built binaries. The lesson is to state what is being counted and use a repeatable method; the count in the historical figure describes that build, not the project today.

Slide 37: Review, deployment, and handoff

In this workflow, the agent plans, builds, tests, and records findings. I review decisions, use the build, and decide when to deploy. The live page then needs its own checks. A successful local build does not show that the published version behaves the same way.

A handoff records the decisions, constraints, and unresolved issues another contributor needs. It is useful before resetting an agent’s context or moving the work to a new session. The lecture’s context-size example is a development observation, rather than a measured threshold at which models become unreliable.

Slide 38: Discuss the tradeoffs

Which parts of this workflow might save effort, and which add review work? Choose one benefit and one drawback, then explain how you would observe them in your own project.

Slide 39: Game AI and multiplayer simulation

The remaining examples examine two different problems: keeping a multiplayer simulation consistent across browsers, and learning or searching for decisions in an equipment-based game. Each needs an explicit account of state, actions, and the checks used to evaluate behavior.

Slide 40: Floodline: shared inputs and a shared simulation

Floodline uses deterministic lockstep: browsers advance from ordered inputs using the same simulation rules. The host coordinates turns rather than serving as the sole simulation authority. The network still needs connection setup, and some connections may need relay services. About Floodline.

Slide 41: Establishing browser connections

WebRTC peers exchange connection information before sending application data. The lecture describes a Trystero-based signaling path and a manually exchanged connection-code path. A direct data channel can reduce the need for a dedicated game server, but signaling, STUN, and possible TURN relaying remain separate infrastructure questions.

Slide 42: Selecting the intended topology

The lecture’s transport can connect peers as a mesh, while the game’s turn protocol uses host-centered links. Identifying host and joiner roles prevents the code from treating the first peer it encounters as the host. The diagram shows the role bytes and channels used by that implementation.

Slide 43: Advancing one tick

A joiner sends its turn to the host. The host collects the turns for a tick and distributes a bundle; peers then apply the same bundle before advancing. Scheduling inputs ahead of their simulation tick gives the transport time to deliver them. The timing values in the diagram describe the lecture’s implementation.

Slide 44: What a checksum covers

A checksum over serialized World state can help detect a disagreement at the same tick. It covers what that serialization includes. Derived navigation state is outside the serialized World in this example. A matching 64-bit hash is a useful check, but collisions are possible, so it is not a proof that every part of two running clients is identical.

Slide 45: Waiting, disagreement, and disconnection

The lecture distinguishes a delayed peer, a build mismatch, a state disagreement, and a departing host. Its implementation also had a known reporting limitation: only the host could detect the checksum disagreement, while a joiner could freeze without receiving the explanation. That is the status described in the September 2026 lecture, not a claim about the current build.

Slide 46: Define the agents’ decisions

The lecture separates an equipment-packing agent from an agent that chooses actions in the world. Their action sets differ, so their state representations and rewards need to match the decisions they actually make. A combat simulation supplies an evaluation, but a reward alone does not establish that training will produce useful behavior.

Slide 47: Check the research and the engine

The planning example begins with claims about the engine and asks the agent to correct them from the code. Research recommendations also need sources that support the relevant design choice. An unread citation or an uncertain release date should remain marked as unverified in the planning record.

Slide 48: Compare the representation with the plan

The example contrasts the proposed state and action representations with what was implemented. If several distinct actions become the same encoded vector, the learner cannot distinguish them through that representation. The numerical dimensions in the historical figure describe the implementation being inspected at that time.

Slide 49: Inspect the path from training to content

This part of the lecture asks how a trained packing result becomes a creature’s equipment. Inspect each transition: what situation is represented, what the agent chooses, how the simulation scores it, and which parts are exported into the game. That gives a concrete way to check whether shipped content reflects the claimed process.

Slide 50: Use trained output as a proposal

The pipeline proposes a creature build from a specified training situation. A person still needs to inspect the result against the design goal. The figures report quantities from the development example; without the metric definitions and evaluation setup, they should not be treated as a comparative performance result.

Slide 51: A training curve that needs investigation

The historical curve rises to rung 11 and later falls to rung 2 while Q-value spread increases. That is an observation to investigate. The curve alone does not identify overfitting or establish a single cause; the implementation and evaluation conditions need checking.

Slide 52: Question the system you are using

Who built the system? What is known about its training data, access conditions, and limitations? Which parts of its recommendation can you verify? When the evidence is unavailable, say so and decide how that uncertainty affects the task.

Slide 53: Return to the development workflow

The workflow ties the lecture together: state the task, request reasons, check assumptions, inspect the running result, and leave a record for the next contributor. See the nine stages above rather than treating the repeated diagram as a second procedure.

Slide 54: Resources

Course materials · Research and publications · Concepts · Tools and games

For model generation and training, see Brown et al. (2020), Ouyang et al. (2022), and the DeepSeek-R1 paper.

Slide 55: Questions and contact

Which claim in your own project would you most want to check before trusting the result?

Sam Gilson · sagilson@ncsu.edu

All research · Course materials