Upon the recommendation of my supervisor Dr. Jonathan Lessard, I recently read a book chapter by Schön titled “The Crisis of Professional Knowledge and the Pursuit of an Epistemology of Practice” (2001). Schön explains that in our everyday activities and profession, we enacted a tacit form of knowing that doesn’t lie on prior intellectual operations, but rather on actional, performative, and pragmatic ones. This “knowing-in-action” (2001: 9) occurs spontaneously and intuitively in our patterns of recognition, judgments, sensations, and know-how. Playing a sport, dancing, musical improvisation, noticing a familiar face in a crowd, or the skillful use of tools all imply the enactment of implicit procedural knowledge. When such activities encounter any bugs, blockages, surprises or deviations from the ideal scenario, the performer engage in an on-the-spot “reflection-in-action” (2001: 11) which Schön defines as a process that has

an inner logic according to which reflection on the unexpected consequences of one action influences the design of the next one. […] In the course of such a process, the performer "reflects," not only in the sense of thinking about the action he has undertaken and the result he has achieved, but in the more precise sense of turning his thought back on the knowing-in-action implicit in his action. He reflects "in action" in the sense that his thinking occurs within the boundaries of what I call an action-present — a stretch of time within which it is still possible to make a difference to the outcomes of action (2001: 11-12).

One major point in Schön’s argument is about our inefficiency to describe and be knowledgeable about this process of “reflection-in-action.” Therefore, the author insists on the necessity of a “reflection on reflection-in-action” (2001: 15). This means to reflect rigorously on how, during the immediacy of a practical situation, we had reflected on a specific obstacle and course of action in order to adapt our performance and overcome the problem at hand. According to Schön, this level of bottom-up and messy human self-reflexivity can open up the epistemology of professional practice to new forms of knowledge that are inaccessible to the dominant top-down and positivist paradigm which focuses on the application of research-based knowledge and technical rationality (2011: 4). With this new lens, we can discover how professionals go on their practice not by simply applying rigid theoretical and applicable knowledge, but by reflecting-in-action in the midst of a puzzling situation. By adopting a reflexive stance on our procedural knowledge and its ability to become aware of itself for improvement purposes, we can shed light on the ways in which certain practitioners reflect on the limits of their knowing-in-action processes and how they spontaneously manage to criticize and restructure their pragmatic knowledge in the face of unanticipated challenges. In doing so, we can study the nature of unspoken skills such as:

- solving problems on-the-spot or reframing problem-setting

- tinkering situation-specific tests, simulations and experiments

- rethinking approaches and methods along the way

- becoming aware of and questioning implicit knowledge and belief system

- mobilization of intuition, judgments, and preferential system

- discovering unanticipated meanings

- developing alternative strategies and contextual micro-theories against the grain of grand theory

- learning to adapt to messy real-world situations

- internalizing, mimicking, and challenging canonical skill sets

As a game design research-creation project, Bug Hunter is directly in line with Schön's argument about the necessity of a reflection on reflection-in-action. As explained in my Manifesto, my goal is to document the whole design process of Bug Hunter to gather data about my experience as a young and ingenuous game designer. This methodology demands that I keep a design journal where I reflect on my learning curve, my decision-making process, my knowing-in-action activities, my intuitive course of (re)action, and the like. To play with Schön beautiful formulation (2001: 13), this is about recording and commenting on my conversation with the materials of the design situation I’m engaged in. One major part of this conversation concerns the bugs I encounter in my day-to-day research-creation activities, both in the sense of practical mistakes or blockages and software or design disturbances. This blog post is dedicated to the exploration of the recent bugging area I'm struggling with: C# programming in Unity. It offers a retelling of my coding journey of the last months.

1) Initial Steps into Object-Oriented Programming:

