Godot Editor Mobile

[Staci Mauger]

Ipublished two games on Godot 3.3 (they are offline since 5 months). I avoid Godot 4 for mobile (that is only my opinion). Godot 4 is much bigger when you build for android or iOS then 3.

I dont know the performance difference between Godot 3 and 4.

But if size matters for you, you should know, that output data is a lot bigger.

I use Godot 4.2.1 in Revengate, a roguelike for Android. This is not a very graphical game, but I really enjoy the revamped TileMap, functions and signals as first class objects, and the live inspector (you can debug the game running on your phone in the Godot editor running on your desktop). I would seriously consider Godot 4 for any new mobile projects.

I am trying to run a mobile game in a Android phone. It is recognized by the Godot editor and I once was able to deploy the app into the phone successfully. However, I now get always stuck at 66% of the loading process trying to install the game. I am working on a Macbook with M1 chip. Also, after this happens, I can no longer use Godot as it does not load any project, even after I force quit it. Only after restarting the computer can I use Godot again.

As you can see from the two images, the game looks completely different from in the editor and in my phone. On my phone, the artwork looks blurry and my background environment is not at all dark. I'm using animated sprites 3d and Custom Color mode in world Environment.

By default, vertex lighting is forced on mobile for performance reasons. You can disable this by unchecking Force Vertex Shading.mobile in the Project Settings. Also, you need to enable Allow Hidpi in the project settings to allow the game to render at native resolution (again at a performance cost).

Also, since you're using pixel art textures, you'll want to reimport them with lossless compression by selecting them in the FileSystem dock, going to the Import dock, setting compression to Lossless then clicking Reimport.

@Calinou said:By default, vertex lighting is forced on mobile for performance reasons. You can disable this by unchecking Force Vertex Shading.mobile in the Project Settings. Also, you need to enable Allow Hidpi in the project settings to allow the game to render at native resolution (again at a performance cost).

The only thing i can think of is that its the device size or positioning of the button thats causing an issue.

It COULD be that its being blocked by something as i remember something about being a possible issue?

Unfortunately i cant test at the moment as my computer is being a real pain about recognising the phone i was using to test before but if i get it working i will try to take a look and see if can figure something out. This being said if it is a device issue it may be an idea to try a different device if you can to see if anything works there.

Yeah those settings are fine.

I got my daughters old S7 back and working in godot this morning and tested it with my project and all the buttons work when i use the remote debug.

I opened your project in 4.1.2 and i get the same issue as you do.

I cannot for the life of me find where the issue is that its not detecting the button presses in your project and why it does in mine.

At this point i suggest downloading the project from the resources and using 4.1.2 to open it and set up the remote debugging and see if it works there.

This way we can rule out a device and export issue and it is something to do with the project.

Edit: I just made a small project with a single button and label. I update the text when I press the button and it works fine. Even when I Remote Debug the button works on my S22Ultra I exported on 4.1.3. So I must have messed something up with my project but have no clue what it could be.

i did find it strange that the errors didnt flag up with running in the editor, only when running remotely, with the debug option selected. otherwise, it was failing silently and just threw me on a red herring search the wrong way.

So, I am coming from Unity, but want to use another engine now as it is becoming unbearably convoluted, expensive and slow. Also, I want to target HTML5 for mobiles for my next game, and Unity is not anywhere close to being able to handle mobile web.

The more mainstream choice is Godot, but I do not like GDscript (looks exactly like javascript, which I really want to avoid), and C# seems to be less supported. Also, it produces pretty large files, which is a problem on mobile. Not sure about performance, but seems Heaps is much more lightweight and wont stand in your way. I used to make a lot of Flash games before, and I like the down to bare bones approach, the Godot editor adds a lot of things I do not really need in my workflow.

I really like Heaps as it is a no-nonsense super optimized framework, and Haxe looks like a great, modern language, very similar to other languages I already know such as Actionscript and C#. Also, I love the game Dead Cells, it is a great showcase giving me a lot of confidence that Heaps is a great choice for commercially competitive games.

