Skip to main content

Extended Syllabus - Programming in C#

Course: Programming in C#
Code: ICD0008
ECTS: 6 (156 student hours)
SIS/ÕIS: Programming in C# (ICD0008)
Duration: 16 weeks + 2 extra defense days (January)
Course year: 2nd year
Semester: Fall (3rd semester)
Format: Flipped classroom
Students: ~175
TAs: 4
Language: Estonian and English as needed.
Written language: English (slides, comments, code, etc...)
Contact: Friday 09:00-12:00, ICO-221 (Weeks 1-16) — optional clinic/demo; 0-3h depending on attendance + extra days Weeks 17-18
Attendance: Friday sessions are optional. Defense attendance is mandatory (remote by prior arrangement only).
Teacher: Andres Käver
Email: andres.kaver@taltech.ee

Student Quick Start​

Weekly workflow: Watch pre-recorded video lectures (~1.5h) before the Friday session. Attend optional clinic/demo Friday 09:00-12:00 (ICO-221). Work on your project during the week (~5-8h). Use MS Teams CSharp channel for questions.

Your game: Everybody builds the same kind of project (a two-player board game: console app first, web app later), but the actual game is assigned by your student code. Take the last digit of the numeric part of your student code, divide by 2 (integer division): 0 → Connect Four, 1 → Tic-Tac-Two, 2 → Reversi/Othello, 3 → Gomoku, 4 → Nine Men's Morris. Details in the Assignments section.

Repository: One git repository per student. The git server, repository naming and setup are defined in Git usage. README with your name, student code, uni-id and assigned game. Nullable warnings as errors from day one.

Deadlines: Code must be committed and pushed to git by 23:59:59 on Thursday evening before the first Friday of each defense period (08.10, 12.11, 17.12), serving as the code-freeze deadline. There are no other deadlines — only defense deadlines matter.

Defense weeks: D1 = Week 6-7, D2 = Week 11-12, D3 = Week 16-17. Retakes on weeks 8, 13 and 18. Each defense period runs on two consecutive Fridays, book a slot on either one.

Passing rules: Each defense must score >50% of its points. You must pass ALL three defenses to pass the course. One retake allowed across all defenses (capped at 75% of original points).

Attendance: Weekly Friday sessions are optional clinic/demo sessions. Defense attendance is mandatory. Remote defense by prior arrangement only.

If code does not compile at defense: You may fall back to the last working commit in your repository, or you will be given a 10-minute hotfix window to resolve compilation issues. If neither produces a running application, the assignment receives 0 points. See "Defense Logistics" for full details.

AI usage: AI tools are encouraged. Keep your prompts and notes. You must be able to explain every line of your code without AI assistance at defense.

Grade scale: 5 (90-120), 4 (80-89), 3 (70-79), 2 (60-69), 1 (50-59), 0 (<50 or failed defense). Maximum 120 points (100 base + 20 bonus).

Tech: .NET 10 (LTS), C# 14, JetBrains Rider, xUnit, SQLite, ASP.NET Core Razor Pages. Everything runs on your own laptop — no VPS, no cloud.

Home Assignments: Syllabus is just plan. Actual assignments descriptions are here: assignments

Goals (from ÕIS)​

  • To develop students’ teamwork and programming skills and provide necessary knowledge and skills on the basis of .NET Framework for software development in a smaller team.

Learning Outcomes (from ÕIS)​

  • L01 - describe the essence of .NET Framework and its main technologies
  • L02 - create simpler applications or parts of larger software solution in C# programming language
  • L03 - create queries in LINQ query language by using additional materials and to use .NET Framework tools in order to obtain data from commonly used data sources (XML, database servers, files)
  • L04 - work in a smaller team

General competencies course develops (not graded)​

TalTech General Competencies

1.1 Self-management and learning competence

  • self-management
  • self-regulation
  • learning skills

1.2 Critical thinking

  • critical information acquisition skills
  • analytical skills
  • problem-solving skills
  • argumentation skills
  • self-assessment skills

1.4 Communication competence

  • self-expression in different forms
  • adaptation of communication style
  • giving feedback

Communication 2026/2027 fall​

Session studies​

There is no difference between different forms of study in lectures. Everybody can attend every lecture/practice.
If you are not attending locally or remotely - you are expected to watch all the missed lectures before attending the next lecture.

Pre-Requirements​

Students should have mastered the following before taking this course:

Programming Fundamentals

  • Variables, data types, operators
  • Control structures (if/else, loops, switch)
  • Functions (parameters, return values, scope)
  • Arrays and basic data structures (lists, dictionaries)
  • Object-oriented programming basics (classes, objects, inheritance) — in any language
  • Debugging techniques

Development Tools

  • Git version control basics (clone, commit, push, pull)
  • Command line/terminal basics (navigation, file operations, running commands)
  • Own laptop with admin rights (school PCs are not suitable, see Technical requirements)

Helpful, but not required

  • Relational database concepts and basic SQL (taught in parallel in the Databases course)
  • HTML basics (needed for the web app in the last third of the course)

No prior C# or .NET knowledge is assumed. Week 1-2 covers the language from the ground up, at a fast pace.

Literature​

Recommended books to read:

Free online documentation (the primary source for this course):

Workload Distribution​

ComponentHours
Video lectures22
Project assignments (A1-A6)96
Defense preparation (3 defenses)18
Self-study (docs, game rules, reading)16
Defenses4
Contact sessions (clinic, demos, Q and A) (16 weeks)0-48 (optional)
Total156

Course Structure Overview​

Core Theme: One Game, Six Steps​

The whole course is one evolving project. Every student implements a classic two-player board game (assigned by student code) and grows it step by step:

