Learn Unity3D: build 3D games with C# and develop your portfolio

Discuss which programming languages or game creation tools the learner has used and what kind of game they want to make. Previous projects can help the teacher assess a suitable starting point. Make sure the computer can run the required software and connect reliably to the internet. The original course recommends a reasonably capable Windows computer and fast internet. Share the computer’s specifications before enrolling so the team can assess suitability; there is no need to buy a new machine before asking for advice.

Keep project files organised in separate folders for images, audio, code and project assets. Back up work regularly. When an experiment causes an error, record what changed and what happened. This helps the teacher diagnose problems and lets learners recognise their progress even when a game is still unfinished.

A starting challenge might be a short game with a clear objective: reach a destination, collect an item or avoid obstacles. Learners then plan rules, choose a camera angle, define controls and sketch a simple scene. This keeps the scope realistic. Before adding detailed visuals, check that the character moves, the rules work and the player knows what to do next.

Once the core game is playable, add scoring, a timer, sound or another scene at a suitable level of difficulty. Teachers encourage learners to explain design decisions rather than simply follow an example. Some projects focus on systems, others on visuals and player experience; outcomes vary with goals and the time spent building them.

Learners read and write C# scripts to control objects in a game. The goal extends beyond making the code run: they form hypotheses when something goes wrong, inspect variable values and change one thing at a time. Challenges may include movement, collisions, button input or the conditions for completing a level.

Breaking problems into small parts helps learners connect code to what happens on screen. Teachers can begin with simpler tasks when more foundation is needed, then increase the complexity. Save a working version before experimenting so that you can return to it and compare results. This builds confidence and persistence.

A useful portfolio explains the challenge, goal, learner’s role, decisions, problems and improvements. Attractive screenshots alone do not tell the whole story. If the game is playable, include a short video or a sequence of gameplay images. Choose C# script samples that clearly show the learner’s contribution; there is no need to include every line of code.

Supporting evidence can include scene sketches, gameplay diagrams and playtest notes, with explanations of the feedback received and changes made. Identify tools and personal contributions honestly. Teachers help select evidence and tell the project’s story, but admissions depend on each institution’s criteria and the actual quality of the work. Unverified admissions outcomes should not be claimed.

Ask what the learner tried this week, what problems arose and what they plan to change next. These questions encourage explanation rather than focusing only on whether a game is finished. Game development includes trial and error. Small milestones, such as character movement, working scores or fixing a bug independently, are meaningful progress.

For portfolio goals, encourage before-and-after images, notes on lessons learned and regular questions for the teacher. Tell the team if the learner needs a different challenge level or has limited time. Understanding a project matters more than rushing to create something large without time to explain the process.

Ask the learner what they find interesting in a favourite game: its story, characters, rules, visuals or sound. Then ask what they would change. This reveals interests and helps the teacher choose an appropriate starting task. Making a short game shows how much thinking, testing and sustained work goes on behind the scenes; it is more than extra time spent playing.

Tell the teacher if the learner has never coded so that a foundation course can be considered. If they have used block coding or Python, bring examples. These show sequencing and problem-solving skills more clearly than age or school level alone.

A first game does not need a huge world or online multiplayer. Choose one core activity that is easy to explain, such as exploring, collecting, solving a puzzle or avoiding obstacles. Define the win condition and the feedback players receive. A small scope leaves time to solve problems and test with real players.

Sort ideas into essentials, desirable additions and features for later. Make the game playable first, then improve its appearance. Managing scope is an important project skill and provides clear evidence of decisions in a portfolio.

Sketch a simple map showing where the player starts, where they must go and what they meet along the way. Arrange the scene to communicate the goal clearly. An attractive object that causes confusion may need a different position, colour or size. Design helps players understand the game as well as making it look appealing.

When creating simple 3D models, consider the computer’s performance and the time available. Start with basic objects and refine them later. A portfolio can compare prototype and revised images and explain changes to shapes, camera angles or routes.

Testing involves more than opening the game without an error. Check whether a new player understands the rules, whether buttons respond as expected and whether any section is too difficult. Let a friend or family member play without explaining every step to reveal problems the creator may have overlooked.

Record what players try to do, what confuses them and their suggestions. Improve one issue at a time, perhaps adding a hint, adjusting timing or moving an object. Retest to see whether the change helped. Testing and iteration are valuable portfolio evidence even if the game is not perfect.

Keep concept sketches, development screenshots, code written by the learner, debugging notes and a short video of real gameplay. Explain the challenge, personal contribution and result for each piece. Many images without context may fail to show the learner’s actual ability.

Select evidence that forms a coherent story: the problem, thinking, practical work, outcome and lessons learned. For a shared project, identify the learner’s own role clearly. Honest explanations help reviewers understand both the learning process and the learner’s responsibility.

Allow time to check the computer and open files before class, as technical problems reduce practical learning time. During a lesson, note questions and capture errors so the teacher can help precisely. Afterwards, review changed files and back up the work securely.

Game projects may require some practice outside class, depending on the learner’s goals, but should remain enjoyable. Small tasks and weekly goals make progress visible. If a problem persists, bring questions and a record of attempted fixes to the teacher rather than deleting everything and starting again without understanding the cause.

Ask about current class times, lesson count and length, trial lessons and make-up arrangements. Share the learner’s experience and computer model. Discuss whether the goal is enjoyment, coding practice or a portfolio, as tasks and intensity can vary.

If a project is needed for a dated application, tell the teacher the deadline early so that a realistic scope can be assessed. Dates, times and places may change; confirm directly before arranging travel or other family commitments.

Assessment looks beyond attractive graphics or the length of a game to whether learners can explain ideas, plan and solve problems more independently. In the Unity3D course, a small project the learner understands fully can be more valuable than a large one they cannot explain. Teachers and parents can review prototypes, test records, revised code and plans for the next improvement.

For a portfolio, plan what the project should demonstrate, what interests the learner and how much preparation time is available. Collect evidence regularly rather than immediately before submission. Progress depends on experience, practice and engagement with teachers; identical outcomes should not be promised for every learner.

Once the first game is playable, choose a focused improvement: refine the player experience, add scoring, make a new scene or explore visuals and sound. One priority at a time makes the effects of each change easier to see. As Unity3D learning continues, interests may develop in game design, programming, modelling or testing. Each path uses different skills and should reflect the learner’s interests.

Sharing a game and receiving feedback also develops communication. Learners can explain what they tried, where it failed and how they changed approach. For further independent study, start with official documentation and small tasks. Regular practice is more useful than jumping immediately into complex systems. Teachers can recommend the next skill to practise based on completed work.

If you have some coding or game creation experience, ask the teacher to assess a suitable starting point. Challenges are adapted to the learner’s background.

Learners develop their own game and collect evidence such as screenshots, design concepts, C# script samples and problem-solving notes to select for a portfolio.

A reasonably capable Windows computer and a reliable high speed internet connection are recommended. Contact the teacher to confirm that your computer is suitable before starting.

There are 14 Sunday lessons of two hours each (28 hours in total). Ask about the 09:00–11:00, 11:00–13:00 or 14:00–16:00 class (Thailand time). A trial lesson is recommended before enrolling. Confirm the current start date and class times with the team.