ItsFirefly

Sorry to self-promote, but, Angeldust (https://angeldu.st) is a single, persistent, real-time voxel world going for about eight years now. Can handle 300+K players on a single server due to massive parallelism. Unfortunately we don't get those player numbers right now, but hopefully in the future!

Angeldust, my 'fast and efficient' video game was on the HN front page for days in 2019: https://news.ycombinator.com/item?id=21858226

I now present the first, native, optimized build for all Raspberry Pi models that you can help test. It's fast, efficient and beautiful. You can play this forever, without DRM or limitations.

Thanks to amazing feedback from HN, I've added great features to the game over time, available on all operating systems:

– control remapping – pasting text (from password managers too!) – energy saving – quest rewards – additional languages (10 in total)

I'm livestreaming as I submit this post; feel free to hop by with questions and comments. It was awesome last time we did this! Here are the links:

YouTube: https://www.youtube.com/watch?v=KFhxfYA98gw Twitch: https://www.twitch.tv/AngeldustLive

Have fun playing! I'll be here after the livestream to answer your replies.

I didn't really use many external resources during development, most of the time I'm just "winging it" and acting towards a goal that I have in my mind. Coming up with a naive solution first, then trying to optimize it a bit in my head, then writing the code for it.

Angeldust's physics are relatively straightforward since it's based on a voxel grid. All game world intersections are approximated using axis-aligned bounding boxes (AABBs). I wrote the physics engine myself from scratch to reduce the number of game world data lookups, because that's pretty much the hot path in the code.

In the YouTube video from my earlier comment you can see that initially I started out with just game world boundary clipping and simple plane physics on the checkerboard. As I expanded my game world model, the physics engine grew along. So my advice would be (again) to start simple and grow from there. You'll do fine!

Thanks for the elaboration, I get that the design just doesn't do it for you personally. Did you already see that the game's also available in a highly abstract "Cartoon" visual style featuring hand-drawn, 2D animated sprites à la Paper Mario 64? Here's the trailer in the "Cartoon" visual style:

https://www.youtube.com/watch?v=J7LK0s8LgmQ

Maybe this style appeals more to you?

Go for it! If you already have OpenGL experience—doesn't matter what level—you "only" have to add a bit of basic 3D world math and input handling. I found SDL (http://libsdl.org) to be a very good core framework to build upon regarding input handling.

For the 3D world, start with a checkerboard pattern or so. In fact, this is almost exactly what I did to start Angeldust. I once showed off some early game prototypes on my stream, take a look at this one for example: https://www.youtube.com/watch?v=qMs8YpkSrg0&t=3289

If you keep watching that stream you'll see other in-progress versions so you can see how my product evolved.

It's ridiculously hard to come up with an answer to this seemingly simple question. I've tracked my time usage pretty meticulously by version number, but for most features I had to develop the server-side, client-side, website and network simulator code simultaneously. Developing this (or any) game I think isn't a process where you build the server first, then build the simulator and then build the client. It's building v0.0 for all parts, then v0.1 for all parts and onwards where all parts gain features in lockstep.

For Angeldust I've done dozens of updates, each and every single one building upon the existing base. Looking back it's amazing to see that the product evolved in an almost linear fashion from v0.0 all the way to the current version without ever having to drop or redo features. But because the product evolved as a whole I can not really distill a time estimate for only the "client side engine".

I mean: would you consider testing the client side engine part of client side engine development? For testing you need a working server. For which you "need" a working network simulator. It's dependencies all the way down.

And how about translation work for in-engine strings, updating shared libraries and frameworks, issue tracking, writing the asset conversion toolchain (which needs assets, which need integration). It's very hard to come up with any solid number. Maybe if you can severely limit your question's scope I can come up with an educated guess.

Sorry for taking a while to reply—I contacted Apple support and it seems like the issue is out of my control. For both you and the GP comment I'd like to refer you to my reply here with background and more information:

https://news.ycombinator.com/item?id=21872869

Sorry for taking some time to reply in full, but I wanted to wait for an official answer from Apple support. Apple informed me that:

"[Y]our apps … are available worldwide and functioning as expected. If your customers are reporting issues, they may not meet the requirements for the apps or have some issues on their devices and would need to contact technical support for assistance."

I'm glad you and others reported problems with availability, but it looks to be something outside of my control. If you still want to get Angeldust on your Apple device from the App Store you might have to contact Apple to help diagnose the issue. I'm sorry that I am unable to help you.

Like I posted earlier, Angeldust is available from several other sources besides the iTunes and Mac App Store:

Itch.io (Win, Mac, Linux, Android): https://metagaming.itch.io/angeldust

Steam (Win, Mac, Linux): https://store.steampowered.com/app/488440/

Google Play Store (Android): https://play.google.com/store/apps/details?id=nl.metagaming....

Angeldust has practically zero level of detail (LoD) and has no occlusion culling. "Almost zero LoD" means that geometry is always rendered at full resolution, but subtle vertex-shaded effects like the waving of grass are not applied for distant geometry. So you will see grass everywhere, but it won't wave when it's "unnoticeably" far away. Other than that I just push millions of mostly buffered triangles and vertices each frame at high view distance without a hitch. Turns out computers are pretty fast these days.

Note that I'm working on a newer render engine that actually uses more GPU shading capabilities and this engine runs even smoother than the current one, since it balances the workload a lot better between CPU and GPU.

As for data structures: both client- and server-side it's pretty much a simple std::map<coordinate, chunk*>. Its O(log(n)) lookup is adequate and I don't want or need to do complicated things to ensure decent performance. On top of the map I do spatially-aware caching to prevent say 99% of actual map lookups which turns the majority of lookups into O(1) which seems pretty much optimal.

As for keeping data: the server is authoritative in everything. The server keeps the data. You can take any device, install Angeldust and sign in with your credentials and you'll find yourself back in the same world, same friends, same progress, same everything that you had on another device.

Same with game state: the server tells the client everything. The client is basically just a dumb graphical terminal application that renders 3D visuals instead of VT100 text.

I think your first question is actually supposed to be: what if a single (not two) entity is modified from multiple chunks?

All external effects that can happen to an entity are written to an atomic integer that tracks healing points, damage points and effects like poison and stunning. Angeldust currently runs on CPUs supporting atomic integers everywhere, so this doesn't have to fall back to mutexes. On platforms/compilers without atomic integers I have a software-fallback that uses mutexes for this, but currently it's not used anywhere.

Most world state is compiled into flat byte arrays each tick to save processing time, since many clients can be in the same area at once. The server bundles these world state byte arrays for chunks near a client together and sends them over the network. The client interpolates from these updates. What you see on screen lags behind subtly to make sure animations are smooth. I think this happens in most online games since you don't really want to extrapolate.

Angeldust's game pace and mechanics are designed so that the interpolation doesn't affect your aiming accuracy or game experience too much.

I considered it, then dropped it. The Google Play Store definitely has a mechanism of adding more data/bundles to your application, but (when I investigated this) you'd need to drag in Google-provided libraries and tie your app to the Google Play Store. I dislike lock-in and do my best to be able to independently develop and distribute my product. So expansion files/bundles didn't look interesting.

To compensate, the Itch.io Android APK is actually pretty much identical to the Google Play Store version, but it just includes all 3D assets too.

Really getting into the nitty-gritty here. If an entity migrates to an inactive chunk, I keep the entity "on hold" and add a "chunk set mutation" to the active chunk set so that the set is expanded in the next tick. The processing thread for this newly added chunk sees that no data exists yet and synchronizes the state from the backend during the subsequent tick. On this tick the entity gets added to the new chunk write state and disappears quietly from the old chunk in the next tick since it isn't "on hold" or copied anymore.

As for the processing per tick: the entire active chunk set gets semi-randomly processed by threads. You'd be absolutely right that the order of operations isn't always deterministic. An entity not being processed for a tick doesn't happen since the old chunk will still process entities that are "on hold", but only perform a subset of operations. Double-processing does occur and this is sometimes visible while playing with a chat message being duplicated. This happens pretty rarely and I took care to make sure occasional double-processing doesn't interfere with gameplay mechanics.

As for synchronization: yes, each tick all processing threads join together and the server performs minor central processing and scheduling. Then the next tick begins and all threads are started again.

You might have noticed I already took a looong time to formulate a reply to your questions. And I'm still not sure how to approach them, so I'll reply to the last part first.

Currently I only have my livestreams as a public presence. I find it a very comfortable and pleasant medium for conveying who I am. It lets me share stories and ideas including non-verbal cues and that's a major plus for me. So if you want to learn more, definitely subscribe or follow on YouTube and/or Twitch:

https://www.youtube.com/AngeldustLive

https://www.twitch.tv/AngeldustLive

I honestly appreciate talking about technical things a lot, even though I might be playing what appears to be a silly video game. As for streaming: I just did three consecutive days, but will take a short break. I'll be back this Thursday.

Pick your poison; I also have a Twitch channel:

https://www.twitch.tv/AngeldustLive

I'm not a social media user and I currently don't keep a public blog. There are many interesting aspects of Angeldust to talk about and I have many war stories from this and previous projects that would make for an interesting read or listen.

Just this evening I talked on my livestream about my rough introduction to SIGPIPE randomly killing my server processes. I can understand that a YouTube or Twitch livestream isn't the most convenient format for hearing these stories, but it's currently my most warm and entertaining way to share them.

Streaming is a highlight in my life, while writing out stories feels like work. Very faintly I'm crystallizing a plan to share knowledge in a written way, but for now I think the livestream is going to be my preferred way for requesting and telling stories.

Oof! I'm the designer and art director myself. Please elaborate a bit as "colors and textures fighting each other" doesn't give me the slightest clue as to what you perceive as problematic. Can you post annotated screenshots so I can learn from this? Then I'll go and fire myself!

I've been playing the game in both the "Cartoon" and "3D" visual style for years and it's been a very pleasant and eye-pleasing experience for me. Please open your world a bit for me. Maybe share some of your design work for inspiration. Thanks in advance for your feedback.

You can read a bit about the Angeldust backend architecture in this comment chain (I have no idea what to call this): https://news.ycombinator.com/item?id=21858618

The Second Life approach sounds like a very good solution if you're having to, and willing to use multiple servers because of performance reasons. I think Angeldust's architecture is a bit cleaner and more straightforward due to different design goals. I specifically wanted to reduce complexity and keep a simple infrastructure so that I could code, debug and manage everything on my own.

I also have the luxury of using a single, big, many-core server if necessary. When Second Life started I don't think 32+-core servers were a thing, so their scaling model was probably also born out of sheer necessity.

I hope you enjoy the experience! To be honest I think Angeldust is a video game tailored for non-gamers. Most people playing Angeldust that I know in real life are not gamers by any stretch of the imagination, but they just like the laid-back pacing, welcoming nature and upbeat atmosphere of the game. It's amazing to see random friends and acquaintances with zero interest in gaming have fun in my game.

Thanks, I took a look. They look geared specifically to getting Unity engine projects "ported". Porting my (non-Unity) code is the least of my worries; I'm already maintaining about ten different build toolchains.

I anticipate most problems in the Nintendo Switch platform rules and guidelines that I'm completely unfamiliar with as of yet. And I lack the hardware to test. But now that I'm forced to think more about it, both seem like solvable problems. Thanks for the inspiration :)

