The Craft of Computer Programming:Lifting the Veil

Donald H. HouseSchool of ComputingClemson UniversityClemson SC, USA

dhouse@cs.clemson.edu

Brian A. MalloySchool of ComputingClemson UniversityClemson SC, USA

malloy@cs.clemson.edu

Cory BuckleySchool of ComputingClemson UniversityClemson SC, USA

cbuckle@cs.clemson.edu

ABSTRACTWe present the conceptual design and first-phase implemen-tation of an approach to computer programming instruc-tion that has been designed to exploit the attractive force ofvideo games. We partition the skills that a professional pro-grammer must master into a sequence of eight levels, whereeach level introduces new programming tasks that are to beimplemented on a progressively more detailed machine ar-chitecture. Our approach is intended to foster a conceptualunderstanding of the internal representation of data, andthe underlying operations being performed on the data byan instruction sequence. To motivate the student program-mer, our approach is designed to be integrated into a videogame where, to progress through the levels of the game, theplayer must also progress through the levels of programmingtasks. After completing all levels the player of such a gamewould have a thorough mastery of fundamental program-ming skills, including array indexing, recursion and pointervariables, coupled with a solid understanding of the underly-ing computational model and the von Neuman architecture.

1. INTRODUCTIONWe are developing an approach to teaching computer pro-

gramming that leverages the attractive force of video gamesto motivate and facilitate acquisition of the skills and un-derstanding necessary for computer programming.

Computer programming is an exacting task that requiresthe programmer to master the rigorous syntax and seman-tics of a computer language, and to understand the under-lying architecture on which the program will execute. Inaddition, the fledgling programmer must begin to masterthe paradigms of programming, including the algorithms andstructured thinking required to formulate a programmaticsolution to a problem [1].

To address the difficulty in learning to program a com-puter, researchers and educators have developed a number ofspecialized programming languages and environments. Mostof these approaches, including Logo, Karel the Robot, Alice

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.FuturePlay 2010, May 6-7 2010 Vancouver, British Columbia, Canada.Copyright 2010 ACM X-XXXXX-XX-X/XX/XX ...$10.00.

and ToonTalk [2, 3, 4, 5, 6, 7, 8], create a programmingenvironment that removes the syntactic rigor and much ofthe semantic difficulty of learning to program; they buildan abstraction of a language and provide drag and drop op-erations, typically expressed as objects or icons, that makecomputer programming accessible to elementary students.These approaches substitute a virtual machine with higherlevel semantics for the von Neuman architecture of the realmachine. The strength of these approaches is that they makecomputer programming accessible to nonprofessionals, in-cluding elementary students. Their weakness is that the ma-chine abstraction hides the true architectural model, whicha professional programmer must comprehend and master.

We believe that a very different approach is needed fortraining students who will become professional program-mers. We are developing a conceptual design that fits pro-gramming instruction into a gaming environment where stu-dent programmers are guided through a progressively morecomplete instruction set and machine architecture until thefull complexity of the machine’s programming interface isexposed. During this process, the student must develop in-struction sequences that solve programming challenges thatbecome increasingly more complex. Thus, there are twocomponents in our approach: an architecture simulator anda video game. The focus of this paper is the architecture sim-ulator, including a full exposition of various levels of progres-sion in programming skill incorporated into the simulator.We provide some guidelines for the design of a video gamethat will seamlessly interface with the architecture simula-tor; however, a full description of an actual game remainsfuture work.

The architecture simulator features real-time animationsto illustrate the actions that are generated by the instructionsequence developed by the user. As the user program exe-cutes, the animation illustrates both control flow and themovement of data between input, memory, registers, andoutput. A key feature of this simulator is that is is designedto gradually “unveil” the underlying complexity of the fullmachine architecture as the student’s grasp of concepts de-velops. This is intended to foster a staged conceptual un-derstanding of the internal representation of data, and theunderlying operations being performed on the data by aninstruction sequence.

We have partitioned the programming skills that a fledglingprogrammer must develop into a sequence of eight levels,where each level introduces new programming tasks that fa-cilitate acquisition of new skills, as well as fostering an un-derstanding of the underlying computer architecture. Our

