Implementing a Ludo Game as a moldable development exercise
Ludo is a simple strategy game for 2-4 players. In these pages we illustrate moldable development by showing how to implement a Ludo game in GT.
Background: an introductory Smalltalk lecture
The Ludo game was the team exercise for the first-year programming course in Java at the University of Bern in 2022. The course included a guest lecture on Smalltalk. (For the live GT slideshow, see the Smalltalk Introductory lecture.)
We decided to implement the same exercise in GT to highlight to the students the difference between programming in Java and Smalltalk, and expecially using moldable development.
For the record, here are the exercise descriptions from the course (it's not necessary to read these to follow the tutorial):
For the sake of simplicity, we are not showing each incremental version of the game, but only the final version. As a result, please keep in mind in the live examples which parts already exist and which ones have not yet been implemented.
The following pages were originally drafted while developing the game, as a way of documenting the moldable development process. The pages were then edited and revised after the game had been completed.
As a first step, we create a simple model of the Ludo board state, without any game logic or graphical presentation
We continue by introducing some custom views for Players and Squares.
We extend the low-level interface to have tokens change their state when they enter play. We prototype this in the Playground, and then promote the snippet to an example method with assertions.
We create a visualization of the board state, that can be used as the basis for various views, and also form the basis for the game UI.
We show how the Die for the Ludo game can be implemented in Playground snippets, while we document our steps as text snippets.
We introduce the
move: method to the game, which, together with
computeTargetFor: encapsulates the rules of the game.
We decorate the Board view with a pane where we can give feedback to the user about what is happening in the game.
Now we start to add examples that track the progress of a game.
We create examples to test all the possible scenarios of tokens landing on other tokens.
We describe the steps taken in merging the
This is an illustration of how we can construct a refactoring scenario with dummy classes.
We want to explore the past moves of a game and the intermediate states, so we introduce first-class moves, and a recording version of the game.
Finally we clean up various open issues.