Maybe do a README at least before posting to HN? I compile Godot daily, but have been ignoring everything but GNU/Linux as a target platform. I don't see anything particularly unique about this being for mobile besides some pretty basic joypad and screendrag stuff.
Here's the script for the first half of the video; second half kind of needs the video to make sense:
Hey, it's Lucky. Sorry for disappearing on you guys, but I've returned bearing gifts. This is my first project in Godot 4.3, called Pocket C. It's a small collection of touch-based controllers for mobile devices, which I think are a great starting point for building mobile SL touch-based games.
In this project, there are three demos included: a first-person demo, a third-person demo, and a top-down demo. These demos are inspired by popular mobile games like PUBG, Call of Duty Mobile, and League of Legends: Wild Rift. All these controllers are based on a joystick-touchpad combination, where the joystick is on the left side and a touchpad is on the right side. This layout is commonly used in many viable mobile games today, and it's at the core of all these demos.
We'll run through the code and the project so you can get started on making your own mobile games. All the source code and assets are included in the video description, along with a GitHub repository link. There's also a built APK, so if you want to test it on your mobile device, it's available there as well.
To me it's strange when people write a starter kit for the engine that supports mobile platforms out of the box. Is mobile support there just for marketing...?
As someone who has recently been doing Godot mobile development with Cursor as my IDE, this repo and the video in another comment gave me some quick thoughts.
1. The main thing the library seems to offer is some pre-packaged libraries for mobile touch controls in GDScript, the custom language for the Godot game dev framework.
2. I have recently come across similar problems to what that this library tries to solve.
3. However, the way I went about solving it was basically using Claude and ChatGPT as my co-developers and asking them to answer coding questions. Here’s a quick example prompt about coding GDScript similar to some of the attributes of the library: https://chatgpt.com/share/c8e713e3-0662-4c7d-8645-9a76b0c032...
4. An optimistic perspective from all the above is that AI coding assistants can make it easier for people to develop libraries like this faster.
5. A negative view would be that AI coding assistants mean people don’t necessarily need “libraries” like this if an LLM can spit out the same results in a couple queries (rather than hunting around Github or the internet for pre-packaged code).
I thought LLMs had pretty big promise until I started trying to use ChatGPT to help me learn Godot. Literally every answer it confidently spit out was just dead wrong. Didn't matter if I specified that was using v4.22 a million times, it'd still give answers mixed in with v3, or in some cases even solutions from other frameworks like Unity. It also mixed up GDScript and its shader language.
Just absolutely awful and unusable. God help whoever has to review or modify a game made in part by a different dev using ChatGPT.
> 5. A negative view would be that AI coding assistants mean people don’t necessarily need “libraries” like this if an LLM can spit out the same results in a couple queries (rather than hunting around Github or the internet for pre-packaged code).
Why use a library when the LLM can spit of a unique reimplementation of the library logic every time you need it?
A positive view would mean an uptick in library quality and sophistication, and a death-knell to the trend of shallow do-one-thing script wrapping libraries.
I've been doing similar mobile development with Godot, and have found the Phantom Camera library to be an example of a better developed and thought out library thats actually worth importing.
You almost certainly should not be updating the character.position both every frame (in _process) and in response to a MouseMotion event. That makes no sense.
Yep, it is definitely worth clarifying that all the code has to be reviewed manually still. An aside is that the LLMs (both Claude and GPT) have common failure modes in using Godot 3 syntax instead of 4, etc.
I meant to make the point that, having worked on mobile game dev recently, if the behavior I'm thinking of seems simple, my workflow instincts have become to go to LLMs first rather than Github. Very possible this is a bad reflex. Just one I've observed directly from my experience implementing similar functionality as the parent library.
It looks like spywaregorilla's comment was downvoted at least once but I think it was making the valid point sarcastically that the idea of "LLM generated code replacing commonly used libraries is a bad one." My original post was positing on whether this might be a future trend though.
Also want to recognize the author of the library (prophesi) commented down below and definitely applaud their work in packaging and open sourcing their work plus making the tutorial video.
