Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–48 of 48 posts

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

#41

Post by sephware »

gameswithgo wrote: post #20
ezekg wrote: post #18

Earlier quoted context omitted.

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.

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

#42

Post by andrewmcwatters »

greysonp wrote: post #28
coldtea wrote: post #11

Earlier quoted context omitted.

> ? 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...

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…

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.

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

#43

Post by andrewmcwatters »

BoysenberryPi wrote: post #14
crowhack wrote: post #12

Earlier quoted context omitted.

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.

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

#44

Post by nullstyle »

pcwalton wrote: post #37
pjmlp wrote: post #35

Earlier quoted context omitted.

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.

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! ;)

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

#45

Post by polityagent »

gameswithgo wrote: post #25
pcwalton wrote: post #24

Earlier quoted context omitted.

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 d…

>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

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

#46

Post by weberc2 »

pcwalton wrote: post #13
weberc2 wrote: post #5

Earlier quoted context omitted.

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

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…

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++. :)

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

#47

Post by asdkhadsj »

felixangell wrote: post #3
tmountain wrote: post #2

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 ga…

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…

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!
Post reply on HN