Dr. Nicola Mingotti has created a short introductory video, “Flaps in Squeak Smalltalk,” that explains how to get started using flaps in the Squeak environment. In the video, he demonstrates how to enable flaps, use them to drag objects into the Squeak World, and explores a few basic configuration options. If you are new to flaps or looking for a quick overview, this video provides a clear and helpful starting point. You can watch it here.
Have a great time with Smalltalk and keep on Squeaking!
In the last lesson, you were asked to identify the objects present in Figure 1 of Lesson 5. From the example, we will be using the object names ShooterGame, Ship, Shot, Enemy, and Score. These names have been chosen because they are clear, descriptive, and directly relate to the roles these objects will play within the game. Each name corresponds to a specific function within the game, and using such intuitive names helps to keep the code organized and easy to understand.
The reason these names were selected is tied to their roles and responsibilities within the game. As you will see in the following explanations, each object has a clear purpose. At the core of everything is ShooterGame, which provides the game screen – the boundary within which all gameplay takes place. It serves as the origin point for the entire game, coordinating the creation and management of other game elements and the overall flow of activity. The Ship represents the player’s character, allowing for movement and interaction with enemies. Shot represents the projectiles fired by the player, which interact with enemies to destroy them. Enemy objects are the targets that move across the screen and can be destroyed by shots. Finally, the Score object tracks the points the player earns by destroying enemies. The following sections of this article will further explain the roles and responsibilities of each object in detail, providing a better understanding of how they work together in the game.
ShooterGame object provides the screen boundary and serves as the foundation from which the entire game emerges. It defines the playable area that other objects use to determine their positions and limits. In addition to supplying this essential structure, ShooterGame also acts as the central controller of the game. It initializes the Ship and Score at the start and recreates Enemy objects when all have been eliminated. It also coordinates the overall flow of the game, including when it begins and ends, and keeps track of the main objects involved in gameplay.Ship is controlled by the player, and its movements will be essential to the game. You can program the Ship to move in all four directions: up, down, left, and right. Unlike many games, the ship will not be destroyed if it comes into contact with an enemy, meaning the player can continue to control the ship without worrying about direct collisions with enemies. The ship’s movement and interactions with other objects will be crucial to progressing through the game.Shot object represents the projectiles that the player shoots at the enemies. Shots will move in an upward direction as the player fires them. The behavior of the Shot is simple: when a shot hits an enemy, the enemy is destroyed. This interaction between the shot and the enemy is one of the core mechanics of your space shooter game.Enemy objects will move left and right across the screen, adding a dynamic element to the game. There will be three Enemy objects in the game, each with its own movement pattern. As the player’s shots hit the Enemy objects, the Enemy objects will be destroyed, and the player will earn points.Score object is responsible for keeping track of the player’s points. Each time an enemy is destroyed, the player earns 100 points, and the score increases accordingly. The score is updated when a Shot hits an Enemy. Because the Score object displays its information on the ShooterGame screen, it maintains a relationship with it.Now that each object’s role and behavior has been identified, it is important to understand how these objects interact during gameplay. Their interactions define how the game functions and how players experience the game world.
Ship appears within the game screen provided by ShooterGame. It moves in response to player input and uses the boundaries of the game screen to determine how far it can travel. The screen boundaries provided by ShooterGame limit how far the Ship can move. ShooterGame provides the space in which the Ship operates, but it does not control the Ship’s movement.Ship releases a Shot that travels upward. This interaction allows the player to engage with enemies and is central to gameplay. The firing of a Shot gives the player a way to respond to the movement of Enemy objects on the screen.ShooterGame establishes the upper boundary for shots. When a Shot moves upward and reaches the top of the screen, it is removed from play. ShooterGame does not manage or direct shots, but its boundaries help determine when a Shot leaves the gameplay area.Shot comes into contact with an Enemy during its path, both the Shot and the Enemy are removed from play. This interaction is a key part of gameplay: successful hits on Enemy objects are the player’s goal. When this happens, the Score is also updated to reflect the player’s progress.Enemy objects move left and right across the game screen using the screen’s width to guide their motion. The screen boundaries provided by ShooterGame limit how far Enemy objects can move. When an Enemy is hit by a Shot, it is removed from the game screen.Score is displayed on the game screen and increases when an Enemy is destroyed. ShooterGame provides the location where the Score is shown during gameplay. As the game progresses, the Score gives players feedback on their performance and accomplishments.Understanding how these objects behave and interact lays the groundwork for building a playable game. By thinking carefully about each object’s role and how it connects with others, you will be better prepared to implement the necessary features in code. These foundational concepts will continue to guide your work as you move forward with designing and programming the game’s functionality.
The tutorials are now also available for use inside the Squeak development environment through the Squeak Help System. Once installed, this resource allows you to read and follow the lessons directly within Squeak, making it easy to experiment with code and concepts without leaving the environment. The Help System documentation is included as part of the downloadable resources for the game and can be added to your Squeak image just like the other game assets.
To access Lesson 6 and the full series of tutorials for building the Shooter Game, visit https://scottgibson.site/ShooterGame/. There you will find everything you need to follow along, including PDFs, Squeak Help lesson content, source code, images, sound files, and other game assets. This resource also allows you to try out the game directly in your browser using SqueakJS. Whether you are new to programming, just getting started with Squeak/Smalltalk, or building on prior experience, these materials will support you as you continue developing your own version of the game.
Have a great time with Smalltalk and keep on Squeaking!
An initiative has recently emerged within the Squeak community to explore bringing Croquet into the modern Squeak 6.0 environment, with their efforts opening up possibilities for personal and educational applications, and potentially paving the way for long-term developments. Community members Edwin Ancaer and Timothy have taken it upon themselves to explore, port, and troubleshoot Croquet – an ambitious collaborative 3D environment originally designed to run in earlier 32-bit versions of Squeak.
Croquet was a groundbreaking software architecture designed for deep collaboration, originally built as an open, free, and highly portable extension of the Squeak programming system. It provided a platform for both development and real-time collaborative work, with no separation between user and developer environments. Focused on 3D shared spaces, Croquet enabled users to interact in context-based collaborations, observing each other’s actions and focus in real time. A collaboration protocol called TeaTime powered this synchronization, and rendering was based on OpenGL. While newer, proprietary descendants of Croquet have evolved since, the version being revived in Squeak 6.0 reflects this original, exploratory vision.
Croquet Jasmine, a developer’s release of the system, is available and can be run live in a web browser using the SqueakJS virtual machine – allowing others to easily explore Croquet without a local setup. You can try a live version here: codefrau.github.io/jasmine/.
Efforts began early in the process, building on Nikolay Suslov’s work to get the original Open Croquet running on the latest versions of Squeak 5.x. His work laid the groundwork for achieving compatibility with Squeak 6.0. You can explore his repository here: github.com/NikolaySuslov/croquet-squeak. You can also check out detailed steps Nikolay has provided to bring Croquet into an early alpha version of Squeak 6.0 here.
A primary obstacle encountered was the tight coupling between Croquet and OpenGL 1. As Vanessa Freudenberg pointed out, OpenGL has been deprecated on macOS for years, complicating efforts to run the system on 64-bit machines. Vanessa suggested considering Vulkan or OpenGL 4 as possible alternatives for the rendering backend.
In consideration of a long-term solution, it is helpful to explore the potential paths forward, each with its own trade-offs:
For a long-term solution, Vulkan appears to be the most promising path – essentially a modern, cross-platform successor to OpenGL, developed to overcome many of its limitations. Although not natively supported on Apple platforms, Vulkan’s compatibility through MoltenVK makes it a viable candidate for achieving performance and portability across environments.
While these options are worth exploring for long-term solutions, they may be unnecessarily complex for personal or educational use. However, the current efforts could prove valuable down the road by revealing key details, helping future work begin from well-understood points in the development process.
Vanessa has managed to run Croquet Jasmine without modifying the Smalltalk code by using the browser-based SqueakJS VM, with a custom OpenGL 1 implementation written in JavaScript. This was accessed via FFI and mapped to modern WebGL. The approach preserves the original graphics code inside the image while offloading rendering to the browser, and could serve as a model for similar efforts going forward.
In efforts to get Croquet working with Squeak 6.0, contributors encountered challenges requiring low-level debugging. Their focus shifted to analyzing behavior via the debug VM, aiming to isolate root causes of instability or failure.
One may wonder why Squeak, being a self-hosting environment, might still require work in C. The environment is written in Smalltalk and is capable of building and evolving itself entirely from within. This self-hosting capability enables fast iteration, deep system visibility, and live modification of running code – all without leaving the environment.
However, Squeak runs on a virtual machine, with performance-critical parts written in a restricted subset of Smalltalk known as Slang (Swiki link). Slang is not a separate language, but a subset of Smalltalk designed to be translatable into C for compilation. This allows the virtual machine, which is largely written in Smalltalk, to be compiled into efficient native code for multiple platforms. When issues arise at the VM level – such as those involving primitives, foreign function interfaces, or memory management – developers must drop down into the generated C code to diagnose and resolve them. You can read more about the Squeak VM on the Swiki here and here.
The benefit of this design is excellent portability: the Smalltalk environment remains consistent across platforms, while only the VM layer needs to be recompiled or adapted for different operating systems or hardware. Having this level of separation allows the Squeak image to remain consistent across multiple platforms without exposing the underlying hardware implementation to the image code itself.
Further analysis suggested that inconsistencies between expected and actual behavior in the virtual machine’s handling of system-level function calls were at the heart of the issue – at least for now. By carefully tracing how external interfaces were being resolved and invoked, the contributors were able to isolate a likely point of failure. The realization was met with enthusiasm, signaling meaningful progress toward resolving the issue.
Edwin humorously remarked that he never expected working in Smalltalk would lead him back to debugging C code – a twist that underscores the unpredictable nature of systems development. Tim Rowledge added that, during his time at ParcPlace, it was an inside joke that those who got hooked on Smalltalk inevitably ended up spending too much time writing C, while the C++ fans who joined the team found themselves writing Smalltalk instead. The irony of this unexpected reality highlights the surprising paths developers take when working with complex systems.
We extend deep appreciation to Nikolay Suslov for his foundational work in bringing the original Open Croquet to Squeak 5.x, which has served as a solid base for moving toward compatibility with Squeak 6.0. A special thanks also goes to Edwin and Timothy for their time, dedication, and resourcefulness in troubleshooting and adapting Croquet to modern Squeak 6.0 systems. Their efforts contribute to the broader community by preserving an important piece of Squeak history and helping to lay the groundwork for future advancements.
The effort to bring Croquet to Squeak 6.0 is ongoing. We wish those involved continued success and invite anyone curious to jump in, contribute, and join the effort to keep Squeak a vibrant environment for innovation and exploration!
Have a great time with Smalltalk and keep on Squeaking!
Congratulations to the newly elected members of the Squeak Oversight Board for 2025. We are grateful to everyone who ran and offered their time in support of the community – it truly takes everyone’s contributions to help Squeak succeed. A big thank you as well to Patrick for once again running the election and handling the process so smoothly. Whether new to the board or continuing your service, we appreciate your dedication and look forward to a productive and exciting year ahead.
Below is Patrick’s official announcement to the Squeak Developers mailing list:
Hi Everyone,
I’m very pleased to announce your Squeak Oversight Board for 2025.
They are:
I would like to thank everyone that served on the board in the term of 2024. Thank you for your contributions to Squeak!
Thank you to everyone that ran this year and for everyone that voted. We are looking forward to a great year in the Squeak community!
Please help me to welcome and congratulate your new board for 2025!!
All the best,
Patrick
Photo by Marco Bianchetti on Unsplash
Dr. Nicola Mingotti has created a highly useful video tutorial, “The Squeak Smalltalk Help System”, where he demonstrates how to use and implement the Squeak Help System in your projects. In the video, Dr. Mingotti walks you through a step-by-step guide on creating documentation for your code, providing valuable insights into integrating the help system into your workflow. You can check out his video here.
Additionally, Dr. Mingotti offers supporting materials in his Swiki article here, which includes code snippets and further comments to aid your understanding.
Overview of the Squeak Help System
One of the many great features of Squeak is its rich set of help documentation. The default Squeak image comes with valuable documentation that covers topics such as: How to Use Squeak, How to Contribute to Squeak, Tutorials, The Terse Guide to Squeak, and Using WebClient and WebServer. This documentation is easily searchable, making it a highly useful resource for your projects.
Help System vs. Code Comments
It is important to note that the Squeak Help System is not intended to replace code comments. Squeak/Smalltalk provides excellent functionality for adding comments directly in your code, and these should remain the primary way to document code behavior, logic, and functionality. The Help System is designed for documentation outside the scope of code comments, such as explaining overall project goals, providing tutorials, or offering guidance on using tools and features in your project.
Features of the Help System
The help documentation system offers a variety of features, including text styling (bold, italics, strikethrough, underline), code formatting and syntax highlighting, and URLs, to name a few.
Additionally, you can add images to your documentation. This feature is currently available in the Trunk image, but you can implement it in other images as well by using its code as a reference. For the 6.0 image, you can perform a fileout of the SqueakHelpTextImage class from the Trunk image and then filein it into the 6.0 image. Alternatively, you can create your own code to implement this functionality! Thanks to Christoph Thiede for providing guidance on how he implemented this feature. You can find his post here.
Clipboard clipboardText: Character startOfHeader asString./path/to/file/image.png with the actual path and filename of your image:SqueakHelpTextImage forForm: (ImageReadWriter formFromFileNamed: '/path/to/file/image.png')Your image is now successfully inserted into your help document!
Conclusion
A big thank you to Dr. Nicola Mingotti for his helpful video tutorial on using the Squeak Help System, which offers a step-by-step guide for integrating the help system into your workflow. His Swiki article is also a helpful resource with code snippets and additional comments. Be sure to check out his materials to further enhance your understanding of Squeak and the Help System!
Have a great time with Smalltalk and keep on Squeaking!
Ramon Leon has a new post on his On Smalltalk blog. In it, he describes how he chose a simple solution for a complex problem. Instead of relying on popular, complex systems, he built a straightforward, file-based job queue in Smalltalk, which has been running smoothly in his production systems for years. He also shares Smalltalk code he created to accomplish this goal, highlighting the effectiveness of simplicity in solving challenges.
Check out his latest post “Simple File-Based Distributed Job Queue in Smalltalk” here.
Photo by Tima Miroshnichenko from Pexels: https://www.pexels.com/photo/close-up-view-of-system-hacking-in-a-monitor-5380664/
In this lesson, you will begin the process of creating your space shooter game by identifying and designing the key objects that will make up the gameplay. Having become familiar with the Squeak programming environment and basic concepts in previous lessons, it is now time to focus on the major components of the game. Understanding and determining these objects and their roles will lay the foundation for the game mechanics we will develop in upcoming lessons.
You will be building a simple, classic space shooter game. The game will feature a user-controlled ship that can shoot, enemy creatures that can be destroyed, and a score that accumulates points for each enemy destroyed. These are some of the primary objects you will work with, but as you proceed, you may discover additional objects or find that you need to adjust the roles and responsibilities of those you have already defined.
When designing your objects, it helps to focus on two key aspects: what the object is and what it does – that is, its roles and responsibilities. For example, the spaceship object is something you control, and its responsibility is to move and shoot at enemies. Similarly, the enemy object is something that can be destroyed when hit by a shot. Other objects, like the score object, also play important roles in your game.
At this stage, you do not need to know all the objects you will need right away – this is perfectly fine! Object-oriented programming (OOP) is flexible, allowing you to modify your design as your game evolves. As you write more code, you might find that new objects are necessary, or some you initially considered may not be needed after all.
As you work through this process, consider the following questions to guide your object design:
Ship. If there are enemies, you might have an object called Enemy. Choosing clear and descriptive names from the start will help your code stay organized and easier to understand.An important part of designing objects is choosing meaningful names. The names you pick should make it clear what each object is and what it does in your game. At this stage, it is best to keep things clear and simple. For example, if you are designing the object that represents the player’s ship, use a name that clearly describes it, like Ship. Similarly, for enemies, choose a name that makes it obvious what the object represents.
For other objects, consider their role and responsibility. What would you call the object that represents something the player shoots? And what about the object that tracks the score? Remember, it is better to use simple, intuitive names that describe the object’s function rather than complicating things with complex names.
Do not worry if the names are not perfect at first. The most important thing is clarity. You can always refine them as your game evolves. In Squeak, renaming objects is easy, so you do not need to worry about getting everything right in the beginning.
In object-oriented programming, the process of designing and refining your objects is ongoing. You do not need to have all the objects figured out from the start, and it is okay if things are not perfect right away. The goal is to focus on understanding what each object does and how it interacts with others to create the overall game experience. Over time, you will continue to refine and expand your design.
Remember that in Smalltalk, making changes to your objects is simple – whether that involves adding new objects, renaming them, or adjusting how they behave. Do not be afraid to iterate and improve as you go along. It is all part of the learning process!
Good luck as you begin designing your space shooter game. Be sure to refer back to the example game screen shown in Figure 1 as well as the rest of Lesson 5 in the online lesson or the downloadable PDF as you proceed.
For Lesson 5 and the complete series of lessons on creating the Shooter Game, including all the necessary resources such as PDFs, source code, images, sound file, and more, visit https://scottgibson.site/ShooterGame/. This site provides everything you need to progress and also lets you play the game directly in your browser, seamlessly powered by SqueakJS. Whether you are just getting started with Squeak/Smalltalk or advancing your skills, these resources will help guide you as you move forward through the game development process.
Have a great time with Smalltalk and keep on Squeaking!
While working with Morphs can be quite easy at times, working with both text and Morphs might not always seem as straightforward. Dr. Nicola Mingotti provides a helpful video that demonstrates a commonly needed functionality in graphical interfaces, where you would typically want to accept a single line of textual data. Check out his video to see how this can be easily accomplished. You can view the video demonstration “Make a TextLineMorph in Squeak Smalltalk” here.
Have a great time with Smalltalk and keep on Squeaking!
Lesson 4: Using Cascades in Code
This lesson will be the last introductory lesson (lesson practices) before we begin the actual game creation.
This lesson is simple and quick, but it introduces cascades, which are commonly used in Smalltalk code. Understanding and becoming familiar with them will help you utilize them effectively, as well as recognize them when you encounter other Smalltalk code. By using cascades, you can reduce code clutter and minimize the amount of typing needed.
The following code is an example from Lesson 3. This code completes messages by using a period which in Smalltalk is the statement separator. Placing a period between two expressions turns them into independent statements.
s := SimpleButtonMorph new.
s label: ‘Move right’.
s target: moveRight.
s actionSelector: #value.
s openInWorld.
The following code is the example from Lesson 4 using cascades.
s := SimpleButtonMorph new
label: ‘Move right’;
target: moveRight;
actionSelector: #value;
openInWorld.
Even though the code looks simpler, it is important to understand what is happening. When the same object is the receiver of a sequence of consecutive messages, you do not need to repeat it. You can remove the repeated receiving object and replace the ending period with a semicolon (;). So, the basic rules for cascades are:
So, if it is as simple as replacing periods with semicolons, why does this lesson’s example not work if a semicolon were placed after “SimpleButtonMorph new”?
SimpleButtonMorph is a class, not an instance of that class. This means that you cannot send instance messages directly to the class itself. A class can receive class messages, but in this example, we are sending instance messages, which can only be sent to instances of the class, not the class itself. Therefore, to interact with the instance, you must first create an instance by sending the message “new” to SimpleButtonMorph. It is this instance of SimpleButtonMorph that can receive instance messages. In other words, all the cascaded messages are sent to the object created by “SimpleButtonMorph new”, demonstrating how a sequence of cascaded messages can be sent to the result of an expression.
In conclusion, understanding and using cascades in Smalltalk can greatly simplify your code, making it more readable and reducing redundancy. By chaining multiple messages to the same object in a single expression, you can streamline your code and focus on the logic rather than repetitive syntax. With this knowledge, you can write more efficient, elegant Smalltalk code and recognize cascading patterns in other code you encounter.
For Lesson 4 and the complete series of lessons on creating the Shooter Game, including all the necessary resources such as PDFs, source code, images, sound file, and more, visit https://scottgibson.site/ShooterGame/. This site not only provides everything you need to progress but also allows you to play the game directly in your browser using SqueakJS. Whether you are just getting started with Squeak/Smalltalk or advancing your skills, these resources will help guide you as you move forward through the game development process.
Have a great time with Smalltalk and keep on Squeaking!
The following announcement was made by Patrick Rein on the Squeak Developers mailing list (here). Please announce your candidacy on Squeak-dev or vote for a candidate. Now is the time to be involved!
Hi All,
It’s that time again to raise your voices and elect your board!
Can you believe it’s been over a year and one day already?
It’s a time for you to stand up, help your community and volunteer to serve!
Squeak wants you!
Every year we elect the SOB (Squeak Oversight Board) consisting of seven members from our community. The current board members are:
For more info on the board please see:
https://squeak.org/board/#the-mission
Everything about the election, including schedule and more, is tracked here:
https://wiki.squeak.org/squeak/6667
Now until Friday 21st of March 2025, 18.00 UTC: Nominations of SOB members and campaigning!
Candidates should nominate themselves and start their campaign on the squeak-dev mailing list. Or if you nominate someone else, make sure that person really wants to run. 🙂 I will not put anyone on the candidate list until that person makes it known on squeak-dev that he/she intends to run.
During this period, the candidates should ideally present themselves on squeak-dev, unless they have already done so, and the community can ask questions.
I encourage you to reach out to potential candidates, people that are active in the community and represent your views, and ask them to run.
Some people will not run without encouragement. Also, I know that some people wait to the last minute to run for the board to see if others will run but please consider getting this year off to a faster start and just jump right in!
The schedule and process are as follows:
The voting period is two weeks long and ballots are sent out via email.
And how do you end up on the voter list? See below. 🙂
IMPORTANT: New voters will NOT be added once the election is started.
You MUST try to get on the voter list before the online election starts or you will NOT be able to vote. If your email address has changed please try to make sure it is changed on the list of voters before the election starts.
If you were invited to vote last year you are already on the voter list, no worries! If you are a new Squeaker and wish to vote you should do ONE of the following:
When the voting period starts all voters will receive an email with instructions and a link to the voting website.
If there are any further questions, just reply in this thread and I will closely track it – or send email to voters (at) squeak.org which points to me.
…so let’s get on with it!
All the best,
Patrick
Photo by Tara Winstead from Pexels: https://www.pexels.com/photo/red-check-mark-over-black-box-8850706/
The Weekly Squeak 