91–100 of 204 posts
This comment will get downvoted but, dude, you are a GOD tier programmer. How?
For the senior citizens viewing this they might relate the term "AngelDust" with the dissociative PCP, let me assure them though, it hasn't been called AngelDust since the 70s. You'd be much more likely to hear it referred to as "wet" or "sherm". IF you went to the ghetto and tried t buy Angel Dust they'd think you were a cop. It's like calling weed "dope". Just a little disambiguation from a drug name etymologist :)
This game is not available in the Dutch Apple App Store :(
This looks impressive. Can you go into how you implemented the immutable world state each tick a bit more? I'm developing a game myself, and figuring out a good method of multithreading it took a lot of work. While I am content with the results, I wouldn't say I arrived at a good solution. It sounds like you went with a purely functional approach? Did you rebuild the entire gamestate each tick, or keep a list of chan…
The Angeldust game world is tracked in an "active chunk set". A chunk is a 2D part of the world, 32x32x64 in-game blocks (meters). The active chunk set tracks only the chunks that contain, or are near, players. This chunk set is processed in parallel on any number of threads/cores configured in the server settings file.
Angeldust tracks two states for the data contained in each chunk, kind of like an array of size 2. Each tick, one state in the array is the immutable "read"-state and the other is the mutable "write"-state. Every tick these states ping-pong between the roles.
During processing the server processes the read state and copies over unchanged entity/world data by simply pushing pointers to that data into std::vectors in the write state. For things that did change I push a new pointer into the write state and clear up the old pointer in the next tick. Pushing pointers saves memory bandwidth since you don't have to copy all entity data for every tick. And still you can guarantee that the "read"-state will be unmodified so that other CPUs/cores/threads can freely access all of the data and pointers.
On the livestream I discussed a few cases where I do use (largely uncontested) mutexes for data synchronization: for friend chat and private chat I do a lookup of destination hero pointers in the "hero map" and then lock/unlock the hero's mutex for pushing chat messages into a vector.
Does this make sense? Let me know if I should elaborate. I will probably take a nap now, but I'll answer you (and others) tomorrow.
I'll also do another livestream tomorrow, because I feel everyone on HN has very useful questions, feedback and ideas.
How did you afford taking off years of work to develop this? Did you have a lot of capital / runway? Low cost of living? Kudos for this extremely well polished project. This is the dream many of us have but can't or won't embark upon. This is very inspirational.
Good question. I started working right after what we call "middle school" in the Netherlands which translates to high school I think. During the daytime I would work my job and in the evening self-study for the "Open University" we have here. I lived with my parents during this time and could save up money as a buffer. Thanks to that support I could financially bridge these past years of development without worrying…
How long did it take you to reach 250k players, and has there been marketing involved?
This HN post is kind of the first attempt at getting the game out to "the public" aside from passively being present on app stores like Steam, Itch and Google Play.
Earlier quoted context omitted.
While I would advise against open sourcing the core of the game, opening the client api may be a good idea - perhaps others can write clients for it, but there may be issuing around people making bots to cheat the game.
I wrote a "bot" myself in the form of a network simulator for general and load testing of the server. If players were to automate the game I'd be more than happy to make a special server where we could show off their work. Making an agent navigate an open 3D space and performing planned tasks would make for an impressive demo for all parties involved.
What are the advantages of using your custom engine instead of unity, unreal engine?
In addition I have complex, dynamic geometry to render. And I wrote a custom, fixed-precision integer math library to prevent rounding errors for the almost infinite game world. Other products have weird rounding errors near the start, the middle or end of their worlds because of inconsistent floating-point accuracy. Moving to doubles only mitigates the problem instead of solving it.
And then it's just efficiency too. I have no idea how or why Unity or Unreal will treat my assets. As demonstrated on the stream: the game instantly switches between visual styles and texture quality. It lazily loads all resources so the main thread is only stalled when doing bulk uploads to the GPU. This makes the game start up in less than a second, something I couldn't pull off with a COTS engine.
Let me know if this answer didn't address your question fully.
Earlier quoted context omitted.
Thanks so much! Finally sharing the end result of all my hard work feels really good. And seeing so many visitors swing by on the livestream is insane!
Yeah. I'm definitely going to follow you for more updates. It will be interesting to slowly learn from you via osmosis as I've been interesting in developing browser games for a long time. Seriously impressive to see what today's tools enable creative people like you to do as a team of one.
I started Angeldust on my trusty, white MacBook1,1 mentioned in the starting post. Having only an Intel GMA945 for powering a 1280x800 display and trying to get a decent frame rate forces some design decisions. I quickly ran into optimizing for GPU overdraw and resources instead of being bottlenecked by the dual-core Intel CPU.
Then I ported the engine to iPhone 3GS where you get the exact opposite situation: the GPU can push lots of pixels to a 480x320 screen, but the ARM CPU is struggling to keep up. Just this 2006/2009 era combination of hardware alone forced me to be efficient with both CPU and GPU. Eventually I even got the engine running smoothly on a first-gen Raspberry Pi on a 1280x1024 display which is no small feat.
I think if you start from "today's tools" on "today's hardware" it's entirely too easy to consider any older platform inaccessible or obsolete, while if you work the other way around you appreciate the sheer power older devices have when used properly. Then moving onto newer hardware is just icing on the cake and just shows you how ridiculously powerful a modern 6-core Ryzen with an appropriate GPU is.