Show HN: Strife, a 2D game library for Go | Hacker News Reader

Show HN: Strife, a 2D game library for Go

github.com

85 pointsfelixangell46 comments

It's great to see things happening in the Golang/2D gaming space, but having looked at your Github page and website, I have no idea what the value proposition of your framework is. There's an example featuring a text editor on the front page (how does this relate to gaming?), and nothing telling me what I'd get out of adopting Strife. Have a look at the https://phaser.io/ for an example of solid marketing around a game framework. Just below the fold, one immediately learns that the about the features the framework offers and why they should care. Also, the last commit is 3 months ago. Is the project still active?

To be honest, the project is kind of mimicking Slick2D which is a simple Java framework that introduced me into graphics programming in the first place.

My kind of dream project here is to maybe make a little tutorial series on how to use the library making a small game with it. Maybe inspire a few young people to get into graphics/game programming to show how simple it is - in the go domain specifically. The library is kind of a no thrills graphics library, maybe I should market it that way.

The project doesn't really market itself too much right now, and I don't think I will focus on that till I've written a reasonably polished game in it either. But thank you for that link I will bookmark it.

Kind of just throwing the project up on here for people to look at & critique.

And that is a point... the feature project is a text editor. Though I think it looks a bit more impressive than the alternative which is a little game I'm working on in my spare time.

The library itself is worked on from time to time. The last commit was a few days ago (a small patch however).

Honestly, I’d love to see a project like GoRails but for game programming, maybe with quarterly topics on eg making a FPS, RTS, etc. I would definitely pay a subscription for that.

you might enjoy my video series. you will probably want to skip ahead to where we set up SDL2

https://gameswithgo.org/

> Go is also flexible in that it does not enforce a particular style of programming

That’s actually kind of a main theme of Go, that it’s very opinionated about what the right way to program is, and doesn’t do you any favors if you try to use it to do things in a way it doesn’t think aligns with that.

Are you working with Phi? I'm interested in a GUI editor frontend for Vim, Kakoune/etc and the idea of using Go for the GUI sounds very interesting!

Rendering text at 60fps is a far cry from rendering a dynamic scene at 60fps.

Any examples of this being used for something non-trivial? I'm generally curious because I figured Golang would be a no-go due to the GC...

Go’s GC is extremely low latency and you can pretty easily avoid allocating using the same techniques as you would in C++.

How low latency are we talkin? 1ms , 10ms ?

Sub-millisecond STWs.

https://blog.golang.org/ismmkeynote

Thanks for this link.

Sub-1ms STW pauses, even for very large heaps.

https://blog.golang.org/ismmkeynote

Seems like it can go sub 1ms

You can't avoid allocating using the same techniques as in C++. In Go you have to know the intricacies of escape analysis to avoid allocation: objects are heap allocated "by default" and sometimes optimized to be stack allocated. In C++ there is no implicit heap allocation and usually no need for escape analysis.

As a practical example, capturing variables in a closure will usually cause them to be heap allocated in Go, but in C++ capturing has no effect on variable storage.

It seems to me that you're not really taking a charitable interpretation of GP's comment. For example, in my game development experience (granted, I'm 6 years removed from that industry) we often relied on object pools to avoid allocation. You don't need to know anything about Go's escape analysis to use a pool to avoid allocation, as far as I can tell. Could you explain your position further?

Go language constructs allocate in ways that are not immediately obvious. So using object pools is not sufficient to avoid allocation in Go as compared to, say, C++.

In my view (which is the dominant view among compiler engineers for GC'd languages), spending a lot of effort to avoid allocation is a poor use of programmer time in a GC'd language. It is better to just improve the GC to make allocation fast. In a properly designed generational GC like that of Java HotSpot, allocation is about 5 instructions. That is a game changer: allocation is as cheap as a function call plus the prologue.

Unfortunately, Go's designers have so far not deployed generational GC, which is why we keep having these threads about avoiding allocation. (I've seen indications in the last couple of weeks that Go may finally be moving to a generational GC, though, and I hope they do.)

Anyone doing HTML 5/Flash like games in Go doesn't need to worry like if they are writting the next Fortnight in Vulkan.

This is why I've been careful to say "CPU-intensive workloads" and not "games", because not all games are CPU-intensive workloads.

Ah, sorry I missed it.

Then I fully agree with you.

You weren't careful to say it in this subthread though. I had a whole response written up to talk about how you're being completely unreasonable with regards to most gaming projects before I saw this clarification. Now all that effort is wasted! ;)

You’re splitting hairs. Yes, you need to reason about escape analysis. This is pretty easy, especially since the compiler will tell you when things escape. It’s certainly easier than... well, pretty much anything in C++. :)

