Differences

This shows you the differences between two versions of the page.

--- turtle [2024/01/12 03:17] – appledog
+++ turtle [2024/01/12 03:37] (current) – appledog
@@ Line 205: / Line 205: @@
 This class clearly and succinctly defines the //turtle world// and the position and velocity of the //turtle//.
+== TurtleProgram.py
+The turtle program is a way to store and deal with turtle programs (i.e. '.t files').
+<Code:Python>
+class TurtleProgram:
+    def __init__(self, turtle):
+        self.turtle = turtle
+        self.program = []
+        self.pc = 0
+    # Erase the program
+    def reset(self):
+        self.program = []
+        self.pc = 0
+    def add(self, s):
+        self.program.append(s)
+    def run(self):
+        self.pc = 0
+        while self.pc < len(self.program):
+            self.do(self.program[self.pc])
+            self.pc += 1
+</Code>
+In this beginning part of the program we define what a program is (an array of lines) and we allow for lines to be added and cleared from the program. There is also the concept of running the program. The addition of the run() command as a stub leads us to part II, the do command. Think of this like an instruction fetch cycle for a CPU, with the do() method being the actual lookup and execution of the command.
+=== opcode execution: do()
+<Code:Python>
+    def do(self, statement):
+        # Create cmd and para based on statement.
+        if ' ' in statement:
+            cmd, para = statement.split(' ', 1)  # one space
+            try:
+                para = float(para)  # make sure it's a number.
+            except:
+                para = 0
+        else:
+            cmd, para = statement, 0  # one space
+        #print(cmd, para) # for debugging
+        # Comment lines -- do nothing.
+        if cmd == "#":
+            pass
+            return
+        # RESET
+        if cmd == "reset":
+            self.turtle.reset()
+            return
+        # GO
+        if cmd == "go":
+            self.turtle.forward(para)
+            return
+        # LEFT
+        if cmd == "left":
+            self.turtle.turnLeft(para)
+            return
+        # RIGHT
+        if cmd == "right":
+            self.turtle.turnRight(para)
+            return
+        # PEN UP
+        if cmd == "up":
+            self.turtle.penUp()
+            return
+        # PEN UP
+        if cmd == "down":
+            self.turtle.penDown()
+            return
+</Code>
+The purpose of do() is to control the turtle. It creates the idea of an automatic turtle which works on the statements of a turtle program. This program could be added manually with .add() method calls or by loading a .t file as shown below:
+=== Loading a .t file
+This is the third part of Class TurtleProgram.
+<Code:Python>
+    def load_file(self, filename):
+        file = open(filename, "r")
+        program = file.readlines()
+        file.close()
+        # Clean up the file.
+        self.program = []
+        for line in program:
+            s = line.strip()
+            if len(s) > 0:
+                self.program.append(s)
+</Code>
+Originally I didn't have the code which cleaned up the program and it wouldn't work. After adding this quick syntax fixer the program worked.
+== Future Development
+=== 1. Refactor Turtle.py
+We encourage refactoring Turtle.py into two separate classes.
+Since we are dealing with a conceptual turtle, there is no reason no to force it into a separate class.
+Conceptually, TurtleWorld.py could be simply a surface in pygame. So it might not need full treatement in  TurtleWorld.py class, but to keep things simple during a phase 1 refactoring we will not merge it with Game.py in the same breath as splitting it into two distinct classes.
+On that note, it is easy to see a bit of a conflict in the idea of a GameWorld (in Game.py). TurtleWorld (in a theoretical TurtleWorld.py) is itself a discrete thing, which is not necessarily a game. So a good argument for leaving Game.py alone and making a TurtleWorld.py is that TurtleWorld is just data and Game.py is the projector of that world onto the screen. However in this theory Game.py would only contain calls to classes during it's lifecycle maintenance (checkEvents(), update(), render(), rinse and repeat.)
+=== 2. Editing
+We discourage in-suite editing and saving of .t files.
+There is no need to do that since they are just text files and text files are a well-established idiom on desktop PCs.
+=== 3. Expanding
+Expanding the commands of the turtle could be interesting.
+As a next-step project, depending on the student, we could add commands for color (and maybe alpha), then we could add commands for line width and maybe line patterns. We could also add commands for polygons, arcs, and circles.
+Beyond those basic drawing ideas the fun gets in when you add line numbers and GOTOs, and then flow control  like IF and so forth. Some fundamental questions to ask the student are, what changes (or what new commands) would we need to write in order to do something like the PONG game, but entirely in T (Turtle)? (Ex: A delay command, a "sheet" command, a switch-sheet command for animation, etc). What about reading the state of the pixel? Or a "goto (x,y)" command for the turtle? How interesting and complex can this become? There are many ideas and possibilities to explore!