The Weekly Squeak

Category: Smalltalk

  • Lesson 2: Programming the Shooter Game in Squeak/Smalltalk

    Lesson 2: Programming the Shooter Game in Squeak/Smalltalk

    Lesson 2: Moving Morphs

    In this lesson, we will focus on making Morphs move, an essential step in creating interactive and engaging gameplay. You will learn how to send messages to Morph objects, enabling them to change their position on the screen. Movement is a key part of any game, whether it involves your ship, enemies, or projectiles. By the end of this lesson, you will understand different ways to move Morphs relative to a specific location, giving you basic control over their movement in your game.

    To begin, it is important to understand how Morph movement is accomplished in Squeak, a version of Smalltalk, as not all Smalltalk implementations support Morphs, which is what we are using here. Squeak is an object-oriented language, meaning everything is an object. Objects can communicate with each other by sending messages, which is how actions and information are requested in Squeak. Much like how people communicate by sending messages to one another, objects in Squeak send messages to request actions or receive information, or both.

    Understanding Messages in Smalltalk

    In Smalltalk, there are three types of messages: unary, binary, and keyword. Unary messages have the highest precedence, followed by binary messages, and then keyword messages. These different types of messages help objects interact in various ways.

    • Unary messages are messages that are sent to an object without arguments.
    • Binary messages consist of special characters like +, -, or @, and each one takes exactly one argument to perform an action or computation involving two objects.
    • Keyword messages consist of one or more keywords, each ending with a colon (:), and each keyword takes an argument.

    The Difference Between position: and position

    In this lesson, you will focus on understanding how to use the position messages. The first important thing to know is the difference between two messages that seem similar but actually work in different ways: position and position:. They both deal with the position of Morphs, but they are used differently.

    • The message position, without a colon, is a unary message. It does not require any arguments and simply retrieves the current position of the Morph.
    • The message position:, with a colon at the end, is a keyword message. It can receive a value or an argument, which is used to change the position of the Morph.

    This difference in how the messages are structured is important because it tells Squeak how to process them. The position message simply retrieves the current location of the Morph, while the position: message accepts an argument to set or change the Morph’s location.

    Understanding How to Control Morph Movement

    By understanding how messages work in Squeak, you can effectively control the movement of Morphs. Each message, whether unary, binary, or keyword, enables you to send specific instructions to objects, helping them change their state or position on the screen. This knowledge of messages forms the basis of interacting with objects in your game.

    As you progress through the lesson, you will learn how to send different types of messages to Morphs, allowing you to interact with them in various ways. This skill will be crucial for making your game dynamic and interactive, enabling you to work with Morphs to create engaging gameplay elements.

    By the end of this lesson, you will have a good foundation in how messages are used to control movement in Squeak, and you will be ready to apply this knowledge in your game.

    Final Notes

    Please remember to save your Squeak image after each lesson. This way, if you ever encounter a problem with your code, you can always close the image and reopen it from where you last saved it. It would be helpful to save your Squeak image after you have successfully completed each lesson, so you can always reopen the image from the last completed lesson in case something unexpected happens while proceeding through the current lesson.

    Note that the extra parentheses in this lesson are not necessary, but they may help new learners visualize the objects conceptually, especially at the start. The syntax is still correct and can be adjusted later, so nothing harmful is being introduced. At this point, it seemed better to provide a visual, conceptual understanding through the code, rather than focusing solely on minimizing syntax. Future lesson code will not include these.

    Lesson Resources

    For the complete series of lessons on creating the Shooter Game, including all the necessary resources like PDFs, source code, images, sound files, and more, visit https://scottgibson.site/ShooterGame/. This site not only offers everything you need to progress but also lets you play the game directly in your browser using SqueakJS. Whether you are just getting started with Squeak/Smalltalk or are advancing your skills, these resources will guide you through each step of the game development process, helping you apply the techniques you learned in this lesson, such as moving Morphs and controlling game objects.

    ← Lesson 1

    Lesson 3 →

    Have a great time with Smalltalk and keep on Squeaking!

  • UK Smalltalk User Group Releases Archived Presentation Videos on YouTube

    UK Smalltalk User Group Releases Archived Presentation Videos on YouTube

    The holidays may be over, but the presents are still arriving from the UK Smalltalk User Group! Videos of previous presentations have been released over the past month, covering a variety of interesting topics–a total of 57 as of this writing! Be sure to check out their new YouTube channel at https://www.youtube.com/@UKSTUG. Also, be sure to visit their homepage at https://www.uksmalltalk.org/, and if you would like to attend any meetings, their Meetup site can be found at https://www.meetup.com/ukstug/.

    Have a great time with Smalltalk and keep on Squeaking!

  • Introduction/Lesson 1: Programming the Shooter Game in Squeak/Smalltalk

    Introduction/Lesson 1: Programming the Shooter Game in Squeak/Smalltalk

    Introduction to the Series

    This article kicks off a series designed to introduce programming to beginners through the creation of a simplified space shooter game using Squeak, an open-source implementation of the Smalltalk programming language. By breaking down the process into a series of manageable lessons, the aim is to provide an accessible and interactive entry point into the world of programming. This series will guide learners through the process of building a game from the ground up while introducing them to essential programming concepts along the way. Upon completion, and with the accompanying resources such as source code, images, and a sound file, students will have everything they need to recreate or enhance the game.

    Who This Series is For

    The intended audience for this article and the accompanying series includes both young learners and adults who are new to coding or to Smalltalk. Whether you are a student, educator, or hobbyist, these lessons are tailored to make programming approachable and enjoyable. Throughout the series, we will dive into key programming principles – such as object-oriented design, the concept of “Morphs” in Squeak, and more – at a beginner-friendly pace. Each lesson is supplemented with practical examples. If you are interested in starting with something fun and educational, and you are curious about how games are made or how Smalltalk can be used in a modern development environment, this series is for you.

    Why a Game, and Why Squeak/Smalltalk?

    So why a game, and why in Squeak/Smalltalk? Why not? Everybody understands the domain of games, or gaming. That is, the mechanics, interactions, and goals – such as managing player input, controlling game characters, defining win/loss conditions, and creating interactive environments. Games are a universal medium that spans across ages and cultures, from simple board games to complex video games. This familiarity makes games an excellent starting point for teaching programming concepts, as the mechanics and goals are intuitive to most people. Moreover, games require a variety of programming elements to function, such as managing user input, handling graphics, implementing game rules, designing levels, and even creating sound and music. These components provide a rich environment for introducing and practicing key programming skills – like decision-making, loops, object-oriented design, and event handling – while keeping learners engaged with a fun, practical outcome.

    Why Squeak/Smalltalk is the Right Tool

    Squeak makes all of this very easy, and you do not need to learn anything more than Smalltalk to get started. The language is intuitive and enjoyable to use, and Squeak provides a powerful and engaging development environment. While games may not balance your bank account, they can serve as an excellent resource for learning programming or a new language. Squeak/Smalltalk, in particular, makes this process both accessible and enjoyable.

    How This Series Came to Be

    This article introduces a series of lessons based on a simplified version of a space shooter game I developed using Squeak. The project, which was both fun to create and my first full Squeak program, turned out to be an ideal way to teach my middle school-aged son Smalltalk, as well as the fundamentals of object-oriented programming (OOP). Although he had prior programming experience, he quickly grasped the language due to its simplicity and the interactive nature of the environment. The natural syntax of Smalltalk, combined with the user-friendly environment, not only made it easier for him to solve problems but also allowed him to be more creative, without needing to alter his natural problem-solving approach. Both the language and the environment “got out of his way,” enabling him to express himself more easily and effectively.

    What Will Be Covered in the Series

    The lessons in this series are designed to introduce key programming concepts – such as classes, methods, debugging, and user interface design – through the process of building and modifying a game. You can find the complete list of lessons on the Shooter Game site. Each lesson was written daily, and I discussed topics both before and during the lesson to provide additional detail and ensure a deeper understanding. This approach allowed me to offer relevant explanations exactly when they were needed, based on my son’s progress and evolving needs.

    For each article, I will aim to provide additional helpful information that may not be included in the lessons themselves. If you feel any details are missing or could be useful, please let me know, and I would be happy to provide further information.

    Interactive, Live Coding Approach

    The hands-on, live coding approach in these lessons encourages learners to experiment and learn in real time, making the process both educational and enjoyable. Each lesson also comes with a downloadable PDF version of the lesson page for easy offline reference or printing. The entire series progressively builds upon itself, allowing learners to gradually develop their programming skills as they move through the lessons.

    Lesson 1: Creating and Positioning Morphs

    For today’s lesson, we will dive into the first step in building our game: “Creating and Positioning Morphs.” In this lesson, we will introduce the concept of a Morph and explore how to create and manipulate these visual objects within the Squeak environment. Understanding Morphs is a crucial part of game development in Squeak, as they serve as the foundation for all the interactive elements of the game.

    What is a Morph?

    In Squeak, a Morph is an interactive graphical object. Like everything in Smalltalk, a Morph can be interacted with through messages. It is not a static, lifeless image on the screen, but rather a lively object waiting to interact with its environment. You can send a message to a Morph to receive information about it or to perform an operation. Everything you see when running Squeak is a Morph object. This presents some very exciting capabilities, as it provides you with the ability to create graphical objects, which can interact with the world (the entire Squeak environment – its display screen in this case) and the world can interact with them.

    The Squeak world works using a coordinate system. The coordinate values can be absolute or relative. Each coordinate value is represented as a point, which has an X coordinate and a Y coordinate. For example, a Squeak world (remember, this will be the full size of the display screen in the Squeak environment) with a display size of 1024×768:

    • The point 0@0 is the top-left corner of the screen.
    • The point 0@768 is the lower-left corner of the screen.
    • The point 1024@768 is the lower-right corner of the screen.
    • The point 1024@0 is the top-right corner of the screen.

    Every point in between represents a location within the world. Points can exist outside of that world too; however, they would not be visible.

    In this game, everything is a subclass of Morph, so you will be using Morphs a lot.

    Before beginning Lesson 1, it would be very helpful to read Chapter 1 of the Squeak By Example book (available as a free PDF, SBE-6.0.pdf), an excellent resource for learning Squeak and understanding its environment. Afterward, you can go straight to the lesson here.

    Additional Resources

    To access the full series of lessons and resources for the space shooter game, Shooter Game, visit the lesson site at https://scottgibson.site/ShooterGame/. There, you will find the complete set of lessons and their associated PDFs, along with the source code, images, the sound file, and other useful resources. You can even play the game directly in your browser (using the awesome SqueakJS!). Whether you are a beginner or looking to learn more about Squeak/Smalltalk, its environment, and its tools, these resources will guide you through each step and provide everything you need to recreate or enhance the game.

    Lesson 2 →

    Have a great time with Smalltalk and keep on Squeaking!

  • Integrating AI Language Models into Smalltalk Development Workflows

    Integrating AI Language Models into Smalltalk Development Workflows

    In recent months, Craig Latta has been exploring the integration of AI language models, particularly GPT-4, into Smalltalk development environments, with the goal of enhancing workflows and improving conversational interactions with the language model. Rather than relying on traditional coding methods, Craig has focused on fine-tuning the model using English system prompts, with promising results. This approach aims to guide the AI’s behavior through prompt evolution, rather than direct coding, leading to surprisingly effective outcomes.

    One of the key insights from this experimentation is that GPT-4’s pre-existing knowledge of Smalltalk and Squeak provides a solid foundation for further fine-tuning. By applying constraints to system prompts – such as instructing the model to avoid sending messages to access objects when direct access via instance variables is possible – Craig has steadily refined the AI’s responses.

    Conversing with the Language Model in Squeak

    A central goal of the project was to enable conversations with the AI model from within any text pane in Squeak, utilizing Smalltalk’s classic “do it,” “print it,” and “inspect it” functionalities. To achieve this, Craig modified the Compiler>>evaluateCue:ifFail: method to handle UndeclaredVariable exceptions. When an undeclared variable (e.g., “What” in “What went wrong?”) triggers an exception, the model object underlying the text pane takes over, interpreting the next chat completion from the language model.

    The model objects Craig has focused on are instances of Smalltalk’s Debugger and Inspector. A notable feature of this approach is that it logs all interactions – whether English prompts or Smalltalk code – into the changes log, just as it would with traditional code. Each model object maintains a reference to the most recent chat completion, allowing successive prompts to be interpreted in the context of the entire conversation, fostering dynamic and evolving dialogues.

    Practical Results and Application

    The system has already shown practical value in a live development environment. For example, when evaluating a prompt like “What went wrong?” in the debugger, the language model provides surprisingly accurate and detailed responses, as if debugging the code itself. Similarly, when tasked with generating Smalltalk code – such as instructions for selecting the most recent context with a BlockClosure receiver – the debugger manipulates the code correctly, demonstrating the viability of using the AI in real-time development workflows.

    Future Exploration

    Currently, Craig is expanding the scope of the AI’s functionality. He is experimenting with prompts that describe the application’s domain, purpose, and user interface, eager to see how the model can assist in these areas. This exploration has the potential to significantly improve Smalltalk development workflows by integrating AI-driven conversational interactions into the process.

    As AI models continue to evolve, Craig anticipates further advancements in integrating these models with development environments, offering new opportunities to enhance productivity, troubleshooting, and even code generation. The future of AI-enhanced Smalltalk development looks promising, and this project represents an exciting first step. For more details on Craig’s exploration of AI in Smalltalk development, be sure to check out his full blog post at thisContext.

    Growing Interest in AI for Squeak Development

    There has been growing interest in applying both semantic understanding and generative AI to the Squeak environment, as these technologies hold great promise for improving development workflows. By combining the ability to generate code with deeper understanding and reasoning, developers are beginning to explore new ways AI can assist with both writing and debugging Smalltalk code. This integration could help streamline development, enhance debugging efficiency, and even assist in explaining complex code patterns, all within the context of Squeak’s unique environment. Or, it could take over the world. You decide. As interest continues to grow, a future article and video from a recent demonstration will explore these advancements in more detail, offering insights into how AI-driven approaches can enhance Smalltalk programming and provide practical demonstrations of these evolving tools.

    Have a great time with Smalltalk and keep on Squeaking!

    Photo by Andrea De Santis on Unsplash

  • Recovering from Frozen Images in Squeak

    Recovering from Frozen Images in Squeak

    When developing complex systems, encountering errors that leave your project in a frozen state can bring much sadness and consternation. For developers working with Squeak/Smalltalk, a frozen image refers to a situation where the system becomes unresponsive. This can happen due to various issues, including deadlocks, infinite loops, or recursive operations in Smalltalk code, which can cause the VM to freeze, hang, or lock up.

    A recent discussion in the Squeak community highlighted how one such incident, caused by a stuck semaphore during an image load, turned into an opportunity for both recovery and valuable practices in safeguarding against future mishaps. You can explore the full conversation in the Squeak-dev mailing list thread (here).

    The Problem: Semaphore Deadlock in the Image File

    In this case, a developer encountered an issue while attempting to draw in multiple background threads, using a chain of semaphores to manage the UI thread. After resolving an error in one of the background threads, the drawing process was resumed. However, it was found that the image would fail to load. Instead of opening, the image became unresponsive and effectively “frozen.” It had likely become stuck due to a semaphore waiting for a signal that would never come. This left the image unresponsive and effectively unusable – or so it would have seemed.

    Recovery Options: DoItFirst and Debugging

    The good news is that there are several options available for recovering from such failures.

    For developers dealing with frozen images at startup, Squeak provides a mechanism called DoItFirst. This is a class that is processed at the very beginning of the image startup sequence, allowing developers to inject custom code or actions before the main system fully loads. By using command-line arguments like --debug, it is possible to force the image to enter the debugger at the earliest point in the startup process, allowing issues to be diagnosed and fixed before the image fully loads.

    Additionally, for situations where the issue is well-understood, the --doit option allows Smalltalk expressions to be passed and executed before any problematic behavior occurs, giving developers a chance to resolve issues before they impact the image during loading.

    Another option is to open the Virtual Machine (VM) in a debugger. In the specific case of a stuck semaphore, you can set a breakpoint in interpret. Run the VM until it reaches interpret a second time (the first invocation does some initialization). At this point, you can use printAllProcesses to locate the stuck process. This should display the semaphore the process is waiting on. Once identified, you can invoke synchronousSignal with that semaphore to unstick it and restore functionality without losing significant progress. While this technique can specifically handle a stuck semaphore, it could also be helpful for other cases of system hangs or unresponsiveness.

    The Importance of Backups and Versioning

    While debugging and recovery tools are invaluable, it is clear that prevention is equally important. Routine backups and effective versioning are essential practices that can mitigate the risks associated with frozen images and other failures. One practice that proved helpful in this case was maintaining regular system backups, which made it possible to quickly restore a previous version of the image with minimal data loss. However, more granular versioning, especially in environments with frequent risky changes, would provide an additional layer of safety.

    Specifically, incremental versioning of the image can be a lifesaver when things go wrong. By saving a new version of the image each time a meaningful step in development is reached, developers can create a clear history of their work. This allows them to revert to earlier versions of the image if issues arise, minimizing the impact of failed changes and speeding up the recovery process. Incremental image saves help ensure that even if an image becomes frozen or corrupted, a previous, stable version can be restored with minimal effort.

    The Robustness of Squeak: Multiple Recovery Options

    One of the key takeaways from this experience is how robust Squeak is in terms of recovery options. Even when a frozen image occurs or the system becomes unresponsive, Squeak offers multiple layers of recovery mechanisms. Whether using DoItFirst to inject custom code during startup or interacting with the VM through a debugger to manually resolve issues with semaphores, there are a variety of ways to recover from errors and get back on track.

    Additionally, Squeak’s development environment is designed to be highly flexible, encouraging experimentation while ensuring that recovery is always possible. One of the key advantages of Squeak is that all the code executed or saved during development is stored in the .changes file. This makes it possible to recover from almost any issue, as the system is built to retain all your code. Even if an image becomes frozen or corrupted, the code itself is never truly lost. With the resources mentioned in this article, developers can restore their environment and continue their work. In Squeak, code is safe; no matter what happens to the image, your code can always be recovered.

    Conclusion

    In conclusion, while Squeak’s development environment offers tools to recover from serious errors, the most effective defense is good preventive practice: maintain regular backups, version your work consistently, and always be mindful of the unexpected.

    For more detailed information on using DoItFirst to debug and recover your Squeak image, visit the DoItFirst Swiki page (here). If you encounter issues like crashes or freezes in Squeak, there are various levels of potential failure to consider, and helpful guidance is available in the What to do if Squeak crashes or freezes resource (here), which offers insight into diagnosing and resolving different types of system freezes or crashes.

    Have a great time with Smalltalk and keep on Squeaking!

  • Squeak meeting on November 2, 2024, in Potsdam

    Dear Squeakers, Smalltalkers, and friends of object-oriented, interactive programming environments!

    We cordially invite you again to our annual meeting of German-speaking Squeakers (Squeak Deutschland e.V). It will be filled with exciting lectures, demos, and discussions led by both us and you, while also serving as the general assembly of the association. If you want, you can end the meeting with us in the evening in a cozy atmosphere in a nearby inn.

    Should I register?

    Do you want to participate or do you have any questions or do you even have an idea for demo / lecture / discussion? Get in touch with us so we can plan better. We would like to remain flexible in terms of time and would plan about 15 to 45 minutes for orientation for each lecturer.

    For participation on site, please register by informal email to: marcel.taeumel@hpi.de

    When do we meet?

    Saturday, November 2, 2024, from 1 p.m.

    Where do we meet?

    We will hold the event in a hybrid form. After registration you can find us on site:

    Hasso Plattner Institute for Digital Engineering gGmbH
    Prof.-Dr.-Helmert-Str. 2-3
    14482 Potsdam

    We are expected to be in the C-E communication zone at ABC (https://hpi.de/medien/anfahrtlageplan.html).

    Alternatively, we provide a virtual connection to the meeting point via Zoom ready. Check out the day of the event again: https://squeak.de/news/.

    How will it proceed?

    The exact process is still being finalized. You may also choose to spontaneously give a brief demo or share an experience report during the meeting. 🙂

    1. Lectures, demos, discussions (1:00 p.m. – 4:00 p.m., subject to change)
      • How can an AI help you explore the objects?
      • How can visual elements make incomprehensible program text clearer?
      • How do you build your own programming language?
      • What new games are there for Squeak? 🙂
      • … And what are you doing with squeak? 🙂 …
    2. Association meeting (4:30 p.m. – 6:00 p.m.)
      • Determination of the logger and the cash auditor
      • Determination of quorum
      • Presentation / change of agenda
      • Update member register
      • Activities of the association 2023-2024
      • Report of the treasurer and the cash auditor
      • Future activities
      • Other
    3. End in a nearby inn (from 6:30 p.m.)

    We hope to meet you again in Potsdam (or virtually).

    Stay healthy!

  • Upcoming Smalltalks 2024 conference at Universidad Nacional de Mar del Plata

    Upcoming Smalltalks 2024 conference at Universidad Nacional de Mar del Plata

    The Universidad Nacional de Mar del Plata will host this year’s Smalltalks 2024 conference from November 13 to 15. A pre-conference Smalltalks track, designed for students and teachers, will take place on November 11 and 12.


    Registration is open here, and talk proposals can be submitted until September 30 (extended from the original September 13 deadline). Accepted talks will be announced on October 10.

    For more details and updates, visit https://smalltalks2024.fast.org.ar/home.

  • Ray Casting With Squeak

    Ray Casting With Squeak

    Ray Casting With Squeak

    On the Squeak developers mailing list, Lauren Pullen shared her experience (found here) using Squeak while working on a rendering engine for a first-person maze game, similar to the technique used to render the original Wolfenstein 3D game. Wolfenstein 3D used a rendering technique known as ray casting. Her project captured our attention prompting us to seek additional information from her about it.

    What is Ray Casting?

    Ray casting is an early rendering technique used in computer graphics and video games, particularly in 2.5D and 3D environments. It is a simplified form of ray tracing, where a ray is cast from the player’s or camera’s perspective into the environment, and the distance to the nearest object along that ray is calculated. This process is repeated for each column on the screen, creating a 3D representation of the 2D world. Ray casting was widely used in the early days of 3D gaming, particularly in games like Wolfenstein 3D (1992).

    From Lisp to Squeak

    Lauren, with her extensive experience in Common Lisp, initially chose it to create a GUI application. However, she faced significant challenges. The graphics library was unreliable, often failing to start, and the outdated documentation made it difficult to work with. She studied MVC while designing her application but struggled with basic functionality, such as displaying a simple window.

    She decided to switch to Smalltalk, specifically Squeak, which had an immediate impact. The graphical elements worked seamlessly from the start, and although she missed some features from Common Lisp, like restarts and method combinations, Squeak provided a development environment that allowed her to focus on development without drastically changing her mental approach to problems.

    Comparing Development Tools

    For game development, she initially relied on a much earlier version of Game Maker Pro. When she explored Godot, she found its complexity overwhelming compared to Smalltalk. The disorganization in Godot’s tutorials made her question how to create a basic viable product efficiently. In contrast, though seemingly minimal, Squeak’s classes Form and UserInputEvent provided all that was needed.

    Advantages of Squeak

    In Squeak, she found it easy to work with graphical elements. Drawing interface components and importing graphics were straightforward, thanks to the source code access for built-in drawing functions. This simplicity was crucial for her development process. While working on the game, she realized that making changes and seeing immediate results was invaluable for debugging. Her experience with Forth taught her the value of functions that do one thing well, and Smalltalk’s debugging tools like Inspect-It and Debug-It further streamlined the process.

    Challenges and Solutions

    However, she encountered challenges. While most errors in Smalltalk were easy to handle—usually, closing the Debugger was all that was needed—some issues could freeze the image, making recovery a bit more manual than desired. She found herself needing to use the Recover Changes window to restore unsaved changes more often than she would have liked.

    In terms of rendering, she faced performance limits with BitBlt when texturing the floor and ceiling. To overcome this, she turned to the AbstractGPU library, leveraging the graphics card for drawing. She continued to use the ray caster to determine what the player could see to speed up the game, but introduced edge pop-in, where objects on the screen edges would suddenly appear while turning the camera, because of differences between the ray caster’s projection and the GPU’s projection. Increasing the field of view used by the ray caster resolved this issue.

    Testing Using Morphic Dungeon

    Morphic Dungeon is what Lauren developed and uses to test the movement and texturing code. She wants to work with textures that are not symmetrical, which requires mapping the top-left corner of the texture to different positions on each face of the 3D objects. This approach also allowed her to test back-face culling—a technique that improves performance by not drawing faces of a 3D object that are not visible to the camera—in the GPU mode. In this mode, the “back faces” are flipped horizontally and appear further away, as if looking at the inside of a transparent painted box instead of the outside. Back-face culling will be essential for rendering the “walls” of tiles that the player can enter or see through, such as grass or support beams along the grid edges.

    Lauren implemented three movement modes:

    • Free Movement and Free Turning
    • Grid-Locked Movement and Free Turning
    • Grid-Locked Movement and Grid-Locked Turning

    Full Free Movement is similar to Wolfenstein 3D, allowing sub-pixel steps and small increment camera rotations.

    Grid-Locked Movement is useful for first-person dungeon crawlers. Grid-Locked Turning forces camera rotation to 90-degree increments, similar to classic non-raycaster games like Wizardry or modern titles like Etrian Odyssey. Free camera rotation, with Grid-Locked Movement, is also supported which is similar to the modern title Operencia.

    While using Morphic Dungeon to test the different movement modes, Lauren encountered an amusing floating point error whereby the player would step repeatedly through walls and out of the play area. This provided a humorous insight into the potential bugs she might encounter.

    Additionally, Lauren tested the game with a family member, revealing that the 40×40 maze, though not difficult from an overhead view, proved challenging from a first-person perspective without an overhead view or compass. This feedback helped her adjust the difficulty of the first area to better suit new players.

    Future Plans

    Looking ahead, she plans to explore non-flat levels and dynamically stitching multiple maps together. This might result in overlaps while rendering, so the ray caster will be in charge of telling the graphics card what to draw. Meanwhile, she will focus on improving floor and ceiling loading performance, although this is currently less critical due to the few vertices involved.

    Lauren believes that developing a game is a great way to introduce people to programming. While tools are useful, having something that you can play with is fun. Old tile-based games and raycasters are particularly appealing to her because they are simple to work with, even for beginners.

    Overall, Lauren believes that Squeak has proven to be an excellent choice for her project, offering the simplicity and functionality needed for a successful game development experience.

    Why Not Give It a Try?

    If you would like to experiment with ray casting in Squeak, you can find out more about her project from SqueakSource here. To use the 3D accelerated package, you will also need AbstractGPU by Ronie Salgado, available (here). Ronie is the author of a number of terrific 3D development tools, including Woden (here) and Sysmel (here). Be sure to explore these excellent resources as well!

    Have a great time with Smalltalk and keep on Squeaking!

  • Discover BYTE Magazine Archives at World Radio History: A Valuable Resource for Tech Enthusiasts and Smalltalk Historians

    Discover BYTE Magazine Archives at World Radio History: A Valuable Resource for Tech Enthusiasts and Smalltalk Historians

    Tim Rowledge, a dedicated community member and long-time contributor, has uncovered a fantastic resource for tech enthusiasts: a comprehensive archive of BYTE magazine issues hosted on World Radio History. This well-organized collection spans from 1975 to 1994 and offers a detailed look at the technological advancements of the time, including the early development of Smalltalk. You can explore the archive here.

    Among the highlights is the August 1981 edition, famous for featuring the iconic Smalltalk balloon on its cover. This issue is notable for introducing Smalltalk’s unofficial logo. Curious about the significance of the hot air balloon and what it represents? Delve into this intriguing piece of history on the Squeak wiki. You can access the 1981 edition here.

    Also of interest is the August 1991 issue, which includes the article “Smalltalk: 10 Years of Objects.” This piece provides a retrospective and a forward-looking view on Smalltalk, reflecting on its progress since the 1981 feature. You can view this edition here.

    World Radio History’s BYTE magazine archive is a valuable tool for anyone interested in the history of computing and programming languages, offering both a broad overview and specific insights into the technology of the past.

    Additionally, Tim also found some other nice historical videos presented by Capt. Grace Hooper at NSA in 1982 on “Future Possibilities: Data, Hardware, Software, and People.” You may find some fascinating bits of history from her lectures. You can view part 1 here and part 2 here.

    The BYTE archive, along with these historical videos, offers a unique perspective on how early technologies and visionary ideas have shaped modern computing. Together, they provide an invaluable window into the technological advancements and influential figures that have defined the computing landscape.

  • Announcing GraphQL for Squeak: A Structured Query Language for Flexible API Development

    Announcing GraphQL for Squeak: A Structured Query Language for Flexible API Development

    A few days ago, Chris Muller announced the immediate availability of GraphQL for Squeak, a package that allows efficient data query and manipulation within the Squeak environment using the powerful GraphQL language. This release introduces a comprehensive implementation of the GraphQL specification, opening another door for Smalltalk developers to create flexible, performant applications with real-time capabilities.

    What Is GraphQL?

    GraphQL is an API query language that allows clients to request precisely the data they need, and nothing more. Unlike traditional REST APIs, where multiple endpoints return fixed data structures, GraphQL provides a single endpoint and a flexible query system. This system empowers clients to define the structure of the response, making it highly efficient and tailored to their needs.

    GraphQL is particularly well-suited for applications that require real-time data updates and complex queries. It supports features such as strong typing, relationships between data types, and aggregating multiple resources into a single query. These characteristics make GraphQL a great fit for building robust servers and clients in Squeak, particularly when dealing with complex domain models and the need for real-time data synchronization.

    Introducing GraphQL for Squeak

    The GraphQL implementation for Squeak, developed by Chris Muller, strictly adheres to the current GraphQL specification (October 2021) and is made available under MIT license. This is a complete implementation. Every grammar, validation, and execution rule defined in the specification is covered by at least one test case. The framework integrates seamlessly with Squeak.

    Key Features:

    • Complete GraphQL Specification Compliance: The implementation covers every aspect of the GraphQL specification, ensuring that your applications can utilize all features, including asynchronous subscriptions.
    • Documentation and Examples: Included help pages illustrate working examples, making it easy to get started and explore the capabilities of the framework.
    • Modular and Extensible: Type systems (and their associated resolvers) can be defined and assembled into complete applications.
    • Custom Scalar Types and Directives: Several additional custom scalar types and powerful directives are included to enhance your development experience and streamline common tasks.

    Interoperability Is King

    One benefit of GraphQL is how conformance to a standard fosters greater interoperability between not only systems but the groups surrounding them: whether between users and developers, organizations and their customers, or front-end and back-end technologies – GraphQL optimizes the right separations of concerns.

    For example, having a standard way to inspect the schema of a live GraphQL-based system opens possibilities for automated cooperation that are impossible without a standard. As organizations publish their GraphQL schemas, implementers can help optimize their customer-facing experience with tools that capitalize on the features of GraphQL. GraphQL allows certain elements like type and field definitions to have integrated markup “documentation” which could be rendered in user interfaces, or as a page in a generated “help” compendium. The possibilities are limitless.

    Being able to easily parse and interact with other organizations’ GraphQL schemas directly in the image could open new potentials for integration. Exploring the following expression lets one browse the type definitions and directives of the GitHub GraphQL API:

    GqlParser parse:
	(WebClient httpGet:
		'https://docs.github.com/public/fpt/schema.docs.graphql') content

    Try It Out!

    Install the GraphQL package into Squeak Trunk by selecting the (head) version of the project from the SqueakMap window (available via the Apps menu of the world main docking bar).

    Alternatively, simply execute this in a workspace:

    Installer new merge: #graphQlTestsEngine

    To verify the installation, tests can be found under the GraphQL-* packages in the TestRunner (available under the Tools menu).

    To get started, you can run the following snippet, which creates a small but complete GraphQL engine for searching all classes in the system for certain names.

    | system engine |

"Define a small type system and its resolver."
system := GqlSystemDefinition
	typeSystem: '
		type Class {
			name : String!
			superclass : Class
		}
		type Query {
			findClasses(pattern : String) : [Class!]!
		}'
	resolver: 
		(GqlCraftedSchemaResolver new map: {
			{ 'Query'. 'findClasses'. SystemNavigation. #allClassesAndTraitsMatching:. #('pattern') }.
			{ 'Class'. 'name'. Class. #name }.
			{ 'Class'. 'superclass'. Class. #superclass }
		}).

"Instantiate the engine, supply a domain provider."
engine := GqlEngine
	systemDefinition: system 
	providers: {self systemNavigation. nil. nil}.

"Execute the only possible query, request the name and the superclasses' name for each result."
(engine execute: '{
	findClasses(pattern: "*Collection") {
		name
		superclass { name }
	}
}') response data

    This query will return the following JsonObject:

    Help Is Available

    After loading the package, a “GraphQL” section will also become available in Squeak’s Help Browser (available via the help menu in the docking bar), where you can find detailed guidance and more complex examples to experiment with.

    Roadmap

    The next step is a networking package to accept GraphQL requests sent from a client to a server and return the JSON responses. This is well underway and planned to be released soon.

    Happy Squeaking!

    Authors: Chris Muller and Christoph Thiede