Idiomes pour composer des jeux EToys

From OFSET Community Wiki

Jump to: navigation, search

Voir aussi: E-toys idiomes de programmation


Traduction de : Markus Gaëlli, Oscar Nierstrasz, Serge Stinckwich, "Idioms for Composing Games with EToys", (fichier pdf), The Fourth International Conference on Creating, Connecting and Collaborating through Computing (C5 2006).

Je ferais la traduction petit à petit. Sergio


Contents

Résumé

Créer ses propres jeux a été la motivation principale d'apprendre à programmer pour plusieurs personnes. Mais les barrières pour apprendre un langage de programmation générique sont importantes, notamment si certains résultats positifs ne peuvent être espérés qu'après avoir écrit plus de 100 lignes de code. Dans cet article, nous voulons motiver quelques utilisateurs potentiels en montrant qu'il est possible de créer des jeux de plateau ou d'arcade comme Lights Out, TicTacToe ou encore Pacman en utilisant l'environnement d'apprentissage constructiviste et ludique Etoys, en glissant-déposant quelques lignes de code. Puis nous présentons quelques idiomes récurrents pour développer ces jeux en seulement quelques lignes.

Introduction

Any problem in computer science can be solved with another level of indirection. But that usually will create another problem. — David Wheeler

Software people tend to favor the joy of complexity, yet we should strive for the joy of simplicity. — Alan Kay

Squeak est une implémentation libre et indépendante de la plateforme matérielle, du langage de programmation Smalltalk écrit en lui-même et par de nombreux développeurs. Il inclue un support pour le réseau, le graphisme 2D et 3D, un environnement intégré de développement et un environnement constructiviste d'apprentissage pour les enfants appellées EToys [9]. Les EToys sont utilisé comme un véhicule pédagogique tout autour du monde, ceci inclue des écoles aux Etats-Unis, au Japon, en Espagne, en France et en Allemagne. Etoys offre une nouvelle façon de programmer au plus grand nombre : généralement, les langages de programmation les plus utilisés comme Java et C++ sont basés sur du texte et nécessite une stricte séparation entre l'interface graphique et le modèle. Au contraire, les EToys qui s'inspire du modèle de Self [18] ont une interface qui permet à un développeur par des opérations de glisser-déposer de manipuler directement des objets visuels. En ne séparant par l'interface du modèle, EToys ouvre l'opportunité d'explorer un paradigme de développement d'application très différent, bien que l'environnement soit plutôt contraint. Nous présentons ici plusieurs applications complexes construites au moyen des EToys et nous identifions plusieurs idiomes qui permet à un développeur de conserver interface et modèle ensemble dans le même objet.

En composant des exemples classiques de jeux construit au moyen des EToys et en publiant des idiomes récurrents utilisés en développant ces jeux, nous espérons motiver et aider de potentiels utilisateur de Squeak pour jouer avec "cet instrument dont la musique sont les idées".

Les jeux présentés dans ce papier ainsi que d'autres peuvent être téléchargés avec leur script à partir du site web du premier auteur [6]. Le reste de ce papier est structuré comme suit : nous introduisons premièrement les jeux classiques construits à l'aide d'EToys, puis nous expliquons les idiomes visuels qui ont été utilisés pour ces jeux.

Jeux

Taquin

Figure 1 : Taquin composé avec 4 lignes de code

Le jeu de Taquin [7] a été inventé par Sam Loyd dans les années 1870. Dans la version originale, les pierres 14 et 15 ont été interchangées et la tâche (impossible) pour le joueur est de mettre tous les nombres de 1 à 15 dans l'ordre. Comme vous pouvez le voir dans la figure 1, il est possible de créer une interface utilisateur de ce puzzle en seulement 4 lignes de code.

Caractéristiques

Il s'agit d'une implémentation basique du jeu mais elle a une interface utilisateur facile à utiliser. Le joueur a juste à déplacer la souris au dessus d'une pierre qui est la voisine d'une cellule vide et immédiatement la pierre se déplace à l'emplacement vide.

