What’s impressive is that the editor itself is fully written in Godot. Godot as a fully blown game engine comes with its very own editor for both visual stuff and scripting. Yet we still appreciated the existing support and used it as much as possible.īut things are changing and GDScript will get its next iteration with Godot 4, which looks very promising, to be honest. No generics, interfaces and other things that you expect to find in a strongly typed language. The notation is similar to Python’s typing, but you can only use native types along with classes, that you can access either by making them global with class_name keyword or loading using const … = preload('…'). Yet, if you learn to live with those disadvantages, it does its job and you’ll find it okay. Also, a clean way of importing classes/scripts together with a proper package manager would make it less like it’s 2003 and you’re still rockin’ PHP3. tscn file and you won’t get any clue from the engine or editor other than meaningless runtime errors. What’s worse, you can instantiate a script instead of a scene by mistake if you name it with class_name or load. Instantiating object is inconsistent - for scripts you call new(), yet for scenes, you call instance(). It lacks the idea of private fields or methods, so you end up with an underscore-prefixed mess. Yet, there are also disadvantages of being a single-purpose and not widely used language. The option of writing semi-async parts of code with yield is really helpful. It brings easy to use event system, that was good enough for most of our cases. We really liked the integration with the engine. Honestly, it felt easy to start using even for a person who hasn’t used Python for like 10 years. If you casually use Python, you’ll feel most at home. GDScript is a python-influenced language, created with a single purpose. So, as long as you’re not a daily C++ or C# developer, you should probably pick GDScript. Also, most of the materials you’ll find over the Internet is based on GDScript. Yet, GDScript seems like the best option as it deeply integrates with the engine so most times code for the same functionality will be much simpler in GDScript. It also brings support for C++ and C# on top of Mono. While many competitors in the area of open-source game engines rely on Lua, Godot brings its very own GDScript language. Also one of the team members had already played with Godot a little bit, so we went with his recommendation. 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). We wanted to pick something universal, that could benefit us also in 3d game dev in future. If you google for such engine, you’ll probably find Godot, Defold and some 2d-only engines. We also prefer to pick open source projects when possible. We thought about Unity for a brief moment, but we don’t love how it works with version control, as scenes are saved in binary format. The gameplay quality was really important for us, so we knew we want to use an existing engine, rather than reinvent the wheel. Why we’ve picked GodotĪs our design team decided to go with an illustrational style, we knew that we’ll be working mostly with animated sprites. Our creative team came up with an idea of an illustrated 2d platform game, interspersed with educational quizzes from time to time. It had to be educational, yet we really wanted to keep it playful and engaging for a casual player. We got commissioned to build a mobile game for an NGO. Yet, we’re not specialized in game dev - that’s a fact, nothing to be embarrassed and we think an important acknowledgement for the rest of this article. We love to tinker with different technologies, and some of us had some experience with Unreal Engine, Unity, Phaser or even Flash in good ol’ days. Let’s start with a short disclaimer - we are mainly web developers. Some time ago, our team built a mobile game.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |