Selecting a development environment
My decision making
The title speaks for itself, but this post is associated to my initial introduction post.
^ In that article, I state that I made a conscious decision to select the Godot Engine software to develop with. Why?
For the past 8 years, my core development experience has been Java based. Although the language is capable of cross-platform development and allows for modern games to be written; yes, there are some great 3D games in Java being developed, you only need to watch ThinMatrix's brilliant series on his wonderful 3D world, for a GREAT example. For me, it is too cumbersome for what I want to create. Further, it doesn't lend itself to mobile devices; which is one of my focus areas.
What were my requirements?
- Must have 2D and 3D capabilities; however, 2D is my initial focus
- Must have a development language/script that is easy to understand and conforms to an established programming language, i.e. Java, Python or C
- Must have the capability to export to Mobile (iOS & Android), PC, Mac, Linux and Web (for Facebook)
- Must have a strong technical community as well as a good availability of resources
- Should be light weight and easy to understand
- Should have a strong focus towards Object Orientated implementation (i.e. inheritance, encapsulation, etc)
- Should have installs for Linux or Mac, if I find myself switching O/S platform for development
- Should be unrestrictive in publishing to different devices, i.e. develop once, deploy many
- Should be as in-expensive as possible
Given this comprehensive set of MoSCoW requirements, I set about testing and trialing many different development tools/engines.
Those downloaded were (in specific order):
NOTE: the following are my personal views, formed from trial and errors. These are not provided to tell you which is or isn't the best game development environment. Please conduct your own research! My requirements led to the final selection.
Game Maker Studio was an interesting product to test. Within only a few days of testing, I felt that I could produce something really fast. It was engaging and interesting to use. It had its own unique scripting language and implemented elements as 'objects' with properties. It looked well designed and documented. However, the more I used it, the more frustrated I got. Further to this, I was always aware that the deployed game ran in a 'game engine' and the code interpreted on the particular device. Overall, I felt it didn't offer what I was looking for.
I then tried AGK, which felt somehow familiar. In fact, anyone who has ever used Blitz Basic on the Amiga or PC will get that feeling instantly with its Basic. For a tool, it provided a rapid capability to generate 2D games. It was fun and I managed to get deployments to Android with little problem. However, it felt under powered in capabilities for my needs. The deployment, again, was to a runtime engine with your compiled App on top. My concern was that I knew I would want to access native operations on devices and this engine would not lend itself to that unrecorded requirement (i.e. camera for AR etc).
Next came Unity. Simply WOW! It provides a massive set of capability, all in glorious 3D. It has a great community and a large set of available resources. It features a wealth of options that actually started to put me off ('how am I going to learn that' scary). Even though I'm proficient with C and Javacript, the vast scale of option boxes scared the hell out of me (just being honest). I could see how powerful it was, but I would have to invest a lot of my time to master it. Further to this, at the time, the cost of exports were extremely prohibitive (in my view) and that there were different licensing models based on how successful your game/group become (to me, this just didn't feel right). Yes, charge by the seat, but not based on successful sales. I believe the product licensing and charging has changed dramatically since, so I do intend to revisit the engine. The final nail in the coffin at the time, for me, was the fact that I wanted to primarily develop a 2D game. In Unity, you actually create a 3D world and then project a 2D viewpoint. This does makes sense to me, but seemed like a waste of capability, especially when deployed to small devices, i.e. forcing a view that wasn't natural; although that does lend itself for the resolution rescaling problem!
After Unity, I found myself scratching my head for a few weeks, weighing up the distinct possiblity of me developing with a native set-up, i.e. using C++ with a multi-platform strategy. This felt and smelt wrong, I knew there would be a solution, I just needed to find it. So in the meantime, I briefly investigated HTML engines.
The main HTML engine I remember testing (there were a few really crap ones!), was Construct 2. This I enjoyed playing with. I could create things quickly; in fact my daughter was learning Scratch at the time and the two had a simliar feel with its scripting.
Whilst playing with Construct 2, I remember stumbling on an annoucement of an Open Source Engine known as Godot Engine. I HAD seen it in a list of search results weeks before, but had ignored it, due to its name.
As soon as I downloaded and the editor popped up, I felt at home. It uses a 'Scene' and 'Tree' design structure that fits with my way of thinking. It has a scripting language that integrates extremely well with all its capabilities. However, what I liked most, was its potential.
The engine is truly open source, allowing the community to create plugin's for new features, such as AR and native access to devices. It also allows developers to code in many different languages under the scripted engine layer.
The script is based on a Python syntax format and is extremely easy to learn, code and debug.
The engine provides cross platform deployment capabilities, for which certain environments export native code for compiling with (i.e. iOS requires the developer to move the code and compile as a native app on the destination hardware, i.e. Mac; I personally love this, as the true power of the device can be realised).
The engine also contains a strong 2D and 3D engine, which is segregated in its tooling, which helps immensely. Although I was primarily interested in 2D, the 3D demonstrations were stunning.
I downloaded and still use version 2.1.4, which is a single exe file for the environment! No install, no registry information. Click and use. Exporting to different devices requires additional environmental packs to be downloaded and configured, but that's expected for a tool that can be expanded as required.
As of writing, a new v3 is nearing the end of Beta testing. It expands on most of the excellent capabilites. The highlights for me are the additional improvements in the 3D capabilities, expansion in support languages and web browser assembly language support; which should see a massive improvement in Web Browser speed. They have also implemented a Visual Scripting tool that looks exciting. I've ignored v3, as I don't want to be distracted by new features.
Overall, this is why I have stuck with Godot Engine. I'm sure Unity is probably a more capable engine, but for me, the ease and simplicity of Godot Engine won out.
As stated above, these are my views. I have written this, NOT to persuade anyone, but to answer the question: Why are you only providing Godot Engine tutorials.