In The Elm Architecture, what's shown on-screen is typically described in the view function, as a function of the current state (the model). We do that for the lobby, scoreboard etc, but not for the Kurves: instead, the update function returns a Cmd describing what should be added to the canvas (or in some cases removed from it) to reflect what's happened since the last tick.

The primary reason why we do it this way is that we could then reuse the rendering logic from the legacy JavaScript version, making it easier to get started with the Elm version.

From a programmer's perspective, it would be great if we could do everything in the view function instead.

Hit detection does not work properly. A worm cannot collide with itself.

Hey @SimonAlling – really awesome app and a perfect rendition of the old Zatacka game. :) Thank you!

Now @MorrisJobke and I want to make it possible to install as a Nextcloud app. (Maybe you already saw https://github.com/jancborchardt/kurve :) – now we are wondering what license your code is under. MIT or AGPLv3 for example would be cool.

So the goal is obviously to replicate the mechanics of the original game as closely as possible. Recently – especially after starting to read the Borland C++ 2.0 manual – I've been getting stronger and stronger suspicions that our implementation of collisions may not be quite correct. This issue is an attempt to document all related findings and thoughts.

About eight years ago (see 2aa5179 – unfortunately a complete mess of a commit), a couple of friends and I sat down and tried to analyze how collisions might be implemented in the original game. After having seen several instances of a Kurve counterintuitively "painting over" another one, rather than dying on apparent impact, we arrived at a theory where a so-called "90 degree draw" would have the three foremost pixels as hitbox, while a "45 degree draw" would only have the single foremost pixel. That should, in theory, allow plays like this. (The so-called "90-degree" and "45-degree draws" are likely the two cases of Bresenham's algorithm.)

In the Borland C++ 2.0 manual, I've found, among others, a lineto function that takes an integer coordinate. The thickness can be specified to either "1 pixel" or, notably, "3 pixels" – the standard Kurve thickness. It seems likely to me that someone creating a game for fun in 1995 would have used something like that, and in general the simplest possible way whenever there were multiple ways to implement something. lineto and similar functions need not necessarily have any relation to collisions, but anyway. Also, given the standard speed of the Kurves (1 pixel per frame when going horizontally or vertically), drawing lines – as opposed to squares – might not actually be necessary.

My friend and colleague Robert – a true veteran of programming – is confident that it must be the already drawn pixels that are used to determine whether a collision has occurred, not some abstract vector representation of line segments or similar. We're not sure exactly how, though.

FWIW, Robert also argues that both the positions and directions of Kurves are probably implemented using fixed-precision arithmetic, not floating-point. For example, a 16-bit number could be used as an x coordinate, with 10 bits for the integer part and 6 bits for the fractional part.

We haven't been able to replicate a situation proving that our eight-year-old theory about collisions (a 1-pixel hitbox for "45-degree" draws) is correct. One way of pursuing that is to run the original game in DOSBox and use Ctrl + F11 to slow it down and use DOSBox' built-in video capture feature to be able to analyze what happens frame by frame.

Of course, it would be absolutely marvelous to get some input from @mxdpeep himself!

Maybe Kurve should display some kind of warning when Vimium or a similar extension is interfering with keyboard input.