171–180 of 204 posts
1) How did you handle such big distance draw? Are you using lod and occlusion culling? Was it PVS or rather depth buffer based solution? Did you use bsp or octrees or something else?
2) what data structures did you use to hold the world and it's objects? And how much of it is kept on the server vs client?
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.
Steam: https://store.steampowered.com/app/488440/Angeldust/
Android: https://play.google.com/store/apps/details?id=nl.metagaming....
iOS: https://apps.apple.com/us/app/angeldust/id687448635
PS. The author mentioned it was free on Android fyi, because it only has the "Cartoon"-engine currently. If i'm not mistaken.
Earlier quoted context omitted.
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.
"Today's tools" do not necessarily allow you to make anything like this. I'd even go as far as to say that an array of ancient hardware and software are the main reason for being able to make a product focusing on compatibility and performance. Not aiming for a moral high ground, but just looking at it practically. I started Angeldust on my trusty, white MacBook1,1 mentioned in the starting post. Having only an Intel…
Earlier quoted context omitted.
"Today's tools" do not necessarily allow you to make anything like this. I'd even go as far as to say that an array of ancient hardware and software are the main reason for being able to make a product focusing on compatibility and performance. Not aiming for a moral high ground, but just looking at it practically. I started Angeldust on my trusty, white MacBook1,1 mentioned in the starting post. Having only an Intel…
Your stories are great to listen to. Is there any other place I can follow you other than YouTube 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.
This looks cool! 250K players is impressive. Are those real players or bots? Interesting to know more about performance too, what is your rate of update per second? How long does it take to process a tick? Do you have a tech blog? Would be really interesting to learn more.
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.
Awesome job. I'm working on a game with some similar technical challenges (landscape is based on actual Earth though) and backend is in Java. I'll see if I can get my friends to play.
Earlier quoted context omitted.
Thanks for the explanation! I happened to be thinking of similar multithreading ideas (chunks and ping-ponging states) recently, but was stuck on what happens when computation happens across chunks in multiple threads. e.g. an object move across chunk border, or an object interaction affecting two objects in different chunks. Could you elavorate on your approach about these? I'm really curious
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 lo…
> The server looks up the destination in the "active chunk set" I mentioned
but what if the entity teleports to an inactive chunk?
> and then uses per-chunk std::vectors guarded by a mutex to push "migrating" entities.
Will these migrating entities participate in later calculation within the same tick, or are they excluded? If excluded, what happens when there are two mechanisms that mutates that entity, but the first one put it into the migrating list of another chunk? If included, the thread of which chunk will continue this calculation?
And when some kind of mechanism mutates two entities in different chunks, which thread is chosen to run this mutation? And how does it mutate the state for an entity in the other chunk?
Meanwhile since you mentioned ticks, (just to be sure) are you using a barrier per tick to wait for all threads to finish the same tick? When are the migrating entities merged into the main list, and are you using another barrier for that?
Earlier quoted context omitted.
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 lo…
Thanks! The idea of having a list of migrating entities per chunk is good, and it avoids locking on the list of all entities in a chunk. But I still have some confusion about it: > The server looks up the destination in the "active chunk set" I mentioned but what if the entity teleports to an inactive chunk? > and then uses per-chunk std::vector s guarded by a mutex to push "migrating" entities. Will these migrating…
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.
Earlier quoted context omitted.
Same. I actually went through and typed my Lastpass-generated password. That was a painful exercise. Anther oddity is that the Android version is free while the Steam version costs money. Is there some other kind of monetisation strategies for that version?
Nope. On Google Play I'm limited to a 50 MiB APK size so I can only ship assets for the "Cartoon" visual style. As you don't get the full experience of having both the "Cartoon" and "3D" visual styles available I find that not charging for the product is good option. Also: my preconception was that Android users are more likely to pirate a product. So to prevent them from downloading a malware-laden pirate APK and ge…