current implementation of the architecture simulator is in-tended as a proof of concept and includes only the first ofthese eight levels. In this paper we describe the conceptualdesign of all eight levels. The eight levels progress in com-plexity as more of the underlying architecture is exposed;this is analogous to the levels of a video game that increasein complexity as the player progresses through the game.

To motivate the development of programming skills, wewill incorporate the programming tasks into the context ofa video game. The game can assume any of the populargenres, but we envision a role-playing game where the playerassumes the role of a character that lives inside of a com-puter and must struggle against computer viruses, robotsand other enemies. To overcome the enemies, the playermust solve puzzles that are generated by the enemies, orthat populate the game as an artifact of enemy activity. Forexample, completion of a programming task involving oneregister might earn an additional register for the player touse in solving subsequent programming puzzles.

This progression through both the video game and thesimulator provides a mechanism of assurance that the playerhas mastered programming concepts at one level before ad-vancing to the next level. In this way, the cognitive demandon the player will be automatically adjusted to his or herlearning rate. More importantly, as players progress fur-ther in the levels of programming skills, they also develop adeeper understanding of the computational model inherentin the von Neuman architecture.

This approach accommodates various learning styles andcapacities and does not depend on a specific game to engen-der student interest. Rather, our modular approach permitsthe development of a variety of game shells that embed ourframework. There is no approach described in the litera-ture that exploits the attractiveness of video games in thisplug-and-play fashion. Finally, our approach is designed tonest identical curricular content frameworks within differ-ent game shells. This approach facilitates tailoring of gameplay to suit a target audience, while maintaining the samelearning content across games.

In the next section we describe previous approaches toprogramming instruction and compare them to our approach.In Section 3, we provide detailed description of our ap-proach, including an overview of the architecture simulatorand a summary of the eight levels of architecture, whichprogressively removes the veil over the underlying compu-tational model. In Section 4, we describe our architecturesimulator that tracks the essential actions of the computeras each instruction executes. Finally, in Section 5, we drawconclusions and describe our ongoing work.

2. PREVIOUS APPROACHES TO INSTRUC-TION ON COMPUTER PROGRAMMING

One of the oldest and most respected approaches to theinstruction of computer programming is Logo, a functionalprogramming language developed in 1967 by Wally Feurzeigand Seymour Papert at Bolt, Beranek and Newman (BBN)[2, 3]. One of the most important features of Logo was theturtle graphics that enabled children and novice program-mers to control a virtual turtle moving around an environ-ment using simple function calls that provide immediate vi-sual feedback about the results of the call sequences. Logosupports data structures such as lists, and control structures

for decisions and loops. Thus, while Logo’s simplicity andgraphics appeal to young users, its sophisticated program-ming constructs provide power for more advanced learning.

A key feature of Logo is the abstraction provided by thesimplified function calls, which remove much of the syntacticcomplexity of the programming language and the architec-ture from user consideration. This feature of Logo is basedon the assumption that actual language syntax and seman-tics place a heavy cognitive burden on the user, who is eithernot ready or incapable of understanding what is happening“under the hood” of the computer.

Karel the Robot, developed in 1981, is similar to Logo [4].The Karel language consists of only 5 basic instructions andthese instructions are used to move the robot, Karel, througha rectangular grid of streets and avenues. The programmeruses these instructions, together with control statements if,while and iterate, to control Karel.

The language Alice, developed at Carnegie Mellon Uni-versity [5], is similar to Logo and Karel in that Alice ab-stracts away the normal language syntax to enable the userto build 3D animations. However, Alice goes further by com-bining an integrated development environment (IDE) withdrag and drop icons to bring visual and 3D programming togroups that are not normally exposed to programming. Arecent version of Alice, Story Telling Alice, was developed topermit the user to create animations containing interactionsamong the characters [9].

