In my latest post I showed some
examples of how I ran mostly the same PC hardware over a period of 8 years.
Today I finally finished setting up my new PC hardware in my new home, so I can
report about what I did differently, my thought process, and some problems I
encountered and hacks I did to solve them.
I'm not sure if this article is interesting for anyone, but I had some fun
setting the new system up and felt like writing about it, so here we go:
After reading the feedback of my recent article about running
DDNet, I noticed that people
found it interesting how I'm trying to minimize money and resources. I also
noticed that I had been doing something similar with my personal computing
hardware setup for an even longer time.
I've mostly been using the same hardware for personal computation purposes over
the last 8 years. In this article I want to talk about some of the hardware
I've been using, how it broke and how I fixed the problems or worked around
them. My goal was to be frugal about hardware, to keep using the same hardware
for a long time and repair it when possible instead of simply buying new
In this article we're going to write a simple 2D platform game. You can also consider this as a tutorial for game development with SDL2 in Nim.
We will read in user input, display graphics and a tile map, and simulate
simple 2D physics with collision detection and handling. Afterwards we will
implement simple camera movement and game logic. To display some information we
will render texts and develop a caching mechanism for said text rendering.
The final result will be a binary file that requires only SDL2 and can be
easily distributed, perfect for games. If you're on Linux we will also present
a simple way to cross-compile Nim programs for Windows.
It's been roughly 3 years since DDraceNetwork (DDNet)
started in the summer of 2013. Last year I wrote a non-technical History of
DDNet. Today in this post we
will dive into the technical side of what makes DDNet run.
For the uninitiated, DDNet is an open-source
Teeworlds, a retro multiplayer shooter. DDNet is
a game in which you, instead of killing each other, cooperate with each other
to work your way through challenging maps, trying to beat the map or get a
better time than other teams.
Introduction to the Introduction (Meta-Introduction)
Wikipedia gives us a nice
description of metaprogramming:
Metaprogramming is the writing of computer programs with the ability to
treat programs as their data. It means that a program could be designed to
read, generate, analyse and/or transform other programs, and even modify
itself while running.
In this article we will explore Nim's metaprogramming
capabilities, which are quite powerful and yet still easy to use. After all
great metaprogramming is one of Nim's main features. The general rule is to use
the least powerful construct that is still powerful enough to solve a problem,
in this order:
About a month ago I set up statistics for the official DDNet servers. My motivations for this are:
Monitor the servers more easily
Get notified about server problems
Have nice graphs to look at
The choices for the software used are mainly made to keep resource usage low, a
general principle used for DDNet since we run on cheap VPSes all around the
world and are limited in CPU and memory resources. In the rest of this post we
will explore the 3 major tools used, their purpose in our solution as well as
their performance impact:
This is my first non-technical post. I'm currently travelling Europe for 1 month after just finishing my CS master. Right now I'm back at home, but will be flying around again in a few days. I've never had a photo camera before, so not sure if the photos are good. This was my route so far with photos:
The size of binaries in the Nim programming language seems to be apopulartopicrecently. Nim's slogan is expressive, efficient, elegant, so let's examine the efficient part in this post by exploring a few ways to reduce the size of a simple Nim Hello World binary on Linux. Along the way we will:
Build a regular program into a 6 KB binary
Disregard the C standard library and build a 952 byte binary
I spent the last weekend working through the amazing
guide for Make a
Lisp, writing a Lisp interpreter in Nim. The
final result just made it into
Running the Nim version is pretty simple. You need the Nim compiler from the devel branch and nre which can be installed through nimble. After installing those you can build and run the MAL interpreter:
$ cd nim
$ nimble build
user> (+ 2 3)
Nim is not the fastest language, it's not the easiest language to write in and it surely has some flaws that should be fixed. Nim has no single "killer feature" like go's goroutines or Rust's memory management. But Nim doesn't need a killer feature. Instead it strikes a reasonable balance that makes it the most efficient language for me:
I can produce reasonably efficient code (faster than Python and Haskell)
that is reasonably readable (more so than Rust, C++ and Haskell)
in a reasonable amount of time (less than Rust, C++ and Haskell)
In my last post I showed what makes the Nim programming language special. Today, let's consider Nim from another angle: What makes Nim a practical programming language?
Programs written in interpreted languages like Python are difficult to distribute. Either you require Python (in a specific version even) to be installed already, or you ship it with your program. This even causes some to reconsider Python as a teaching language.
How does Nim work around this problem? For starters your program gets statically linked against the Nim runtime. That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in.
The Nim programming language is exciting. While the official tutorial is great, it slowly introduces you to the language. Instead I want to quickly show what you can do with Nim that would be more difficult or impossible in other languages.
I discovered Nim in my quest to find the right tools to write a game, HookRace, the successor of my current DDNet game/mod of Teeworlds. Since I'm busy with other projects for now, this blog is now officially about Nim instead, until I find time to continue developing the game.
Easy to get running
Ok, this part is not exciting yet, but I invite you to follow along with the post:
To learn some Nim I held a talk about it at the GPN14 (in German, Slides).
Afterwards I started solving Rosetta Code tasks in Nim to get a better feel for the language and standard library. That also made me discover some rough edges in the language, but luckily the community, albeit small, is active and competent. All the small code pieces I wrote are now on Github too.
What I noticed is that most problems are as easy to solve as in Python, but much more performant. I'm now more confident that this language is the right choice for writing HookRace in.
I have been running DDraceNetwork for 1 year, which started out as a little server of a Teeworlds modification called DDRace. It has turned into the biggest project within Teeworlds, offering servers in 6 countries with thousands of players and dozens of mappers. We also offer a custom server and client (Windows, Linux, OS X, Android).
Now it's time to start something new. I'm working on a new game called HookRace, which will be the successor to DDraceNetwork. It will be its own game, not based on Teeworlds.