CSYE 7270: Virtual Environments and Real-Time 3D

What must you understand when Claude Code builds your Godot game? Liam, in for Professor Bear, explains the Fall 2026 CSYE 7270 course: directing and evaluating AI-assisted virtual environments, not submitting impressive code you cannot explain.

Walker organizes Game brief → Build → Playtest → Inspect → Revise → Export. The course learning pattern is Predict → Build It → Use It → Ship It → Verify. Students supply intent and judgment; AI assists implementation and inspection; Godot supplies the running evidence.

The opening assignment changes Walker Jumpman's character identity, adds at least two new jump-and-landing opportunities, and moves the finish to the new end. The film connects this work to plausibility auditing, problem formulation, tool orchestration, interpretive judgment, and executive integration—the course's vocabulary for supervising AI-assisted work.

COURSE MAP Walker and Godot; AI-assisted game art; Blender with the community Blender MCP integration; scenes, physics, and game design documents; shaders and materials; particles, animation, interaction, and audio; profiling, procedural systems, and scoped advanced projects.

Modules map to companion-book chapters, released one or two per week. Assignments are 100 points every ten days. Use Canvas for actual deadlines and project milestones. Each assignment includes a Brutalist Godot explainer, an honest Frictional log, explicit human/AI attribution, and matching GitHub and Canvas versions.

ACCESS AND RESPONSIBILITY Course exercises assume working Claude Code access through Northeastern's course arrangements. Check access early; contact the instructor if it fails. The starter uses regular Godot and GDScript, not the .NET edition, and does not require separate API credits. Northeastern Claude access: https://claude.northeastern.edu/ AI Policy for Professor Bear's Courses | Using AI Responsibly in Class: https://youtu.be/8Ut0Cdl6vMw

SOURCE AND TOOLS Walker Jumpman: https://github.com/nikbearbrown/walker-jumpman Brutalist: https://github.com/nikbearbrown/brutalist.art Godot: https://godotengine.org/ Walker playlist: https://www.youtube.com/playlist?list=PLbeL9xXuLsLs

PRODUCTION AND EVIDENCE Liam is an AI narrator using local Kokoro speech synthesis, not Bear's recorded or cloned voice. Claude interfaces are reconstructions. Game stills are identified archival captures from actual scripted-input Godot runs, not new student implementations or human playtests. Proposed character changes, level extensions, and the failed-landing example are labeled constructed illustrations. Test conformance does not establish fairness, fun, or adequacy for a particular player. Native 3840×2160, 24 fps master; optional English closed captions, no burned-in subtitles. Created with the Brutalist AI deep-explainer structure and Liam persona.

Transcript

A lightly formatted transcript of the video, with timestamps so you can jump to any section on YouTube.

[0:00] Please use Walker to explain what I must understand when Claude Code builds my Godot game. That is the question behind CSYE7270. I'm Liam in for Professor Bear. This course is about directing and evaluating virtual environments, not collecting impressive-looking code you cannot explain. The scarce skill is not typing, it is judgment. Claude can help produce the implementation. You must decide what the game is trying to do, recognize a plausible mistake, and explain why a revision is better. We will follow one small platformer from a vague request to evidence you can defend. Separate the roles. You supply the intent and acceptance criteria. Walker organizes the brief, build, playtest,

[0:40] Inspection, revision, and export cycle. Claude Code proposes and edits code. Godot runs the interactive world. An agent's confident description is not a substitute for observing that world. Here is the actual Walker jump and starter before students' extension. This is an archived frame from the existing project, not a proposed redesign. Establish that baseline first. If you never observe the original controls and level, you will not know whether your changes preserve them. Godot supplies nodes, scenes, rendering, physics, and the running game. GDScript connects those pieces with behavior. The course uses the regular Godot engine. The starter does not require C# or the .NET edition. Claude Code is the coding

[1:21] Assistant. It is not the engine. The Walker loop has six moves: game brief, build, playtest, inspect, revise, export. Notice where inspection sits. Playing reveals an observation, inspection traces its cause, revision changes the cause. Export packages a version. It does not retroactively prove that the version was good. These exercises assume working Claude Code access through the course's Northeastern arrangements. Check that access early and contact the instructor if it fails. Separate API credits are not a starter prerequisite. Install the course-specified Godot version, then open the starter's project file rather than creating an unrelated empty project. The course names five supervisory capacities. Plausibility auditing asks whether the result makes

[2:05] Sense. Problem formulation defines the task. Tool orchestration orders the work. Interpretive judgment gives the result game-specific meaning. Executive integration keeps the session aimed at one goal. These are the course's vocabulary for supervision, not five buttons in Godot. Problem formulation begins before prompting. Make the character better is not a specification. Give the character a distinct silhouette while preserving movement speed and collision behavior is closer. Name one concern, an invariant you will preserve, and the files or systems the agent must leave alone. Tool orchestration is about dependencies. Inspect the existing player first, change its visual identity next, check the silhouette in motion. Only then extend the level in a separate

[2:47] Change. If art, physics, camera behavior, and geometry all move together, a regression has too many possible causes. Plausibility auditing starts with a specific suspicion. This archived jump frame tells us where the visible character was. It does not prove that every landing works. A new sprite could look centered while its collision shape stays elsewhere. Ask what observation would reveal that mismatch, then test it. Interpretive judgment supplies the meaning of a result. A collision test can report contact. It cannot decide for your audience whether the landing feels fair or the character reads clearly against the background. Use machine checks as evidence. Make the design judgment yourself and explain the

