Show HN: Doom port to pure Go – Gore
github.comHi HN, I’ve been working on Gore – a port of the classic Doom engine written in pure Go, based on a ccgo C-to-Go translation of Doom Generic. It loads original WAD files, uses a software renderer (no SDL or CGO, or Go dependencies outside the standard library). Still has a bit of unsafe code that I'm trying to get rid of, and various other caveats.
In the examples is a terminal-based renderer, which is entertaining, even though it's very hard to play with terminal-style input/output.
The goal is a clean, cross-platform, Go-native take on the Doom engine – fun to hack on, easy to read, and portable.
Code and instructions are at https://github.com/AndreRenaud/Gore
Would love feedback or thoughts.
What an inspired name :)
I'd love to `kubectl run doom` and kill monsters when I'm supposed to be working
Services could have "location" data attached in their metadata and orchestrator could actually place them on the map. They could have some "personality" traits as well and e.g. to kill a service you could walk up to it and do the deed.
Why not both? https://github.com/storax/kubedoom
There is also prior art, PSDoom:
> The Doom process manager (PSDoom) is a modification of the game Doom that displays representations of the processes running on a machine. Rather than using standard text-mode UNIX tools to view and manipulate processes, one surveys and shoots at a room full of bloodthirsty mutants, as shown in Figure 1.
> Less than a week after the initial version of the code was written, the project’s website was attracting tens of thousands of visitors per day. Approximately 800 responses were e-mailed to the author or www.slashdot.org within the first two months. Of these responses 27% praised the project, 23% offered suggestions for improving PSDoom, 10% found the project funny, 10% reported technical problems, 8% related PSDoom to science fiction or to the future of interfaces, 1% disliked the project, and 0.6% were frightened by its implications.
"Doom as an Interface for Process Management" (2002), https://www.researchgate.net/publication/2522409_Doom_as_an_...
Great effort.
Although I tend to be a critic of Go's design, I love projects like these, as they make the point not everything needs to be C or C++ for game development.
Kudos for the project.
I feel that it's hard to be mad at Go if you look at it as "python 4.0."
Hardly, given that it isn't as expressive as Python, that role belongs to Mojo.
The only reason so many folks leave Python for Go, is the usual problem of writing C libraries instead of finally having a proper JIT in CPython, and having PyPy being largely ignored by the community.
Go's structural typing allows for quite a lot of flexibility often otherwise only found in scripting languages (I would suspect that this was the single biggest reason as to why the TypeScript folks started to move to Go for the ported compiler rather than something like dotnet based like C#).
Go's strucutural typing already existed in languages of the ML linage, nothing new.
F# can do that just fine, if the team actually cared about using .NET.
Not sure if "Python 4.0" is the best comparison.
Go is compiled, Python - interpreted. Go focuses on concurrency, Python on making it easy to do things with code.
Many things that are a one-liner in Python (but itself or with a library), in Go take quite a lot of lines or boilerplate. For example, there is no built-in string templates in Go.
Say, what gui/graphics/game-ish libraries are available for Go?
The ebitengine that this project mentions?
If I recall the exact same topic has been posted a month back; checked - the exact same text - word by word.
Will it run myhouse.wad?