Szoftvertechnológia
Software Technology
The goal is to see a whole software development process, not just the programming: planning and modelling, version control as a team, continuous integration, testing and review. The game is the vehicle.
The sessions simulate a scrum team: there are no separate exercises – everyone works on the team's game, each week every member answers three questions, and at each milestone the team demos its work. The pages below follow the milestones and add the guides the team needs along the way.
Hall of Fame
Highlighted projects from earlier semesters
The best projects of the course on the course GitLab – see what a finished game, its repository, issues and pipeline look like before you plan yours.
Requirements
What it takes to complete the practice part. Dates and deadlines are on Canvas.
Team project
Teams of three, at most four – every team builds the same game
One language per team. Java and C# get the most support; other languages and engines are possible, with less help.
Milestones
Four milestones, each scored 0–10 per person
At least 4 points on every milestone. The practice grade is the average of the four.
GitLab activity
Everyone works from their own account
Only your own work can be graded. From the second milestone your issues, commits, branches and merge requests weigh heavily.
Weekly scrum
Three questions, every week, from everyone
What have you done since last week? What will you do by next week? Is anything blocking you?
Lecture tests
A mid-semester and an end-of-semester test
Two thirds of the questions must be right. The result does not change the grade, but passing both is a condition of getting one.
The final milestone also needs a short gameplay video, and from the third milestone the CI has to run a static-analysis code-quality check.
Sessions
Open a session here, or on its own page in a new tab.
Session 1
Kick-off: the course, the teams, the tools
How the semester runs: teams of three (at most four) build the same game through four milestones that simulate sprints, with a weekly three-question scrum, GitLab as the project hub and individual scores from 0 to 10.
Milestone 1
Requirements and design: use cases, class and database diagrams
Milestone 1, without code: turn the specification into use cases and user stories with acceptance criteria, and design a model–view class diagram and a database diagram on the GitLab wiki.
Milestone 2
Working as a team in git: issues, branches, merge requests
Milestone 2: the team workflow – protected main and develop, a branch per issue, commit messages checked by git hooks, labelled issues on a board, and reviewed merge requests merged with merge commits.
Milestone 3
Continuous integration: pipelines, unit tests, static analysis
Milestone 3: a pipeline on every merge request – format check, build, unit tests with coverage and static analysis – for Java, .NET and Unity, plus how to read a red job and run the same checks locally.
Milestone 4
The final product: clean code, tests, release
Milestone 4: finish against the Definition of Done – clean code, edge- and failure-case tests, high model coverage – then release through a release branch and a tag, and present a demo and a gameplay video.
Guides
Stand-alone pages: references, background reading and fixes for common problems.
Guide
Setting up the team repository
A one-time checklist for the team's GitLab project: template, protected branches, merge request rules, labels, board, milestones, CI badges and a smoke test – with the GitHub equivalent of every setting.
Cheat sheet
An issue from start to merge, with commands
A cheat sheet to keep open: every step from creating an issue to cleaning up after the merge, with the git commands, how to bring develop into your branch, and fixes for the usual accidents.
Guide
Code review: how to write it and how to take it
What a reviewer checks and in which order, how to write comments marked by weight, how to answer a review, how big a merge request should be, and how to rotate reviewers in a team of three.
Reading
How this maps to industry practice
The course workflow next to real companies, from startups to enterprises: what is the same everywhere, what changes with size, trunk-based vs Gitflow-style branching, and the terms you will hear as an intern.