When I decided that I needed to develop programming knowledge and skills before doing anything else, I conducted preliminary research on the web about “how to learn programming.” Some say start by reading code.  Advisers online proposed to do the basic C# tutorial before anything else. Some colleagues suggested starting with Python to learn the basics. Listening to my colleagues, I booted up Python and PyCharm and start with two YouTube tutorials: “Python Tutorial - Python for Beginners [Full Course]” (Programming with Mosh, 2019) and “Python Tutorial for Absolute Beginners #1 - What Are Variables?” (CS Dojo, 2017). This first contact with programming was harsh. I felt quickly overwhelmed with new notions and I was unable to do any exercises by myself. I was printing messages in the console, doing basic arithmetic operations, interpolating variables in strings, looping through list of numbers and names, and using functions like the “upper()”, “lower()”, and “replace()” to operate different kinds of operations on the characters of a string. At that stage, I couldn’t see the link between what I was learning and what I wanted to do with Bug Hunter. More importantly, I felt disconnected from the video game medium because my code didn’t lead to any visual elements, objects in movement, interface elements, interactions, etc. Not being a game environment turned me off. Quickly, I lost interest in Python because it felt more aligned with web and app design.

In the hope of getting closer to Unity and its programming language, I turned toward C#. First, I followed the free online video series “C# 101” (Hanselman & Havens, 2019) combined with ad lib reading on the web about object-oriented programming (OOP) and its key concepts. Again, I was struck by conceptual confusion, incomprehension of syntax logic, and a feeling of nonsense in front of recurring symbols and colorful keywords. What is the meanings of “+=,” “++,” “&&,” “!=,” “==,” etc.?  What signifies words like “using,” “return,” “void,” “var,” “static,” “enum,” “get,” “set,” etc.? Why is the code vertically ordered like that (namespace at the top, variable declaration right after, and then methods at the end)?

While I was following instructions, I managed to print strings in the console, do basic mathematical equations, code some simple conditional statements, loop through items in a collection, create comments in the coding using “//,” etc. The problem is that I had no solid theoretical understanding of what I was doing and I didn’t know how it might become useful for my game creation project. I was trying to learn how to code without any clue about any game-specific programming needs in terms of objects, components, common functions, design patterns, etc. I known I wanted to create a game in Unity using C#, but I didn’t grasp how to get there and I had no idea of what I needed to learn and why. Without any sense of direction, no wonder why I threw myself in all these directions (at some point I even tried learning how to code in JavaScript using Atom and p5 library).

Upon reading these lines, you might think that these initial steps were a complete waste of time (as I thought so myself). In retrospect, it wasn’t. Although this first exploration was uninformed and disoriented, it initiated me to core vocabulary, it allowed me to envision the proportion of the challenges ahead, it introduced me to the idea of an integrated development environment, it highlighted the need for grammatical rigor, it pinpointed the importance of reading documentation, and the like. It settled the table for what was to come, a pretty rough table but still.

2) Going Under the Hood: Unity Engine

Faced with discouragement, I decided to dialogue with my coding problem from a different angle. I reframed my problem-setting and started studying the Unity game engine instead. My idea was to apprehend the means of production in the hope of discerning my programming needs along the way. My first move was to get my hand on a “Unity for dummies” kind of book. My research led me to Unity for Absolute Beginners written by Blackman (2014). Guided by this new resource, I downloaded and installed Unity and launched the thing. That was a blast! Finally, I was learning and manipulating stuff that was directly related to game creation. The book also came with a demo scene named AngryBots offering a full fledged level to be explored and toyed with. That was a crucial moment where I internalized the Unity technical environment and integrated a plethora of new essential skills: learning the different subsections; navigating the 3D scene; reconfiguring the layout of the editor; moving the virtual camera; adjusting lighting; repositioning, rotating, and rescaling objects; discovering the various components available; studying parent-child inheritance; activating and deactivating chunks of the environment; getting to know how things are actually named; establishing the connection between objects in the hierarchy, their place in the scene and their components in the Inspector.