Idiome : Curseur visuel

La cellule vide courante est conservée dans le curseur de la zone de jeu du puzzle (playfield).

Idiome : Voisins connectés

L'astuce consiste à faire des cellules avec des bords arrondis. Il est alors possible de changer la disposition des cellules de telle sorte que les cellules voisines horizontales et verticales se recouvrent alors que n'est pas le cas de celles en diagonale. Le test pour savoir si une cellule est voisine de la cellule vide se transforme alors en requête pour savoir si le morph de la cellule recoupe le morph de la cellule vide qui est conservé comme une variable du conteneur.

Memory

Figure 2 : Memory composé avec 32 lignes de code

Memory [4] est un jeu d'enfant classique dont le but est d'identifier des paires de cartes identiques parmi un ensemble de cartes retournées. Lorsqu'une paire correspondante est découverte, les cartes restent faces visible jusqu'à ce que toutes les paires soient découvertes.

Caractéristiques

Notre version possède un compteur de clicks nécessaires pour l'utilisateur pour retourner toutes les cartes et un bouton de redémarrage qui devient actif lorsque toutes les cartes sont retournées. Comme on le voit dans le figure 2, nous avons utilisé des photos plutôt que des symbole comme il est facile de les importer dans Squeak : il suffit de les glisser-déposer dans la fenêtre de Squeak. Nous avons composé le jeu avec seulement 32 lignes de code.

Idiome : Curseur visuel

La dernière carte révélée est conservée dans le curseur du playfield du jeu de Memory. La fois suivante qu'une carte est retournée, elle est comparée à la carte la plus récemment retournée. Si elles sont identiques, elles sont toutes les deux retournées sinon elles restent face à terre.

Lights Out

Figure 3 : Lights Out composé avec 6 lignes de code

Le but de Lights Out [11] (voir figure 3) est de transformer toutes les cellules de la même couleur. Lorsqu'une cellule est sélectionnée, cette cellule ansi que ses voisines horizontales et verticales, inverse sa couleur.

Caractéristiques

Nous avons implémenté seulement les principes de base qui gouverne ce jeu. Il n'y a pas de gestion du jeu ou de réinitialisation de l'application. La taille de la zone de jeu peut facilement être ajusté en ajoutant ou en enlevant des cellules.

Idiome : Curseur visuel

La dernière cellule sélectionnée est conservée dans le curseur de la zone de jeu.

Idiome : Voisins connectés

L'idée est d'utiliser encore une fois les coins arrondis et de changer la présentation de telle sorte que toutes les cellules voisines horizontales et verticales se recoupent. Alors le deuxième script s'exécute qui inverse toute les cellules recoupant la cellule courante enregistré dans le conteneur. Comme la cellule courante se recoupe avec elle-m^ême, elle est aussi inversé.

Pong

Figure 4 : Pac man composé avec 28 lignes de code

Pong (voir figure 4) est le premier jeu d'arcade qui ait jamais existé and a été réalisé à l'origine au moyen d'un oscilloscope. Deux raquettes de ping-pong de chaque côté d'une table peuvent être déplacé vers le haut et le bas afin de faire rebondir une balle vers l'autre joueur.

Caractéristiques

Nous avons implémenté un algorithme très simple de rebond pour la balle : si la balle collisionne la raquette, elle rebondit avec un angle de retour égal à son angle d'arrivée. Le score du joueur gauche est augmenté si la balle est ratée par le joueur droit et vice-versa. Rien de spécial n'arrive dans cette version lorsqu'un joueur gagne. Les joueurs doivent appuyer sur une touche du clavier à chaque fois qu'ils veulent déplacer la balle.

Idiome : Environnement intelligent

Les murs horizontaux et verticaux sont des rectangle-siblings (?) distincts. Si le mur vertical s'aperçoit qu'il intersecte avec la balle, le compteur opposé est incrémenté de un et la balle est remise au milieu de la zone de jeu.

Idiome : Texte comme une variable

