> The result is a ~300 KiB statically linked executable, that requires no libraries, and uses a constant ~1 MiB of resident heap memory (allocated at the start, to hold the assets). That’s roughly a thousand times smaller in size than Microsoft’s. And it only is a few hundred lines of code.

And even with this impressive reduction in resource usage, it's actually huge for 1987! A PC of that age probably had 1 or 2 MB of RAM. The Super NES from 1990 only had 128Kb of RAM. Super Mario Word is only 512KB.

A PlayStation from 1994 had only 2MB of system RAM. And you had games like Metal Gear Solid or Silent Hill.

I have an actual commercial game from 1987 :) https://github.com/TheJare/stardust-48k

> X11 is old and crufty, but also gets out of the way. Once a few utility functions to open the window, receive events, etc have been implemented, it can be forgotten and we can focus all our attention on the game. That’s very valuable. How many libraries, frameworks and development environments can say the same?

This is my thought as well. You can even avoid some of the grotty details of this article if you use Xlib as your interface instead of going in raw over a socket. Basic Xlib is surprisingly nice to work with, albeit with the caveat that you're managing every single pixel on the screen. For something like a game where you're not using system widgets it is all you need.

Where people ran into trouble is when they try to add the X Toolkit, which is far more opinionated and intrusive.

One of the first DOS PC programs I made was a MineSweeper clone. It was done as a special request for some friends who had machines that were not up to running Windows, but were addicted to minesweeper from school computers. It was a little weird trying to implement a game I hadn't seen myself, but they gave me very precise descriptions (I think most of them have Math PhDs now)

I did it in Turbo Pascal with BGI graphics. I remember having problems with recursively uncovering empty tiles in large levels where mines were sparse. Recursive algorithms turned out to be rather tricky in general when the stack segment is 64k.

I added a starting disk of various diameters which let you pick a starting location without risk of explosion, which I think was appreciated.

Writing a game, or any software in 1987 would be painstaking compared to the luxury we have today. Back then it was normal to run DOS and DOS can only do one thing at the time. You open your editor, write code, close your editor, run the compiler, run your program, test your program, exit program, re-launch editor, etc. Over time small improvements where made to this flow like a DOS Shell and even things like DESQView that allow for basic multitasking.

This is probably a better description (from a code point of view) on what you had to do as a programmer to write a game in the late 80s / early 90s:

https://cosmodoc.org/

Great "old-school" article! Intrigued to try Odin sometime.

> One interesting thing: in Odin, similarly to Zig, allocators are passed to functions wishing to allocate memory. Contrary to Zig though, Odin has a mechanism to make that less tedious (and more implicit as a result) by essentially passing the allocator as the last function argument which is optional.

I heard some hype lately about Godot so took a look today... I'm super bummed that the wasm is 50MB minimum just to get the engine rendering a blank scene.

Seems like that could be further optimized especially for simple 2D games that don't use many features. I was impressed overall though. I hadn't looked at Godot in a long time.

Oh, the author has a cool example of a minimalistsic Wayland GUI application:

https://gaultier.github.io/blog/wayland_from_scratch.html

Good job!!

I did a 1-1 replica of the Windows 95 version of Minesweeper.

You can find it at https://github.com/danielricci/minesweeper

I didn’t do anything fancy in terms of reducing the size of the output file, but it was fun to try and replicate that game as best as I could.

I will say, while this is interesting and fun to see, using a trivial library like SDL adds almost nothing to the overhead and expands support to non *nix OSes.

There is definitely something to be said of bloat but probably not in this case. You could even keep supporting Linux versions as old as this promises by using legacy 1.x SDL.

Different topic but this article got me lost down a rabbit hole looking for something similar for the TI86. Ah, memories...

Simon Tatham's Mines Windows exe stands at ~180KiB as seen at https://www.chiark.greenend.org.uk/~sgtatham/puzzles/

Can I say when you said “video game” am thinking arcade, dos, windows … or even mac (1984). Xwindows!!! … as someone said Sdl based … and unix curses based.

It is legitimate but by 1987 …

Even some games from 1984 or even earlier are amazingly complex, making you wonder how they made them in such short time with limited tools and manpower.

It's noteworthy that it's impossible, by design, to write a statically linked Wayland executable. You have to load graphics drivers, because there's no way to just send either pixel data or drawing commands to the display server, like you can in X11. You have to put the pixel data in a GPU buffer using a GPU driver, then send the GPU buffer reference.

Fun fact: the Windows 3.1 minesweeper had a cheat code! Typing:

  x y z z y S-Return

would cause the top left pixel of the screen to change color depending on whether the cursor was over a safe square or a bomb. Since you could plant flags before the timer started, it was possible to get rather unrealistic times.

Microsoft’s official Minesweeper app has ads, pay-to-win, and is hundreds of MBs

WTF? This is a showcase of everything wrong with the company today.

That code is a bit too readable for that time period in games, hehe. See Doom:

https://github.com/id-Software/DOOM/blob/master/linuxdoom-1....

I Remember that around 1985 was more simple to write basic games in the TI99/4A in TI Extended BASIC or Logo. The sprite support was an advantage from writing basic games on PCs without sprites support. I remember a performance similar to the Atari 2600 and not using Assembler.

I did this last year, built a zero player pixellated space simulator using pygame.

I'm often curious about how people organized / conceptualized development in the 60s, 70s and 80s.

In 1987 the game would have been written in Assembly.

This is more like 1992.

Michael Abrash's book was published in 1990.

I really appreciate the effort and attention to detail that went into this.

Honestly at that time I remember getting fed up using a library for the graphics of a simulation I was doing over a weekend.

So I just threw out the graphics library and wrote directly to the screen memory. Lots of games did that

"Let’s write a video game from scratch like it’s 1987"

"We will implement this in the Odin programming language"

checks Odin homepage...

"The project started one evening in late July 2016"

> Since authentication entries can be large, we have to allocate - the stack is only so big. It would be unfortunate to stack overflow because a hostname is a tiny bit too long in this file.

What? How big are your hostnames?

> I don’t exactly remember the rules though so it’s a best approximation.

What?

1 MB of assets? Huh?