As I progressed in the book, I had to do a lot of research on Google to read definitions of basic things like mesh, vertices, prefab, collider, lightmap, animator, materials, shaders, etc. I had no clue (or at least a vague idea) of what those words were referring to. Gradually, I was making sense of the lingo and other keywords I had come across during my initial steps in the coding world. It was now possible to frame some coding requirements in game development terms. Needless to say, this was a major shift in mindset. Now, I was learning while having a tone of fun and my curiosity was highly stimulated. I could finally foresaw how my new knowledge and know-how can be applied to my own project. I was paddling in the right direction. Then came chapter 5 “Introduction to Scripting with C#.” That was the beginning of something else entirely.

3) Scripting the surface

Blackman opens chapter 5 by presenting an old MonoDevelop script editor. As I remembered from my Python/PyCharm short experience, I looked for a newer development environment for Unity scripting and Windows. It led me to Microsoft Visual Studio Community. I installed the software and specified that it was for game development with Unity. The package comes with an incredibly useful feature called Visual Studio Tools for Unity. Among other things, this free extension comes with my life savior and AI coding guide: IntelliSense. As you may know, IntelliSense is a code-completion tool that dialogues with Unity API to relay messages from Unity documentation. It does deductions of what you are trying to do based on analysis of your code and offers the best possible coding suggestions. On top of that, it highlights many typographic errors such as lack of parentheses, missing namespace, missing semicolons, unused method, and spelling mistakes between variables. It automates complex syntax and shows essential definitions, descriptions and ready-made templates for common code objects. Not only does it save me some time, but it became a learning tool in itself through which I study C# syntax, punctuation, object meaning, argument configuration, etc. That being said, at this point of my coding journey, I wasn’t able to fully comprehend what IntelliSense was telling me because the lingo still remains too cryptic.

Through this fifth chapter, I revisited all core Unity-related C# concepts like variable types (numbers, string, Boolean, GameObject, etc.), exposing variable in the Inspector, reading error in the console, commenting on the code, implementing condition statements, using important operators, and major game-related methods (Start, Update, Find OnCollisionEnter/Exit, SendMessage, etc.). Because all the programming was done inside the Unity environment, everything made a lot of more sense to me. I wasn’t simply coding out of thin air in PyCharm, in a web browser or in Atome to see results in a virtual server. I was myself creating new scripts in the project panel of the game engine. I named it according to conventions. I edited the content in Visual Studio and assigned it to my game objects. Moreover, I was able to immediately see the effect of my code inside the 3D scene, the console, and the Inspector. I could see in real time the type of variables I created, the values I determined, and components I was referencing and modifying.

For example, I remember the first time I managed to move a game object through code. It may seem trivial, but it felt like a huge improvement. Figure 1 shows a simple script applied to a bench. It makes the object rotate until it reaches 270 degrees in the Y axis. At this point, the bench is told to move forward on the Z axis.

The GIF in figure 2 exposes the script in action. You can also notice the door opening when the bench reaches a certain threshold. Another script manages the door opening and closing animations by the means of an OnTriggerEnter() and OnTriggerExit() methods that check if the object entering the door’s box collider is tagged as “the bench.”

                                                                                                      Figure 2: A bench being moved though code

Here was a game changer: to immediately see the effect of my code in the game engine and in the game at run time. Being able to observe and analyze the materialization of abstract code helped me understand what I was coding. It clarified the connection between the textual objects of the code and the actual parameters and components that were operated on. I finally understood the line of communication and interaction between the programming realm and its pragmatic implication for game making. For a young creator at the beginning of its learning curve, that was a big deal with a significant motivational impact.