Menu library → Console game engine → JSON persistence → EF Core + repository → Minimax AI → Razor Pages web app (same libraries, cross-play)

  1. A1 (Weeks 1–3): a reusable console menu system as a separate class library — usable in any console app, knows nothing about games.
  2. A2–A6 (Weeks 3–15): the game itself, cumulative on the same solution. Game logic, persistence and AI live in class libraries, so the console app (A2–A5) and the web app (A6) share them. A game started in console can be continued in web and vice versa.

The focus is on building software in layers: UI separated from logic, logic separated from storage, storage behind interfaces — so that swapping JSON files for a database, or a console UI for a web UI, is a small change and not a rewrite.

Core Curriculum - Console (Weeks 1-10)​

WeekFridayTopicAssignmentDefense
104.09Course intro, .NET 10 / C# 14 tooling (SDK, CLI, Rider, git), C# refresher, Console API, solutions & class librariesA1: Menu library-
211.09OOP: classes, inheritance, interfaces, generics; nullable reference types; records/structs; delegates & lambdasA1 cont.-
318.09Collections, generics, LINQ; game engine design (config / state / rules / UI separation)A1 due; A2: Console game-
425.09JSON (System.Text.Json), file & directory IO, persistence design (repository interfaces)A2 cont.; A3: JSON persistence-
502.10xUnit testing, exceptions, debugging, code quality, D1 preparationA2 + A3 due-
609.10EF Core intro (video only)A4: EF Core + repositoryD1 starts (A1+A2+A3)
716.10EF Core: relationships, migrations, querying, storing game stateA4 cont.D1 cont.
823.10Repository pattern, Dependency Injection & configuration in console apps, solution layeringA4 due; A5: AI opponentD1 retake
930.10Game AI: game trees, minimax, alpha-beta, C# implementation, AI testsA5 cont.-
1006.11Evaluation heuristics per game, difficulty levels, performance, async/cancellationA5 due-

Web Curriculum (Weeks 11-18)​

WeekFridayTopicAssignmentDefense
1113.11HTTP + ASP.NET Core Razor Pages intro (video only)A6: Razor Pages web appD2 starts (A4+A5)
1220.11Razor Pages: PageModel, handlers, routing, Razor syntax, layout, tag helpers, forms, model bindingA6 cont.D2 cont.
1327.11Razor Pages + EF Core + DI + async; reusing class libraries; rendering the boardA6 cont.D2 retake
1404.12Web game flow: parallel games, per-player links / DIY auth, partial views, AI moves in webA6 cont.-
1511.12Polish: cross-play console ↔ web, validation, error handling, README, demo prepA6 due-
1618.12Buffer / consultation-D3 starts (A6 + Demo)
17Jan 2027 (TBA)Extra Defense Day-D3 cont. + consultation
18Jan 2027 (TBA)Extra Defense Day-D3 retake + consultation

Weeks 17-18 (Extra Defense Days): Two additional contact days in the January exam session for the second D3 defense day, D3 retake and consultation. This replaces the theory quiz and the practical exam of previous years - all assessment is done through project defenses.

Defense periods: Each defense runs on two consecutive Fridays (D1: weeks 6-7, D2: weeks 11-12, D3: weeks 16-17). Book a slot on either Friday. The retake is only on the third Friday (weeks 8, 13, 18). Code freeze is on the Thursday before the first Friday of the period — the frozen commit is what gets graded, whichever day you defend.
Final defense organization might change - instead of 3 fridays we might do it in 2 weeks: friday + saturday and single friday from second week.

Game assignment: Your game is fixed by your student code (see Assignments). No project proposal is needed — A1 starts in Week 1.

Teacher discretion: If class progression requires more time on the console part, the web assignment (A6) may be condensed (see Reduced Curriculum). Decision made by Week 13, after the D2 period, based on defense pass rates.

Testing from A2 on: Unit tests (xUnit) on game rules are mandatory from A2 and are extended in every later assignment (repository contract tests in A4, AI tests in A5). There is no separate testing assignment; testing is a rubric dimension at every defense. It is kept light on purpose — test what breaks: win detection, move validation, save/load round-trips, "AI takes the winning move".

Cross-cutting patterns (weave throughout):

  • Interface-based repository — designed in Week 4 (JSON), second implementation in Weeks 7-8 (EF Core), reused unchanged in Week 13 (web)
  • Dependency Injection — introduced in Week 8 in the console app, the same registrations move to the web app in Week 13
  • async/await + cancellation — introduced in Week 10 for a responsive AI, reused in Week 13 for async page handlers and EF Core

Cross-course integration: The spring course "Web Applications with C#" (ICD0024) continues directly from here and assumes EF Core, DI, repositories, Razor syntax and tag helpers from this course. Students in the JavaScript course (ICD0006) will later put a JS frontend on top of a C# backend.

Assignment deadlines

  • Code must be committed and pushed to git by 23:59:59 (Tallinn local time) on Thursday evening before the first defense Friday of each period: 08.10.2026, 12.11.2026, 17.12.2026. This is the code-freeze deadline.

How the course works

  • Before session: videos, personal preparation
  • During session: demo and Q&A with teacher, clinics and defense with TA's
  • After session: assignment work + support channels
  • Git server and AI access provided by course. Everything runs on your own laptop (SQLite + Kestrel) — no VPS needed
  • Expected time per week: 8–10h (videos ~1.5h, r&d ~5–8h, optional demos and clinic ~0–3h)

Grading Overview​

Assessment Model: All grading is done through project defenses. No separate theory or practical exam.

Defense Points (100 total + 20 bonus)​

