6 ms·

Show HN: Doom port to pure Go – Gore

148 points by EstIgnavus 1y ago

Hi 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 https://github.com/AndreRenaud/Gore Would love feedback or thoughts.

alexchantavy 1y ago
I'd love to `kubectl run doom` and kill monsters when I'm supposed to be working
- MrDrMcCoy 1y ago
  Why not both? https://github.com/storax/kubedoom https://github.com/storax/kubedoom
  - merelysounds 1y ago
    There is also prior art, PSDoom: > The Doom process manager (PSDoom) is a modiﬁcation 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_Interface_for_Process_Management https://www.researchgate.net/publication/2522409_Doom_as_an_...
    - EstIgnavus 1y ago
      I remember when this was announced. It had another humorous side effect - in Doom monsters can kill other monsters, which meant the PSDoom could result in processes randomly killing one another.
- varispeed 1y ago
  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.
- hu3 1y ago
  What about Minecraft as a k8s admin tool? https://github.com/erjadi/kubecraftadmin https://github.com/erjadi/kubecraftadmin
pjmlp 1y ago
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.
- alrs 1y ago
  I feel that it's hard to be mad at Go if you look at it as "python 4.0."
  - stared 1y ago
    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.
    - 9rx 1y ago
      > Not sure if "Python 4.0" is the best comparison. Or is it Python that is not best compared to "Python 4.0"? Python doesn't live up to the guiding principles of Python, such as preferring only one obvious way to do something. Go is, in many ways, more Python than Python. > Many things that are a one-liner in Python Case in point. Many of those one-liners are just as obviously expressed as multi-liners (e.g. list comprehension vs. traditional 'for' loop). > no built-in string templates in Go. Another good example. There is no special syntax, but the standard library provides. Special syntax would give two obvious ways to do it.
  - pjmlp 1y ago
    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.
    - 1y ago
dvh 1y ago
Will it run myhouse.wad?
- EstIgnavus 1y ago
  Tragically, it will not. Most 'modern' Doom wads use features that weren't present in the original release (ie: they need GZDoom, Boom, or one of the other modern engines). This is a port of the original release, so it's missing those kinds of features. The idea for this wasn't really to make a new fully featured engine for modern wads, it was more for sneaking the Doom engine in to unrelated projects, easter-egg style. I've run this on various embedded systems that I use Go with. One of the demos is a webserver that uses mjpeg streaming for example.
xxs 1y ago
If I recall the exact same topic has been posted a month back; checked - the exact same text - word by word.
- EstIgnavus 1y ago
  Ah yes, I did repost it. The previous time didn't get much traction, and I thought enough time had passed that a repost wouldn't be problematic. Apologies if I was mistaken.