I want to target both HTML5 (for an easily accessible demo) and Steam. But, after creating the game for HTML5, how hard is it to build a Steam version of it? I noticed Dead Cells comes with a huge amount of DLLs. How would I know which ones to include? Any tools available for a Steam export and to connect to the Steams services/API?

How well is the HTML5 build protected from prying eyes? From what I understand Haxe targets javascript and not webasm, so it means the game code would be quite exposed. Is there any way to protect it?

It should be quite easy to target both HTML5 and desktop from the same code, but i would advice you to try and develop testing both HL and HTML5 along as you go - this way you will be ready to publish to Steam in no time!

And as far as the HTML5 code being protected - there are ways to obfuscate js code for the browser - this would be the same ways as normal js developers would use. But i wouldnt worry about this - remember the code is generated - so good luck to anyone trying to rewrite or use parts of it anywhere else. Just dont store important info in plain text

I tried to look more at Godot, but the editor heavy approach and GDscript optimized system is just not very attractive. The main reason I am looking at it is because of wider community support while Heaps is mainly an engine for internal use made public, if I understand it correctly. So, I am unsure about its lifespan and future support.

About protecting the game. Is the pak format also used for HTML5? Do you know if it would be possible to add a small layer in the loader that deencrypt an encrypted pak, to at least protect the game data files a bit and make it unavailable to the pak unpackers out there?

As @datee said you should be able to make HTML5 and Steam releases quite easily but I remember some people having some hurdles along the way when it comes to the dlls to use for Steam. Seemed quite easy to deal with though in the end.

We got commissioned to build a mobile game for an NGO. It had to be educational, yet we really wanted to keep it playful and engaging for a casual player. Our creative team came up with an idea of an illustrated 2d platform game, interspersed with educational quizzes from time to time.

We wanted to pick something universal, that could benefit us also in 3d game dev in future. Defold seems nice, but at the time of our decision, it seemed much less mature and popular (1.2k stars on GitHub, vs 35k for Godot). Also one of the team members had already played with Godot a little bit, so we went with his recommendation.

For writing scripts, you can use an external editor (there are third party packages with syntax support for VSCode, Atom and Sublime). But that, at least for VSCode, requires the official editor to be open in the background anyway.

And yet, there were many things that we were very positively surprised with. To name a few - sprite animations, 2D transformations, global and local coordinates, collision handling and many other things. Prototyping, managing assets and level designing were a breeze. And at the end, we managed to (with some effort) get rid of (or around :)) all major bugs.

Godot provides us with two ways of styling components. You can either manually attach styles per each component (these can be saved into files and reused between multiple components), or you can define so-called themes. This way, you can style a component together with its children - kinda like with CSS, but with a visual editor. To be honest, we found using just reusable styles without whole themes thing more streamlined and easy enough to maintain for a project of our scale.

Godot (/ˈɡɒdoʊ/[a]) is a cross-platform, free and open-source game engine released under the permissive MIT license. It was initially developed in Buenos Aires by Argentine software developers Juan Linietsky and Ariel Manzur[6] for several companies in Latin America prior to its public release in 2014.[7] The development environment runs on many platforms, and can export to several more. It is designed to create both 2D and 3D games targeting PC, mobile, and web platforms and can also be used to develop non-game software, including editors.

Godot allows video game developers to create both 3D and 2D games using multiple programming languages, such as C++, C# and GDScript.[8] It makes use of a hierarchy of nodes to facilitate the development experience.[9] Classes can be derived from a node type to create more specialized node types that inherit behavior. Nodes are organized inside of "scenes", which are reusable, instanceable, inheritable, and nestable groups of nodes. All game resources, including scripts and graphical assets, are saved as part of the computer's file system (rather than in a database). This storage solution is intended to facilitate collaboration between game development teams using software version control systems.[10]

3a8082e126