Running a game incubator inside a university

The KBTU GameLab incubator has launched six game projects so far. Three of those are currently being published on Steam. The programme runs inside a university, which changes the maths in a few specific ways.

Selection

The biggest single decision is which projects get in. I look for three things, roughly in order:

1. A team that will still be a team in six months. Skill matters less than whether these people have shipped anything together and are likely to keep showing up when it stops being fun.
2. A scope that fits the calendar. A university incubator runs on semesters. A two-year idea is the wrong idea; a six-month idea with a playable demo at the end is the right one.
3. Something specific that's good. Not "a good game" — a specific thing that's good. A mechanic, a mood, a hook. Projects without one tend not to survive contact with their own second month.

Mentorship

Mentorship in an incubator is mostly about unblocking and calibrating, not teaching. These teams are adults. What they need from me is a steady read on whether their current week was productive or performative, and where external expertise — artist, composer, legal — would pay for itself.

The academic calendar

The awkward truth about running this inside a university is that the calendar fights you. Exam weeks, registration, holidays — the developer brain can't easily ignore what the student brain is dealing with. The fix is boring: plan around it. Don't schedule milestones against the weeks you know are going to be half-weeks.

Steam as the proof

Three of six projects reaching Steam isn't "three out of six succeeded"; it's three of six crossed a high, specific bar that most incubator projects don't. That's the right bar to optimise for. Internal demo days are worth something, but "shipped on Steam" is a much harder thing to fake.