[3:25] Tradeoff you accepted. Executive integration prevents the session from drifting. The assignment is to change a character and extend a playable level. A proposed inventory system might be clever and completely irrelevant. Keep the brief visible, record deferred ideas, and judge each new task against the goal instead of the agent's enthusiasm. Now inspect the real starter. Player drawing and movement live in the player script. Level geometry comes from a data file. The session script builds and manages the running world. That ownership map tells you where to ask for change and where to look when the result surprises you. The first change is a new character identity, not just a new color. Use the

[4:04] Baseline as a comparison reference. A student might change the silhouette, face, or accessories while preserving the movement contract. That redesigned character is proposed work here. This film is not presenting an unbuilt student solution as finished gameplay. In this source snapshot, the player's collision rectangle is 18 by 28 game units. The drawing is a separate concern. Our schematic enlarges both so you can see the difference. Changing the art does not automatically change the collider. If you intentionally change collision, update the specification and the tests, too. For the first assignment, add at least two new jump and landing opportunities and relocate the finish to the new end.

[4:41] More floor is not automatically more play. Show the route, explain the choices it asks of the player, and preserve a reachable start to finish experience. This archived completion frame came from scripted input. It demonstrates one successful route in the recorded build. It is not a human play test, not a measurement of enjoyment, and not evidence about your future extension. Preserve that distinction when you describe tests in your own submission. A larger level affects more than one visible platform. The finish position, camera limits, resource references, and runtime behavior may depend on other values. The course calls this the dangerous middle. Follow the dependency links. Do not approve a change merely

[5:20] Because the file you edited looks reasonable. Before the next build, write a prediction that can fail. After extending the level, I can land on both new platforms, reach the new finish, die, and restart at the original spawn. Record the observed result for each part. A claim becomes useful when you know what would contradict it. Suppose the second new landing fails. That is a constructed teaching example, not a new test run. Compare the geometry with the movement you promised to preserve. Adjust one cause, rerun the failing case, then repeat the baseline checks. Quietly weakening the test would hide the problem instead of fixing it. In week two, the same supervisory

[5:57] Pattern moves to game art. Use tools you can access, compare candidates, record prompts and provenance, and inspect the imported result at game scale. A beautiful isolated image can become an unreadable character. A paid image subscription is not the learning objective. Week three adds Blender through the community Blender MC P integration. A generated mesh is an intermediate artifact. Inspect its geometry, scale, materials, and exported form, then verify it inside Godot. A correct-looking Blender viewport does not prove that the imported asset behaves correctly in the game. The middle of the course connects scenes, collision, and physics to the game design document, then to shaders and materials. Specify what should

[6:37] Happen before asking for code. A shader compiling establishes one kind of conformance. Compare controlled inputs and visible output before calling its appearance correct. Particles, animation, interaction, and audio unfold over time. A still screenshot cannot show whether an effect starts too early, an animation transition pops, or a sound repeats after restart. Trace the event, the state change, and the visible or audible response, then test that sequence in the running scene. Later work adds profiling, analytics, navigation, behavior trees, procedural content, and appropriately scoped networking, mobile, or extended reality constraints. These are still walker and Godot problems. Measure a baseline, justify a focused change, and integrate the result

[7:20] Into projects you can reproduce and defend. Modules map 101 to companion book chapters released one or two per week. Assignments follow a separate clock, 100 points every 10 days. There is an individual project and a group project. Canvas supplies the deadlines and project milestones. This overview does not invent dates or project waitings. Every assignment also includes a brutalist Godot explainer, use a walk-through to show behavior, a game development explainer to connect it to implementation, or a game design document explainer when that is the assignment's focus. >> [snorts] >> Selected films become class discussion material. Narration should explain actual evidence, not promise footage you never recorded.

[8:01] Predict, build it, use it, ship it, verify. Predict the result before prompting, build one focused change, use it in the game, ship a reproducible version and explanation, verify the claims against evidence. This learning loop and Walker's production loop reinforce each other. Neither means press generate and trust the result. In your sources and fictional log, name what you contributed and what the AI contributed. Include the wrong turns, the evidence that changed your mind, and what remains unverified. The GitHub version and the Canvas submission must match. A polished film cannot replace an honest account of the work. A failed run can teach more than a confidence summary. Here the archive

[8:38] Captures the starter's failure state. In your own work, inspect what triggered failure and whether recovery behaves as specified. Then ask the human question, does this teach the player fairly or merely satisfy a machine check? The agent can help propose acceptance tests, analyze traces, and suggest revisions. Those are useful contributions. It still does not inherit your responsibility for choosing the goal or defending the result. Conformance asks whether the system meets stated checks. Adequacy asks whether those checks and that experience serve the intended player. The verdict. This is a course in supervising interactive systems. Learn the subsystems well enough to specify behavior and catch plausible errors. Use

[9:17] Clawd code to accelerate implementation. Use Godot to observe the result. Use the five capacities to explain the decisions that no generated code listing can make for you. Your turn. Please use Walker to inspect Jumpman, preserve its movement, and propose a new character and two new landings. Start with that prompt, then review the proposed changes before accepting them. Your evidence should show the baseline, the extension, a failure and restart, and one revision you can explain. >> Nick Bear Brown Teaching Club >> >> Nick Bear Brown Teaching Club >>