Another game changer was the accessibility of unity standard assets and built-in components. I recall the pleasure of experimenting with primitive objects and various “Physic Materials” (like friction and bounce effects) to learn how Unity handles physics. I also enjoyed toying with the built-in prefab “FPSController” which is a capsule-shape “Character Controller” component paired with a rigidbody, a “First Person Controller” script, and a camera as children. This “out-of-the-box” dummy character allowed me to test my code and start to learn notions in an embodied real game situation without having to program the complexities of first-person character movements. This hugely stimulated my fascination, my curiosity, and my desire to experiment with physics through coding.

Because the book was published in 2014, the nomenclature of some coding elements had changed a little bit with more recent Unity versions. Consequently, I had to figure out by myself how to correct obsolete lines of code contained in the book. For instance, when Blackman explains how to code the playback of an audio clip, she writes: “audio.Play().” For some unknown technical reason, it wasn’t working for me. I had the same blockage when I tried to play an animation with the proposed line “animation.Play().” After doing some research online, I discovered that these expressions were deprecated. It was explained that “audio.Play()” had to be replaced with “GetComponent<AudioSource>().Play()” and that “animation.Play()” is now written: “GetComponent<Animation>().Play().” At the time, it frustrated me to struggle my way around such discrepancies. However, I learned invaluable skills: how to formulate good programming questions in Google, how to search and navigate the Unity documentation, and how to use forums like Unity Answer and Unity forums. Without even knowing it, bugs were allowing me to become more and more resourceful.

At some point, I hit the code barrier. Because programming isn’t the main focus of the book, all notions are presented in a “short-and-sweet” overly general manner. No theoretical background. No in-depth explanations of how things work. The vocabulary is simplified in such a way that the author uses the word "function" over the proper term "method." To give another example, when Blackman addresses the accessibility of variables in the Inspector or via other scripts, she never speaks of “access modifiers” but rather of “exposing variables” by declaring them as public or internal. I had the feeling that important stuff was thrown at me from all directions without the necessary basis. I was able to manage my way around because the book tells you exactly what to code. But in reality, I didn’t understand everything I was coding. Still, I decided to go along with it despite the fact that I was prematurely launched into versatile usage.

Arriving at chapter 8 on weaponry and special effects, I learned to set up a Potato Launcher to shoot explosive potatoes at small bunnies. On collision enter, the shot bunny had to be destroyed and replaced with a “deadReplacement” bunny prefab followed by a shrinking animation and another destroy method. The code proposed in the book looks exactly like figure 3.

For a reason I didn’t understand at the time, I kept receiving an error message that I was unable to decode. My limited knowledge of programming didn’t allow me to solve the problem by myself. My learning curve had plateaued and my progression in the book was severely blocked. Although it was irritating to experience such limitations, it pushed me to polish another essential skill: how to use Unity Answer properly. Determined to find a solution, I created an account, got acquainted with the Markdown Syntax, and asked my question to the community in great details and with the right vocabulary. One day later, a user came to my rescue. I’ve been taught that the error message was indicating that the “deadReplacement” parent I was trying to assign to my local variable “deadParent” on line 58 didn’t exist in the current context. To validate this information, my savior helped me set up a useful debugging conditional statement to check if my deadReplacement missed an object or missed a parent (Fig. 4).

With this new debug technique in my coding arsenal, I confirmed the absence of a parent object from which to instantiate my dead bunny. Having spotted the culprit, a simple correction solved my problem and everything was now working like magic (Fig. 5). I was back on track.

This small coding adventure marked by a highly frustrating aporia filled with trial and error, guess work and feeling of powerlessness, ultimately ends with an epiphany. That short-lived moment of joy came with a strong realization: I could not keep coding without a more robust understanding of OOP theoretical basis. As a scholar craving for in-depth comprehension and well-formed know-how, I had enough of shallow coding based on rough imitation. I decided to take my coding journey to the next level.

4) A Sharp Dive into C#

Getting my hand on a book solely dedicated to C# programming was the next logical step. A research on the topic led me to Learning C# by Developing Games with Unity 2019 Fourth Edition (Ferrone, 2019) whose proposition is to teach advanced C# programming through the creation of a basic game inside the Unity environment. That was perfect. I could simultaneously deepen my understanding of both coding and game development in the technical environment in which I was having fun.

