Game Development

A reader who has never programmed has several ways in. Make Games for Playdate with Lua calls itself perfect for beginners: it teaches Lua by building small games for a handheld console, and the console is not needed, since its development kit includes a simulator.[1] From Player to Creator (2026) is written for school-age readers and follows one game from idea to publication in Godot.[21] Two short books build a dungeon game in plain Python in the terminal, Build Your Own RPG Dungeon Crawler in Python with no engine and no artwork,[22] and The Dragons Code as a first programming course for complete beginners, children and parents included;[23] Python - A Space Adventure teaches a first language through a story and ends with a small space game.[24] Those who would rather not write code can begin with the course Code-less Game Design Workshop, which assembles a ball-and-brick game in Construct,[51] and Minecraft-learn from scratch (2021) introduces programming ideas to children inside a game they already play.[14]

Programmers should pick by what they already know. Beginning Game Programming with Go assumes Go and no experience of games;[2] Unity for Software Engineers is for professional software engineers and skips the introductory C# that other Unity material begins with;[3] Forge2D and Flame with Flutter: Create 2D Physics Games From Scratch expects Flutter and Flame,[6] and Game Engine Foundations With C++ expects C++.[5] For JavaScript there is a course from the first variable, Using JavaScript OLOO in game development,[44] and the sixteen-lesson Phaser III Game Design Course Workshop (2019), which builds one browser game in Phaser 3.[43]

The books for working professionals are about architecture and people rather than a first game. Development & Deployment of Multiplayer Online Games Vol. I (2017) addresses intermediate and senior developers and technical decision-makers;[7] Gear Up, 2nd Edition (2018) is for teams and their leads;[18] Outlast the Tools is for producers;[11] Practical Python for Production under Pressure is for technical directors who already use Python and Qt;[12] and The Guide to Computer Simulations and Games (2018) is for trainers and educators and does not assume the reader can program.[13]

Video games began in research laboratories around 1960, reached the public through arcades and home consoles in the 1970s, and for two decades were written close to the hardware by small teams. Through the 1990s the reusable engine separated from the game built on it, and in the 2000s engines such as Unity and Unreal were licensed widely enough that a small studio, or one person, could ship a game. The web browser became a platform twice: first through Adobe Flash, and then, as Flash was withdrawn in the 2010s, through HTML5 and JavaScript frameworks.

The library's books carry traces of each stage. One is a case study of a text adventure its author wrote in 1986 in assembly language for a supercomputer's input and output subsystem.[15] The author of a Unity book began around 2003 with Game Maker, a two-dimensional engine, and returned years later to a scene he found greatly changed.[3] The browser-game collections include chapters on converting old Flash games to JavaScript,[35] and the Go book rebuilds, at small scale, an independent game of 2022 that started a style of its own.[2] A book on roguelikes notes that the form has lasted forty years.[22] The newest books record a harder moment: one cites an industry survey of 2026 in which 28 per cent of game professionals reported having been laid off in the previous two years.[11]

A game differs from most programs in that it never waits: the loop runs every frame whether or not the player does anything. Make Games for Playdate with Lua introduces it by counting frames, then explains screen coordinates, with the origin at the upper left, and the build step that turns source code and assets into a file the console or its simulator can run. Its games grow from a version of table tennis to a turn-based role-playing game in the last two chapters, and it treats the console's limits in resolution, colour and input as an advantage for learning.[1] Beginning Game Programming with Go takes the same route for a programmer who wants no black boxes. It uses Ebitengine, a two-dimensional library that supplies a window, a loop, rendering, input and audio and deliberately nothing more, no editor, physics or scripting layer, and has the reader build the scene graph, camera, collisions and particles of one action game across fourteen chapters. Its case for Go is fast compilation, a single executable and easy cross-compilation, and its design chapter sets out exactly what the game being imitated does, down to weapons that fire by themselves so that the player's only job is to move.[2]

The smallest first games need no graphics at all. Build Your Own RPG Dungeon Crawler in Python builds a terminal game with a tile map, randomly generated dungeons, monsters and turn-based combat,[22] and The Dragons Code introduces each Python idea as a feature of its dungeon, lists for the inventory and functions for combat.[23] Python - A Space Adventure reaches a game loop, ship movement, collisions and sound only in its twelfth chapter.[24] Snake Game for the Web (2026) is a larger exercise, a worm game for the browser built in fourteen iterations with Node.js, a database and Docker, much of it the web application around the game.[25] Vibe Coding Video Games with Python (2026) asks a different question, whether someone with no knowledge can get such games from a language model by prompting: it has several models write Python imitations of classic titles and reports where they fall short.[26]

