net_

So the solution is to build applications around less of a common base? I don't follow the logic, with respect to Zed. I get what you mean if there's a first-party UI solution in your language (e.g. Swift), but in that case you don't need an open-source UI library.

I haven't worked on screen reader support, yet. Support for alternative text input is built into SDL. UI size scaling is a feature I plan on adding eventually.

In 2020, I started working on a (C++) game engine. Since the only decent open-source UI option was Dear ImGui (which was obviously a bad choice for consumer-facing UIs), I ended up rolling my own retained-mode UI library on top of SDL. Now, it's fully-featured enough that I rarely have to touch it. There's even a major company using it for embedded products.

I don't get why every language's community doesn't just do the same thing: roll an idiomatic UI lib on top of SDL. It was tough, but I was able to do it as a single person (who was also building an entire game engine at the same time) over the course of a couple years.

I transitioned from a "normal" keyboard to a Glove80 last year. I immediately didn't like using the standard layout, so I switched to Colemak-DH which I've found pretty comfortable.

The thumb clusters are definitely a pain, I find myself only really using the 3 closest buttons one each side. Even then, the closest button on the upper row requires a stretch that gets uncomfortable after a while. It hasn't been bad enough for me to consider trying other keyboards though--the prices are too high for me to feel comfortable buying something I might not like.

To anyone that switches to a split keyboard, I strongly recommend also getting a trackball mouse (I use a Ploopy Adept). It lets you center the keyboard in front of you without needing to stretch too far while manipulating the mouse.

I've heard The Audio Programmer discord is a great resource for this sort of thing. Worth checking out: https://www.theaudioprogrammer.com/

For 25-player lobbies and some persistent state, I can't help but feel it's over-engineered. Certainly many games (including popular mmos) have been made with much less. This seems like they were engineering defensively against the potential of massive success, which ends up slowing everything down at the point where you need to move most quickly (pre-launch game design iteration and testing).

I don't mean to be reductive though, clearly a lot of work has gone into this architecture and they know their problems better than I do. Props to the devs for seeing it through and getting the game launched!

I made a video series on networking theory for virtual worlds that has been well received: https://youtu.be/0wOZusuMIIM

I've also been working on an engine for the past few years if you want some code examples: https://github.com/Net5F/AmalgamEngine

I've thought a bit about how I would add text-based procedural generation to my virtual world engine (I would love to have an "edit a book to change the world" experience, like Myst's linking books). The hard part is the composition of smaller things into larger concepts, since you have limited data.

For example, developers often devise a system of generic water tiles that they can fit together to form any sort of river. But how do you algorithmically go from the text "I want a river that starts large, gets narrow, then turns East" to a valid map layout? The water tiles and the ways they fit together are specific to the world, so there's nowhere near enough data to train a model. You could hardcode procedural logic based on key phrases ("river" + "start large" + "get narrow" + "turn east"), but that's a lot of work for a very limited implementation.

The most promising idea I've come up with is a node-based intermediate representation. You could use general data on rivers to determine how they're shaped, then use that to translate the user's prompt into a series of nodes on a map. Then, you just need to hand-implement a system to iterate the nodes and place tiles based on whether the next node is straight ahead, turning, etc. This approach could generalize to other concepts like mountains. At that point, it's just about making the text-based stage sufficiently predictive of what the user wants instead of just being a Logo-like.

Popular games switching from pub servers to matchmade 5v5/6v6 bums me out. It feels like it was just done to chase esports money, and it's such a worse casual experience. Way more stress, way less community.

Man, the negative sentiment on this site towards C++ is pretty alien to me.

C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. Clearly it has upsides, so it's baffling to me when people greet attempts to reduce the downsides with either "This doesn't make sense, just scrap it for something else" or endless nitpicks about the approach chosen.

A smart guy has decided to put his time towards improving a hugely influential language. That seems like an uncontroversial positive to me, and I welcome any useful results.

In the other direction, the "all fields at default value serializes as size 0 message that you can't send" behavior has been an unending annoyance since switching to proto3.

That's a really good idea. I've been thinking of what I could do as the first little reference project after I split up the engine and project code. I think a small world with text chat and games like tic tac toe would be perfect.

I'm speaking mostly to the design of our virtual worlds. New tech is certainly interesting, but I feel we're trying to build a roof before the walls.

For example, compared to commercial worlds from 2005 (or text muds from 1995 for that matter), modern virtual worlds are largely the same or worse at helping players form meaningful relationships with eachother. The same goes for their proficiency at helping players connect to the world itself, or at moderating their playerbases.

These are all things that could be more rapidly iterated on in a healthy indy scene, producing new trends and patterns that would lead to more fulfilling interactions with virtual worlds.

All credit to https://kenney.nl/ for the art. These free isometric assets have been invaluable during development, and they look great!

Good point about the sprite editor. I've been struggling with finding interesting things to show in picture form since most of the work so far isn't graphical. The sprite editor and in-world build mode are things that I should show, though.

It's worth saying that, by far, most of the processor time goes towards the networking (serializing, compressing, sending, receiving).

Specifically with the game loop though, the interest management system takes the most time, with the movement system close behind. The interest management system uses a spatial partitioning grid (the "EntityLocator") to efficiently build lists of what entities are in range of each client entity. The movement system moves entities while enforcing a (currently very simple) collision check.

With 1000 clients connected, the interest management system averages around 600us per run, and the movement system around 450us (measured using Tracy). The server runs at 30 ticks per second, so the simulation loop has to fit within a 33ms deadline each tick.

Hey all, Net_ here.

Virtual worlds are really important to me. They've helped me through a lot of tough times, and I think they're a necessary part of our future. Unfortunately, they've largely been stagnant for the past 15 years. This is my attempt to push the needle forward by providing developers with an open-source engine to easily make their own.

This is a sprite-based, isometric-only, single-server, non-instanced engine. I'm keeping it very focused so that we can make the workflow as streamlined and joyful as possible. The full project will eventually also include a chat server and user account management.

A simple demo world is available to play around with, just download and run the client: https://github.com/Net5F/Amalgam/releases/latest

It's still very early, but the netcode and engine architecture are in a pretty good place. I have two network load test scenarios that I'm benchmarking against: 150 clients in 1 area (video link in repo readme), and 1000 in groups of 10. Even on modest hardware, there's plenty of headroom available for adding more features. Still to come: NPCs, items, interactions.

Load test results (Linode server, $30/mo, 2 - 2.6GHz):

Scenario | Bandwidth usage | Average CPU usage (200% max)

150 in 1 | 1.66MB/s | 25%

1000 in 10 | 1.31MB/s | 76%

I welcome all feedback. The project has a long way to go before it's really useful to developers, but I figured I should get over my nerves and start showing it.