Because I had an idea of the complexities of C# from my initial steps into OOP programming, I approached the book more methodically. I arranged a working environment that became the virtual lab where I studied and experimented with C# in the last month. Using the new technical skills I’ve learned from Blackman’s book, I started a new project, set up a basic scene with various primitive objects, and generated a unique script for each of the main programming concepts presented by Ferrone. Each of these scripts contains code that exemplifies the concept. I included extensive comments that define the words being used, describe how the code works, and explain how specific blocks of code interact with each other from different scripts. On the side, I had organized a complex Word notepad modeled on the book structure alongside countless web browser tabs open on Unity Documentation, Unity Answer, Microsoft C# documentation, and numerous YouTube tutorials. Figure 6 illustrates how this virtual lab looks on my dual monitor setup.

This Unity theoretical project becomes something in-between an embodied note document and a workspace where C# theory and practice were learned in action. This was a significant breakthrough. The book’s specialized and educational level of discourse offered me an in-depth revision of all the notions I had previously encountered superficially and consequently never fully understood. It clarified and answered crucial questions I had about the conceptual, technical, and practical aspects of the C# fundamentals. By digging much deeper into scripting, Ferrone helped me wrap my head around floating abstractions that I had difficulty anchoring in an actual game context.

As a comparison, we can look at how Blackman and Ferrone present the concept of class. In Blackman words: “A class is a kind of blueprint or template that allows you to define parameters and functionality in a generic way” (2014: 198). Then, the author goes on and introduces the notion of variable: “Variables are the means of storing information that is used and often changed throughout your game. […] These are parameters that help you store important values, help you keep track of states, and allow for the customization of the gameObject the script is applied to” (2014: 200). On his part, Ferrone explains things in a different order and uses real world metaphors to help you make sense of abstract notions. First, he defines a variable on a technical level:

a tiny section of your computer's memory that holds an assigned value. Every variable keeps track of where its information is stored (this is called a memory address), its value, and its type (for instance, numbers, words, or lists) (2019: 70).

Expanding on that definition, he puts forward a practical conceptualization of variables as a container or a placeholder that can be created at will, filled with different content (or left empty), moved around, and referenced when needed. The mailbox metaphor is presented to crystallize this understanding. Like a variable, a mailbox is an identifiable container that can hold anything from personal letters, bills, pictures, an object in a package, etc. The use of metaphors as a teaching device played an important cognitive role for me. It allows me to map abstract concepts onto a knowledgeable domain of experience. I was then able to mentally frame the meaning and functions of a variable in a more grounded manner.

After having defined a variable (the same is done for the notion of method), the author introduces the concept of class. Class is described as a “super container,” a “data structure,” and a “blueprint” that contains “variables, methods, and other programmatic information, all of which can be referenced when an object of the class is created.” (2019: 81). Ferrone invokes the post office metaphor to further this explanation. Similar to a class, a post office is an autonomous environment that has a physical address (a variable) and the capacity to perform functions (methods) like receiving and delivering mail. He adds the idea of inter-class communication specifying that information and behaviors from a certain class can be verified and used in another class. The post office address or delivery function could be utilized elsewhere by referencing the name of the post office class followed by a dot notation (.) and the desired variable or method. We would then have something like:

PostOffice.Address

PostOffice.DeliverMail()

From Blackman to Ferrone, I consolidated a more profound and holistic understanding of C#. For starters, I learn the right theoretical vocabulary. For example, before reading Ferrone, I had difficulty distinguishing between parameters and arguments when declaring and calling a method. I had similar uncertainties between class and struct, variable and local variable, and specific access modifiers, keywords, and operators. With these confusions out of the way and a clearer comprehension of the lingo, my code-reading skills greatly improved. It became much easier to grasp how different blocks of code function and interact together from within and without a class. In parallel, it gave me the right knowledge to decode efficiently IntelliSense's color code and precious mouseover descriptions. Furthermore, I refined my C#-oriented “question-formation” skill. When confronted with a coding blockage, I was now equipped to formulate much more precise queries in search engines and solve my problems.

