8 ms·
Making games in Go for absolute beginners
- penguinpower 3y ago[dead]
- kubanczyk 3y agoBased on ebitengine. To fix: a hanging sentence "Here’s how an example Sprite component can look like"
- gigafuture 3y agoGreat tutorial. I really enjoyed it and saved it for later.
- NAHWheatCracker 3y agoI've been working on a game over the past year in Go using https://github.com/g3n/engine https://github.com/g3n/engine. I picked Go because I like the language and wanted to learn it. I picked g3n-engine because I wanted to work in 3d after making a few 2d games in the past. Making games is so much more challenging and rewarding than almost all of the work I've done for pay. There's always so much more to learn that doesn't feel like just relearning how to do the same thing except with a different framework of the week.
- mrintegrity 3y agoThis is great, the dificulty goes up rapidly. I only got to level 3 before quickly dying (playing on mobile Firefox)
- satellite2 3y agoIt's really a nice project. It's really too bad that it doesn't compile for mobiles. It's the one point preventing large adoption of go as a gaming language I think. I haven't found a 3d lib that supports building for mobiles. And it's really too bad, because go would be perfect for writing games.
- uka 3y agoDoing a game with ebitengine myself. Refreshingly nice experience.
- dimgl 3y agoI always wondered if Go would be a good language to make a game in due to its concept of goroutines. Maybe one of these days I’ll give it a shot.
- cdogl 3y agoUnfortunately, garbage-collected languages have historically not been great for real-time action games. Throughput and performance can be excellent, but without control over the garbage collector pauses can wreck the experience. For any game that doesn't require smooth frames for the experience, the best language is the one you're most comfortable with (modulo some base level of game dev community) Edit: on the other hand, Go is a superb candidate for a back-end game server. I'd say the same goes for the network client layer, but the language interop story is not ideal.
- pjmlp 3y agoDidn't stop Notch to become rich, even with some hiccups.
- beautron 3y agoI'm making a game in Go, and it runs perfectly smooth on my 240hz monitor (and should run perfectly smooth on 1000hz monitors once we get there). The garbage collector has not been an issue, because I use memory the same way as if I were doing it in the C language: Allocate all memory used by the game at program launch. I find this scheme easier to work with in Go than in C, because Go's slice type is a natural fit for partitioning these launch-allocated blocks of memory (as they get used and reused during the game). The garbage collector doesn't get called if you don't allocate. And for the most part¹, it's easy to reason about where Go allocates (if you know C). So my rule is: Always know where your memory is; never allocate. This may sound like it's going against the grain of Go, but I find Go to be handily amenable to this style. I had my concerns going in, but it just hasn't been a problem. My game runs silky smooth. At this point, my only concern about using Go to make a game is that bringing the game to consoles does not have a well-trodden path. ¹ So far, the only thing that has surprised me is that assigning a value type (like an int) to an interface allocates! (So another rule is to only assign pointers to interfaces [pointers to memory allocated at launch].) And while this was a surprise to me, I was pleased with how quick the debugging went: I noticed frames were dropping, so I ran go's pprof tool, which led me directly to the (freshly coded) interface assignment that was stealth allocating. (Also, this allocation becomes less surprising the more I think about how interfaces are implemented.)
- asda22sdasd 3y agoWhile ebiten is fun, it absolutely will be limiting for your larger project. Consider options and research properly before choosing tech. In the case of ebiten + golang, you will suffer greatly from the FFI overhead when calling external graphics API:s.
- nehal3m 3y agoBeware the factory factory factory. https://factoryfactoryfactory.net/ https://factoryfactoryfactory.net/
- deleted 3y ago[deleted]
- endofreach 3y agoas much as i hate the overhead of frameworks & all the tooling that is (seemingly) required for simple things nowadays, the analogy that is attempted to be made, doesn't really fit well. The author seems to have been too focused on writing a "classic analogy" that has it's own URL rather than writing a good & fitting one for the case he/she dislikes – and especially, putting real thought into the analogy to make it a really good one.
- LegibleCrimson 3y ago> The author seems to have been too focused on writing a "classic analogy" that has it's own URL That doesn't track, given the sources at the beginning. One person wrote the essay, then somebody else started hosting it at that URL. There doesn't seem to be a direct connection between the writer and the URL at all.
- Thaxll 3y agoThis is not true, for 2d game the performance of Ebiten is good, you don't suffer from ffi. Some games have been shiped on that engine, even running on the Nintendo switch.
- 3y ago
- nikki93 3y agoNice! Ebiten is a super nice API for Go. Lots there to be inspired by in API design. Another API I like a lot is Love for Lua (which also actually can be used from C++). Re: the comments on here about the GC etc. -- I've posted about this a couple times before but I've been using a custom Go (subset / some changes) -> C++ compiler for hobby gamedev, which helps with perf, gives access to C/C++ APIs (I've been using Raylib and physics engines etc.) and also especially has good perf in WebAssembly. Another nice thing is you can add in some reflection / metaprogramming stuff for eg. serializing structs or inspector UI for game entity properties. I was briefly experimenting with generating GLSL from Go code too so you can write shaders in Go and pass data to them with shared structs etc. The compiler: https://github.com/nikki93/gx https://github.com/nikki93/gx (it uses the Go parser and semantic analysis phases from the standard library so all it has to do is output C++) (it's a subset / different from regular Go -- no coroutines, no GC; just supporting what I've needed in practice -- typechecks as regular Go so editor autocomplete works etc.) A game made with it a while ago for raylib game jam along with the raylib bindings and other engine stuff: https://github.com/nikki93/raylib-5k https://github.com/nikki93/raylib-5k Very old video of a longer term game project I'm using it on which also shows state-preserving reload on rebuilds and also the editor inspector UI: https://youtu.be/8He97Sl9iy0?si=IJaO0wegyu-nzDRm https://youtu.be/8He97Sl9iy0?si=IJaO0wegyu-nzDRm (you can see it reload preserving state across null pointer crashes too...)
- tjpnz 3y agoIs size still an issue with Go if you wanted to compile to WASM and target the browser?
- pjmlp 3y agoIf the browser is the main target, I would just use browser native engines like Pixijs.
- angra_mainyu 3y agoshout out to babylon.js, incredibly good 3d game engine for the browser
- pjmlp 3y agoDefinitely, my example was for 2D games. Currently the one with best WebGPU support.
- Narishma 3y agoWhat would a 2D game need WebGPU for?
- angra_mainyu 3y agoPlenty of 2D games are actually in 3D rendered to a flat "2D" representation. Also, shaders are a thing in 2D games.
- Narishma 3y agoOk but you don't need WebGPU for those things, WebGL should be fine.
- pjmlp 3y agoBabylonJS is not for 2D games, read the thread properly.
- angra_mainyu 3y agoI've used raylib-go (raylib bindings for Go) and ebiten. Both are excellent libraries. Personally I tend to use raylib-go much more, as it can readily supports 3D and has a strong community around it.
- Kiro 3y agoThis is great. I feel it's missing something about delta time though.
- m110 3y agoThanks! I had a paragraph about delta time but since Ebitengine works based on the TPS, I eventually decided to drop it to not make it confusing. Here's a good summary, I think I'll link it in my post: https://ebitencookbook.vercel.app/blog/2022/04/16/TPS https://ebitencookbook.vercel.app/blog/2022/04/16/TPS
- susam 3y agoWhile writing games in any programming language is a very rewarding experience, I have found HTML5 Canvas and JavaScript to be very effective for writing games as absolute beginners too. If sound is needed, there is Web Audio too, all available right within the web browser. It is quite possible to write simple games without using any external JS libraries by sticking to first principles only, e.g., drawing simple shapes with fillRect(), simple collision detection algorithms, generating simple tones using OscillatorNode, etc. Here is one such game I wrote sometime back: https://susam.net/invaders.html https://susam.net/invaders.html Also, if the entire game is written as a single HTML file, the game becomes immediately distributable too. All one needs to do is host the HTML file somewhere or send the file to someone in order to share the game.
- klabb3 3y agoSeconded! Especially if you only have keyboard controls. Once you have mouse events there is no mapping between mouse position and an object in game, which makes it a bit harder. If so, you may wanna use svg. It makes it easy to handle mouse events, rendering is “free” and you can also do smooth animations with CSS. The main downside imo is that svg has more browser inconsistencies for some reason. Example: https://loz.payload.app/ https://loz.payload.app/
- deleted 3y ago[deleted]
- marcosdumay 3y agoThe web is becoming a really good OS. We just need make web assembly better for higher level languages, because neither javascript not rust are an end-all great language for small games.
- capl 3y agoI am a fan of Go due to the focus on simplicity in the language... but why Go for game dev? The purpose of the language was to tackle backend services previously written in C++ focusing on junior developers, not game dev. It's not really a popular tool for the job: Python, which is a simpler language, has a much larger community of gamedev noobs. Or maybe better yet: start with Godot and GDScript
- susam 3y ago> ... but why Go for game dev? The purpose of the language was to tackle backend services previously written in C++ focusing on junior developers, not game dev. I'd say using any language for game development should be embraced, not discouraged. Imagine if William Crowther had thought, "Why Fortran for game development? The purpose of the language is to tackle scientific computing." Thankfully, he did not think like that. All Crowther had with him was PDP-10, Fortran, a teletype that probably looked like https://en.wikipedia.org/wiki/File:ASR-33_at_CHM.agr.jpg https://en.wikipedia.org/wiki/File:ASR-33_at_CHM.agr.jpg, some sheets of paper, and a sense of fun! Without being bothered about what these tools were really meant for, he went ahead and developed Colossal Cave Adventure thereby introducing the genre of text-based adventure games into the field of computing. A player had to type their input into the teletypewriter and wait for the computer to print the output on, well, physical paper! Still it was fun. It is nice to have fun and write games with whatever technology we have got.
- corethree 3y ago[flagged]
- deleted 3y ago[deleted]
- veqq 3y ago> Python, which is a simpler language This seems crazy to me. How so?
- deleted 3y ago
- appstorelottery 3y agoI tend to write fireworks or simple particle simulations in a new language / graphics api to test for performance as my first step (aka learning how to place a pixel on the screen, double buffer or whatever, do some simple logic / math, and learn the compilation pipeline). It's always a fun task and an easy benchmark: how many pixels can I move per frame? I did this in 2021 in GO and Ebitengine and I was blown away by the performance the screen was mostly white with pixels, how easy it was to get the context running, and how many pixels I could move on the screen at 60fps... I was truly impressed. I've been using this approach for the last 30 years I guess ;-) We're a long way from moving a few hundred pixels on a 16 bit CPU per frame... greybeard out
- giancarlostoro 3y agoI always do a web project because it typically shows you language features that you wont see in "Hello World". It also shows me what the database drivers look like, if its painful to setup, and all that fun stuff.
- mamcx 3y agoI do the same, but different kinds of projects exercise different stacks. A web project does not prepare you for a bad UI history, for example...
- canadianfella 3y ago[dead]
- JoeyJoJoJr 3y agoI also created a performance test with Ebitengine, like I have done for many 2d engines/rendering libraries in the past. Typically I like to test performance with the web/WASM target. More often than not, even just a few rotating sprites will result in some dropped frames. I was extremely surprised at just how insanely smooth Ebitengine performed. For my purposes it was the second most performant engine/rendering library, second only to Kha. Being new to Go I was also blown away how simple it was to just copy memory around and create Braid-like time travel, as well as the exceptionally simple build process. Rust and Bevy get a lot of mentions on Hacker News, but I think Go and Ebitengine will be my next choice to build my next game.
- tslocum 3y agoI have been a happy user of Ebitengine for several years. If you are interested in seeing the source of some games created with it, check out the awesome-ebitengine list. https://github.com/sedyh/awesome-ebitengine https://github.com/sedyh/awesome-ebitengine All of the games listed on my itch.io profile were created using Ebitengine, and they are all open source. https://rocketnine.itch.io https://rocketnine.itch.io
- rTX5CMRXIfFG 3y agoI’m going to react just to the first part of the article since the rest isn’t really of interest to me. If you’re experiencing the kind of burnout that the author described, I’d suggest an alternative to doubling down and “reclaiming” your hobby: make your interests evolve. It could very well be your body (specifically your brain) telling you that you’re stagnating. It doesn’t have to be different getting programming, but perhaps you’ve reached a point that it is time to go deeper, possibly into CS theory.
- its_kenta 3y agoNot a Go dev, but a long time viewer of one YouTuber/Twitch streamer that makes his games in Go for a long while now. He's creating a small MMO in Go which you can test out here: https://mythfall.com https://mythfall.com UnitOfTime is his YT & Twitch handle https://www.youtube.com/@UnitOfTimeYT https://www.youtube.com/@UnitOfTimeYT Uses his own binding to OpenGL and WASM to WebGL2 for Web version. Used to use Go myself, but fell out with it. But I can understand why people would enjoy making games with it. Just like SolarLune himself uses Golang for his gamedev. A lot of people seem to ask the same question tho: "Why make it in Go? Doesn't it have GC?" From my understanding Go's GC is quite robust as well. In a nutshell, nice to see Go having more usage outside the norm that devs expect it to only be used in.
- Seb-C 3y agoNice to see such a topic come up. 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/ When I started two years ago, I basically had to choose a language and a package/framework, so I'd like to share my experience about it. First, about the package, there are two major ones for 2D games, which are Ebiten(gine) and Pixel. I initially chose Pixel, because it seemed more documented at the time and had a bigger community. Overall, it was good as long as the game was simple, but unfortunately I regretted this choice later. Don't get me wrong, I am not here to discredit the author, because there is a phenomenal amount of open source work that was done, and I am thankful for it. But as my game grew more complex, the engine started to cause big architectural challenges, memory leaks (it does not correctly garbage collect OpenGL's objects for example), and it's multi-threading model is flawed. I also discovered that it was in fact not maintained. Overall it lacks too much maturity for a serious game. In the end, I decided to ditch it, because it was easier, and my proposals for help on GitHub never got any answer. It took some effort, but having my own engine based on OpenGL was the best choice in this case. When it comes to Ebiten, I have only used the sound library called Oto, but overall my opinion of the whole package now is that it is well maintained and architected. Now when it comes to choosing a language, I hesitated between: - Go, which I had a lot of experience with and seemed good enough, even if the typing system is a bit too weak - Rust, which I was (and still is) interested in, but had no experience, and unsure if it was worth it in terms of productivity (because of the additional time spent on worrying code, and the compilation time itself). Also, it didn't have game engines which seemed as mature as in Go at this time (I wish I had known that I would end-up with my own engine). - C++, which is the industry standard, but on which I have very limited experience. Also, I just didn't want to bother with the header files and the compilation stack. I chose Go, and too be honest it is a choice that I now regret, but also I have to live with it because I cannot afford a rewrite at this point. Go certainly had a lot of productivity benefits, but also major flaws when it comes to game development: - The lack of packages related to data structures. In games, we need a lot of specific sets, trees, queues, tries and maps, but those are almost non existent in Go. The best one is "gods", which still does not support generics. Overall it is always difficult to find quality and experienced packages, even for broadly used and fundamental algorithms. - The fact that dependency cycles are handled on a package basis, and not per-class or per-file. This is a major source of headaches for video games, because contrarily to web servers, there are not a limited number of predefined layers: everything needs to depend on almost everything else, and Go makes it even worse in this case. - The lack of data structures is made even worse by the native map, because it forcefully randomizes the iteration order, which causes a lot of bugs and makes it unusable 90% of the time. The authors wanted to prevent people from using it as if the key order was guaranteed, but their fix also broke the natural consistency of iteration order. This means for example that the drawing order of objects is different every frame, even when the data didn't change at all. - When it comes to modding, there are not much options, because Go does not have a very easy or natural compatibility with FFI (cgo is awkward to use, and not really usable with dynamic linking), the native plugin package is experimental (and not even working in windows), and the support for WebAssembly is still quite poor (but getting better).
- mortallywounded 3y agoI love Go and have been thinking of using it for a game project, but I can't help but feel like the web itself is a far better stack. The web browser gives you a rich collection of things you need out of the box and fairly "cross platform" by nature. You get things like graphics, audio, networking, debugging utilities, access to webgl / webgpu, etc. As much as I hate to admit it.. it seems the web is far more suited for it than Go. I'm sure the game dev purists out there are pointing and laughing at the idea though :)
- deleted 3y ago[deleted]
- atleastoptimal 3y agoThe question is: is Go a good platform to write big games in? Are there enough libraries and performance to justify using it over C#?