What Smalltalk Can Teach Modern Game Developers

A programming environment from the 1970s and 1980s might seem an unlikely place to find ideas for modern game development.

Smalltalk predates Unreal Engine, GameMaker, Unity, C#, Blueprints, modern GPUs, and even the commercial video game industry as we know it. Yet some of the problems Smalltalk's designers sought to solve should sound remarkably familiar to game developers today:

How can we change software quickly, see what happens, understand the result, and keep refining it without constantly fighting the tools?

That question may be Smalltalk's most important legacy.

Smalltalk is often remembered as a foundational object-oriented programming system. Objects, classes, inheritance, encapsulation, and polymorphism certainly matter. But focusing only on object-oriented programming misses something bigger.

Smalltalk was also an attempt to rethink how programmers interact with software while it is running.

And that idea remains surprisingly relevant to game development. 

Smalltalk Was More Than a Programming Language

The Smalltalk designers did not view programming as simply writing source code, compiling it, running an executable, finding a problem, returning to the editor, and repeating the process. They wanted programming to be more immediate.

The Smalltalk/V Tutorial and Programming Handbook describes programming as a dynamic, evolutionary process and presents the environment as a combination of a language and the tools needed to explore and manipulate a system. Its development approach is explicitly described as design-prototype-refine: install small pieces of code, see the results immediately, experiment with ideas, and allow the application to take shape incrementally.

That sounds less like traditional software development and much more like how good game development often works.

• Build something
• Play it
• Change it
• Play it again

A movement mechanic that sounds perfect in a design document may feel terrible when you control the character. An enemy encounter that looks balanced in a spreadsheet may be boring in the game. A level that looks impressive from an editor camera may become confusing from the player's perspective.

Games have to be experienced. That makes iteration speed extraordinarily important. Smalltalk understood the value of shortening that feedback loop decades ago. 

The Real Unit of Development Was the Object

Smalltalk's second major lesson is familiar but easy to underestimate: think about software as a world of objects with responsibilities.

In Smalltalk-80: The Language and Its Implementation, Goldberg and Robson describe an object as something with private memory and a set of operations. Other parts of the system interact with the object by sending it messages rather than directly manipulating its internal implementation.

For a game developer, this is a remarkably natural way to think. Consider a door:

The door has state:

• Open or closed
• Locked or unlocked
• Perhaps damaged or undamaged

And it has behaviors:

• Open
• Close
• Lock
• Unlock
• Take damage

The player should not need to know exactly how the door represents those states internally. The player asks the door to open. The door decides whether it can.

Now apply the same thinking to an enemy, weapon, vehicle, inventory item, switch, elevator, quest, or NPC.

A game starts looking less like one giant program and more like a society of interacting things. That was central to Smalltalk. And it maps unusually well to games because a game world is already made of things that have state, behavior, and relationships. 

Messages May Be More Important Than Classes

Modern discussions of object-oriented programming often center on class hierarchies. Smalltalk puts the emphasis elsewhere: messages.

A message is essentially a request sent to an object. The sender specifies what it wants, while the receiving object determines how to respond. The object's public messages form its interface with the rest of the system.

That distinction leads to a useful game-development question.

Instead of asking: What data should I get from this object?

ask: What should I ask this object to do?

Imagine combat code that repeatedly reaches inside an enemy to change health, animation state, movement speed, AI state, and visual effects.

Now compare that with asking the enemy to: TakeDamage. The enemy becomes responsible for deciding what that means:

• Perhaps an armored enemy reduces the damage
• Perhaps a shield absorbs it
• Perhaps a boss enters another phase
• Perhaps a destructible robot loses a component.
• The sender does not necessarily need to know.

That separation makes systems easier to change because fewer parts of the game need to know each other's internal details.

Goldberg and Robson argued that this reduction in interdependencies was one of the ways Smalltalk helped manage software complexity. They even described replacing an internal representation without disturbing the running system, provided the message interface expected by other objects remained intact.

For game development, that is a powerful design principle:

Protect the interaction between systems from the implementation inside those systems. 

Programming Inside a Living World

Perhaps the most interesting Smalltalk idea has little to do with syntax. Smalltalk programmers worked inside a persistent world of running objects.

Modern Squeak, a descendant of Smalltalk, still demonstrates this philosophy. Its development environment includes browsers, inspectors, explorers, workspaces, debuggers, and other tools for interacting directly with objects. A saved Squeak image can preserve the state of the running environment, including its objects.

More importantly, Squeak by Example describes programming in Smalltalk as working in a world of live objects rather than static program text, allowing programmers to inspect and even modify those objects while receiving rapid feedback.

