Game design is a specification and iteration discipline rather than an ideas role.
Documentation
Writing down how systems work in enough detail to be built.
Which is most of the job.
Balancing
Numerical tuning across interacting systems.
Which is spreadsheet work as much as intuition.
Playtesting
Watching people play and identifying what is not working.
Specialisms
Systems, level, narrative, combat and economy designers.
Which are distinct roles in larger teams.
Why the ideas are the easy part
Every team has more ideas than it can build, and the constraint is never coming up with them.
Which means the job is choosing which to pursue, specifying them precisely enough to be implemented, and then finding out through testing that most of them do not work as intended.
A designer spends far more time removing and revising than inventing.
Working with engineers and artists
Specifications that can actually be built within the schedule.
Which requires understanding what things cost.
Prototyping
Rough versions to test a mechanic quickly.
Which is the fastest way to find out something is not fun.
Data-driven design
Telemetry informing tuning decisions.
Which supplements judgement rather than replacing it.
Getting into it
Small finished projects rather than large unfinished ones.
What a working day looks like
Writing and revising specification documents, tuning numbers in spreadsheets, reviewing implementations, running playtests and arguing about scope.
Which is unglamorous and is the actual work.
The proportion of time spent on creative invention is small, and most of it happens early in a project.
Cutting features
Deciding what does not get made.
Which is a designer's most consequential and least enjoyable responsibility.
Working within technical limits
Designs constrained by what the engine and the platform allow.
Documentation discipline
Specifications that stay current as things change.
Which is difficult and matters enormously on large teams.
Portfolios
Small completed games demonstrating judgement.
The misconception worth correcting
Design is frequently imagined as the role that decides what the game is, when it is mostly the role that works out whether what everyone hoped for actually functions.
Which involves being wrong repeatedly and in public, and revising accordingly.
Designers who cannot abandon their own ideas quickly tend not to last.
Numbers and spreadsheets
Economy, progression and combat tuning as quantitative work.
Which surprises people entering the field.
Communication
Explaining intent clearly to people who will build it.
Which is the most transferable skill in the role.
Different studio sizes
Broad responsibility on small teams, narrow specialism on large ones.
Learning it
Making small things and finishing them.
A note on how this industry reports itself
Games is an unusually opaque business for one with such a visible product. Budgets are rarely disclosed, sales figures are announced selectively, player numbers are quoted in whichever metric flatters, and profitability is almost never stated at all.
Most of what is publicly known comes from court filings, leaked documents, regulatory submissions and former employees speaking after the fact. That material is reliable when it exists and covers a small fraction of the industry, which means any general claim about how games perform commercially rests on a limited and non-random sample.
Why the production side is worth understanding
A great deal of frustration with games comes from decisions that look inexplicable from outside and are entirely predictable once the structure is visible. Why a game shipped unfinished, why a beloved studio was closed after a successful release, why a sequel dropped features the previous game had, why a service shut down two years in.
None of these are mysteries. They are the outcomes of funding structures, platform economics, portfolio decisions and the fact that games are made by people working to schedules set before anyone knew what the game would be. Knowing that does not make the outcomes better; it does make them legible.
Where the better information is
Developer conference archives are the single best public source on how games are actually made, and a large number of talks are freely available. Regulatory filings during acquisitions have disclosed more real financial detail than a decade of press releases. Trade publications with named industry sources are considerably more informative than consumer coverage on business questions.
One thing worth remembering
Games are made by people, mostly people who care a great deal about them, working inside commercial structures they did not design and frequently cannot change.
Criticism of a game is fair. Criticism of the decisions behind it is usually aimed at the wrong floor of the building, and the people who take it are rarely the people who made them.
Further reading
Developer conference archives, postmortems written by the people who shipped the projects, and trade reporting with named industry sources are the three places where this material is covered properly and in public. All three are freely available, and none require any technical background to follow.