Welcome to my blog.

Keeping my promise and motivation up… here’s the second installment of the Open Hexagon leaderboards devlog. I have made quite a lot of progress in the past few days, and have implemented the following features:

• Headless mode with replay validation

• Bought a Arch Linux VPS on Linode for the server

Hello everyone!

This is going to be a DevLog about the implementation of one particular feature for my game Open Hexagon: online leaderboards.

### open hexagon

First of all, what is Open Hexagon?

The past few days have been “interesting”. My Twitter has been raided by the part of the gamedev community that doesn’t see much value in Modern C++ and prefers writing code with a very low level of abstraction. However, this time I didn’t start it, unlike a while ago

This article (1) tells the story of the heated discussions one of my tweets spawned, (2) analyzes some common requirements and misconceptions game developers have, and (3) provides a list of Modern C++ features which every game developer should use.

Enjoy.

Imagine that you have been designing a programming language for over 30 years and that it gradually became widely used across the globe. Some of the decisions you made at the beginning were excellent and contributed to the success of your project. Some others, however, were not the best: over the years you and your users realized that the world would have been a better place if those choices you made eons ago were slightly different.

You keep evolving your language, adding useful features and keeping it up to speed with the competition. The bad choices and older (now obsolete) constructs still linger.

You try removing the most dangerous and least used aspects of the language, and while their dismissal is highly successful, some users will undoubtedly be hindered by it. For more popular constructs, you attempt deprecation: a large part of the community welcomes it and migrates their codebases, while another finds the work required to achieve conformance either unjustifiably large or impossible due to legacy dependencies or licensing issues.

It’s been exactly 447 days since my last article, “compile-time iteration with C++20 lambdas”. I should be ashamed.

In my defense, I’ve been very busy since then… and I’m going to tell you all about it in this blog post.

As my memory fades away more quickly due to getting older, I had to go through my various social media accounts to reconstruct a timeline of the most important events in these past months. While very convenient, I also have to admit that it is sort of scary to see how all my history is publicly available.

In one of my previous articles, “compile-time repeat & noexcept-correctness”, I have covered the design and implementation of a simple repeat<n>(f) function that, when invoked, expands to n calls to f during compilation. E.g.

repeat<4>([]{ std::cout << "hello\n"; });

…is roughly equivalent to…

[]{ std::cout << "hello\n"; }();
[]{ std::cout << "hello\n"; }();
[]{ std::cout << "hello\n"; }();
[]{ std::cout << "hello\n"; }();

If you squint, this is a very limited form of compile-time iteration. When writing generic code, I’ve often needed similar constructs in order to express the following actions:

I’m back in London from Jacksonville, where I attended my first ISO C++ meeting. Apart from the long flights and long working hours, it has been a very enjoyable experience for multiple reasons:

• I was able to actively participate in the evolution of the language and influence it by voting and discussing;

• Seeing the amount of work, the engaging debates, and the formal procedures used to move C++ forward gave me a newfound appreciation for all the members of the committee and for the language;