• That idea should immediately interest game developers
• A running game is also a world of live objects
• The player exists somewhere
• Enemies have health
• Doors have states
• AI agents have targets
• Weapons have ammunition
• Quests have progress
• Timers are counting
• Objects are colliding
• Events are firing

Most bugs become easier to understand when you can examine that world rather than merely stare at the source code that created it. Smalltalk made that kind of interaction fundamental to programming. The distinction matters.

Instead of thinking:

Edit code → compile → launch → reproduce → observe

Smalltalk encouraged something closer to:

Observe → inspect → change → continue → observe again

The closer a modern game-development workflow gets to that second loop, the more practical experimentation becomes. 

Rapid Iteration Changes What You Are Willing to Try

Iteration speed is not merely a productivity issue. It also affects creativity.

Suppose testing an idea takes twenty minutes. You will naturally become selective. You will think harder before trying something because every experiment carries a cost.

If testing an idea takes twenty seconds, the economics change. You try things:

• What if the enemy moves twice as quickly?
• What if the door closes automatically?
• What if the jump is slightly higher?
• What if this corridor is half as long?
• What if the weapon pushes enemies backward?
• What if five enemies attack instead of three?

Most experiments will not survive. That is fine. The point is discovering the few that should.

Smalltalk/V's development philosophy deliberately supported experimentation before an application was complete. Rather than requiring developers to fully define the system before using it, the environment encouraged the system to evolve as understanding improved.

That is especially important for games because you often cannot know whether an idea works until you experience it.

A fast feedback loop therefore becomes part of the design process itself. 

Debug the World, Not Just the Code

Smalltalk's live-object philosophy also changes the way we debug.

Traditional debugging tends to begin with source code:

• Where is the bug?
• Which function caused it?
• Which line failed?

Those questions matter, but Smalltalk encourages another question:

What is happening inside the object right now?

• Inspect the object
• Look at its state
• Send it a message
• See how it responds
• Follow the relationships between objects.

Squeak by Example describes inspectors and explorers as tools for examining and modifying live objects, while its debugger is part of the same integrated programming environment. This is an especially useful mindset for gameplay problems.

If an enemy refuses to attack, the most useful question may not initially be which line of code is wrong?

It may be:

• What state is the enemy in?
• What target does it currently know about?
• Is the player inside its detection range?
• Is another condition preventing the transition?
• What message did it receive?
• What object currently owns the relevant decision?

You are debugging a world of changing state, not merely a collection of text files. That is a very Smalltalk way of thinking. 

What This Means for Modern Game Development

Modern game developers do not need to abandon their engines and start building games in Smalltalk. That would miss the point. The interesting question is not whether Smalltalk should replace modern development tools. It is: Which Smalltalk ideas should we deliberately preserve in modern workflows?

The following four stand out:

Keep the feedback loop short.
Anything that reduces the distance between an idea and its experience improves the development process.

Give objects meaningful responsibilities.
A game object should not merely be a convenient container for variables. It should represent something that knows how to perform behaviors appropriate to its role.

Prefer communication over internal manipulation.
Ask objects to perform meaningful actions instead of allowing unrelated systems to reach inside and modify their state whenever possible.

Treat the running game as something you can investigate.
Inspect objects, watch state change, trace interactions, and understand the game as a living system.

None of these principles belong exclusively to Smalltalk. But Smalltalk brought them together unusually well. 

The Smalltalk Lesson

Smalltalk's lasting contribution to game development may not be object-oriented programming by itself. It may be a philosophy of software development:

Software should remain easy to explore, change, and understand while it is running.

That philosophy matters even more for games than for many conventional applications.

Games emerge through experimentation. Mechanics evolve. Levels change. Systems interact in unexpected ways. A perfectly reasonable design can fail the moment someone starts playing it. The development environment should therefore make change inexpensive.

The architecture should make experimentation safe. Objects should have understandable responsibilities. Systems should communicate without needing to know unnecessary details about one another. And developers should be able to investigate the world they have created while it is alive. Smalltalk was pursuing that vision decades before today's game engines existed. Technology has changed dramatically. The lesson has not.

Relevant References

• Smalltalk/V 286 Tutorial and Programming Handbook, Digitalk, 1988.
• Christoph Thiede and Patrick Rein, Squeak by Example, Edition 6.0, 2023.
• Adele Goldberg and David Robson, Smalltalk-80: The Language and Its Implementation, 1983.
• Squeak.org. https://squeak.org/
• Object Orientation is NOT about Objects. The Secret Most Programmers Don't Know! https://youtu.be/lmAarC0Zhq4?si=5NKpRS0kw4Ka523c