ToonTalk is an interactive world that resembles a moderncity in which a carefully designed sequence of puzzles intro-duces the user to programming concepts and techniques [7,8] It consists of typical city objects such as houses, streets,cars, trucks, birds and boxes. Houses contain robots, whichperform most of the actions for solving problems in theToonTalk world. The robots can be trained to performsmall tasks by entering commands into the “thought bub-bles” above each robot’s head. The canonical programmingconcept exemplified in ToonTalk is swapping the values oftwo locations: the robot is instructed to grasp the contentsof one location, set it down, grasp the contents of the otherlocation and place it in the first location, and then to graspthe original item and move it to the second location.

3. LIFTING THE VEILIn this section, we describe our approach toward instruc-

tion in computer programming and provide details aboutthe sequence of eight levels of programming tasks that pro-gressively expose information about what actually happenswhen computer programs execute. Our goal is to incorpo-rate these programming tasks into a video game. Solutionsto the puzzles are intended to be used to permit the playerto make faster progress in the game, or provide incentives tothe player in the form of powerups, more powerful weaponryor additional information.

The intent of our design is that as the player progressesthrough the video game levels, he must also progress throughthe levels of programming puzzles. As the levels progressand the puzzles increase in complexity, additional languageconstructs and architectural features are added until, finally,the entire organization of a computer program is presentedas it is laid out by a typical compiler. As registers, mem-ory and instructions are added to the architectural modeland the programming assignments increase in complexity,the student programmer will make progress in mastering ar-

rays, recursion, and pointers in a sandbox environment thatprovides guidance in avoidance of many common program-ming errors.

3.1 Level I: Programming FundamentalsFigure 1 illustrates the initial architectural model, pre-

sented to the student at Level I. The student uses only fourregisters and five instructions; however, there are a myriad ofimportant program specifications that the nascent program-mer can master with this reduced instruction set, includingswapping two integers, reversing two integers and finding thelargest of an arbitrarily sized set of integers. At this level,the student is armed with five instructions, including input,output, assignment, if and while. However, these instructionsprovide a large enough arsenal to master the fundamentalconcepts involved in I/O, loops and decisions. In addition,at this level, our simulator uses animations to illustrate themanner in which data is moved from registers as the in-structions execute. The animations serve to clarify the realactivities that occur when instructions execute.

A DCB

Figure 1: Level I consists of only four registers.

3.2 Level II: Array IndexingAt Level II, we augment the four registers from Level I

with indexed memory, illustrated as E in Figure 2. Indexedmemory serves as an analogy to an array, which can presentdifficulties for the fledgling programmer. The presence ofthe array structure enables the introduction of the notionof run-time determination of the stored data set size. Thisallows us to introduce new program specifications: for ex-ample, reading a sequence of integers until an end sentinelis encountered, printing the sequence in reverse order, andsorting a sequence of integers.

A DCB

E

0 987654321

Figure 2: Level II adds an array.

3.3 Level III: Type SystemsAt Levels I and II, the student programmer developed

code that used only integer variables without the encum-brance and protection of type declarations. The design ofLevel III introduces the notions of variable naming and typesattached to variables, permitting the declaration of variablesof type int, float, and char. Figure 3 illustrates, on theleft, a sample program that might be developed at Level III,and the corresponding architectural view on the right. Inthe sample program, the user has declared two integer vari-ables, i and j, an array f of floats, and a character variablec. On the right side of the figure, the allocated memory cells

i 5

int

c ‘y’

char

f

0 321

2.371 210.00.060-3.012

float

int i, j;float f[4];char c;

i = 5;j = 3;f[0] = 2.371;f[1] = -3.012;f[2] = 0.060;f[3] = 210.0;c = ‘y’;

j 3

int

Figure 3: Level III introduces typed variables.

are illustrated with labels to the left of each cell, indicatingthe declared type of the variable. The value assigned to avariable is shown inside its cell. Consistent with the ho-mogeneous nature of arrays, the simulator assigns the sametype value to all array locations.

The introduction of type information also introduces agreat number of new problem specifications that can beposed to the student programmer. For example, problemsabout integer division, modular arithmetic, and characterstrings can now be introduced. Although the notion of inte-ger truncation can be difficult for student programmers, thearchitecture simulator provides visual feedback when solvingsuch problems as computing a remainder.

