I would like to make a 2D game with Nim, but I can't find any game library with documentation or recently updated, can you suggest me one ?
Thank you
I've had good experiences with SFML via the csfml wrapper: https://github.com/oprypin/nim-csfml
It may need some updates and you need to be comfortable using the SFML docs and applying them to Nim.
TL;DR: It's not that hard to develop custom framework for simple 2D games in Nim.
Well, I'm new to Nim, and to game programming (and game frameworks / libraries), yet two weeks ago I had been working on some old game remake for a month. (Then I had to stop with this pet-project of mine, since I got other work to do for living.) I can share my experience for benefit of all interested.
I had started with Lua (Love2D), and the development was fast, yet I was unable to hide my code. I didn't want somebody take my code and change it to be something different than I wanted it to be. So I started to look for alternative technologies (especially for the statically typed, and compiled).
At first, I looked at Haxe (many frameworks, focused on game development) - but I was unable to compile even simple examples on my Linux machine. I gave it up.
Then I tried Go. I used a custom Docker image, with SDL2 and its bindings for Go. It worked, and I was quite happy with the build tools. I hadn't used any framework, I had built my own, simple one, within just two days.
There were only two problems: (1) the language was too simple (e.g. lack of enums, I used constants instead, but it felt like a hack, not a real solution), and (2) the executable binary size was really huge.
The first problem was more important, since I don't care too much about the binary size, yet the simple comparison between Go and Nim for SDL2 "hello, world" is MBs vs KBs. If Go produces so large binaries, then what about the memory consumption? (Besides, come on - it's and old 8-bit game remake, it should be as small, as possible!)
So I had tried Nim. I also used my custom Docker image. I can point out the following differences between Go and Nim:
1a. I find the lack of built-in hash tables in Nim a disadvantage. For a language that should appeal to Python programmers... (Go is sometimes referred as a Python replacement, and it has maps!)
1b. Also importing everything into main namespace feels a little odd (at least for me). Of course, I use "from ... import nil", but it feels not very Nim-style, and then I cannot use overloaded operators. But for me, it's worth the price of having more control over my namespace.
1c. And I LOVE whitespace indentation!
2. The Nim docs are out-of-sync with the Nim's Docker images. I use the latest Nim (0.19.4?), and the docs on the website are (I suppose) for the next version, since there are functions, which I haven't found in the Nim's source code for the latest version. Where are docs for 0.19.4?
The docs is something, that should be fixed as soon as possible. Go is MUCH more developed in this crucial field.
All in all, there are many areas, in which Nim is behind Go. Yet for a simple project (like a retro game remake), developed by a single person, it can be used and provides more power for programmer. And development of a simple game framework is not a big deal. (Of course, it all depends on the kind of game...)
1a. I find the lack of built-in hash tables in Nim a disadvantage.
https://nim-lang.org/docs/tables.html eh?
the docs for stable version are here https://nim-lang.org/documentation.html
3. Also the Nim's SDL2 bindings API is very inconsistent, in comparison to Go's SDL2 bindings API.
you could take a look at other bindings, that are actively maintained https://github.com/Vladar4/sdl2_nim
I can only hope, that it take so long only for the first time.
Ridiculous, in comparison to both Go (1-2MB) and Nim (100k).
I'm not sure, whether it uses static, or dynamic linking, though.
It's a module, not a built-in datatype.
In both Python, and Go, I don't have to import anything, when I want use dictionaries/maps.
A really minor flaw, IMO.
you could take a look at other bindings (...)
After a (really) quick look: it seems to have a more consistent API. Thanks.
(Why the heck two diffferent bindings??? ;-))
And Nim lacks the build tools, available for every Go programmer.
What tools?
1a. I find the lack of built-in hash tables in Nim a disadvantage.
Can you explain that? There are advantages of course for not making hash tables a compiler builtin, for example it would make the compiler more complex, separate modules let us choice different implementations. I do not see the disadvantages, but there may exists some. I hope you do not consider "import tables" as one?
1b. Also importing everything into main namespace feels a little odd
Have you had serious problems with that? I could indeed imagine that problems occur for projects with some millions of lines of code, so I would like to see such large Nim projects, or at least hear experiences with such large projects. Do you have created one already?
4. And Nim lacks the build tools, available for every Go programmer.
What is your concrete problem with Nim built?
I've had good experiences with SFML via the csfml wrapper
I'm surprised to hear that, because my experience with it hasn't been great. Maybe it's just me being a complete noob, but I keep having to wrap the library's procs to abstract unnecessary type castings (to and from cint, for example) that could be abstracted by it by default. I also feel like I have to be careful here and there to avoid naming collisions.
Not mentioning having to manually destroy pointers all over the place...
Also that it deviates from the original naming conventions makes it rather annoying to figure out. I know my way around the original SFML. To be fair, I could be using vscode, which would make my life easier on that, but my potato has too little memory to run it properly... :(
Godot is probably the best 100% free game engine overall. It has 2D support (now with "pseudo-3d"). There are Nim bindings.
They're quite outdated unfortunately. But aren't they bindings for native scripts, though? (Rather than direct replacement for GDScript.)
Yeah, it's definitely not perfect and indeed the deviation from original naming conventions was my number one annoyance too (would love to fix that if I had the time). Getting rid of the need to destroy pointers manually should now be possible with Nim's better destructors and/or ARC (but at the time it wasn't possible to make it better).
The main reason I said I had a good experience is because I managed to finish a Ludum Dare game with it. :)
@Libman @wittygat
Actually I'll have to correct my previous statement about godot-nim bindings, they actually do seem to work with the latest godot without issues. I just tried it and successfully compiled godot-nim-stub with godot 3.2 rc1. Everything worked properly.