Les compteurs sont en fait juste des textes : chaque mur vertical a une variable d'instances qui est typé comme "player" et pointe vers le texte.

Tic Tac Toe

Figure 5 : Version deux joueurs de Tic Tac Toe avec 36 lignes de code

Tic Tac Toe (voir Figure 5) est un jeu de plateau classique et l'un des tous premiers programmes écrit par les premiers auteurs sur le Commodore 64 en utilisant Basic, le langage de programmation auquel chaque propriétaire de C64 était confronté après avoir allumé sa machine. Le but du jeu est de disposer trois pierres dans une ligne diagonale, verticale ou horizontale.

Caractéristiques

La version EToy procure une interface utilisateur relativement complète. Il donne aux joueurs une information en retour sur qui a gagné le jeu et pourquoi (indiquant la ligne gagnante en rouge), et un bouton de réinitialisation, qui n'est activé qu'à la fin du jeu.

Idiome : Environnement intelligent

Comme les EToys n'offre pas de mécanismes pour faire des opérations sur les matrices, nous avons besoin de procéder autrement pour détecter si 3 pierres d'un même joueur sont disposées en ligne. Nous faisons cela en introduisant des lignes comme on peut le voir sur la figure 5. Nous associons à chaque pierre des joueurs soit une valeur 1 ou -1. Lorsqu'une pierre est placé, sa valeur est ajouté au compteur de chaque ligne concernée. Lorsqu'une ligne atteint la valeur 3 ou -3, nous savons qu'un joueur ou l'autre a gagné.

Idiome: Fabrique visible

Nous indiquons le joueur courant, en mettant le curseur du holder (?) soit en forme de cercle ou de croix. Dans le même temps, nous utilisons la pierre indiquée, comme prototype pour la copier dans la case vide sur laquelle l'utilisateur a cliqué.

Space Invaders

Figure 6 : Space Invaders composé avec 64 lignes de code

Peter Vogel, un enseignant, avec quelques connaissances en Basic a développé ce jeu d'arcade classique (voir figure 6) en EToys, avec un peu d'aide de la part d'un des auteurs.

Caractéristiques

Nous avons conçu quelques aliens lanceurs de bombes, un vaisseau qui ne peut tirer q'une roquette visible à un instant donné, et qui uniquement manipulable par l'intermédiaire d'une manette de jeu et pas à partir du clavier (le support du clavier dans les EToys est seulement arrivé récemment). Le jeu fournit aussi un affichage du jeu et la possibilité de le redémarrer.

Idiome : Encoder les interactions à l'intérieur des objets concernés

Lorsqu'une roquette touche un alien, il est détruit. Pour avoir une référence sur un alien, nous encodons la méthode "vérifier pour destruction" sur les aliens, qui font tous partie de la même fratie (siblings). D'un autre côté, nous encodons le comportement des bombes aliens détruisant le vaisseau mère dans les bombes comme nous avons un seul vaisseau-mère et ainsi sa référence est claire.

PacMan

Figure 7 : Pac man en 36 lignes de code, mais pac man ne peut pas manger de monstres

Pacman est le jeu classique d'arcade dans lequel on contrôle un personnage dans un labyrinthe de tel sorte qu'il mange des pilules et évitent les monstres. Si certaines pilules sont mangées, pacman peut manger les monstres pendant un certain temps.

Caractéristiques

Les pilules peuvent être mangées, le score est géré, et les monstres envoient pacman dans la tombe. Pour l'instant, pacman ne peut pas manger les monstres. (Voir figure 7) Il faut bien admettre que le plaisir fut plus dans le développement du jeu que dans le fait d'y jouer effectivement, tant la version actuelle est trop pauvre en fonctionalités pour être vraiment intéressante.

Idiome : Environnement Intelligent

Une astuce que nous avons utilisé pour que les monstres suivent les allées a été d'insérer des points aux intersections. Lorsque les monstres collisionnent avec de tels points, il change leur direction aléatoirement. Nous avons également introduit une zone de jeu (playfield) tombe : si pacman meurt, il est inclu dans une zone de jeu cachée appellé "tombe". Nous avons seulement à le retirer ce cette zone lorsque le jeu redémarre.

