CMST 315: Game Design I

CMST 315 at UMGC is a hands-on introduction to 3D video game design and programming, in which you take a game from concept to final product in an industry-standard 3D engine.

UMGC now lists the course as XRDE 315, Game Design I (formerly CMST 315). It is also the stated prerequisite for UMGC's virtual reality, augmented reality and virtual world-building courses, so the habits you build here carry into the rest of the extended reality sequence.

The difficulty is that it combines two disciplines at once. You need design sense (what makes a mechanic fun and clear) and programming skill (making it actually work in C#), plus the project management to finish on time.

What CMST 315 Covers

• 3D game engines: scenes, game objects, components and the editor workflow.
• 3D game design: level layout, camera, goals and feedback to the player.
• Gameplay mechanics: the rules and actions (move, jump, collect, score) that make up play.
• Sound effects: audio that confirms actions and builds atmosphere.
• C# programming: variables, conditions, methods and scripts attached to objects.
• 3D physics: rigidbodies, colliders, gravity and forces.
• User interface design: score, health, menus and readable on-screen text.
• Project management: scoping, milestones and finishing a playable build.

Key Concepts Explained

The Game Loop and Frame Updates

Engines redraw the scene many times a second and call your update code each frame. Movement must therefore be scaled by the time since the last frame, or the game runs faster on quicker computers.

Colliders, Triggers and Physics

A collider gives an object a physical shape; a rigidbody lets the physics system move it. A trigger is a collider that detects overlap without blocking movement, which is how most pickups and checkpoints work.

Scope as a Design Skill

A small game that is finished and polished beats a large one that is half built. Defining a core loop (for example: explore, collect, avoid hazard, reach exit) keeps the project achievable.

Typical Assignments and How to Approach Them

Writing a Short Game Design Document

Because the course takes a game from concept to final product, a planning document is a natural early step. Keep it short and practical. A one or two page design document that you actually use is worth more than a long one nobody reads.

• Pitch: one sentence describing the game and the player's goal.
• Core loop: the repeated actions that make up play.
• Controls: every input and what it does.
• Win and lose conditions: how a round ends.
• Assets: models, sounds and UI elements needed, and where each comes from.
• Milestones: what will be playable at each checkpoint.

Listing asset sources also covers licensing: free assets often come with attribution or usage conditions you need to follow.

Where Students Get Stuck

• Null reference errors. A script refers to an object that was never assigned. Check the inspector fields and the object's name or tag.
• Physics behaving oddly. Moving rigidbodies by changing their position directly, rather than through forces or velocity, causes jitter and missed collisions.
• Over-ambitious scope. Planning an open world in a few weeks. Cut features, not polish.
• No version backups. A broken scene with no earlier copy. Save milestone copies or use version control.

Study Tips for CMST 315

• Learn C# basics (variables, if statements, methods) alongside the engine, not after it.
• Read error messages fully: they name the script and line number.
• Playtest every session and keep a short bug list.
• Keep notes on what you build; later XRDE courses reuse the same engine skills.

How We Help with CMST 315

Send the brief, the rubric, relevant scripts or screenshots, and any error messages. A tutor with programming and game design experience explains the logic, helps you debug, and can write a model design document or commented example code for a similar mechanic so you can apply the idea in your own project.

GradeEssays is independent of the University of Maryland Global Campus. Our help is tutoring and reference only; the game and code you submit should be your own, in line with UMGC's academic integrity policy.