Dunno, I find that no matter what language I code in, the dominant effect is that I get better at coding as a whole. It's not the coding in a different language that lets skills in another deteriorate, it's the lack of practice. Anyway, Godot Script is so easy and inoffensive that I doubt it makes anyone unlearn anything.
Regarding Unreal, yeah, no doubt it's the technically most advanced solution available without forking over huge amounts of cache, probably even without that qualifier. This comes with a bunch of prices, however:
- System requirements for development are prohibitive (Just about what I have).
- Minimum download size of the end product is huge (some 100 MB).
- The renderer does not scale back well at all to weaker hardware.
And the fact that it's not really considered open source means that nothing made with it will ever find its way onto Linux installation disks, historically a big source of users for us.
I finished my week-and-a-bit with Godot experiment. Here's what I got, a proof of concept Tron game with one cycle, not even AI enemies and very, very rough all around. My favorite thing is that you can still control the orientation of the explosion. Yeah, I said I wanted to do a different primitive game first, but I've been using lightcycles to learn new programming environments for almost 30 years now, I'm too old to stop
Source is here:
https://code.launchpad.net/~z-man/+junk/godot_tron_test
Latest builds here:
http://vps-zman.armagetronad.org/~manue ... _tron_test
Mac build untested. Android version has reduced visual quality so it can run with 60 FPS on my devices.
Evidently, it's only got the bare minimum stuff. I wanted to find out how hard the engine is to use, and the answer to that is: not hard at all. Simple things can usually be done in a single line of script. Clobbering together the main menu (layout possibilities, even just the positioning, far from exhausted): click together buttons, click on button press event, click OK, fill in code that should execute. Moving the cycle forward is literally just "cycle.translate(Vector3(0,0,step))". Yeah, like everyone else, they put the y axis up... Oh well. Scripts are all short, pretty much all single pagers. The raycast that checks for collision of the cycle with walls is an object in the scene that gets polled automatically every frame, the cycle code or anyone else interested can just fetch the results. The explosion effect is entirely done without code, just the animation system. The signal system allows for great modularization. In a full game, for example, the cycle would emit a signal when it is destroyed. The game mode code would listen to that and trigger a respawn or check win conditions, on a win, it would emit a 'round end' signal. The match management code would listen to that, etc. Here, I abuse it
The explosion animation end signal is what triggers the return to the main menu, and I extended the animation over the natural length to get an extra delay. Bad Z-Man.
It's fun to work with. It's extremely tempting to add just one more thing. For example, I wanted to leave out the collisions and just check the graphics, but it was just so easy... and then, of course, I had to add the explosions. And the primitive control flow. The documentation is good; it's been used enough so that, for example, entering "screen width in Godot" in Google gives you meaningful results.
There was a magic moment. A scipt was referencing a scene tree node via some relative path. I moved the node around, then wanted to adapt the path to the new location.... only to find that had already happened automatically.
Performance of the script is all right. I did a primitive benchmark, it came in between 100% Python speed (just int calculations) to 50% python speed (function calls dominate). C++ on the same problem has 50000% Python speed, of course. Its fine as long as you keep all per-frame actions in C++. Which I have not done here, I wanted easily publishable builds with the pre-built templates.
Graphical effects: It's got bloom and HDR. The bloom looks a bit aliasy to me, maybe it's done on a lower resolution buffer. With tweaked art, it'll be fine. The cycle shadow is real (shadow mapping); it'll look better in Godot 2.2, I already verified that from current GIT sources. Maybe good enough to enable trail shadows. The headlight tests dynamic lights, they work well. I could not find the right parameters to make it cast proper shadows, though.
All in all, it's not stellar, does not come close to Unreal or Unity. It would suffice, however. Much better than what we have now, at least it would support proper materials with emission and diffuse components, so cycles with pretty glowing lines. And we could get rid of code driven graphics. There's a bit left here, the trail is done with hardcoded immediate mode geometry. Better would be to take a template wall and stretch it to the right length.
Oh, null checks are done automatically in debug mode, they cause breaks. In release mode, the script tries to hobble on and just does nothing. Probably all right for games.
It's not all sunshine. The editor is also basically a Godot game, it runs in a single window only, making it hard to make good use of a multi-monitor setup, You can't view the scene and edit scripts at the same time. It's possible to start the game fixed on a monitor of your choice, at least. The editor has a quirk I find hard to get used to: When you open a vector for editing, edit a couple of values, then click outside, it counts as undo and the entered values are lost. You really have to press enter to commit. File dialogs often open in directories that make no sense. Import formats are limited. The right mouse button does nothing in the 3D view, it could be used for panning, for example.
But yeah, overall, it's quite good. Certainly the best single open source game creation tool I've ever seen.