Idiome : Encoder les interactions à l'intérieur des objets concernés

Pacman mange les pilules. Mais nous n'avons pas codé ceci dans le pacman mais dans la pilule : seulement dans ce cas nous avons une référence vers la pilule mangé que nous pouvons utiliser pour la cacher.

Idiome : Texte considérée comme une variable

De nouveau, nous incrémentons un champ textuel conservant le score le plus haut à chaque fois qu'une pilule est mangée.

PetitPetri

Figure 8 : le dîner des philosophes avec un réseau de Petri en 24 lignes de code

Les réseaux de Petri sont le "flipper" des mathématiciens [15]. Ils sont utilisés pour décrire formellement des processus concurrents dans l'exemple classique d'interblocage des philosophes qui dinent [5]. Nous avons implémenté un éditeur de réseau de Petri simple en EToys (voir figure 8) et nous l'avons utilisé dans un enseignement de master à l'Université de Berne. Un réseau de Petri consistent en des transitions et des places connectées par des arcs dirigés. Une place est un conteneur qui peut contenir plusieurs éléments. Si les arcs arrivants à une transition sont connectés à des places contenant au moins un élément, alors la transition peut être activée et déclenchée. Lorsqu'une transition est déclenchée toutes les places connectées en entrée réduisent leur nombre d'éléments de 1 et toutes les places sortantes augmente leur nombre d'élément de 1.

Notre implémentation [12] utilise le cadre d'application Connectors de Ned Konz [10], qui se trouve dans la version 2005 de Squeakland. À la différence d'autre cadre d'applications graphique comme Hotdraw [3], les connecteurs et les éléments connectés peuvent être programmé directement : la où avec Hotdraw il faut généralement dupliquer la topologie d'un graphe en représentant à la fois graphiquement et comme modèle, les connecteurs invitent le développeur à manipuler directement les noeuds et les arrêtes. Les connecteurs par exemple offre des expressions pour envoyer des messages à tous les noeuds entrant ou sortant.

Caractéristiques

Ceci est une implémentation vraiment de base des réseaux de Petri mais avec une interface facile à utiliser. Les transitions, les places et les arcs peuvent être créé utilisant des boutons fabriques offerts par le cadre d'application des connecteurs. Lorsqu'une transition devient active, elle passe au vert et il devient possible de cliquer dessus pour la déclencher. Les éléments sont représentés par des entiers, qui peuvent être éditer directement. Des connections multiples entre les places et les transitions ne sont proposés pour l'instant.

Idiome : Fabrique visible

Une partie essentielle de l'interface utilisateur de PetitPetri est la barre de boutons à partir de laquelle il est possible de construire de nouveaux conteneurs, transitions et arcs. Le créateur de bouton fait partie du cadre d'application des connecteurs.

Idiomes

Examinons de plus prêt les idiomes que nous avons utilisé pour construire les jeux décrits ci-dessus. Although we do not wish to belabor the point whether these are “just idioms” or “re- ally design patterns” [8], we note that they seem to fit the characterization of design patterns posed by the architect Christopher Alexander:

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a mil- lion times over, without ever doing it the same way twice. [1]

Le principe de conception derrière chacun de nos idiomes est : "La forme est la fonction" [19] : les objets introduits ou adaptés sont tous visuels et ainsi mélange leur comportement et leur présentation comme les objets nus (naked objects) de Pawson et al. [14]. Le comportement de ces objets visuels dépendent de leur forme, position ou couleur. Ainsi nous pouvons maintenir un nombre de lignes de code peu élevé.

Comme l'architecture LLoyd Wright disait :

la forme suit la fonction - ceci a été mal compris. Forme et fonction devrait être une, joint en une union spirituelle.

Environnement intelligent

Encoder d'une autre manière le comportement implicite d'un objet dans un autre objet de l'environnement.