3.4 Level IV: Contiguous MemoryIn the design of Level IV, we introduce the important

concept of memory, that each variable declared in the userprogram is assigned both a type and an address, and theaddress of a variable corresponds to a location in memory.We also introduce the fact that memory is a contiguous se-quence of locations and that each location has an address.In this gentle unveiling of the von Neuman architecture, weassume that the contiguous sequence of memory locationsbegins at location 0, and that all variable types fit into onecell of memory.

Figure 4 illustrates two possible views of the mapping be-tween variable names and memory locations that can beshown to the user. For Figure 4a, a sample program isshown on the left, variables i, j, f and c are shown in themiddle, and the corresponding contiguous memory locationsare shown on the right. The important concept that we in-troduce here is that the values assigned to these variablesare not stored in the symbol, but rather the symbol indicateswhere the actual values are stored. For example, the value 1in the box for variable j corresponds to memory location 1,shown on the right side of the figure, where j’s actual valueof 3 is stored.

Figure 4b illustrates an alternate display of the same infor-mation where, rather than storing memory addresses in thevariable symbols, the simulator draws arrows to the memorylocations to visually indicate the mapping between variablesand memory locations. This illustrates a key feature of oursimulator design, which is to provide, whenever possible, al-ternate views of the underlying architecture, including per-mitting students to revert to previous architectural views.We do this to permit students to return to their comfort

13

12

11

10

9

8

7

6

5

4

3

2

1

0 5

2.371

210.0

0.060

-3.012

‘y’

i 0

int

c 6

char

f 2

float

j 1

int

3

int i, j;float f[4];char c;

i = 5;j = 3;f[0] = 2.371;f[1] = -3.012;f[2] = 0.060;f[3] = 210.0;c = ‘y’;

?

?

?

?

?

?

?

(a) References shown by indices

5

2.371

210.0

0.060

-3.012

‘y’

i

int

c

char

f

float

j

int

3

int i, j;float f[4];char c;

i = 5;j = 3;f[0] = 2.371;f[1] = -3.012;f[2] = 0.060;f[3] = 210.0;c = ‘y’;

?

?

?

?

?

?

?

3

2

1

0

(b) References shown visuallyFigure 4: Level IV exposes memory layout and references.

zone if, at any time, they become confused by a new repre-sentation.

3.5 Level V: Internal Representation of DataThe design of Level V shows the student that the actual

memory layout is in the form of individually addressablebytes, and that different variable types use different numbersof bytes. We also introduce the notions of binary numbersand hexadecimal representation. At this level, the studentprogrammer learns the stark difference between the internalrepresentations of the three data types that we introducedat Level III. Students can begin to see why a variable oftype float can be much larger but not as precise as an inte-ger, since the visual representation illustrates this difference.The student also begins to see that the internal representa-tion of character data takes only a single byte. Of course,the introduction of the internal representation of characterdata necessitates that we also introduce the concept of bytemanipulation, since character data does not require a fullcomputer word.

Figure 5 illustrates the extension of the architecture toinclude the internal representation of data and therefore hasthe same user program that used in our previous discussion.However, the figure now shows that the memory addressesfor the user declared variables are expressed in hexadecimal,and the right side of Figure 5 shows that the internal repre-sentation of data for each computer word is now partitionedinto four bytes, and the memory addresses of each computerword are now listed in hexadecimal. For example, the sym-bol information for variable j now shows that the value forj is located at memory address 4. Hopefully, the studentcan now see that the value for j[2] is stored at memory lo-cation C and that the internal representation of the data isC040C49C. Full comprehension of the internal representa-tion of floating point numbers requires further study; ourinterest here is that the programmer become familiar withthe notion that the internal representation of various datatypes is markedly different.

34

30

2C

28

24

20

1C

18

14

10

C

8

4

0 00 0000 05

40 BE17 77

79

3D C275 8F

C0 C440 9C

43 0052 00

00 0000 03

i 0

int

c 24

char

f 8

float

j 4

int