An engine supplies what every game needs so that a team writes only what is particular to its own. The shelf has one book each on several, and two on how an engine is made.

Stephen Gose's books and courses share one method and one vocabulary. He separates game mechanics, the rules, logic and data of a game, from game mechanisms, the visible components a framework provides to display them, so that the same mechanics can be dressed in different artwork or moved to another framework.[8] Genres, in his account, are defined by a common challenge and not by content or medium, and single-player and multi-player are not genres but modes of delivery.[10] Each book then takes one framework and one kind of game.

The design books on the shelf are practical ones. Phaser Game Design Workbook frames making a game as product management, from the concept and the business questions through a design document to distribution and marketing, and has the reader develop a game of their own beside the author's rather than copy it.[30] The combat workbook argues that the earliest decision, what kind of game a studio builds, shapes every later one, and that games with open-ended possibilities have historically been the hardest to schedule.[8] On genre the same author is cautious: a genre does not sell a game, but it tells an audience what to expect, and a designer who strays too far from those expectations loses the audience while one who stays too close is overlooked.[10]

The multiplayer series begins its own account with the design document, read from the point of view of a game that many people will play at once.[7] The simulation guide supplies the vocabulary underneath: the simulation gives the player something to manipulate, the mechanic, and the need to raise a score supplies the conflict.[13] And the 1986 text adventure shows how far design can be compressed: the whole state of the game was sixteen yes-or-no facts, worked out on paper first.[15]

Development & Deployment of Multiplayer Online Games Vol. I exists, its author says, because the practices that work in multiplayer games are known in the industry and rarely published: senior developers at different companies would confess to doing things against every book and discover they were all doing the same. The series treats everything from social games to massively multiplayer shooters, and stock exchanges with them, as one family. All of them exchange packets over the Internet, any of which may be lost; all have in practice two transport protocols to choose from, UDP and TCP; and their servers and databases resemble one another more than their clients do, the differences lying chiefly in how much delay each kind of game can tolerate.[7] The second volume takes up what to build and what to reuse, including the dependence that comes with adopting an engine, and an event-driven architecture for the client;[16] the third covers server-side architecture, the database server and fault tolerance, and was published as a beta its author put at about 80 per cent complete.[17]

Making Multiplayer Online Games (2021) approaches the same subject for browser games, a JavaScript client talking to a server over WebSockets, and as a business to be run.[19] Identity, Authentication and Gaming (2025) covers one service every online game needs. A single-player game on one device may need no login, it notes, but once a game spans devices or is played with others, accounts and permissions have to be built, and the login is the front door to the game.[20]

Gear Up, 2nd Edition collects more than a hundred practices contributed by veterans of game studios, on how teams work day to day, on coaching and leadership, on iterations and risk, and on the environment a studio provides.[18] Practical Python for Production under Pressure is about the tools behind the artists. Its author compares writing pipeline software for film and games to working in a pit crew, where getting the driver back out is the first priority, and defends Python for the purpose on grounds other than speed: flexibility, integration with the existing software, a low barrier to entry and ease of distribution. The sampled chapters are on frontline tools and the code debt they leave, on shipping a rough tool now and a proper one later, and on managing one's own workload.[12]

The newest books are about what language models change. Outlast the Tools (2026) sets two tests for any use of AI in production, whether it makes the work better for the team and whether it makes the product better for players, and distinguishes both from productivity. Its concern is how judgement forms. A producer learns, it argues, through mistakes that are costly enough to teach and cheap enough to survive, made in junior roles under a senior's eye; layoffs have removed those roles from above while AI absorbs the same administrative and coordinating work from below, and the tools are used most by the executives who already have the judgement to assess what they return.[11] AI Workflow for Game Designers (2026) is the practical counterpart, a designer's manual for using a coding assistant task by task in systems design, combat, narrative, level design, balance and live operations, with chapters on cost and copyright.[29] Vibe Coding Video Games with Python supplies the experiment, and reports that its generated games are first levels only and not always complete.[26]

The Guide to Computer Simulations and Games is written on the principle that a racing driver should understand the car: people who commission or design educational games, its authors say, often know little about how such software works, and the book undertakes to explain how simulations and games are built so that they can be designed, used and evaluated better.[13] Minecraft-learn from scratch works from the other side, using an existing game as the classroom. It describes Minecraft as a sandbox with no set objectives, in which players set their own goals, and then teaches events, variables and loops through small projects inside it.[14]