nottorp 1y ago
Say, what gui/graphics/game-ish libraries are available for Go? The ebitengine that this project mentions?
- rob74 1y ago
  Yes. Ok, if that answer is too short: there are some others (https://github.com/avelino/awesome-go?tab=readme-ov-file#game-development https://github.com/avelino/awesome-go?tab=readme-ov-file#gam...), but ebitengine is by far the most popular...
markpapadakis 1y ago
What an inspired name :)
romperstomper 1y ago
Just curios, why everything is in a single large file (doom.go ~46K LOC)? Is it because of how Go handle modules?
- donatj 1y ago
  Nah, I suspect it's just because it's a machine translated port of the original C to Go > The original C code was converted to Go using (modernc.org/ccgo/v4), by cznic (https://gitlab.com/cznic/doomgeneric.git https://gitlab.com/cznic/doomgeneric.git). This was then manually cleaned up to remove a lot of manual pointer manipulation, and make things more Go-ish, whilst still maintaining compatibility with the original Doom, and its overall structure.
  - romperstomper 1y ago
    Ah, I see, thanks!
  - EstIgnavus 1y ago
    Yes, that's exactly correct. I had intended to break it apart back to the original Doom source layout, but I haven't completed that yet. I'm not 100% sure if that's a good idea anyway.
- nasretdinov 1y ago
  I must say I'm really surprised it's so small too, for a reasonably complicated game
flowerthoughts 1y ago
I love how ebitengine's author jumped in and helped out with optimizations: https://github.com/AndreRenaud/gore/pull/48 https://github.com/AndreRenaud/gore/pull/48
- EstIgnavus 1y ago
  I'm amazed at how prolific he is. I've interacted with him a couple of times, and he's always super polite and helpful. In spite of the fact that he is also churning through issues/code on a number of projects.

148 points by EstIgnavus 1y ago

alexchantavy 1y ago

I'd love to `kubectl run doom` and kill monsters when I'm supposed to be working

MrDrMcCoy 1y ago
Why not both? https://github.com/storax/kubedoom https://github.com/storax/kubedoom
- merelysounds 1y ago
  There is also prior art, PSDoom: > The Doom process manager (PSDoom) is a modiﬁcation 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_Interface_for_Process_Management https://www.researchgate.net/publication/2522409_Doom_as_an_...
  - EstIgnavus 1y ago
    I remember when this was announced. It had another humorous side effect - in Doom monsters can kill other monsters, which meant the PSDoom could result in processes randomly killing one another.
varispeed 1y ago
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.
hu3 1y ago
What about Minecraft as a k8s admin tool? https://github.com/erjadi/kubecraftadmin https://github.com/erjadi/kubecraftadmin

pjmlp 1y ago

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.

alrs 1y ago
I feel that it's hard to be mad at Go if you look at it as "python 4.0."
- stared 1y ago
  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.
  - 9rx 1y ago
    > Not sure if "Python 4.0" is the best comparison. Or is it Python that is not best compared to "Python 4.0"? Python doesn't live up to the guiding principles of Python, such as preferring only one obvious way to do something. Go is, in many ways, more Python than Python. > Many things that are a one-liner in Python Case in point. Many of those one-liners are just as obviously expressed as multi-liners (e.g. list comprehension vs. traditional 'for' loop). > no built-in string templates in Go. Another good example. There is no special syntax, but the standard library provides. Special syntax would give two obvious ways to do it.
- pjmlp 1y ago
  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.
  - 1y ago

dvh 1y ago

Will it run myhouse.wad?

EstIgnavus 1y ago
Tragically, it will not. Most 'modern' Doom wads use features that weren't present in the original release (ie: they need GZDoom, Boom, or one of the other modern engines). This is a port of the original release, so it's missing those kinds of features. The idea for this wasn't really to make a new fully featured engine for modern wads, it was more for sneaking the Doom engine in to unrelated projects, easter-egg style. I've run this on various embedded systems that I use Go with. One of the demos is a webserver that uses mjpeg streaming for example.

xxs 1y ago

If I recall the exact same topic has been posted a month back; checked - the exact same text - word by word.

EstIgnavus 1y ago
Ah yes, I did repost it. The previous time didn't get much traction, and I thought enough time had passed that a repost wouldn't be problematic. Apologies if I was mistaken.

nottorp 1y ago

Say, what gui/graphics/game-ish libraries are available for Go? The ebitengine that this project mentions?

rob74 1y ago
Yes. Ok, if that answer is too short: there are some others (https://github.com/avelino/awesome-go?tab=readme-ov-file#game-development https://github.com/avelino/awesome-go?tab=readme-ov-file#gam...), but ebitengine is by far the most popular...

markpapadakis 1y ago

What an inspired name :)

romperstomper 1y ago

Just curios, why everything is in a single large file (doom.go ~46K LOC)? Is it because of how Go handle modules?

donatj 1y ago
Nah, I suspect it's just because it's a machine translated port of the original C to Go > The original C code was converted to Go using (modernc.org/ccgo/v4), by cznic (https://gitlab.com/cznic/doomgeneric.git https://gitlab.com/cznic/doomgeneric.git). This was then manually cleaned up to remove a lot of manual pointer manipulation, and make things more Go-ish, whilst still maintaining compatibility with the original Doom, and its overall structure.
- romperstomper 1y ago
  Ah, I see, thanks!
- EstIgnavus 1y ago
  Yes, that's exactly correct. I had intended to break it apart back to the original Doom source layout, but I haven't completed that yet. I'm not 100% sure if that's a good idea anyway.
nasretdinov 1y ago
I must say I'm really surprised it's so small too, for a reasonably complicated game

flowerthoughts 1y ago

I love how ebitengine's author jumped in and helped out with optimizations: https://github.com/AndreRenaud/gore/pull/48 https://github.com/AndreRenaud/gore/pull/48

EstIgnavus 1y ago
I'm amazed at how prolific he is. I've interacted with him a couple of times, and he's always super polite and helpful. In spite of the fact that he is also churning through issues/code on a number of projects.