3 ms·

> I am the developer of Astral Divide, which is entirely written in Go: https://store.steampowered.com/app/2597060/Astral_Divide/ https://store.steampowered.com

> I am the developer of Astral Divide, which is entirely written in Go: https://store.steampowered.com/app/2597060/Astral_Divide/ https://store.steampowered.com/app/2597060/Astral_Divide/ Your game looks great, congrats on your progress! I especially enjoyed how the zoom works when you're leaving/arrive planets, and the unique propulsion system (also, the anchor made me giggle!). > lack of data structure packages I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not. > package structure not suited for games I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seems to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their architecture? > maps are random when iterated Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=459c3f57b60fd3a0c9d024a90b9cef2e https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630 https://github.com/golang/go/issues/2630) issues. You should probably be using a b-tree if you aren't willing to sort it yourself. > modding options If you don't care about unloading https://github.com/pkujhd/goloader https://github.com/pkujhd/goloader Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero https://github.com/tetratelabs/wazero It also has a bunch of libraries for embedding scripting languages https://awesome-go.com/embeddable-scripting-languages https://awesome-go.com/embeddable-scripting-languages, with Tengo _probably_ being the quickest https://github.com/d5/tengo https://github.com/d5/tengo I'd _highly_ recommend Ebitengine in the future, as not only have there been multiple brilliant games using it, but it also has Switch/Android/iOS support, and you can find help with any issue whatsoever in their Discord. People have even built 3D games with it, and Hajime is an absolute beast of a developer.

Seb-C 3y ago
> Your game looks great, congrats on your progress! I especially enjoyed how the zoom works when you're leaving/arrive planets, and the unique propulsion system (also, the anchor made me giggle!). Thank you. Feedbacks are very much appreciated. There is still a long was until an eventual release, but it's very fun to work on it. > I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not. I had trouble finding basic structures like sets or linked lists, as much as more specific ones like R-tree, M-tree, KD-tree quad-tree or specific kinds of tries. When quickly searching on Google, there are pretty much always some results, but when looking at the details it's not that great. Most of the packages have some kind of flaw that was a deal-breaker for me. Most common ones are: - The package is something developed by one guy 4 years ago, and has pretty much no stars and is abandoned - The structure is somehow backed by the native `map`, meaning that it has the same randomized iteration order - There is some kind of logic to try to handle multi-threading, mixed-up with the data structure's logic. Often with mutexes/locks, thus killing the performance. My game is pretty much only mono-thread, and I just need something simple and that does not care about synchronization. - The structure is not generic, but only uses `interface{}` - The structure lacks tests or have unreadable code made of 1-letter variables > I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seems to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their architecture? Thanks for the reference. After looking at it, is seems to me that they are creating really tiny packages made of one or two files. I don't want my codebase to end-up with thousands of 1-file packages, it does not seem very maintainable. I want to keep having packages with clearly defined purposes and domains. > Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&editio https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630 https://github.com/golang/go/issues/2630) issues. You should probably be using a b-tree if you aren't willing to sort it yourself. I think that you didn't understand my message (or I didn't explain clearly enough). I do not need the items to be sorted, I need the iteration order to be consistent. Let's say that I insert A, B and C in a map, then want to iterate on it. I will get an unspecified order, maybe ABC, maybe CBA, maybe BAC, which does not matter to me. However, in any language, this order will be consistent across all future iterations unless the data is changed. This is a natural property of any data structure. So if I got CBA in the first loop, I will also get CBA in the second and third loops. In golang this is not the case because they actively inserted a random order. It means that even if the data does not change, I may get CBA in the first iteration, but BAC in the second, then ABC... Which created a ton of issues for me. > If you don't care about unloading https://github.com/pkujhd/goloader https://github.com/pkujhd/goloader > > Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero https://github.com/tetratelabs/wazero > > It also has a bunch of libraries for embedding scripting languages https://awesome-go.com/embeddable-scripting-languages https://awesome-go.com/embeddable-scripting-languages, with Tengo _probably_ being the quickest https://github.com/d5/tengo https://github.com/d5/tengo Yes, I noticed those packages recently. The problem is that there is little data about how reliable and maintainable goloader is going to be on the long term. As I care about performance and security, I don't want a scripting language, but WASM seems to be a very promising possibility. I have made benchmarks with 2~3 WASM engines in Go, and so far I am not completely convinced about the quality and performance of the available APIs. Also, when compiling Golang to WASM, the native compiler is still abysmally bad and does not have full support for imports, so Tinygo is a must-have. Anyway, modding is still a long term idea at this point, so hopefully the ecosystem will get more mature within a couple of years.