int i, j;float f[4];char c;

i = 5;j = 3;f[0] = 2.371;f[1] = -3.012;f[2] = 0.060;f[3] = 210.0;c = ‘y’;

?? ?? ??

?? ?? ?? ??

?? ?? ?? ??

?? ?? ?? ??

?? ?? ?? ??

?? ?? ?? ??

?? ?? ?? ??

?? ?? ?? ??

Figure 5: Level V. Byte structure and hexadecimal exposed

3.6 Level VI: Functions & Activation RecordsAt level VI, we introduce the important concept of pro-

gramming using functions. We represent a function invoca-tion as a tabbed rectangle, where each tabbed rectangle repre-sents an activation record. An activation record appears foreach function invocation and activation records are stored ona run-time stack called the control stack [10][p. 433]. Thecontents of activation records vary with the language beingimplemented; however, each record must store enough in-formation to fully represent each procedure invocation. Inour approach, we gradually expose more information aboutfunction activations.

Figure 6 illustrates our initial representation of functionsand their corresponding invocations and activation records.Figure 6a illustrates an abstraction of a control stack in theupper left, the corresponding user program in the lower left,

?? ???? ??

00 0000 03

00 0000 03

00 0000 02

00 0000 02

main

foo

m C

int

n

int

10

?? ???? ??

main::i

main::k

main::j

foo::m

foo::k

foo::nk

int

14

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

int main(){ int i, j, k; j = 3; k = 2; i = foo(j, k);}

int bar(int m){ int n; n = 2 * m; return n;}

int foo(int m, int n){ int k; k = bar(m) + n; return k;}

34

30

2C

28

24

20

1C

18

14

10

C

8

4

0

(a) Upon entrance to foo

?? ???? ??

00 0000 03

00 0000 03

00 0000 02

00 0000 02

main

foo

bar

m 18

int

n

int

1C

00 0000 03

00 0000 06

?? ???? ??

main::i

main::k

main::j

foo::m

foo::k

foo::n

bar::n

bar::m

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

?? ???? ??

int main(){ int i, j, k; j = 3; k = 2; i = foo(j, k);}

int bar(int m){ int n; n = 2 * m; return n;}

int foo(int m, int n){ int k; k = bar(m) + n; return k;}

34

30

2C

28

24

20

1C

18

14

10

C

8

4

0

(b) At the end of barFigure 6: Level VI introduces procedures and scope.

and an internal representation of the corresponding datavalues and memory locations on the right side of the fig-ure. The user program on the left side of Figure 6a containsthree functions: bar, foo, and main. Execution of the userprogram begins in main and the current state of the simu-lator indicates that the user has made a call to foo; thus,there are two records on the control stack: a record for mainat the bottom of the stack and a record for foo at the topof the stack. Also, the simulator tracks the current valueof the program counter and indicates its current value withan arrow pointing to the signature, the first line, of functionfoo.

The activation record for foo, shown in the upper leftcorner of Figure 6a, conveys important information aboutfunction invocation: all values for local variables and valueparameters must be stored locally, in the activation recordfor foo. Our representation of each record as a tabbed rect-angle illustrates the essential nature of a stack: the onlyrecord that is available is the record on top of the stack.

Our memory layout at Level VI is illustrated on the rightside of Figure 6a, where we use the notation main::i to des-ignate the location corresponding to the variable i in main.Our use of the C++ scope operator is intentional and willfacilitate the transition to object-oriented programming. Animportant consideration here is that the value, currentlystored at location 0, main::i, is undefined since the activa-tion record for function foo is still active and a value has notbeen returned yet for variable main::i.

Figure 6b further illustrates the actions of the controlstack, with an activation record for function bar at the topof the stack. The arrow in the figure indicates that execu-tion has reached the end of bar and that a value has alreadybeen placed in memory location 1C, on the right of Figure6b. Our architectural simulator is illustrating to the stu-dent programmer the technique used to return values fromfunction invocations. As execution continues, the activationrecord for bar will be popped from the stack, a value for kwill be computed for function foo, and eventually, a valuewill be returned for main::i, and that value will be enteredinto memory location 0. This treatment of the control stackmirrors the manner in which function activations are han-

