Hi
I'm new to this forum. I read about nim sometime ago, but anyway I am programming languages noob and I haven't really tried nim.
Recently godot game engine (http://www.godotengine.org/) introduce a new binding API focuses to support static programming languages (fb link: https://www.facebook.com/groups/godotengine/permalink/795009643968965/). Godot uses gdscript as main script language, but some have concerns about it performance.
I'm interested to know what are your thoughs about if be nim beneficial in godot and how difficult could be to support nim in godot. Since nim is a very fast programming language and the syntax is very similar to gdscript, I think can be interesting as optional programming language for godot. But maybe, and because my lack of deep knowledge about the subject its not the case.
- This new API is meant for statically typed languages that support multi-threading, so no ruby, lua or python, etc.
- Examples of this are languages such as Java, Pascal, Haxe, TypeScript, Rust, Dart, Go, whatever.
This just in -- "MORE PROGRAMMING LANGUAGES IN GODOT, WANT TO HELP?" --
There currently is a lot of demand for additional languages, such as Java, Haxe, Swift, Object Pascal, etc. As Godot 2.2 will focus on new languages, this a great time to help us develop and improve the binding API. Of course it may seem like a challenging effort.
Officially, our supported languages for now will be GDScript, Mono, VisualScript and C++. If you want to help integrate another language, you should first of all contact us (see contact info at the bottom of the site or use IRC: #godotengine-devel on Freenode).
I think Nim would be a perfect fit for Godot. Nim already has a focus on game programming, and I think some people involved in Nim are doing 3D immersive environments, scientific visualization, etc. And Godot already has a preference for Pythonic syntax with GDScript, their default scripting language.
On a separate topic, I'd also like to quote this (from the same article):
Truth is that Mono is very well made, has excellent, modern binding extensions (the complete opposite to Java/JNI) and supports multi-threading just fine. As a result, it should integrate smoothly into Godot. The only reason we did not want to go this route in the past was due to license restrictions, but this ceased to be a problem a few months ago when Microsoft acquired Xamarin and relicensed Mono under the MIT license.
That's exactly what I was talking about when (back in 2012) I nagged Araq to s/GPL/MIT/! :D
Maybe godot should use nim intead gdscript, Like nim!
Godot is a good game engine.
From the example:
# Copyright 2017 Xored Software, Inc.
import strutils
import godot
import engine, label, resource_loader, packed_scene
gdobj FPSCounter of Label:
var lastFPS: float32
method ready*() =
setProcess(true)
method process*(delta: float64) =
let fps = getFramesPerSecond()
if int(fps * 10) != int(lastFPS * 10):
lastFPS = fps
self.text = "FPS: " & formatFloat(fps, ffDecimal, 1)
Unfortunately this binding needs a forked version of the engine. You must consider this binding as a W.I.P.
Anyway it's nice work and I hope this will be completed soon.
I try to follow instructions from the project examples
https://github.com/pragmagic/godot-nim/tree/master/examples/stub
but when I run
nake build
nakefile.nim(5, 8) Error: cannot open 'godotapigen'
Tiberium, have you experienced that ?
Hi Tiberium.
I installed godot-nim using "nimble install godot" command succesfully but with this warning.
Warning: File 'apigen.nim' inside package 'godot' is outside of the permitted namespace, should be inside a directory named 'godot' but is in a directory named 'apigen' instead. This will be an error in the future.
Nake tells my GODOT_BIN path is "invalid".
GODOT_BIN path: /home/drit0/Programmes/Godot3.0/godot-master/binEdit: Sorry I solved that but I don't know how.
That binding bloats Godot project much more than the C++ and D bindings, it's sad.
On the other hand the scripts are dramatically simpler to write than the C++ ones.
The settings need so much steps and the binding script create so much files in the project. IMHO that godot-nim thing must be reserved to convert scripts who slows down the game, so it can't replace totally GDScript (the integrated Godot language).
Who cares how many files it creates? Only what you use (import) gets compiled. C++ and D bindings have to generate the same number of classes.
"The settings need so much steps" - not sure what this refers to. If you have Nim and Godot you basically only have to install nake and set GODOT_BIN environment variable. Compare that to any other bindings.
The decisive question is how it affects your productivity. Nim is not harder to write than GDScript and it's easier to maintain in the long term due to static typing, plus it has plenty of powerful features that you can make use of, while GDScript is dead simple. So it can replace GDScript and it's a win for a large project.