Motivation

Le jeu de Tic Tac Toe est gagné quand trois pierres du même type sont mises sur une ligne horizontale, verticale ou diagonale. Manquant d'un type de données invisible et abstrait en EToys, le développeur est obligé de penser à une représentation visuelle de ces lignes. En introduisant de véritables lignes intelligentes, le problème peut être résolu. De plus, la condition de victoire peut être visualisée en colorant la ligne gagnante en rouge. Mettre de l'intelligence dans l'environnement est une technique bien connu et peut-être trouvé dans Kedama et StarLogo [13] [16], dans lequel l'intelligence est mise dans les "patches" dans lesquels les tortues vivent.

Applicabilité

Utiliser cet idiome à chaque que le comportement d'un objet dépend de son environnement. Demander vous si vous pouvez altérer l'environnement de telle sorte qu'il représente visuellement le problème.

Conséquences

Modifier l'environnement soit en changeant ses propriétés visuelles, comme sa couleur, ou bien en introduisant de nouveaux objets visuels non seulement aide à créer une solution plus distribuée et plus objet, mais aussi permet de donner un feedback visuel direct à l'utilisateur.

Usages connus

Dans la démo EToys classique de la voiture, de filles de 10 ans sont arrivées à une solution différente pour automatiquement faire tourner la voiture sur une piste : au lieu de proposer deux capteurs de couleurs différentes, elles ont encodées la solution dans l'environnement - lorsque la voiture voit un lac bleu à l'intérieur de la piste, la voiture tourne à gauche, lorsque elle voit la couleur grise qui entoure la piste à l'extérieure, elle tourne à droite. Dans l'implémentation du pacman, nous avons encodés les jonctions pour les montres en disposant des carrés à la jonction. Lorsqu'un monstre rencontre de tels carrés, il change de direction aléatoirement.

Encoder les interactions dans les objets concernés

Lorsqu'un objet d'un certain type interagit avec un objet d'un autre type, encoder le comportement dans l'objet affecté.

Motivation

Les roquettes détruisent les aliens. Pour détruire un alien, il faut disposer d'une référence sur l'alien affecté après qu'il est a rencontré une roquette. EToys pour l'instant ne propose pas des références vers des objets touchés par un objet donné. Il devient donc nécessaire de détecter la rencontre du côté de l'objet affecté, parce que forcemment il a une référence sur lui-même.

Applicabilité

Utiliser cet idiome à chaque fois que vous avez besoin de vérifier une condition externe comme des collisions et vous avez besoin de changer de l'état de l'objet plus tard. Encoder le test et sa conséquence dans l'objet affecté.

Conséquences

Utiliser cet idiome va ralentir votre jeu. Au lieu de laisser le pacman détecter les collisions avec les pilules, il est nécessaire de lancer un processus pour chaque pilule dans le jeu.

In the case of collisions each EToy should have a pluggable behavior or trait [17] that would allow the developer to ask it for all objects which actually collide with it. Therefore it would be desirable to enumerate these objects and send some messages to them: EToyers miss the select: and do: idioms known from Smalltalk and this idiom only provides a trick to circumvent this problem.

Dns le cas de collision chaque Etoy devrait avoir un comportement qui permette au développeur de lui demander pour tout les objets qui sont en collision. Donc, il serait souhaitable d'énumérer ces objets et de leur envoyer un message. Les Etoys ne disposent pas des idiomes select: et do: de Smalltalk et seuls ces idiomes peuvent résoudre le problème.

Usages connus

Le pacman qui mange des pilules et les roquettes tuant les aliens.

Curseur visuel

Stocker l'élément sélectionné d'une zone de jeu (playfield) dans un curseur.

Motivation

Comme nous avons vu dans Lights Out et le jeu de Taquin, il est souvent nécessaire d'itérer parmi tous les éléments d'un playfield et de comparer chaque élément avec un en particulier. Afin d'accomplir cela, nous stockons l'élément qui nous intéresse dans le curseur du playfield qui l'entoure.