Seb-C 3y ago

> Your game looks great, congrats on your progress! I especially enjoyed how the zoom works when you're leaving/arrive planets, and the unique propulsion system (also, the anchor made me giggle!). Thank you. Feedbacks are very much appreciated. There is still a long was until an eventual release, but it's very fun to work on it. > I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not. I had trouble finding basic structures like sets or linked lists, as much as more specific ones like R-tree, M-tree, KD-tree quad-tree or specific kinds of tries. When quickly searching on Google, there are pretty much always some results, but when looking at the details it's not that great. Most of the packages have some kind of flaw that was a deal-breaker for me. Most common ones are: - The package is something developed by one guy 4 years ago, and has pretty much no stars and is abandoned - The structure is somehow backed by the native `map`, meaning that it has the same randomized iteration order - There is some kind of logic to try to handle multi-threading, mixed-up with the data structure's logic. Often with mutexes/locks, thus killing the performance. My game is pretty much only mono-thread, and I just need something simple and that does not care about synchronization. - The structure is not generic, but only uses `interface{}` - The structure lacks tests or have unreadable code made of 1-letter variables > I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seems to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their architecture? Thanks for the reference. After looking at it, is seems to me that they are creating really tiny packages made of one or two files. I don't want my codebase to end-up with thousands of 1-file packages, it does not seem very maintainable. I want to keep having packages with clearly defined purposes and domains. > Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&editio https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630 https://github.com/golang/go/issues/2630) issues. You should probably be using a b-tree if you aren't willing to sort it yourself. I think that you didn't understand my message (or I didn't explain clearly enough). I do not need the items to be sorted, I need the iteration order to be consistent. Let's say that I insert A, B and C in a map, then want to iterate on it. I will get an unspecified order, maybe ABC, maybe CBA, maybe BAC, which does not matter to me. However, in any language, this order will be consistent across all future iterations unless the data is changed. This is a natural property of any data structure. So if I got CBA in the first loop, I will also get CBA in the second and third loops. In golang this is not the case because they actively inserted a random order. It means that even if the data does not change, I may get CBA in the first iteration, but BAC in the second, then ABC... Which created a ton of issues for me. > If you don't care about unloading https://github.com/pkujhd/goloader https://github.com/pkujhd/goloader > > Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero https://github.com/tetratelabs/wazero > > It also has a bunch of libraries for embedding scripting languages https://awesome-go.com/embeddable-scripting-languages https://awesome-go.com/embeddable-scripting-languages, with Tengo _probably_ being the quickest https://github.com/d5/tengo https://github.com/d5/tengo Yes, I noticed those packages recently. The problem is that there is little data about how reliable and maintainable goloader is going to be on the long term. As I care about performance and security, I don't want a scripting language, but WASM seems to be a very promising possibility. I have made benchmarks with 2~3 WASM engines in Go, and so far I am not completely convinced about the quality and performance of the available APIs. Also, when compiling Golang to WASM, the native compiler is still abysmally bad and does not have full support for imports, so Tinygo is a must-have. Anyway, modding is still a long term idea at this point, so hopefully the ecosystem will get more mature within a couple of years.