|
| 1 | +# Audience, objectives and pedagogy |
| 2 | + |
| 3 | +This document aims to outline the motivation for the creation of the block |
| 4 | +coding plugin, the intended audience, design goals and non-goals. |
| 5 | + |
| 6 | +Note that the design, the pedagogy, and the tool itself are all under |
| 7 | +evolution. This document aims to describe the direction we see ourselves |
| 8 | +going in; the actual tool itself may be a bit 'behind' in the implementation |
| 9 | +of these principles. |
| 10 | + |
| 11 | +## Overall motivation |
| 12 | + |
| 13 | +We want to engage the largest possible audience in game creation, with a |
| 14 | +particular focus on young and underserved audiences. We aim to grow the game |
| 15 | +creation spark in those that didn't know they had it, and help aspiring |
| 16 | +game creators step towards becoming expert users of the Godot engine. |
| 17 | + |
| 18 | +Learners on this journey must face a tremendous learning curve. Godot is |
| 19 | +very powerful, and it is also complex. Learners within these groups face |
| 20 | +numerous challenges in order to become proficient at Godot, and within those, |
| 21 | +the most significant challenge is the need to learn GDScript, which is |
| 22 | +often their first exposure to computer programming. |
| 23 | + |
| 24 | +The block coding plugin aims to make game creation in Godot much easier |
| 25 | +to achieve for those learners, by postponing or eliminating the need to learn |
| 26 | +computer programming & GDScript. Those learners can first focus their |
| 27 | +attention on learning their way around the Godot editor, node types, |
| 28 | +inspector properties, animations, etc. without the simultaneous additional |
| 29 | +burden of having to learn programming. |
| 30 | + |
| 31 | +## Learning tool |
| 32 | + |
| 33 | +This plugin is intended to be used as a learning tool. The intended audience |
| 34 | +consists of aspiring game creators that are getting started in Godot, and |
| 35 | +have limited or no computer programming experience. |
| 36 | + |
| 37 | +Block coding is not intended to be a replacement for GDScript. We anticipate |
| 38 | +that there will things that are infeasible to achieve with block programming, |
| 39 | +but perfectly possible with GDScript or other advanced programming tools. |
| 40 | + |
| 41 | +We anticipate that once learners have found their bearings in Godot, if they |
| 42 | +have enough curiosity and motivation for the coding aspect they will then |
| 43 | +progress to learn GDScript and abandon block coding. |
| 44 | + |
| 45 | +That said, we are not against receiving contributions that increase the |
| 46 | +scope of what can be achieved with block programming, as long as that |
| 47 | +does not detract from the learner experience within our primary audience. |
| 48 | + |
| 49 | + |
| 50 | +## A layer on top of Godot |
| 51 | + |
| 52 | +We offer block coding as a layer on top of Godot. It does not intend to |
| 53 | +deviate far from the typical foundations of 'ordinary' Godot game building. |
| 54 | +In order to build games with blocks, you need to understand nodes and scenes, |
| 55 | +you need to use the inspector, build tilemaps, etc. The block coding aspect |
| 56 | +is aimed to be complementary, we will not attempt to (e.g.) offer an |
| 57 | +animation-building block language (we expect the user to learn and |
| 58 | +use Godot's standard animation functionality). |
| 59 | + |
| 60 | +This is somewhat contrary to some other block coding environments. Scratch, |
| 61 | +for example, seeks primarily to be a highly effective digital creation tool |
| 62 | +that embodies the principles of constructionism. As such, they have features |
| 63 | +and behaviours that are not feasible or interesting for our tool, e.g. |
| 64 | +in Scratch everything is a sprite (there is no hierarchy or typing, every |
| 65 | +block works on every sprite), and blocks are live e.g. the program is |
| 66 | +constantly running in some sense, you can click on blocks to instantly see |
| 67 | +what they do. These features are inherent to Scratch's focus on being the |
| 68 | +most powerful digital creation tool around, whereas our block coding |
| 69 | +language's inherent focus is on top of the existing norms of the Godot engine. |
| 70 | + |
| 71 | +## Teach Godot concepts, but with natural language |
| 72 | + |
| 73 | +Learners who succeed in using our tool to build games will become familiar |
| 74 | +with the concepts of game building with Godot & GDScript, however we prefer |
| 75 | +to use natural language for the text on the blocks themselves (e.g. "when |
| 76 | +another node collides with this one") rather than Godot's technical terms |
| 77 | +(e.g. "on body entered"). |
| 78 | + |
| 79 | +We believe the use of natural language provides a much smoother learning |
| 80 | +experience, and that if learners later progress to GDScript, they will be |
| 81 | +immediately and effortlessly able to recognise that the syntax to do X was |
| 82 | +worded as Y in the block language. The important thing is that they have |
| 83 | +picked up the underlying concepts through building games with blocks. |
| 84 | + |
| 85 | +## Focus on high level abstraction |
| 86 | + |
| 87 | +Our block language does not intend to mirror GDScript. Instead, we focus on |
| 88 | +providing a higher level of abstraction. There's so much value in having |
| 89 | +learners being able to very quickly drag and drop just a few blocks and have |
| 90 | +a working game. It makes building simple games that much smoother. We want to |
| 91 | +trigger a "holy cow, I can actually do this" spark in our learners after just |
| 92 | +a few minutes, which will provide the motiviational drive for them to persist |
| 93 | +along the challenging journey of mastering Godot. |
| 94 | + |
| 95 | +Compared to GDScript, there are also some things that are just tedious and |
| 96 | +boring to do in regular blocks, like displaying a score counter on the |
| 97 | +screen. Try creating block code to maintain a score variable which you then |
| 98 | +convert to text, embed in a label and show on-screen, it's a bit annoying how |
| 99 | +many blocks are involved in that simple operation. So we provide higher level |
| 100 | +components that make common things like this dead simple. |
| 101 | + |
| 102 | +Despite our desire to provide fun, easy high level blocks, we do not exclude |
| 103 | +the provision of lower level blocks as a secondary goal. For example, we |
| 104 | +provide a single ultra simple high-level block that lets you move a sprite |
| 105 | +around based on arrow key input, which is heavily inspired by Makecode Arcade's |
| 106 | +"move mySprite with buttons" block. However if you wish to calculate a |
| 107 | +sprite's movement vector based on keyboard input, and then ask the physics |
| 108 | +engine to move things around (as you'd typically do in GDScript), then we have |
| 109 | +blocks that let you do that. |
| 110 | + |
| 111 | +## Limited scope of game genres & functionality |
| 112 | + |
| 113 | +Through our focus on learner-suitable high level abstraction instead of |
| 114 | +mirroring GDScript, we hit the tradeoff that some capabilities are lost, |
| 115 | +you may encounter things that you can't implement in blocks. |
| 116 | + |
| 117 | +We're focused on facilitating creation of 2D games, particularly platformers |
| 118 | +and top-down games. We'll try to plug obvious gaps in the block collection and |
| 119 | +capabilities as we find them. |
| 120 | + |
| 121 | +We're open to contributions that increase the scope of what can be created |
| 122 | +with blocks, as long as it doesn't compromise the learner experience on |
| 123 | +those 2D game genres. |
| 124 | + |
| 125 | +## Code generation is not a goal |
| 126 | + |
| 127 | +Internally, our plugin converts block scripts created by the user into |
| 128 | +real GDScript. There's a button that lets you see the GDScript code generated |
| 129 | +by your blocks. |
| 130 | + |
| 131 | +We regard the code generation as an internal implementation detail that might |
| 132 | +go away in future. It is done this way because it was the fastest way to |
| 133 | +prototype the block language back when we started the project, and we haven't |
| 134 | +yet encountered strong reasons to change it. But we might. |
| 135 | + |
| 136 | +It's nice to think that this functionality could have some value to learners |
| 137 | +who later progress onto GDScript. If they can build in blocks and then see |
| 138 | +the equivalent GDScript, isn't that going to facilitate the transition? |
| 139 | + |
| 140 | +While there's undoubtedly a little value in that, in reality it is not |
| 141 | +as useful as it sounds. A learner's programming journey typically begins |
| 142 | +with very trivial programs or carefully orchestrated small code changes, to |
| 143 | +avoid being overwhelmed by a larger body of work. Learners benefit most from |
| 144 | +high quality, well crafted and nicely formatted code, with associated |
| 145 | +documentation and guidance. The internal output of our block coding plugin |
| 146 | +does not attempt to provide any of those; we wouldn't advocate showing it |
| 147 | +to learners who have never seen code before. |
| 148 | + |
0 commit comments