I'd say: have fun! With Angeldust being a shared, persistent, open online world it's a pretty cool place to make friends and work on building projects together. You can leave a permanent mark in a place where you can be someone else compared to real life.

But I always advise enthusiastic players to keep an eye out on real life. Mind your health and your relationships. Real life, family, friends—they all come first. Of course you can be friends in-game and even build meaningful relationships there, but that's no substitute for living a well-balanced "real" life.

I've been an avid gamer in the past, and right now I'm a very avid developer. I try to balance that in real life by playing sports and exercising three or four times per week. Going out on walks, to the movies, meeting up with friends. "Balance in all things" as a character from Baldur's Gate would say.

Attaching a price tag it (done!) and trying to spread the word through relevant channels (in progress). Posting on Hacker News has been a thoroughly enjoyable process so far and I look forward to meeting more great minds.

Don't sweat it! I did get an older version of Angeldust running on OpenBSD with pledge and unveil without problems. It's just not a market I can comfortably cater to at the moment. Kick back and relax for a moment and there'll probably be a binary or source distribution for *BSDs too. Same with Raspberry Pi. Game runs beautifully, but I have no great packaging and distribution process yet.

In addition I also ran Angeldust on Haiku. There is no reason why a product like this wouldn't run everywhere.

(Also shoutout to theo and/or tedu if you're here.)

Since your message popped up right at the top I'm going to reply to it, hopefully summarizing my view on this and addressing the lively discussion about the game's name.

There is a special meaning for the game. The short backstory is included on the game's website. Here's the gist: in the game's lore Violet and Crimson are angel siblings. Violet is the angel of creation, Crimson the angel of destruction. Due to unforeseen circumstances both angels shatter to dust. This dust dwindles towards the planet where the game takes place. Subsequently parts of the game world and its inhabitants have been permanently infused with magical energy. Energy derived from the dust of angels. Angeldust.

"Angeldust" is beautifully fitting and it's a beautiful name in my opinion. I wouldn't want it any other way. There's an entire design language behind the lore, the names and composition of the game world. To a casual observer this might not be apparent or make sense. But everything ties together perfectly.

I've seen discussion and jokes about the name before when reaching a larger audience. It's great that people have an opinion on the name and some of it's (in my view) lesser known historical usages. As far as I'm concerned Angeldust is a pretty cool video game product with unique properties. In no way, shape or form do I want to endorse or conjure connection to other, past uses of "Angeldust". I hope you can appreciate the context, connection and product that "Angeldust" refers to for me.

And then I get there's a bit of confirmation-bias and pattern-matching going on with my name. I wouldn't have expected otherwise from the smart hackers here. I have no good argument against this. I wasn't aware that I share my name with a (for you all, well known?) dude from the past. Given finite first and last names, collisions are bound to happen. Maybe we should start using MD5- or SHA-hashes as names to prevent this in the future.

Don't worry about a thing. Over the years I've come to appreciate feedback in any shape, way or form. Anyone taking the time to reflect on my product, my work or me as a person is someone who's apparently invested, but possibly didn't get the exact thing they were hoping for. I can only listen and learn from this.

It might also help that I'm Dutch and we're supposedly pretty "direct" by default. I've also learned from dealing with Russian players who are even more versed at that craft.

Migrating requires downtime since the game server runs as a monolithic entity. I migrate between dedicated servers and VPSes based on expected demand. Right now we're running on big metal to be able accommodate many players coming while I'm more actively promoting it.

When the hype settles down I'll probably move back to a small VPS. I always joke that Angeldust and the server would even run on your toaster. I bet it would even be able to serve hundreds of simultaneous players before turning into toast.

I'm going to give a sentimental answer instead of a fully accurate one. This also came up during the livestream, so it's a great question!

When I was a five or six years old kid I used to program on our home computer, a Philips P2000. Monochrome green on black CRT, Zilog Z80 CPU, different ROMs for running BASIC or Pascal or whatever you hacked onto it. My very first program drew Christmas trees on screen. Very appropriate to share this story right now. I immediately showed my mom, who wasn't really impressed, because she didn't understand what I had done. I had told my computer what to do—wow!

Then one day I was walking around the schoolyard imagining the world around me being digitized and available as large, 3D blocks inside my computer. "My" P2000 wasn't advanced enough to pull it off and similarly I wasn't advanced enough to program something like that. But the idea of having a coarse, 3D replica of my world and being able to have fun in there with my school buddies always stuck with me.

Many years later, at an intellectual dead-end in my job I took a month-long vacation to regain focus on my life and myself. And I suddenly remembered my childhood dream, or fantasy, of that 3D world. And I realized that computers were now advanced enough and I was advanced enough. So I decided to take on the journey, channelling my inner five-year old.

Some players have joked about this with me. That they're actually investing their time in the figments of a five year old's imagination. And that's not far from the truth. Even though Angeldust is better, more beautiful and more professional that I had ever imagined, it is the actual implementation of my childhood dream.

So the answer to your question is that I started development somewhere between being five years old and now. Hopefully this answer still gives you some joy and insight!

Both you and Exuma: thanks for the down to earth answers! I'll give it my best shot.

Good follow-up question! As for the read state, you're already golden in the sense that you only read data and don't update it. If a chunk needs world or entity data from a neighboring chunk—or even halfway across the world—you can just follow pointers there and you know the data is available and accurate.

For the write state, you're absolutely right that entities will need to transition between chunks. The server looks up the destination in the "active chunk set" I mentioned and then uses per-chunk std::vector<>s guarded by a mutex to push "migrating" entities. This requires a mutex since multiple CPUs/cores/threads/chunks can be pushing entities to the same destination chunk. These mutexes largely have zero to little contention.

Does that answer your question in an acceptable way?

Thanks! A slight word of warning though, something that also came up during yesterday's livestream:

I've been really lucky to be able to successfully fulfill my childhood dream by making this game. But like Freddie Mercury sung: it's [not always] been a bed of roses or a pleasure cruise. I've sacrificed progress in other areas of my life to see this through to the end. I hope to catch up there starting as early as next year. Nonetheless I definitely wouldn't be the same without having taken on this adventure. I've grown so much as a developer, an entertainer and even as a person by creating Angeldust.

Of course! I can't distribute iOS apps outside of the iTunes App Store, but I do have DRM-free, standalone versions of Angeldust for macOS here:

Itch.io: https://metagaming.itch.io/angeldust

Steam: https://store.steampowered.com/app/488440/

If anyone nows a way to distribute iOS 6.1+ apps that doesn't violate my agreements with Apple, get in touch with me :D!