Applicabilité

Utiliser cet idiome à chaque vous devez sélectionner un élément d'un playfield.

Conséquences

Actually there is already a cursor in play- fields but it is only settable via the index of an element. Incrementing the cursor index of playfields is enough when one wants to do simple animations. For selecting given el- ements it is rather cumbersome to first detect the index of the element only to set it later. It would be nice if EToys provided a direct way of setting the cursor to some given element.

Usages connus

Les curseurs visuels sont utilisés pour faire des animations comme l'a montré Allen-Conn et al. dans [2]. We broadened their scope for highlighting an element of a playfield to detect overlapping elements like in the 14-15 puzzle or Lights Out or to store them as in Concentration.

Texte comme des variables

Utiliser des textes pour enregistrer directement des valeurs.

Motivation

It is cumbersome to introduce integer typed variables holding some score-value, only to update some text fields later whenever the score has changed. Instead we use the text-morphs provided by “supplies” to directly store the score into them. We then can get or set the score via the numericValue tile found in the “basic”-category of the text-viewer.

Applicabilité

Use this idiom whenever you display some textual information to the EToy-user that might be recom- puted later.

Conséquences

As an alternative one could also introduce new variables and then drag out watchers to display their values to the user. But these watchers come with a small font and currently one cannot change these font-families and font-sizes. Text-morphs can be seen as global variables. But this does not hurt too much in the case of the games we presented here: All the objects which are of interest to the user are also of interest to the developer and fit on one screen. Texts can also be “scoped” by putting them into some playfields.

Usages connus

We used this idiom whenever we had to dis- play some score or high-score to the user.

Voisins connectés

Encode neighborhood relationship of objects by letting them overlap.

Motivation

Many board games consist of a matrix of connected cells. In some games the cells are neighbors only horizontally or vertically (e.g., 15-puzzle), in some also the diagonals are neighbors too (e.g., Game of Life). In order to detect if two cells are neighbors, one can change the layout of the matrix in such a way that connected neighbors over- lap. If the cells are not neighbors on the diagonals, we make the borders rounded, thus reflecting their relationship both to the EToy-Developer and to the user. The developer then only has to ask if the current cell, possibly stored in a visual cursor, overlaps a given (e.g., clicked) cell.

Applicabilité

Use this idiom whenever you need to intro- duce neighbors to each other.

Conséquences

Cet idiome permet au développeur de détecter si deux cellules sont voisines.

Usages connus

See Section 2 for the 15-puzzle and Lights- Out or [6] for the game of life. The trick in the case of these matrix based playfields is to change the layout of the matrix, so that neighboring morphs overlap.

Fabrique (motif de conception) visible

Store the prototype of an object in some place which makes sense to the end user.

Motivation

Having a display indicating the ships left is essential to the space-invaders player. When a ship is de- stroyed, the user has the imagination, that the next ship comes out of the home base. But what makes sense to the user, also makes sense to the developer: She could reuse the rocket base as a visual prototype-holder to fetch the next rocket, after one has been destroyed.

Applicabilité

Use this idiom whenever you have stones of different colors to set, ships to launch or pacmen to put into some game.

Conséquences

This idiom allows the developer to display valuable state information like ships left to the user, while fully exploiting the metaphor of a base station by really tak- ing the next ship from there. Therefore the lines of code decrease, and the game is easier to understand.

Usages connus

In the Tic Tac Toe example we indicated the current player in the holder by highlighting his/her stone. This very stone is copied into the cell clicked, when the player makes his move, before the next prototype stone is selected again. The button-makers of

Remarques de conclusion