>? I'm generally curious because I figured Golang would be a no-go due to the GC...

Huh? Tons of GC languages are used for games. Heck, web games use JS. Not to mention the whole C#/Unity thing that even powers AAA games...

Yeah that's true but I disagree it's a good idea. Most AAA shops still use non-GC languages because they need the full control/cannot waste ms on random GC pass.

Game dev here. Unless you are making GTA or some high fidelity 3D game. You are wasting your time using a language like C++. You are going to spend more time dealing with memory than actually making your game which is pointless in a 2D game.

Yep. I'm always more curious about how I can get back milliseconds based on 2D rendering techniques and GPU-related concerns. I'm almost never thinking about memory consumption. It's always stunningly low, even for games doing a ton of things.

You'd almost truly have to go out of your way to consume browser-levels of memory.

If they use Unreal, they are using C++ with GC.

Once you get past a certain point of developing a complex game in Unity, one of the optimization techniques is to keep runtime allocations at 0 bytes in order to prevent a GC pause from ever happening. This was a huge pain back when Unity was on Mono 2.10.8 (released Dec 2011) but it's a bit better now.

It's a fight against the GC typically

Unfamiliar with any game codebases or much C++, but I know in C we'd do zero-allocation or controlled arena allocation for "embedded" uses. I'd imagine Allocation tuning is always present. Was it much harder in C#?

.NET has support for stack allocation and manual management of native memory.

Many forget that MSIL is rich enough to support C++, initially via Managed C++, later replaced by C++/CLI.

The major features in C# 7.3 are related to slices, improved stack allocation and reducing copies of value types.

>Once you get past a certain point of developing a complex game in Unity, one of the optimization techniques is to keep runtime allocations at 0 bytes in order to prevent a GC pause from ever happening.

It is, but it's still an option. It's not like "language with GC" == no-go for games, as the parent implied.

Just like it is a fight against malloc() if the game's architecture is not done properly.

No idea why this is getting downvoted. You'll naturally need more control over memory when building AAA high-performance 3D games, but there's tons of great 2D games made with GC languages (see: Love2D, OpenFL, HaxeFlixel, ImpactJS, Unity).

In a lot of 2D games, simple patterns like object pooling are more than enough to squash any GC problems. There's a whole spectrum of performance requirements out there -- no need to discount a framework due to it's language.

Interestingly enough, many times GC tricks like object pooling aren't even the first concern; it's usually proper utilization of GPU buffers and understanding pixel fill-rate more than anything.

It's truly wonderful time for all programming languages in this space.

The biggest problem with doing CPU-intensive work in Go is not the latency of the GC but rather the lack of maturity of the optimization pipeline compared to GCC and LLVM, the lack of good support for things like SIMD, the relatively poor throughput of the GC, the large overhead of cgo (which matters quite a lot for graphics!), etc.

I didn’t realise that Go didn’t use LLVM when Swift a much complex language uses it. Is there any specific reason for Go not using LLVM.

fast compile times is a core value for Go would be one reason.

The Go FAQ says they are working on it, and they mention the difficultly making some changes from C conventions leading them to not use it initially. https://golang.org/doc/faq#What_compiler_technology_is_used_...

The reason the Go developers cited is fast compile times, as well as the belief that LLVM is "too big". I don't agree with these: LLVM compile times are fine for ahead-of-time compilation, and LLVM is big because it does important things.

I do have mixed feelings about LLVM for safe GC'd languages, though. LLVM is full of undefined behavior, and its support for precise moving tracing GC is not widely used. So I can definitely sympathize with not wanting to use LLVM for Go, but not for the reasons they cited.

>LLVM compile times are fine

What constitutes 'fine' depends on workflow, size of project, machine horsepower, and personal preference. Some projects require a bit more compile -> experiment -> change -> compile -> experiment -> change than others.

I would recommend a language with a repl for that kind of project

Its my understanding that the throughput was intentionally sacrificed for low GC pause times.

Correct. That is not the decision I would have made, and it's especially relevant for CPU-intensive workloads.

The current Go is great for writing a 60fps game server. The pauses are very low, and the qualities that make it great for a server also make it great for a game server.

I'm close to implementing hot code update -- in my Go game servers!

Unreal and Unity use a GC.

It is a matter how it gets used, not that it is present.

For a 2d game engine like this, there's no problem with a GC based language, people write 60fps 2d games in lua/python (which Go easily outperforms), C# and even 3d games like Minecraft in Java.

Weird that the example they chose to show is a text editor

Reply on news.ycombinator.com