DefensePointsPassing (>50%)
D1: Menu library + Console game + JSON persistence (A1+A2+A3)30>15
D2: EF Core + Repository + AI opponent (A4+A5)30>15
D3: Razor Pages web app + Full demo (A6 + Demo)40>20
Total100>50
Bonus points (TA/Teacher discretion)+20
Maximum possible120

Each assignment (and the D3 demo) is graded 0–100 and then weighted into defense points:

D1 points (0–30) = 30 × (0.25×A1 + 0.50×A2 + 0.25×A3)/100
D2 points (0–30) = 30 × (0.40×A4 + 0.60×A5)/100
D3 points (0–40) = 40 × (0.70×A6 + 0.30×Demo)/100

Why these weights: A2 (engine + UI + first tests) is the load-bearing piece of the console phase; A1 and A3 are smaller. In D2 the AI is algorithmically heavier than the EF port, but the repository swap is the architectural checkpoint. D3 keeps 30% for the integrated demo, because cross-play and "all modes everywhere" only exist when the whole solution is coherent.

Passing Requirements

  • Each defense must achieve >50% of its points to pass
  • Must pass ALL defenses to pass the course
  • Overall course grade based on total points earned
  • An assignment that is missing or does not run scores 0 for that assignment (the defense may still pass on the other assignments)

Retake Penalty

  • Retakes only available for failed defenses (<50%)
  • Retake maximum is 75% of original points
  • One retake allowed total
  • In case of technical issues (e.g., git server outage) contact teacher

Bonus Points (up to 20) TAs and teacher may award bonus points for:

  • Exceptional code quality or architecture
  • Going beyond requirements — extra game variants, console animations, XML export/import, iterative deepening or transposition tables in the AI, live board updates in web (htmx / polling), ASP.NET Core Identity, Docker / VPS deployment of the web app
  • Outstanding documentation
  • Creative solutions
  • Helping other students
  • Active participation

Grade Scale​

GradePoints
A (5)90-120
B (4)80-89
C (3)70-79
D (2)60-69
E (1)50-59
F (0)<50 or failed defense

Learning Outcomes ↔ Assessment Alignment​

Learning OutcomePrimary Assessment
L01: Describes the essence of .NET and its main technologiesDefense questions at D1–D3; A4 (EF Core), A6 (ASP.NET Core)
L02: Creates simpler applications or parts of larger solutions in C#A1–A6 (class libraries, console app, web app)
L03: Uses LINQ and .NET tools to obtain data from files, databases, XMLA3 (JSON files), A4 (EF Core + LINQ-to-entities), A5 (LINQ in move generation / evaluation)
L04: Works in a smaller teamSelf-organised group work, peer help in clinics and Teams; individual repository and defense

For the detailed mapping including teaching weeks and evidence requirements, see the Learning Outcomes ↔ Assessment Mapping section at the end of this page.

Reduced Curriculum (If A6 Web Is Condensed)​

If teacher decides (by Week 13) that the web part must be condensed, A6 becomes A6-lite: config CRUD in web, game list / create / continue, human vs human in two browser windows, and continuing a console-started game in web (DB only). Dropped from A6-lite: AI and AI-vs-AI in web, JSON ↔ DB switch in web. Defense points stay the same:

  • D1: 30 points
  • D2: 30 points
  • D3 (A6-lite + Full Demo): 40 points
  • Bonus: +20

D1 points (0–30) = 30 × (0.25×A1 + 0.50×A2 + 0.25×A3)/100
D2 points (0–30) = 30 × (0.40×A4 + 0.60×A5)/100
D3 points (0–40) = 40 × (0.50×A6-lite + 0.50×Demo)/100 — the demo then emphasises console-side AI and persistence, cross-play still required in the console → web direction

Defense Logistics​

Schedule (Full Curriculum)

  • D1 (Weeks 6-7, Fri 09.10 and 16.10): Menu library + Console game + JSON persistence - A1 + A2 + A3 (30 points). Retake Fri 23.10 (Week 8)
  • D2 (Weeks 11-12, Fri 13.11 and 20.11): EF Core + Repository + AI opponent - A4 + A5 (30 points). Retake Fri 27.11 (Week 13)
  • D3 (Weeks 16-17, Fri 18.12 and January extra day): Razor Pages web app + Full demo - A6 + Demo (40 points). Retake on the second January extra day (Week 18)
  • Code freeze: Thursday 23:59:59 before the first Friday of each period (08.10, 12.11, 17.12). The frozen commit is graded, whichever Friday you defend on.
  • Code must compile and run at defense. If the latest commit does not compile or the application does not start:
    1. Fallback: The student may request to use the earlier commit in their repository. Students are encouraged to tag a known-good commit before each defense.
    2. Hotfix window: If no tagged commit exists, the student has a one-time 10-minute window to fix compilation issues on the spot. The timer starts when the TA identifies the issue.
    3. If neither produces a running application: The assignment receives 0 points for that defense.
  • Code defense is done using the student's own laptop. SQLite and Kestrel run locally — no VPS, no cloud
  • Defense slots are allocated via register.proxy.itcollege.ee — book a slot on either Friday of the period
  • Students must bring their own laptop to defense
  • 4 TA-s and the teacher are working in parallel, be prepared to wait for your turn. Hours on defense Fridays may be extended beyond 12:00 when needed
  • Remote defense or off the hours defense are possible, but require prior agreement

