Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Angeldust – a fast and efficient video game

news.ycombinator.com

Post reply on HN
Print view View original

181–190 of 204 posts

Re: Show HN: Angeldust – a fast and efficient video game

#181

Post by dreamingincode »

ItsFirefly wrote: post #179
dreamingincode wrote: post #178

Earlier quoted context omitted.

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…

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 wr…

I see. It seems sometimes we do have to live with non-deterministic behaviors or even small errors.

I'm still unsure about the following question from your answers: > 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 the entity in the other chunk? My initial thought was this would require adding locking on every entity, since it might be accessed from another chunk/thread. But that's clearly not ideal. Maybe have a separate list for outside-chunk changes, and merge them with internal changes later?

And regarding having two states: How/when are you sending world state to clients? My thought was to clone the current state periodically and send it to clients (can sending takes less than one tick? I don't have an idea). Sending state to clients seems to be needed if the game needs client side predication, hence this question.

Re: Show HN: Angeldust – a fast and efficient video game

#182

Post by Hit_Man »

tanyatik wrote: post #75

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.

Out of the almost 284k accounts, nearly 25k of those accounts have no gold, so probably logged into the game and logged off, without playing the game. And 34k have less than 1,000 gold. Some of the players have 100s of accounts, and those are mainly for claiming land, since each account can only claim 64 plots of land.

Re: Show HN: Angeldust – a fast and efficient video game

#183

Post by Hit_Man »

ossworkerrights wrote: post #26

How long did it take you to reach 250k players, and has there been marketing involved?

The over 283k accounts that are on AngelDust are not unique players. Many players have 100s accounts, mainly for the purpose of claiming enough land to build towns.

Re: Show HN: Angeldust – a fast and efficient video game

#185

Post by TminusDoom »

theredbox wrote: post #55
oneeyedpigeon wrote: post #27

Earlier quoted context omitted.

Not sure why anyone's downvoting you, but I suspect the name is 100% on purpose - it would be quite the coincidence otherwise. I remember a game called Speedball in the 90s, which was very successful - this is nothing new!

Ofc it is on purpose. This guy goes by name Frank Lucas.

Frank Lucas IS a great mind and developer. To make a connection between two people that share the same name and imply similarities on the sole basis of that similarity, doesn't make sense.

Re: Show HN: Angeldust – a fast and efficient video game

#186

Post by ItsFirefly »

lokedhs wrote: post #180
ItsFirefly wrote: post #89

Earlier quoted context omitted.

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…

I've seen some games downloading assets after the application is started. Did you consider implementing it like that?

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.

Re: Show HN: Angeldust – a fast and efficient video game

#187

Post by ItsFirefly »

dreamingincode wrote: post #181
ItsFirefly wrote: post #179

Earlier quoted context omitted.

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 wr…

I see. It seems sometimes we do have to live with non-deterministic behaviors or even small errors. I'm still unsure about the following question from your answers: > 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 the entity in the other chunk? My initial thought was this would require adding locking on every enti…

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.

Re: Show HN: Angeldust – a fast and efficient video game

#188

Post by ItsFirefly »

odrzutowiec wrote: post #171

Hello, very impressive project, great job! I have two qestions, somehow related but not fully. 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?

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. 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.

Re: Show HN: Angeldust – a fast and efficient video game

#189

Post by hummmster »

ItsFirefly wrote: post #135
findyoucef wrote: post #109

Have you thought about porting this to Nintendo switch? Indie community is huge so many games do well on the platform.

Yes. A lot! Unfortunately I've always considered "the big three" consoles completely out of reach for my project. Many players have asked about a port to the Switch and other consoles. I'm confident I'd be able to pull it off technically without too many issues. But I have zero experience dealing with parties like Nintendo and adhering to their (I imagine) very strict policies for games. Being a mostly-multiplayer cr…

might as well start at the official site https://developer.nintendo.com/the-process

Re: Show HN: Angeldust – a fast and efficient video game

#190

Post by verytrivial »

ItsFirefly wrote: post #169
nnq wrote: post #167

The graphic style - oh, my eyes!!! Please team up with a designer, or with a different designer! ...I don't mean the quality, it's understandable resources are constrained. I mean the actual artistic decisions ... it burns your visual cortex with all those colors and textures fighting each other. What's the theme, "kindergardeners on acid meeting Elvis"?! or "South Park but in Fortnite drawn while drunk"?

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…

Not the commentator, but I say "your game, your rules!"

That said, with the same level of detail I'm brought to mind of the original Xbox Fable game which in my humble opinion had really excellent art direction for its day -- a mixture of cartoon-y, arty, and moody but only only at times, not constantly gloomy like modern games. Consistent lighting and selective contrast in detail.

Actually, even the 360 remake was a step backwards! https://www.youtube.com/watch?v=gib34dN0zXI

Post reply on HN