Nous avons montré qu'il est possible de grande variété de jeux classiques en EToys en quelques ligne de code. As such, EToys is surely attractive to beginning programmers who are eager to see the fruits of their labours as early as possible. However, we believe that EToys exposes some other im- portant notions that seem to run against the grain of con- ventional programming. Most significantly, EToys trashes the conventional wisdom that one should separate the model from the view. All objects have a graphical representation. Furthermore there are no objects that are not graphical. This can be both a curse and a blessing, as illustrated by the pro- gramming idioms we have identified. For instance, in order to get around the fact that there are no hidden data struc- tures, one must introduce visible entities that make up for this lack. Instead, however, of simulating data structures with graphical objects, one programs in a different way — the programmer is forced to think in terms of what is ex- plicit and visibly present. Some of the idioms we have identified begin to look like design patterns — best practices that that solve com- mon design problems — but others look a bit like clumsy workarounds that compensate for shortcomings in the pro- gramming environment. We do not yet have enough insight to propose alternative solutions, but we hope that we may have convinced the reader that EToys are more than just toys, and could well indicate a path to more expressive and direct way of programming. We also hope our examples and suggested idioms help a bit to make teaching and learning to program possible and fun, which it should be.

Remerciements

Nous remercions le support financier de la "Swiss National Science Foundation" pour les projets “Tools and Techniques for Decomposing and Composing Software” (SNF Project No. 2000-067855.02, Oct. 2002 - Sept. 2004) et “RECAST: Evolution of Object-Oriented Applications” (SNF Project No. 620-066077, Sept. 2002 - Aug. 2006).

Bibliographie

  • [1] Christopher Alexander, Sara Ishakawa, and Murray Silverstein. A Pattern Language. Oxford University Press, New York, 1977.
  • [2] B.J. Allen-Conn and Kimberly Rose. Powerful Ideas in the Classroom. Viewpoints Research Institute, Inc., 2003.
  • [3] John Brant. Hotdraw. Master’s thesis, University of Illinois at Urbana-Chanpaign, 1995.
  • [4] Concentration. http://en.wikipedia.org/wiki/Concentration_(game).
  • [5] Edsger W. Dijkstra. Hierarchical ordering of sequential processes. Acta Informatica, 1(2):115–138, 1971.
  • [6] Composing Simple Games with EToys. http://www.emergent.de/etoys.html.
  • [7] 15 Puzzle. http://en.wikipedia.org/wiki/N-puzzle.
  • [8] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, Reading, Mass., 1995.
  • [9] Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay. Back to the future: The story of Squeak, A practical Smalltalk written in itself. In Proceedings OOPSLA ’97, ACM SIGPLAN Notices, pages 318–326. ACM Press, November 1997.
  • [10] Ned Konz. Connectors: A framework for building graphical applications in squeak. In IEEE C5: The Second International Conference on Creating, Connecting and Collaborating through Computing, volume 2, pages 96–103, 2004.
  • [11] Lights Out. http://en.wikipedia.org/wiki/Lights_Out_(game).
  • [12] Oscar Nierstrasz and Markus Gaelli. PetitPetri—A Petri Net Editor done with EToys, September 2005. http://www.iam.unibe.ch/~scg/Teaching/CP/PetriNets.
  • [13] Yoshiki Ohshima. The Early Examples of Kedama, A Massively Parallel System in squeak. In IEEE C5: The Third International Conference on Creating, Connecting and Collaborating through Computing, volume 3, pages 93–100, 2005.
  • [14] Richard Pawson and Robert Matthews. Naked Objects. Wiley and Sons, 2002.
  • [15] James L. Peterson. Petri nets. ACM Computing Surveys, 9(3):223–252, September 1977.
  • [16] Mitchel Resnick. Turtles, Termites, and Traffic Jams. MIT Press, 1994.
  • [17] Nathanael Schärli. Traits — Composing Classes from Behavioral Building Blocks. PhD thesis, University of Berne, February 2005.
  • [18] David Ungar and Randall B. Smith. Self: The power of simplicity. In Proceedings OOPSLA ’87, ACM SIGPLAN Notices, volume 22, pages 227–242, December 1987.
  • [19] Bosse Westerlund. Form is Function. In Proceedings DIS 2002 Serious reflection on designing interactive systems, pages 117–124, July 2002.
  • [20] David Wheeler. http://en.wikipedia.org/wiki/David_Wheeler.
Personal tools