Format

  • D1: 10-15 minutes per student (Menu library + Console game + JSON persistence)
  • D2: 15-20 minutes per student (EF Core + Repository + AI opponent)
  • D3: 20-30 minutes per student (Web app + full demo of the whole solution)
  • Student presents work (3-5 min) — show it running, not slides
  • TA asks questions and may request a small live change (e.g. change the win length, switch persistence from JSON to DB, add a difficulty level)
  • Points awarded immediately after defense
  • Points are recorded in Moodle gradebook within 2 working days
  • If a student disagrees with the awarded points, they must contact the teacher (not the TA) within 5 working days via email (andres.kaver@taltech.ee). The teacher will review the code, git history, and if necessary conduct a brief re-defense. The teacher's decision is final.
  • Overall course grade is published in ÕIS after all defenses (including retakes) are complete

D3 Full Application Demo Requirements

  1. Fresh clone of your repository → dotnet build → dotnet test — green
  2. Console: create a game from a preset and from a custom configuration, play human vs human, save, exit
  3. Web: list games, continue the game saved from console, play human vs human in two browser windows (two different player links)
  4. Show the JSON ↔ DB switch (couple of lines or a config value); a JSON-saved console game loads in web
  5. Human vs AI and AI vs AI in both console and web, with difficulty selection; AI answers within its time budget
  6. At least one of your mandatory custom-rule extensions demonstrated live (e.g. a win across the cylinder edge, a wall in Reversi, flying in Nine Men's Morris)
  7. Show the tests, the migrations, the repository interfaces and the DI registration
  • No slides - show the actual working application and code structure
  • Be prepared for TA to request specific scenarios
  • README and AI usage log present in the repository

Defense Assessment Rubric

All defenses are assessed using these five dimensions:

DimensionWhat TAs evaluate
Functionality & rules correctnessRuns from a clean clone; assigned game and its mandatory extensions are correct; presets exist; every play mode required at this defense works
Architecture & reuseMenu library / game engine / DAL / UI separation; interface-based repositories; dependency direction; zero duplicated game logic between console and web
Data & algorithmsD1: JSON round-trip of configs and games. D2: EF model and migrations, JSON and EF behave identically, minimax + alpha-beta + evaluation + difficulty. D3: cross-play, parallel games, AI in web
Testing & code qualityxUnit tests exist and pass; nullable warnings as errors; naming, conventions, project organization, meaningful git history
Explanation & understandingAbility to explain any line of code without AI assistance; perform a requested live change; explain trade-offs (JSON vs DB, search depth vs time, stateless web requests)

TA Calibration: All TAs use the same rubric and scoring guidelines. Before each defense period, TAs complete a calibration session with the teacher using sample submissions (one per game). The five games differ in rule complexity — calibration accounts for that, the rubric does not change. Borderline cases (within 2 points of a pass/fail threshold) are escalated to the teacher for a second review if needed.

Passing Rules

  • Each defense requires >50% of its points to pass
  • Failing ANY defense = failing the course (regardless of total points)

Retake Policy

  • Only ONE retake allowed in total (across all defenses)
  • Retake is only possible if defense failed (<50%)
  • Retake penalty: maximum 75% of original points available
  • Retake must be completed before the next defense period starts:
    • D1 retake: Week 8 (before D2)
    • D2 retake: Week 13 (before D3)
    • D3 retake: Week 18 (second Extra Defense Day)
  • Students needing retakes should aim for bonus points to compensate for the penalty
  • Retake is on the Friday following the two-week defense period (one day only)

For example: Student passes D1, fails D2, uses retake, then fails D3 → course fail (because no retake left + must pass all defenses).

Bonus Points (up to 20)

  • Awarded at TA/teacher discretion throughout the course
  • Can be given during any defense or for overall performance
  • Bonus points added to final total after all defenses complete

Students with special needs​

Students with special needs are encouraged to contact the instructor at the beginning of the course. If special needs may affect participation or assessment, the instructor should be informed at the beginning of the course so appropriate accommodation can be arranged. Students may also contact the university support services for accessibility arrangements. All requests will be handled confidentially.

AI Usage Policy​

AI usage is permitted and encouraged. Teacher uses AI in his everyday work constantly. AI theory, principles or usage is not taught or discussed in this course (at least not officially)

  • Look into Agentic Software Development course materials
  • All your coursework will be graded orally, you are personally responsible for any artifacts and achieved learning results

Encouraged (permitted)

  • Using AI for code generation with proper specifications (Claude Code, Codex, PI Agent , etc.)
  • Spec-driven development: write specifications first, let AI generate implementation
  • Learning from AI explanations of language features and patterns
  • Debugging with AI assistance
  • Documentation generation

Required documentation

  • Keep prompts/specs used (a short AI usage log in the repository)
  • Note what AI got wrong
  • Describe your modifications
  • Alternative solutions considered

Not acceptable (defense fail)

  • Submitting AI code without actual understanding
  • Copying without verification
  • Unable to explain your codebase without AI assistance
  • Cannot explain WHY the repository / DI / minimax was designed the way it is in your code

Academic Integrity​

You are allowed to use any source for your work, citations are not mandatory. Wide usage of AI is allowed (expected). Self organized group work is allowed (each student must maintain their own code repository). You are allowed to use external code (ai, external help, etc.). Personal requirements apply - code in git, tests, individual defense. Third-party code/assets must follow their license terms.

But you must be able to explain your work/code individually in minute details and defend it in front of the teacher and TA's - without external/ai help.

No animals were harmed during the making of this course. Except my dog, who was harmed by me not having enough time to play with him.

Planned Lectures Content (Prerecorded Videos)​

Week 1: Intro + Tooling + C# Refresher + Console (4 videos, ~90 min total)​

Video 1.1: Course Introduction (15 min)

  • Flipped classroom format, how to use the Friday clinic
  • Three defenses, points, grade scale, retake rule
  • Your game by student code, one repository, README, code freeze
  • AI policy — encouraged, but you explain every line

Video 1.2: .NET 10 & C# 14 Landscape + Tooling (25 min)

  • Runtime, BCL, SDK; .NET Framework vs modern .NET vs Mono / .NET Standard (L01)
  • dotnet new, build, run, test, sln, add reference; NuGet
  • JetBrains Rider tour: solution explorer, run configurations, debugger, database tool
  • global.json, .gitignore, Directory.Build.props with <Nullable>enable</Nullable> and <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  • Git workflow (server and repository setup: Git usage)

Video 1.3: C# Refresher (30 min)

  • Top-level statements, value vs reference types, var
  • Strings, interpolation, parsing user input safely
  • Control flow, switch expressions, pattern matching basics
  • Methods, parameters, tuples, expression-bodied members
  • Console API: ReadKey, cursor position, colours, Clear, OutputEncoding for Unicode pieces

Video 1.4: Solutions, Class Libraries and Menu Design (20 min)

  • Multi-project solution, project references, public API surface
  • Designing a menu library: nested menus by recursion, hot keys, mandatory items per level
  • Why the menu library must not know about the game

Week 2: OOP (4 videos, ~95 min)​

Video 2.1: Classes and Members (25 min)

  • Fields, properties, auto-properties, init, required
  • Constructors, primary constructors, static members
  • Access modifiers, namespaces, assemblies, nested classes

Video 2.2: Inheritance, Interfaces, Generics (25 min)

  • virtual / override / abstract / new
  • Interfaces and default members
  • Generic classes, methods and constraints
  • IGameBrain-style abstractions for later assignments

Video 2.3: Nullable, Records, Structs (25 min)

  • Nullable value types and nullable reference types; ?., ??, ??=, !
  • Late initialization patterns that keep the compiler happy
  • record, record struct, with expressions — immutable configurations
  • struct vs class, tuples, boxing

Video 2.4: Delegates and Lambdas for Menu Actions (20 min)

  • Delegates, Func, Action, Predicate
  • Lambdas and closures
  • Events (short)
  • Wiring menu items to actions, returning "what happened" from a menu

Week 3: Collections, Generics, LINQ + Game Engine Design (4 videos, ~95 min)​

Video 3.1: Arrays and Collections (25 min)

  • 1D, 2D ([,]) and jagged ([][]) arrays — picking a board representation
  • List, Dictionary, HashSet, Stack, Queue — move history, lookup tables
  • Copying and cloning collections (why your AI will care)

Video 3.2: Generics and Iterators (20 min)

  • IEnumerable<T> / IEnumerator<T>, yield return
  • Indexers, IComparable<T>, IEquatable<T>
  • Extension methods

Video 3.3: LINQ (25 min)

  • Method syntax vs query syntax, deferred execution
  • Where, Select, Any, All, Count, First, OrderBy, GroupBy, Aggregate, Zip
  • Scanning lines on a board with LINQ — and when a plain loop is better

Video 3.4: Game Engine Design (25 min)

  • Configuration vs state vs rules vs UI
  • Immutable configuration, MakeMove with validation, win / draw detection, turn handling
  • Hot-seat loop in console
  • Designing the API so that AI (A5) and persistence (A3/A4) plug in later
  • Per-game notes: grids (Connect Four, Gomoku, Reversi, Tic-Tac-Two) vs a graph of points (Nine Men's Morris)

Week 4: JSON + File IO + Persistence Design (3 videos, ~85 min)​

Video 4.1: System.Text.Json (30 min)

  • JsonSerializer.Serialize / Deserialize, JsonSerializerOptions
  • Enums as strings, records, [JsonIgnore], [JsonPropertyName]
  • int[,] is not supported → jagged arrays or flat array + width
  • XML awareness: XmlSerializer in 3 minutes (L03)

Video 4.2: File, Directory, Path (20 min)

  • Cross-platform paths, user home directory, app data folder
  • Listing saved games, safe (atomic) writes, IO exceptions

Video 4.3: Persistence Design (25 min)

  • What to store: configuration, state, move history, players, timestamps, ids
  • DTO vs domain object
  • IConfigRepository / IGameRepository contracts, CRUD semantics, naming and ids, versioning
  • The same contract will be implemented with EF Core in A4

Week 5: Testing, Exceptions, Debugging, Code Quality (4 videos, ~90 min)​

Video 5.1: xUnit (25 min)

  • Test project, [Fact], [Theory], [InlineData], Assert, naming
  • Testing win detection, invalid moves and each custom-rule extension
  • dotnet test and the Rider test runner

Video 5.2: Exceptions and Validation (20 min)

  • try / catch / finally, custom exceptions
  • Throw vs return a result object, guard clauses
  • Validating configurations

Video 5.3: Debugging in Rider (20 min)

  • Breakpoints (conditional), watches, step in / over / out, evaluate expression
  • Common board bugs: row/column swap, off-by-one, cylinder wrap

Video 5.4: Code Quality and D1 Preparation (25 min)

  • Naming, SOLID-lite, project layout, README
  • Git hygiene, tags as fallback
  • D1 rubric walk-through and typical TA questions

Week 6: EF Core Intro (1 video, ~40 min)​

Video 6.1: Entity Framework Core Intro (40 min)

  • ORM concept, packages, DbContext, DbSet, entity classes
  • SQLite provider and connection string
  • dotnet ef tool, first migration, database update
  • Browsing the database in Rider

Week 7: EF Core Deeper (3 videos, ~90 min)​

Video 7.1: Entities and Relationships (30 min)

  • Primary and foreign keys, one-to-many (Configuration → Games), navigation properties
  • Required / optional, data annotations vs Fluent API, indexes, max length, cascade delete

Video 7.2: Migrations, Change Tracking, Querying (30 min)

  • Migration lifecycle, Add / Update / Remove / SaveChanges
  • AsNoTracking, Include (eager / explicit / lazy), projections
  • Logging SQL, async variants

Video 7.3: Storing Game State (30 min)

  • Serialized JSON column vs normalized move table vs both
  • Keeping ids stable between JSON files and DB, DateTime / UTC
  • Seeding preset configurations

Week 8: Repository Pattern + Dependency Injection (3 videos, ~90 min)​

Video 8.1: Repository Pattern (30 min)

  • Interfaces in the shared library, JSON and EF implementations with identical behaviour
  • Contract tests that run against both implementations

Video 8.2: Dependency Injection in Console Apps (30 min)

  • Microsoft.Extensions.DependencyInjection / Hosting, service lifetimes
  • appsettings.json, swapping persistence with one line or a config key

Video 8.3: Solution Layering (30 min)

  • MenuSystem, GameEngine (domain), DAL.Json, DAL.EF, ConsoleUI, Tests
  • Dependency direction, no cycles
  • Preparing for the WebApp project to reference the same libraries

Week 9: Game AI — Theory and Implementation (4 videos, ~95 min)​

Video 9.1: Game Trees and Minimax (25 min)

  • Perfect-information zero-sum games, terminal states, depth, branching factor per game

Video 9.2: Alpha-Beta Pruning (25 min)

  • Worked example, move ordering, complexity, cut-off

Video 9.3: Implementing in C# (30 min)

  • GetLegalMoves, apply / undo vs clone, negamax form, depth limit
  • IMoveProvider abstraction (human / AI) shared by console and web

Video 9.4: Testing the AI (15 min)

  • Deterministic tests: takes the immediate win, blocks the immediate loss, only legal moves
  • Seeded randomness, timing assertions

Week 10: Evaluation, Difficulty, Performance, Async (4 videos, ~90 min)​

Video 10.1: Evaluation Functions per Game (30 min)

  • Connect Four: windows of N
  • Tic-Tac-Two: lines inside the grid, grid mobility
  • Reversi: corners, mobility, stability, parity
  • Gomoku: open / closed threes and fours
  • Nine Men's Morris: pieces, mills, mobility, game phase

Video 10.2: Difficulty Levels (20 min)

  • Depth, random-move mixing, evaluation noise, time budget, iterative deepening
  • Optional: transposition table

Video 10.3: Performance (20 min)

  • Stopwatch and the profiler, allocations, structs vs classes, arrays vs LINQ in hot loops, cloning strategies

Video 10.4: async/await and Cancellation (20 min)

  • Task, async / await, CancellationToken, timeouts
  • AI-vs-AI loop with delay, keeping the console responsive
  • Groundwork for the web app

Week 11: HTTP + Razor Pages Intro (1 video, ~40 min)​

Video 11.1: HTTP and Your First Razor Page (40 min)

  • GET / POST, status codes, statelessness
  • ASP.NET Core project layout, Program.cs, Pages/, routing by file
  • dotnet run / Kestrel, first page with a model

Week 12: Razor Pages (4 videos, ~95 min)​

Video 12.1: PageModel and Handlers (25 min)

  • OnGet / OnPost, named handlers, route parameters
  • [BindProperty], model binding, Post-Redirect-Get

Video 12.2: Razor Syntax and Layout (25 min)

  • Expressions, code blocks, control structures, directives
  • _Layout, sections, _ViewImports, _ViewStart

Video 12.3: Tag Helpers and Forms (25 min)

  • Form / input / select / label / validation helpers
  • asp-page, asp-route-*, asp-page-handler
  • Validation attributes, ModelState

Video 12.4: Scaffolding + Async in Web (20 min)

  • Scaffolding CRUD pages for configurations
  • Async handlers, EF Core async

Week 13: Razor Pages + EF Core + DI + Reuse (3 videos, ~90 min)​

Video 13.1: Wiring the Libraries (30 min)

  • Registering DbContext and repositories in web DI, appsettings.json
  • Migrations from the web project, the same DAL as console

Video 13.2: Rendering the Board (30 min)

  • Loops in Razor, table / CSS grid, clickable cells via links or forms with route values
  • Highlighting last move / winner, game-over state
  • Multi-step moves (Nine Men's Morris, Tic-Tac-Two grid move)

Video 13.3: Request Lifecycle and State (30 min)

  • Load → apply move → save per request, game id in the URL
  • TempData / ViewData, error pages, basic concurrency awareness

Week 14: Web Game Flow (3 videos, ~90 min)​

Video 14.1: Parallel Games and Players (30 min)

  • Game list, create / join
  • Per-player secret link (GUID token) or username / password DIY auth
  • Whose-turn checks, spectator view

Video 14.2: Partial Views and AI in Web (30 min)

  • Partials for board and status, auto-refresh (meta refresh / small JS poll / optional htmx)
  • Triggering the AI move on POST, time limits, AI-vs-AI stepping

Video 14.3: Cross-play Console ↔ Web (30 min)

  • Same repository and ids, save format compatibility, round-trip test
  • Switching JSON / DB in web

Week 15: Polish + Demo Preparation (3 videos, ~75 min)​

Video 15.1: Validation, Errors, UX (25 min)

  • Server-side validation, friendly errors, logging, seeding presets
  • Edge cases: draws, pass moves in Reversi, flying in Nine Men's Morris

Video 15.2: Testing the Web Layer Lightly + AI Usage Log (20 min)

  • Optional WebApplicationFactory smoke tests
  • What to put in the AI usage log

Video 15.3: D3 Checklist and Retrospective (30 min)

  • Demo script, tagging, README, typical D3 questions
  • What continues in Web Applications with C# (ICD0024)

Assignments (A1–A6) and grading​

  • The course is assessed through six project assignments (A1–A6) plus the final demo. Each is graded on a 0–100 scale and recalculated into defense points according to the defense weighting. Grading is done by the TA and/or teacher; in case of dispute, the teacher's decision is final.
  • Testing is cross-cutting: xUnit tests are introduced in A2 and must be maintained and extended in all subsequent assignments. There is no separate testing assignment.
  • A1 is standalone, A2–A6 are cumulative — one solution, growing every assignment.

Detailed technical requirements, checklists and rubrics are published in the course home page for each assignment.

Project technical requirements​

  • Repository: one git repository per student. The git server, repository naming and setup are defined in Git usage. README.md with your full name, student code, school email, uni-id and assigned game. Use a proper .gitignore (Visual Studio + Rider).
  • Tooling: .NET 10 (LTS), C# 14, JetBrains Rider. The solution must build with dotnet build and pass dotnet test from a fresh clone. No absolute local paths; the SQLite file lives in a relative or user-home location.
  • Nullable warnings as errors on solution level is mandatory (Directory.Build.props).
  • Menu system in a separate class library, supporting unlimited depth of menu levels. First level mandatory items - exit. Second - exit, return to previous. Other levels - exit, return to previous, return to main. Menu must support user actions (delegates), updateable labels based on user interaction, not allow identical hot keys, etc. Menu item selection either via regular input (with validation) or cursor based "console gui". The library must not reference the game — it is reusable in any console app.
  • Game: your assigned game with its mandatory custom-rule extensions. Configurations can be precreated (presets, seeded) and selected; user configurations have full CRUD and are validated.
  • Play modes: human vs human hot-seat (players take turns behind the same PC), human vs AI, AI vs AI — in console from A5, in web from A6.
  • CRUD for configurations and game states (save, list, load / continue, delete) using both JSON text files and an EF Core database (SQLite is fine). Interface-based repositories — switching between file system and database should take just a couple of modifications in code (or a config value).
  • AI: minimax with alpha-beta pruning and an evaluation function, at least 3 difficulty levels. The UI must not freeze (time budget / cancellation). Roughly ≤ 5 seconds per move at the highest level on a laptop.
  • Web: ASP.NET Core Razor Pages. Unlimited amount of active parallel games, players in different browsers / tabs. Reuses the game engine and DAL class libraries — no copy-pasted logic. A game started in console can be continued in web and vice versa. No ASP.NET Core Identity required: DIY per-player links, a username, or a per-game password are all acceptable (Identity = bonus).
  • Tests: xUnit project. Game-rule tests from A2, repository contract tests from A4, AI tests from A5.
  • All deadlines are in Tallinn local time (Europe/Tallinn). Written language is English (code, comments, README, commits).

Your game - assigned by student code​

Take the last digit of the numeric part of your student code (e.g. 2234566IADB → 6) and integer-divide it by 2:

Last digitGameRulesMandatory custom-rule extensionsPreset configurations (seeded)
0, 1Connect FourWikipedia, Hasbro instructions(1) Board width, height and winning connection length are configurable. (2) Board is either a rectangle or a cylinder — columns wrap around, so a winning line may cross the side edge.Classic 7×6 / 4 · Connect3 5×4 / 3 · Connect5 9×7 / 5 · Cylinder 7×6 / 4
2, 3Tic-Tac-TwoReview with rules, GamesCrafters, Video(1) Board N×N, movable grid M×M (M ≤ N), winning length W (W ≤ M) and pieces per player P are all configurable. (2) Unlock threshold — the number of pieces a player must place before moving the grid or moving a piece is allowed.Classic 5×5, grid 3, win 3, 4 pieces, unlock 2 · Big 7×7, grid 4, win 4, 6 pieces, unlock 3 · Tiny 4×4, grid 3, win 3, 3 pieces, unlock 1 · Plain 3×3, grid 3 (= tic-tac-toe, handy for AI tests)
4, 5Reversi / OthelloWikipedia, World Othello rules(1) Board size configurable (even, 4–16, rectangle allowed) and opening variant (Othello fixed diagonal start vs Reversi free placement of the first four). (2) Blocked cells (walls) — a configurable set of unplayable cells; flanking cannot pass through a wall.Othello 8×8 · Mini 6×6 · Reversi 8×8 free opening · Walls 8×8 with 4 blocked cells
6, 7GomokuWikipedia(1) Board size (9–19, rectangle allowed) and winning length (4–6) are configurable. (2) Overline rule toggle — exactly N wins (standard) vs N-or-more wins (free-style). Optional: pro opening (first move in the centre, first player's second move at least 3 away).Free-style 15×15 / 5 · Standard 15×15 exact-5 · Small 9×9 / 4 · Pro 19×19 / 5 with opening rule
8, 9Nine Men's MorrisWikipedia(1) Variant family — pieces per player and board topology (Three / Six / Nine / Twelve Men's Morris; Twelve adds diagonals). (2) Flying threshold (fly at 3 pieces, at 4, or disabled) and a "may remove from a mill when no free piece exists" toggle. Note: the board is a graph of points with adjacency and mill lists, not a grid; moves are multi-step (select, destination, capture).Nine classic · Twelve (diagonals, no flying) · Six · Three

All five are perfect-information games, so minimax / alpha-beta applies to every one of them. The games differ in rule complexity; TA calibration accounts for that, the rubric is the same for all.

A1 – Menu system class library (Weeks 1–3)​

Goal: Build a reusable console menu library (unlimited depth, mandatory items per level, delegates for actions, updateable labels, unique hot keys, validated input or cursor-based navigation) and a small console application demonstrating it.

Scope note: The library must not know anything about your game. You will reuse it unchanged in A2–A5.

Prerequisite: repository created and named correctly, README filled, teacher and TAs added, nullable warnings as errors enabled.

Evidence (submission): menu library project, demo console app, git history.

Expected submission time: end of Week 3.

Indicative grading (100): menu behaviour 50 · demo app 15 · code quality (nullable-as-errors, no game references, naming) 20 · git + README 15

A2 – Console game: configuration, board, game brain, hot-seat (Weeks 3–5)​

Goal: A playable version of your assigned game with its mandatory custom-rule extensions: configuration UI with validation and presets, board UI in console, game brain (rules, move validation, win / draw detection), human vs human hot-seat play using the A1 menu.

Scope note: Game engine in its own class library; console UI in a separate project. This is the load-bearing assignment of the console phase — later assignments only add persistence and AI around it.

Prerequisite: A1.

Evidence (submission): engine library, console app, xUnit tests for the rules and for each extension.

Expected submission time: end of Week 5.

Indicative grading (100): rules + mandatory extensions 35 · configuration UI + validation 15 · board UI + hot-seat flow 20 · unit tests 15 · code quality 15

A3 – JSON persistence and CRUD (Weeks 4–5)​

Goal: Save, list, load / continue and delete both configurations and game states using JSON text files, behind repository interfaces defined in the shared library.

Prerequisite: A2.

Evidence (submission): DAL.Json project, repository interfaces in the shared library, saves stored in a user directory, round-trip tests.

Expected submission time: end of Week 5.

Indicative grading (100): configuration CRUD 30 · game state CRUD (save / load / continue / delete) 40 · interface-based design 15 · tests + code quality 15

A4 – EF Core persistence + interface-based repository (Weeks 6–8)​

Goal: The same CRUD on an EF Core database (SQLite is fine) with migrations. Switching between JSON and DB takes a couple of lines of code or a config value. Repositories are registered through Dependency Injection.

Prerequisite: A3 interfaces.

Evidence (submission): DAL.EF project, migrations folder, contract tests running against both implementations, DI registration in the console app.

Expected submission time: end of Week 8.

Indicative grading (100): EF model + migrations + SQLite 30 · EF repository implementation 30 · one-line / config switch 20 · contract tests on both implementations 10 · code quality 10

A5 – AI opponent (Weeks 8–10)​

Goal: Minimax with alpha-beta pruning and an evaluation function for your game, at least 3 difficulty levels, human vs AI and AI vs AI in console, with a responsive UI (time budget / cancellation).

Prerequisite: A2 move generation.

Evidence (submission): AI in the engine library (or a separate library), AI tests, short timing notes in README.

Expected submission time: end of Week 10.

Indicative grading (100): minimax 25 · alpha-beta 15 · evaluation function 20 · difficulty levels 10 · human vs AI + AI vs AI + responsive UI 15 · AI tests 10 · code quality 5

A6 – Razor Pages web app (Weeks 11–15)​

Goal: Implement the same game as an ASP.NET Core Razor Pages web application, reusing the engine and DAL libraries: configuration CRUD, unlimited parallel games (players in different browsers / tabs), all play modes, per-player links or simple DIY auth, cross-play with console.

Prerequisite: A4 + A5.

Evidence (submission): WebApp project running locally, README with run instructions, AI usage log.

Expected submission time: end of Week 15.

Indicative grading (100): runs on reused libraries, no duplicated logic 25 · configuration CRUD in web 10 · parallel games: create / join / list 20 · all play modes in web 20 · JSON / DB switch in web 10 · code quality + UX 15

D3 demo (100, weighted 30% of D3): cross-play console ↔ web 30 · all modes in both UIs 20 · presets + extensions shown live 15 · dotnet test green from fresh clone 15 · README + AI usage log + git history 20

Learning Outcomes ↔ Assessment Mapping​

Learning Outcome (from ÕIS)Where TaughtWhere AssessedEvidence
L01: Describe the essence of .NET Framework and its main technologiesWeek 1 (runtime, SDK, BCL, NuGet), Weeks 6–8 (EF Core), Weeks 11–13 (ASP.NET Core)D1–D3 defense questions; A4 (EF Core), A6 (ASP.NET Core)Multi-project solution, migrations, running web app; explanation of what runtime / SDK / EF Core / Kestrel do
L02: Create simpler applications or parts of larger software solution in C#Weeks 1–3 (language, OOP, engine design), Week 8 (layering, DI), Weeks 12–14 (Razor Pages)A1–A6Class libraries reused by two different front-ends (console and web)
L03: Create LINQ queries and use .NET tools to obtain data from XML, database servers, filesWeek 3 (LINQ), Week 4 (JSON / files, XML awareness), Week 7 (LINQ-to-entities)A3 (files), A4 (database), A5 (LINQ in move generation / evaluation), A6Repositories, LINQ queries in engine and DAL, tests. XML is awareness-only; XML export earns bonus
L04: Work in a smaller teamFriday clinics, MS Teams peer help, self-organised group workIndirectly: bonus points for helping others; every student keeps an individual repository and defends individuallyNote: assessment is individual on purpose — the team skill is practised, not graded

Note on ".NET Framework" in L01 and L03: The ÕIS text predates modern .NET. This course reads it as ".NET" (the cross-platform runtime, .NET 10) and mentions the legacy .NET Framework only for context.