dled in the actual compiler implementation for functions.

00 0000 05

00 0000 01

00 0000 03

?? ???? ??

00 0000 1A

00 0000 03

00 0000 10

main::i

main::k

main::j

foo::m

foo::k

foo::n

?? ???? ??

?? ???? ??

00 0000 0B

?? ???? ??

?? ???? ??

GLOBALS

g 0

int

mainfoo

m 14

int

n

int

18 foo::f

g

00 0000 0D

00 0000 03

f 4

int

k

int

1C

int main(){ int i, j, k; j = 3; k = 2; g = 5; i = foo(j, k);}

int g;

int bar(int m){ int n; n = 2 * m + g; return n;}

int foo(int m, int &n){ static int f = 0; int k; k = bar(m) + n + f; n = 2 * k; f = f + 1; return k;}

34

30

2C

28

24

20

1C

18

14

10

C

8

4

0

Figure 7: Level VII introduces global and static variables.

3.7 Level VII: Global & Static VariablesLevel VII introduces global and static variables. There

is a tabbed rectangle shown in the upper left of Figure 7,which is an abstraction for global name space, where globalvariable g is represented. The control stack for the userprogram is shown to the right of the rectangle for globalmemory and the user program is shown under the tabbedrectangles in the lower left of the figure.

The tabbed rectangle for global variables illustrates thatstorage for g is at memory location 0. The record on thetop of the control stack is for function foo and the programcounter, shown as the arrow at the end of foo, illustrates thatcontrol has reached the end of the function. The record forfoo indicates the addresses where value parameters m and nare stored, the address where local variable k is stored, andthat static variable f is stored at memory location 4.

The important consideration at Level VII is that the staticvariable is stored with global variable g because subsequentinvocations of foo will use this same storage and f will re-tain its values across invocations to foo. However, storagefor parameters and local variables of foo are stored afterthe variables for function main. Thus, our simulator illus-trates the dynamic nature of function invocation and thecorresponding local and value parameters, whereas storagefor static variables is similar to storage for global variables,but the scope of static variables in functions is local to thefunction.

3.8 Level VIII: Pointer VariablesAt Level VIII, our design is to present the full memory

model as it might be laid out by a typical compiler, in-cluding the introduction of dynamically allocated memory,pointer variables and reference parameters. Figure 8a showsa typical user program for this level and Figure 8b showsthe corresponding memory model. The user program con-tains five functions: swap, readnums, writenums, sortnumsand main. Function swap illustrates reference parameters n1and n2 and the arrow at swap shows that execution is cur-rently in this function; the user code for swap illustrates thetraditional 3-step swap. We use the C++ notation, &, to in-dicate reference parameter transmission. Function readnumshas two parameters and the first parameter is a dynamicallyallocated array, table, which provides storage for the num-bers to be sorted. table is also a parameter to writenums andsortnums.

Figure 8b illustrates the memory model for the user pro-gram in Figure 8a, where a control stack is shown in theupper left, with function swap at the top of the stack. Arecord for global variables global1 and global2 is shown be-neath the control stack, and the current state of memory isshown on the right of the figure. Our memory model illus-trates storage for both the heap and the control stack andthese data structures grow toward each other. Storage forthe two global variables is shown in the lower right of thefigure. The heap, shown at the top of the memory model,shows that storage has been allocated for eight integers. Thecontrol stack of the memory model now has the activationrecords for the three functions on the control stack: main,sortnums and swap.

As the student programmer progresses through our eightlevels, more of the underlying architectural model is un-veiled, until finally, at Level VIII, the full model is exposed.Comprehension of this model should equip the student to beable to write code for virtually all program specifications.

4. THE ARCHITECTURE SIMULATOROur work is currently at the level of a conceptual design;

however, as a proof of concept we have implemented andexperimented with Level I of the architecture simulator. Oursimulator is written in Python and we use the Pygame APIfor our event-driven simulations [11, 12, 13]. Pygame is isa cross-platform set of Python modules, designed for videogame construction. Pygame includes computer graphics andsound libraries designed to be used with Python.