Secondly, Ferrone’s book rigorously exposes naming conventions and dissects the formal syntax of all basic C# programming objects: from variable to method, selection statements (if-else) to collections (arrays, lists, dictionaries), all the way down to iteration statements (for, foreach, and while loops), class, struct, and enumeration. Otherwise, with a precise demonstration of how to use the dot operator in the post office example, I had finally unravelled that in order to refer or call any variables, methods, or components of a given class, you have to dig down into things, from the more global object to the more local. Before that, I thought that anything could be utilized simply by using the right spelling, like by writing “DeliverMail()” instead of “PostOffice.DeliverMail().” All the notes I have taken about the syntax formalities of those C# objects have consolidated a sort of theoretical bible to which I return regularly.

Thirdly, I could finally put words on OOP principles and logic that I was experiencing without knowing it, such as encapsulation, inheritance, composition, and polymorphism. This refined knowledge helped me conceptualize my practice while also laying the ground for more advanced stuff. For instance, I discovered that encapsulation (how an object's variables and methods are accessible from other classes) extend beyond the 4 common access modifiers (public, private, internal, and protected). When declaring variables, it is possible to secure the values with keywords such as “const” and “readonly” or by using the "get" and "set" accessors. Studying polymorphism, I learned that a child class instantiated from a parent blueprint also has the freedom to modify the parent’s methods to suit its needs, meaning you can override existing methods with virtual ones. Although I don’t fully foresee the practical implications of these more advanced notions at the moment, this knowledge paves the way for more intermediate programming territories explored at the end of the book, such as interfaces, class extensions, generic programming, delegates, events, and defensive programming.

When I finished Ferrone’s book, I returned to Blackman and picked up where I left off. Armed with my new theoretical knowledge and know-how, I was equipped to make sense of the author coding process. From now on, I wasn’t simply copying the code characters by characters. I was constructing and reading the code with clairvoyance and I was fully interiorizing its logic. More so, I was able to correct some compiling errors by myself. For instance, I was getting ahead of Blackman’s explanations by changing the access modifier of some variables from private to internal in order to be able to refer to them in other classes. I was also capable of correcting various obsolete coding formulations autonomously. One of these cases concerns the use of “Application.LoadLevel()” to load a new scene. Relying solely on IntelliSense and my personal knowledge, I saw the need to declare the missing namespace “UnityEngine.SceneManagement” at the top of my script. From there, I replaced the deprecated method with the new one called “SceneManager.LoadScene().”

I could see similar improvements when I was implementing HUD and GUI elements. At some point, Blackman declares a GameObject variable to store a “GUI text” object whose role is to keep track of the remaining number of bunnies left to kill in the garden arena. To do so, she uses the line: “public GameObject bunnyCounter.” From there, she calls the “GUI text” component of bunnyCounter and sets its value to a string transposition of an integer variable named “currentBunCount.” She does that with the following line: “bunnyCounter.guiText.text = currentBunCount.ToString().” Unfortunately, my newer version of Unity was returning an error message. The class “GameObject” doesn’t contain any “text” variable or method to be accessed anymore. After some research on the web, I found a forum named StackOverflow where I learned that I had to use a “Text” class from the new Unity UI system in order to access the text component of my “bunnyCounter” variable. Being in a knowing-in-action scenario, I modified the data-type of my variable (“public Text bunnyCounter”), changed the call to the text component (“bunnyCounter.text = currentBunCount.ToString()”) and added the necessary directive (“using UnityEngine.UI”) to use the new UI system.

In my learning curve, these small moments of “knowing what to do and how to do it” were proof of tangible progress being made on the coding front. My knowing-in-action and reflection-in-action skills were significantly improving. The training of my “programming brain” (Ferrone 2019: 195) had finally paid back. My intuition and judgment had served me well.

5) Reflecting on the Horizon

