On Monday, we all presented our pitch decks. We all filled out a brief form on each pitch, and after the session Vanissa gave some general feedback.
She said overall, some people could have used more moodboards. I feel this could definitely apply to me, as there are relatively minimal visual materials in the pitch deck. Perhaps more inspiration photos/fuller moodboards could have given a clearer idea of the aesthetic/atmosphere.
She also said a lot of us could have made better use of sound to support our pitch. Again, I could have done this to communicate the atmosphere of my game, along with some of the narrative beats discussed. Perhaps some background music, with some specific sound design on the slide depicting the climax of the game. This could serve to further highlight the contrast between the unassuming and unsettling ends of the story.
We also received the results of the peer feedback forms. From the numbers, it seems people thought my pitch communicated my game idea well, and for the most part, felt they understood it.
There was one set of results that were far more critical than the others, however when compared to the others it appears to be an outlier, and after speaking to other peers it seems they also have an outlier set of results like I did. While of course criticism is valuable, the sheer contrast between that set of responses and the others does lead me to view it as more of a reflection of the peer who gave the responses rather than the quality of my pitch.
There was one set of responses that said they neither agreed nor disagreed with this statement in reference to my pitch. This does confuse me as I feel my game pillars were the clearest/most solid aspect of my pitch – they went through diligent iteration. I wonder if perhaps the game loop did not clearly contextualise my pillars, or if I should have gone more in depth explaining the body-horror genre to people who aren’t familiar. It was my belief that I should forego that for times’ sake, but maybe I was wrong and it hindered people’s understanding. Even so, this was the only feedback that implied this – the majority seems to say I did alright.
ERASTZ is a webseries created by user saint greaver. The pilot premiered on January 10th, 2026.
I became aware of this series because of the popularity of the Trench Dogs short.
Specifically, I found the character/s of Charlie and Cathy (seen in the thumbnail above) super impactful and compelling in both their visual design and backstory.
After watching the pilot, I found myself super inspired by ERSATZ’ unique premise and setting in which its body horror takes place.
The main premise of ERSATZ is actually incredibly relevant to my game idea. The main character, Mophead, is made of so many different parts and has been rebuilt so many times that he has lost his individual identity and memory. Of course, the setting and context is different to my idea, but the idea that the body horror has been enforced on Mophead by a wider sense of “duty” to serving society links surprisingly well with the story and themes of my game.
While ERSATZ is very visually different to what I envision for Criteria, I’m very glad I looked into it as it is a super cool take on body horror and the premise is right up my alley. The characters are also incredibly compelling and I’m excited to follow its progress as a series.
Ricky Haggett, co-founder of development studio Honeyslug, gave us a guest talk about their holistic studio culture. It was very insightful, providing a look at how an unconventional workflow & creative process can work at a studio level.
He brought emphasis onto allowing ideas to blossom and evolve in a way that AAA studios may not, avoiding boxing people into concrete role titles, and an argument against GenAI usage.
While his methodology does come from a place of privilege (being in a position of power at a studio with such a unique and flexible set-up), I did appreciate seeing a different perspective on how games can be made in the industry. It would be logistically difficult to totally apply this way of working to student life due to it being comparatively more rigid, but it did remind me that I am here to explore the creative potential of games, and it’s okay to foster/prioritise that.
Target Audience/Demand
I went on steam and looked at the reviews of games I felt inspired my game or shared an element with it. I included these in my pitch deck, showing there is demand and excitement around interactive fiction, games with impactful stories and genre-based twists.
I also used this post for inspiration as Until Then is a game that really replenished my desire to use games as a storytelling medium.
Concept Art
I also decided to create some quick concept art, as I knew some visuals would be important to supplement my pitch deck and communicate my vision.
I started with concept art for the starting design of our protagonist. Initially on the far left I started with a generic gangly robot design. However, one of the core pillars of this idea is achieving body horror with a clearly non-human character, so then I pivoted the direction. I tried putting together basic shapes, focusing on something between abstract and animalistic.
This is not anywhere near a final design as I did very little iteration or exploration, but I did seek feedback on this design and peers said it was cute which was what I wanted. I want players to get attached to their character to make the changes more impactful.
Again, with the “final form” of the protagonist, this was something very quickly thrown together that I hoped would give an idea of the emotional response I was looking for.
I then did some very quick airbrushing and added a darker background to act as somewhat of a mockup for the final upgrade. I wanted it to demonstrate a significant change in atmosphere and signify some dread – that there is no going back to the design we once knew.
If I had the time I would have done more concept art/character design work, however I feel these will do a satisfactory job of communicating the general vibe and supporting my pitch.
As the narrative and its themes are at the core of my game’s experience, I’m going to focus on solely narrative beats and writing for my first prototype. There’s a range of tools I could use: Twine, Ink, Bitsy, Downpour, even Powerpoint. For my first prototype, I’m going to use Ink, as I’ve used it before and I think it’ll be quite effective at prototyping the core narrative beats and whether they have the desired effect/response. As this is my first prototype, I’m going to use the Inkle editor’s built-in preview box to display and showcase it.
I’ve used Ink once before a while ago as I knew I wanted to make narrative-driven games. I used the unfinished file I created while learning the basics to refresh my memory and guide me in making this prototype.
I struggled figuring out how to use variables. I wanted to do this just for efficiency, but found it hard to figure out due to my lack of familiarity with programming. I looked to various websites for articles and tutorials that might help.
I really struggled with how to make a prototype that could be made in less than a week and showcased in 2-3 minutes while also testing out the core of my idea. The core effect I want to achieve is a *gradual* sense of unease, and it’s rather difficult to make something feel gradual in the span of 2-3 minutes.
After some 1-to-1 discussion with Vanissa and Jordan, I decided to focus on prototyping a smaller snippet/mechanic of my game (see: Flickgame Prototype), just to provide evidence of player testing and feedback collection. Even though I gave up on this Ink prototype, I still feel working on it gave me valuable insight into how I saw the narrative elements and pacing taking form in the most basic sense.
The aim with this prototype was to very quickly mock-up the installing of the upgrades. While not exactly the core experience I wanted to test, but with time running out and still no evidence of prototyping and testing game products, Jordan advised me that even something small and quick like this would do the trick.
I chose flickgame due to its ease of use. I have admittedly put extremely little time into developing any programming/technical skill, and so trying to use anything more advanced than flickgame or Ink felt out of the picture. I had also considered Bitsy, but I felt the restraints that come with that engine would be too stressful to work around in the short amount of time my procrastination had left me.
While this prototype was extremely rushed and low quality and born out of some necessity and stress rather than real desire to test this mechanic, it was valuable to put down a rough idea of how I imagined this mechanic and get feedback on it. Of course theoretically I knew the importance of prototyping small gameplay sections and mechanics early in development, however experiencing it did make it much clearer to me how fundamental this process is in making sure no elements of a game get to a point of no return and end up falling short.
Playtesting & Feedback
I chose a few key questions to focus my notes around while people playtested this prototype.
Can they figure it out for themselves?
Everyone who tested was able to understand that the stand-out colours signified clickable areas. However, due to the field of view, people didn’t notice the arms being detached and replaced, so they weren’t clear on what they were actually doing. Due to the lack of context, they believed there was something broken we were fixing.
Are they curious about the wider context?
Playtesters asked what each of the buttons did and why they were pressing them. They were also curious about the rest of the robot’s body.
Did anyone get stuck? Was there anything unexpected?
There were some bugs where buttons linked to pages they shouldn’t have at certain points. This was because this prototype was quite rushed, so in copy-pasting some of the slides I did not delete the links to other pages.
Some people interpreted the check mark on the display to mean that they shouldn’t touch anything because the robot was operating well. It took some time for them to realise they still needed to interact, and some people interpreted turning the motor power off as a bad thing and tried to undo it. A lot of people got temporarily stuck trying to figure out what to do after turning it off.
The two arrows used to represent detaching the original set of arms was interpreted by some as two options with different results, despite flickgame only providing one link per colour, and the arrows were the same colour.
People were generally unclear on what parts they were looking at, with feedback wondering what buttons and such did, and observations saying the main board inside the robot’s chest looked like a bomb (fair enough, random wires and buttons everywhere on a device).
What would players like to see explored further?
I got some very valuable feedback saying that the perspective being from the outside gave a player the idea that we were playing as a separate character from the robot. While this was only supposed to test out a small mechanic, this was insightful and made me think of how the developed game could get creative with perspective/camera angles during these sections. Perhaps our character could project a diagram version of their chest onto the wall opposite and view it that way, or just have it as a HUD display sort of thing.
There was also general feedback wanting more signs/highlights to signify what the interactive areas were. I do understand this, but I do also want the experience for this mechanic in the larger game to be the player slowly building knowledge of how these systems work with as little guidance as possible – not just for a rewarding/engaging experience, but also because diegetically, our character would already know how they work and being told in a tutorial may break some immersion. If this game goes into development this will definitely be a consideration for further prototyping and testing.
Sophie was kind enough to give us a very informative talk about game loops and give us feedback/ideas on elevator pitches for our games. Pictured above is what I did during the game loop activity, where she gave us classic games to then put into game loops.
She split the basic structure into start state, player action, result of action and win/fail. Here, you can see that we failed to question whether Snake has a win state. At first you’d say no, but as the play space is limited, there is a limit to how long your snake can be – therefore the win state would be achieving the highest possible score/length within the finite space of the game.
Then she came around to briefly touch upon elevator pitches for our games 1-on-1. I was initially struggling to condense the interesting part/s of my idea into one/two sentences, however after I said that in my head I have a main question I’m trying to answer, she said it was a perfect first slide to hook people with, and then to use her suggested elevator pitch as the next slide.
With this, and a lot of iteration on my game pillars last week, I felt confident enough to start putting some of these things into a PowerPoint so I wasn’t going to be making the entire pitch deck last minute (below are the hook, elevator pitch, game overview, design intention and game pillars I came up with on Monday).
Sophie also suggested we use narrative flow charts/diagrams for narrative-heavy games. She didn’t have an example in her slides, so I decided to do some research as it feels especially relevant to articulating my idea, whether it ends up in my pitch deck or not.
I had a look around at articles and even considered using Twine, however the lack of narrative-altering choice within the narrative means I’m not convinced that a flow chart/Twine prototype would be effective at testing my desired effect.
Game Loops
I also starting working on how to articulate and present the game loop/s for my idea. I started by jotting down the second-to-second, minute-to-minute and hour-to-hour actions/progression. While day-to-day was also frequently included, I feel the scope for my game is not large enough for that. I want it to be a gradual experience, but not long enough to be unachievable for a semester-long project.
Tone and Style
Vanissa ran a workshop today to encourage us to consider the tone and style of our game along with some reference boards to communicate the visuals. This was useful in encouraging me to find reference materials to include in my pitch as I knew I wouldn’t have time to create that much concept art.
When envisioning the aesthetic inspiration for my game, the first thing to come to mind was, of course, FNaF. Scott Cawthon‘s penchant for uncanny robot designs is an obvious thing for me to analyse, to see how I can use mechanical parts to design a character that elicits that uncomfortable feeling I want to introduce over time. He also has plenty of unassuming robots that aren’t large or looming, so I can also look for inspiration for the starting/original form of our robot protagonist.
The Desolate Hope is a 2014 game that rolls platformer, dungeon crawler and RPG turn-based combat into one package.
I played the first several minutes of the game to get a feel for how the art looks in motion and what the mechanics are like. Easy to say, a word to sum up this game is OVERWHELMING. The settings are filled to the brim with assets, there’s immediately three levels of simulation (?) with different gameplay, and there’s already multiple shops to buy… items? Upgrades? Switch stats? I don’t know – none of this is to mention the controls. No WASD, Z to jump, Esc IMMEDIATELY closes the game (I have no idea how to access settings or if I even can), and there are two buttons to cycle through dialogue at different times.
However, I can say that the art is certainly worth looking at. The game centers around these large robots called Derelicts, and each has it’s own room and a breathtaking, looming design.
I really admire that all the designs are distinct yet extremely cohesive – it’s believable that they were built by the same organisation.
My favourite Derelict is the last one pictured here. They all have somewhat of a “puppet on a string” vibe, but the humanoid/mask face really elevates that here. I love the contrast between the thin, hanging arms and the broad shoulders and upper body, and also the general aesthetic of his room. The combination of human and robot elements (later used in the FNaF franchise with characters like the puppet and Ballora) really lends itself to the uncanny valley feeling. I think taking inspiration from how these characters play with proportions and adding some asymmetry would make for some really cool and unsettling visuals.
Outside of Week 2’s scaffolding focused on intention and experience, I would also like to research the body-horror genre. I am set on using that as a framework for the player experience and it is my intention for the game to do something unique within this genre – I want to try achieving the same emotional response body-horror tries to elicit through non-organic material. It is at the heart of my idea and no matter how it is executed I would like that to be preserved.
The above article was really great at giving me a variety of perspectives on how body horror can be used, what makes it tick and what it can represent.
Generally, article author Shannon Lewis boils body horror down to two things: change and relatability. Its essence is about transformation, and the emotional response people have comes from the thing being transformed. As she says, “I have a body and I know what it means to be afraid.” This combination of two core human experiences is what the genre hinges on to create impact.
While there is plenty of discussion of how gore is so effective at doing this, there are also other factors that make body horror so compelling as a useful tool/subject.
I find the quote from scriptwriter Freddie Van Der Velde to be very relevant to my game idea:
“[Body horror] finds its roots in our primal fear of the uncanny and from an internal, not external threat. This leads to an alienation of our own physical self”.
There’s a very clear link here to my game’s core theme of loss of self. There’s also plenty of uncanny valley-based robot designs out there (most famously from the FNaF franchise but Scott Cawthon’s other works and other media in general can also provide me some good aesthetic inspiration) that I could draw from later down the line to elicit similar feelings of discomfort that would usually be achieved through organic material in this genre.
This article briefly touches on how body horror can sometimes veer into ableism. I had a similar concern with mine that with the wrong execution, this game could very easily be interpreted as transphobic – I had toyed with the idea of playing as the mechanic rather than the robot, but having a character you created change themselves to do what makes them happy and for it to be presented as grotesque… you can see how it could be interpreted horribly. This thought was why I decided the robot should be the protagonist. This makes it easier to explicitly show that the robot does not want to transform themselves, and explore the complex dilemma of whether they really want to be accepted into the program if it means having to meet all these requirements. I think this should help dispel most of that potential misinterpretation.
I already spoke about avoiding misinterpretation. The first video I watched talked about how body-horror as an allegory for the trans experience is often used to represent puberty and the dysphoria it can cause for trans people. It is a forced, imposed transformation.
My game’s idea hinges on the fact that the transformation of the main character’s body is a choice they feel they have no other choice but to make. It is a price they feel they have to pay, not the thing they want. I want to make this distinction clear through the visual novel segments to avoid misinterpretation and support the horror of the transformation.
The second video helped me understand why I gravitated to using a robot as an allegory for gender identity (as a genderfluid individual myself). Robots are seen as artificial/less than human and are reliant on others to appear real/legitimate – both in the sense of gender affirming care (surgeries, binding, etc) and the need for validation from others to feel secure that others see you the way you do (use of desired pronouns and name).
Robots are often “othered” in media in a way which resonates with me, and there are plenty of examples of media where robots act with the goal of wanting to be taken seriously/seen as equal. I feel this links to my game and the main character – the transformation of their body fundamentally changes who they are, as the desire to be seriously considered for the program (taken seriously, seen as equal to others) takes precedent over preserving their true self. It is a metaphor of the pain and horror of changing oneself to conform and appease others.
On Monday Venezia Georgieva (Principal Game Designer at Sumo Digital) visited to give us a talk on what Game Overviews, Game Pillars and Game Loops are, how to craft these and what their purpose is in game dev. She used existing games and their official content to give us case studies for better understanding of these concepts.
We then did an activity to start applying these to our games, as overviews, pillars and loops are expected to be part of our pitch deck.
Venny said I was on the right track with the pillars, with the feedback that | just needed to keep iterating to get the descriptions as concise and clear as possible. I was hesitant to reference a genre with the phrase “robot body-horror” which I’ve used in my head as a core part of the project, however Venny said it’s an acceptable phrase for a pillar because it’s a specific twist on genre that communicates the experience.
I struggled with the game loops, as my game is heavily narrative and linear, whereas the case studies had more gameplay and/or choice. However, through discussion with peers and more thought, I feel I’ll be able to visualise the experience through this lens.
I did also ask Venny how to approach this after her talk, and she said that “resources” could be time or story progression, and there are still player actions to form a loop such as talking to people and collecting things.
GAME PILLAR ITERATION
In Ellipsus, I used the draft feature to iterate on my game pillars, trying to make them clear, concise and meaningful. Here is every iteration with major changes, with the differences highlighted.
2ND PASS
Robot Body-Horror – Play as a robot who wants to be taken seriously by a space exploration program. Progress and see your character become more unfamiliar.
Diverse NPCs in a Sci-fi World – Form relationships with people and aliens to gain and install new parts. Discover the customs of this far-future world and its societies.
Upgrade Your Body with Developed Knowledge – With each body part/Through repetition/With practice, learn the systems and parts that make you tick to replace your parts safely.
The 2nd pass was my first attempt to improve on my paper-written pillars. I was focused on immediately emergent changes that would communicate the experience better, like the tagline “robot body-horror” and shortening the descriptions.
4TH PASS
Robot Body-Horror – Play as a robot desperate to be taken seriously by a space exploration program. Increase your chances of being selected by upgrading your parts. As you progress, your body and relationships gradually transform – for better or worse.
Dive into a Sci-fi World – Explore a far-future world and interact with its inhabitants to obtain parts. Form relationships, learn about customs and discover the societies of the far-future.
Upgrade Your Body with Developed Knowledge – With each upgrade, familiarise yourself with the systems and parts that make you tick to replace your parts safely.
The 4th pass has many significant changes. There are more verbs (explore, interact, learn) and short descriptor words (desperate, gradually) to more clearly communicate what the player will do and feel.
5TH PASS
Robot Body-Horror – Play as an ambitious robot desperate to be taken seriously by a space exploration program. Try to increase your chances of being selected by upgrading your parts. As you progress, your body and relationships will transform – maybe not in the way you expect.
Dive into a Sci-fi World – Explore the far-future and interact with its inhabitants to obtain parts. Form relationships and discover the intergalactic society of this cyberpunk world.
Puzzling Parts – With each upgrade, familiarise yourself with the systems, wires and power units that make you tick to replace your parts safely; all while adapting to how these upgrades change your body.
More keywords for a vivid picture of the experience: ambitious, intergalactic, cyberpunk. I added the verb “try” and edited the last sentence to imply the narrative, which can hopefully be pieced together in combination with the other pillars (I will seek feedback on this tomorrow). I also gave the last pillar a new, catchier name as I was struggling to think of something both effective and accurate. I also expanded on the emotional challenge this pillar should uphold, as should all of them.
On Monday we did an exercise of analysing an existing game’s design intention and how the developers choices support these.
This game has very clear subject matter – you work at an immigration checkpoint for a fascist state.
Papers, Please intends to immerse the player in the environment described above, with audio and visual motifs clearly based on the USSR. There is an emergent design intention of hopelessness – this is supported by the design choices of a repetitive/mundane closed game loop and the constant reminder at the end of every day of by how little of a margin you are able to support your family. While your actions do heavily affect the story/events and what ending you get, these are either winding up imprisoned or dead, or simply aiding an organisation larger than you (whether that is the government or the resistance group EZIC). This is also underlined by the repeated occurrence of terrorist attacks, which over time desensitizes the player to the shocking nature of this once again immersing the player in the experience of living in a fascist state – of the individual being powerless compared to those with more influence, or having to make great sacrifices to overthrow them.
MDA Analysis
Mechanics: approval/denial of entry, reading and analysing documents, important choices
Aesthetics: emotional responses to consequences/outcomes of actions (eg. guilt, pride etc.), underlying sense of hopelessness
Applying this lens to my game idea
The class & lecturer’s analysis of Unpacking‘s essential experience & how it uses “show not tell” gameplay to tell a story gave me an idea for how to condense one of my ideas from last week to have a realistic scope for a student project and make the design intention clearer.
While the world exploration & NPC interaction was the springboard for this idea, I feel the experience I wanted to design lies in exploring the question of identity with the body-horror-esque idea of replacing body parts. During this session I had an idea inspired by how Unpacking uses the actions you’re performing and the items you interact with to tell the story rather than being dialogue heavy.
Switching the focus from obtaining the parts to attaching them to the robot’s existing body as a design choice would make the experience more focused on the above central theme and more realistic to develop in one semester.
The gameplay loop could switch between brief visual novel/talking sections between the robot and his mechanic to provide context on characters and their relationships and goals, and piecing the new parts with the robot’s existing body. This part could involve simple logical puzzles – maybe certain parts of the robot’s body need to be rotated or opened to attach parts, or some power modules need to be turned off.
This idea allows for a more flexible game length – you could split it into a few levels, eg. new legs, arms, torso then head. With each “level”, the player would be replacing a more integral part of the robot, eventually being forced to confront the loss of the robot they’ve gotten to know throughout the game – or maybe being presented to the choice to preserve him.
These aren’t set in stone, but provide options for pillars that could support my desired intention & experience.
Intention & Experience
I’d like the player to feel a gradual, strong sense of discomfort and loss from the bodily changes/borderline mutilation they enact on their robot character.
I would like players to experience the tension between the desire to achieve a goal and the cost of attaining it.
I want players to consider questions of body, identity and conformity through the metaphorical nature of the body-horror genre.
Discussion
After discussion with Vanissa and Issy, we came up with another idea that would make the tension listed above a more consistent and prominent part of the experience. Rather than being set in the workshop, the player could already be in the training program for the space mission. Throughout, they could be presented with the choice of upgrades – if you upgrade, you don’t fall behind and are more likely to make it on the crew, but maybe other characters you had/form relationships with have varying negative reactions to it as you start to lose what is integral to your character. Alternatively, if you choose not to upgrade, you could fall behind in certain aspects. There would be different characters urging you (in subconscious or outward ways) in different directions, and perhaps like Life is Strange, it could all culminate in one big final choice that determines the outcome for your character.
Vanissa suggested I try making something – whether it’s a storyboard or sketches or a powerpoint – to get a clearer idea of what feels right for this vision and what direction it should go in.
We both agreed it’s still a struggle to keep the idea to a realistic scope, but I will research the key elements I want the game to explore and create an experience of, and try making something to do with the game. By doing both of these, hopefully I can have a better idea of the experience I want the game to create.
Additional Iteration
We did an exercise on Tuesday of iterating on our current idea with different genres, however none of the ideas really grabbed me, and I struggled quite a bit with thinking of other directions to take it in.
Considering core element & prototype
After Monday I felt very stuck on what the game would actually entail, and how to execute my desired experience in a scope-conscious way. I discussed this with Jordan and some peers and they reminded me that while advice is useful, I’m not obligated to follow everything to the letter, and it’s important to keep what I really want this game to say and achieve as a vice to hold on to while developing the idea.
With this in mind, I was able to brainstorm with them and land on a solid gameplay loop and prototype idea that are both feasible for our time constraints.
GAMEPLAY
Visual Novel sections. Each stage/level will be bookended with a short exchange between the robot (player character & protagonist) and their mechanic. There may also be brief dialogue while obtaining and attaching parts.
Obtaining parts. At the start of each day, after talking to their mechanic, the player will go into the world and find the part they’re looking for. It may be simple as buying, or they might need to dumpster dive, steal or craft. There could be NPCs that the player interacts with multiple times, however the inclusion of this would depend on time.
Attaching parts and seeing change. The action of attaching/upgrading/replacing parts would be conveyed through small puzzles. For example, some parts may need to be rotated or a certain system may need to be powered off. Then there would be a wide shot showing how our character now looks after the upgrade.
The core of the game is the story and narrative beats. As the player strives for the goal of qualifying for the program, there’s a building sense of unease, with a final realisation/climax at the end. To achieve this, throughout the game the player could be upgrading/replacing a part more integral to their identity, as mentioned earlier in this post. The game may end with replacing/erasing the memory core, but with the game ending before the process is over, leaving it sort of open-ended while still achieving that sense of losing identity that’s at the core of the idea.
Then in terms of prototyping, Jordan suggested making a condensed version of the narrative in Bitsy, seeing if the beats and climax have the desired impact without the fluff.
Tech Session
I booked a 1-to-1 session with Ross this week to seek guidance on resources to build technical skills and knowledge, and also for what engines/tools would best suit both the prototyping and development of my idea.
Since I’m starting with basically zero programming knowledge, I want to have a resource I can go to throughout the year to develop myself in a language/engine/skills that are widely applicable and useful while also (relatively) easy to pick up. In terms of prototyping, I can use Bitsy, but I’d like to see if there are other options for accessible tools that might still develop my technical knowledge.
Ross gave me various things to look into for both prototyping and skill development.
Ross sent the above resource to help me learn GDScript, the programming language used in Godot. He also heavily advised not to get stuck only following tutorials, and to learn by both research and practice.