Figure 9 illustrates a scenario where the player is askedto solve the problem of finding the largest of three numbersthat are input from the keyboard. A yellow status bar isshown in the upper left corner of the figure and four registersare shown in the upper right corner. The selection of five

instructions is shown below the yellow status bar, includinginput, output, assignment, if and while.

The user code developed by the player is shown in thelower left of Figure 9a. This user code illustrates a typicalstudent solution to the problem of finding the largest of threeintegers. The large purple window to the right of the usercode is the output window, where output from the user codeis placed. To permit the user to step through instructionexecution, a slider bar is shown in the lower right corner ofthe figure. This slider bar permits the user to view programexecution either one statement at a time, Step, or to controlinstruction execution at speeds of slow, medium and fast.There are also two buttons on the lower right that permitthe user to clear the code winder, Clear Code, or to clear theoutput window, Clear Output.

Finally, the upper middle section of Figure 9a shows wiresconnecting the registers to the user code window and to theoutput window. As the simulator executes the instructions,sparks flow along the wires. The sparks metaphorically il-lustrate the transmission of data from the registers to theoutput window; this transmission is informed by executionof an instruction and the currently executing instruction isindicated by the arrow on the left side of the user code win-dow.

After the player completes a proposed solution to a pro-gramming puzzle, the simulated execution of the code canbe used either to verify that the solution is correct, or to fa-cilitate the debugging process. Typically, the simulated ex-ecution of an incorrect solution will provide feedback aboutwhere the fault lies. After successfully solving a puzzle, orafter failing to solve a puzzle, the player may request thata sample solution be presented in the user code window.The student solution illustrated in Figure 9a uses three ifstatements and four comparisons to find the largest of threenumbers. However, this solution is error prone and does noteasily scale to more than three numbers. Figure 9b illus-trates a better solution to the problem of finding the largestof three numbers. This solution scales to more than threenumbers and is less error prone than the student solution.

5. CONCLUDING REMARKSWe have described the design and preliminary implemen-

tation of our approach to computer programming instructionusing a gaming environment. Unlike previous approachesthat build an abstraction of the architecture to hide detailsand make programming accessible to non-professionals, ourapproach progressively exposes the details of the underly-ing computational model. Our target audience is the stu-dent who is interested in becoming a professional program-mer and therefore needs to master the underlying computa-tional model. Through a succession of eight levels, we intro-duce features of the architecture and corresponding memorymodel until the full model is exposed, including arrays, re-cursion and pointer variables. We have described a proto-type implementation of Level I of our architecture simulatorand we have illustrated its use in solving programming chal-lenges.

At the end of a game, our hypothesis is that the studentprogrammer will have acquired full comprehension of thecomputational model that forms the cornerstone of profes-sional computer programming. We are currently workingon the design and implementation of a video game to beused with the architecture simulator and our future work

int main(){ int n; int *table;

input(n); table = new int[n];

readnums(table, n); sortnums(table, n); writenums(table, n);}

void sortnums(int *table, int n){ int low; int i;

low = 0; while(low < n - 1){ i = low + 1; while(i < n){ if(table[i] < table[low]) swap(table[i], table[low]); i = i + 1; } low = low + 1; } }

void readnums(int *table, int n){ int i;

i = 0; while(i < n){ input(table[i]); i = i + 1; } }

void writenums(int *table, int n){ int i;

i = 0; while(i < n){ output(table[i]); i = i + 1; } }

int swap(int &n1, int &n2){ int temp;

temp = n1; n1 = n2; n2 = temp;}

int global1, global2;

(a) user program

100010041008100C101010141018101C102010241028102C103010341038103C104010441048104C105010541058105C106010641068106C107010741078107C1080

GlobalsControl Stack

Dynamic Heap

main

sortnums

swap

00 00 00 0A00 00 09 1200 00 00 0300 00 0A C200 00 00 4100 00 12 0200 00 01 AB00 00 00 2D

00 00 10 0000 00 00 08