Looking back at my reflection-in-action process in the face of puzzling situations, I realized that I heavily relied on the tacit skills I have developed as a game researcher. Here, I have in mind things like abstract and logical thinking, methodological workflow, analytical reasoning, writing and reading aptitudes, efficient note taking, research and documentation capabilities, communicational competences, careful concerns for page layout, easiness with new software environment, degrees of self-reflexivity, intellectual curiosity and a passion for game-related knowledge. All these abilities are part of a cluster of knowledge and know-how that is about “knowing how to learn.” Hence why they were so quintessential in kickstarting my coding journey, especially regarding conceptual assimilation, attention to spelling and syntax, ensuring code readability, identifying problems, searching for solutions, project organization, using specialized documentation and interacting with the Unity community.

On the downside, I observed that my mathematical and arithmetic aptitudes were seriously rusty. Some of the more complex calculations I had implemented through Blackman’s book are still a bit obscure in my mind. For example, I was taken by surprise when I discovered the way the author calculates the instantiation of a series of vegetables in different gardens using a "for loop" to spawn them in equally spaced rows. I felt the same way when I was coding the gradual reduction of an energy bar following the slow depletion of a battery energy level calculated in percentages. This is one of my main fears at the moment as I am unable to foresee the calculations I might have to code in the future and how I will do so.

At the end of the day, I also learned not to be discouraged by such overwhelming novelties. In a way, the confusion I had felt when I was struggling with variables and methods isn’t so different from the incomprehension I'm facing now with math problems, encapsulation, polymorphism, or generic and defensive programming. If there is one thing I realized since my initial programming steps with Python up until my C# coding experience in Unity, is that appropriate knowledge is acquired in due time and through practical repetition. Mastering new coding notions requires reading, revisiting, and unfolding the same concept multiple times, from different angles, and through various voices.

On top of that, every bug and mishap is a learning and creative opportunity, no matter how annoying it may be. In a way, such flawed situations are irritating precisely because they take you out of your comfort zone and require extra research, reading documentation, and knowledge acquisition. In the end, one can conclude that glitching is learning. To pursuit this journey, I’m now equipped with basic C# programming skills and a solid mastery of Unity fundamentals. The next step is to start prototyping Bug Hunter. New coding challenges will be embraced along the way as I’m heading toward a new horizon where glitches await, for better and for worse.

References

Blackman, Sue (2014). Unity for Absolute Beginners. New York: Apress.

CS Dojo (2017). “Python Tutorial for Absolute Beginners #1 - What Are Variables?” YouTube (December 26). https://www.youtube.com/watch?v=Z1Yd7upQsXY.

Ferrone, Harrison (2019). Learning C# by Developing Games with Unity 2019 Fourth Edition. Birmingham and Mumbai: Packt.

Hanselman, Scott and Kendra Havens (2019). “C# 101.” Channel 9 (September). https://channel9.msdn.com/Series/CSharp-101/?WT.mc_id=Educationalcsharp-c9-scottha.

Homesteading with Hill (2011). “Deus Ex Human Revolution: Hacking.” YouTube (August 26). https://www.youtube.com/watch?v=RbFdLZmdX-c.

Programming with Mosh (2019). “Python Tutorial - Python for Beginners [Full Course].” YouTube (February 18). https://www.youtube.com/watch?v=_uQrJ0TkZlc.

Schön, Donald A. (2001). “The Crisis of Professional Knowledge and the Pursuit of an Epistemology of Practice.” In Competence in the Learning Society, John Raven & John Stephenson (eds), pp. 185‑207. New York: Peter Lang. Available online at: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.880.9895&rep=rep1&type=pdf.