?? ?? ?? ??

00 00 10 00

00 00 00 0000 00 00 08

00 00 00 01

00 00 10 0000 00 10 01?? ?? ?? ??

?? ?? ?? ??

GLOBALS

global1 1080

int

global2 107C

int

mainsortnumsswap

n1 1058int

temp 1060int

n2 105Cint

01234567

(b) memory modelFigure 8: Level VIII introduces dynamic memory allocation.

includes the development of techniques for utilizing the ar-chitecture simulator in higher education instruction in com-puter programming. The instructional method for using thearchitecture simulator will be developed using a formativeexperiment [14]. Following the design of an instructionalmethod, we will test the confirmed model to determine ifthe approach compares well with traditional computer pro-gramming instruction. The comparison studies will involvea traditional experimental model using a control group or acounter balanced design [15] to determine the effectiveness ofusing the architecture simulator when compared with tradi-tional programming instruction. These formative and tradi-tional experiments will investigate two dependent variables:comprehension of the computational model and engagementin the programming activities when using video games intandem with the architecture simulator. we believe that ourapproach will be especially attractive to the millennial stu-dent [16].

6. REFERENCES[1] R. W. Floyd, “The paradigms of programming,”

Commun. ACM, vol. 22, no. 8, pp. 455–460, 1979.

[2] T. L. Foundation, “What is logo?” Website, April2009, http://el.media.mit.edu/Logo-foundation/logo/index.html.

[3] S. Papert, Mindstorms: Children, computers, andpowerful ideas. Basic Books, January 1981.

[4] R. E. Pattis, Karel The Robot: A Gentle Introductionto the Art of Programming. John Wiley & Sons, 1981.

[5] W. P. Dann, S. Cooper, and R. Pausch, Learning toProgram with Alice, Brief Edition. Upper SaddleRiver, NJ, USA: Prentice-Hall, Inc., 2006.

[6] CMU, “Carnegie mellon collaborates with ea,”Website, March 2006,http://www.alice.org/simsannounce.html.

[7] K. Kahn, “A computer game to teach programming,”

in In Proceedings of the National EducationalComputing Conference. University Press, 1999, pp.127–135.

[8] ——, “Toontalk – steps towards ideal computer-basedlearning environments,” in A Learning Zone of One’sOwn: Sharing Representations and Flow inCollaborative Learning Environments, M. Tokoro andL. Steels, Eds. IOS Press, 2004, pp. 253–270.[Online]. Available:http://toontalk.com/English/ideal learning abs.htm

[9] C. Kelleher, R. Pausch, and S. Kiesler, “Storytellingalice motivates middle school girls to learn computerprogramming,” in Proceedings of SIGCHI. New York,NY, USA: ACM, 2007, pp. 1455–1464. [Online].Available: http://dx.doi.org/10.1145/1240624.1240844

[10] A. V. Aho, R. Sethi, and J. D. Ullman, Compilers:principles, techniques, and tools. Boston, MA, USA:Addison-Wesley Longman Publishing Co., Inc., 1986.

[11] G. van Rossum, Python Library Reference. PythonSoftware Foundation, 2001.

[12] P. Shinners, “Pygame,” 2010, [Online; accessed11-March-2010]. [Online]. Available:http://www.pygame.org/news.html

[13] Wikipedia, “Pygame – Wikipedia, the freeencyclopedia,” 2010, [Online; accessed 11-March-2010].[Online]. Available:http://en.wikipedia.org/wiki/Pygame

[14] D. Reinking and B. A. Bradley, On Formative andDesign Experiments: Approaches to Language andLiteracy Research, 2008.

[15] W. Trochim, The Research Methods Knowledge Base,2nd ed. Atomic Dog, 2001.

[16] itnews, “Employers: Look to gaming to motivatestaff,” April 2010. [Online]. Available:http://www.itnews.com.au/News/169862,employers-look-to-gaming-to-motivate-staff.aspx

(a) Finding the largest: Brute Force

(b) Finding the largest: Advanced ApproachFigure 9: The Architecture Simulator for Level I