281–290 of 407 posts
What's surprising to me is Dwarf Fortress author uses Visual Studio Community, rather than the paid version of that IDE: > "In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above." Surely there has been years where his revenue has exceeded $1 milli…
Earlier quoted context omitted.
"Tool" is still a class, with perhaps very generic polymorphic methods (e.g. do_default_action() ). The problem is not polymorphism per se, but rather about having a deep class hierarchy aka lasagna code. My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.
Nah, the problem is OOP polymorphism that conflates too many separate things. If you have a language that can actually express "implements this interface", "has this member", and "delegates this interface to this member", then you don't need traditional "extends" inheritance at all; sometimes you want to do the exact equivalent (and you can), but most of the time you want to do something narrower.
I love the idea of Dwarf Fortress and I think the internet purest mission is to disseminate works of passion such as this, not to sell me ads instead. That said, I can't get past the ASCII interface -- I'm a huge fan of IF games (which used to be called "text adventures" in the olden days) and I can deal with spartan UIs, but for real-time strategy/sandbox games, I absolutely need some sort of graphics. Tiles, at lea…
Earlier quoted context omitted.
> For games that want this level of complex interaction between components, entity component systems are the way to go. Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well. One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so o…
> One promising direction is getting rid of entities. > > Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components You are essentially describing ECS here. In ECS, entities are nothing but a "handle" without any additional data, normally just an integer used to link common components together.
If entities could be IDs to which components are connected, or containers holding components. Either case has disadvantages.
If entities hold components, then iterating over components means iterating over entities, which slows down all systems. A rare type of component still degrades with adding entities.
If instead components link to entities, and you want multiple components to interact, then these interactions slow down the system because of multiple lookups that need to be done.
Author proposes to use a graph structure between components, getting rid of entities-component duality. Proposes to use pointers which allows calling into any component and process then all required components.
I am not entirely sure if this would solve all problems, but this seems to be the proposal. It seems setting up the graph dynamically would be quite the task, though. For example, I don't immediately see how to guard against cyclic behavior and too many calls into a single component etc.
> What’s your favorite bug and what caused it? > A: It’s probably boring for me to say, but I just can’t beat the drunken cat bug... That was the one where the cats were showing up dead all over the tavern floor, and it turned out they were ingesting spilled alcohol when they cleaned their paws. I think that bug explains very well just how deeply complex Dwarf Fortress really is. Drinks can be spilled. Some drinks ha…
> What’s your favorite bug and what caused it? > A: It’s probably boring for me to say, but I just can’t beat the drunken cat bug... That was the one where the cats were showing up dead all over the tavern floor, and it turned out they were ingesting spilled alcohol when they cleaned their paws. I think that bug explains very well just how deeply complex Dwarf Fortress really is. Drinks can be spilled. Some drinks ha…
Other amusing DF bugs: Dwarfs trying to clean their inner organs (dwarf wounded, doctor closes the wound, dirt stay inside) Undying children in the moat water (for years... just swimming there...) Killer carps (there was a long time during which carps were really overpowered because constant swimming was buffing them up really good, dwarfs getting close to water sources were eaten by carps) Catplosions (Tarn loves ca…
My understanding of the legend is that a player began experiencing a catsplosion, and wanted to find a way to get rid of the cats. So he started tinkering with the game a bit, and eventually tried setting the blood temperature to a very high number. This killed the cats, but also had the unfortunate side effect of setting them on fire. And the cats were multiplying faster than they were dying, so there was a massive, expanding fireball of burning cats.
If this legend is wrong, I'd love to hear another version.
This is a little bit of a hijack but if I wanted to start coding games as a side project, where would I start? Which platform? Mobile, PC, console? Any good introductions on the subject of solo game development? I know I can google this, but I trust HN users more than the Google algo.
Earlier quoted context omitted.
Nah, the problem is OOP polymorphism that conflates too many separate things. If you have a language that can actually express "implements this interface", "has this member", and "delegates this interface to this member", then you don't need traditional "extends" inheritance at all; sometimes you want to do the exact equivalent (and you can), but most of the time you want to do something narrower.
Is that an example of decorator pattern?
In my experience it is nigh impossible to design-pattern your way out of a language simply being unable to express what you need it to express without incurring a severe performance penalty (anathema for game development) or resorting to code generation (which is itself prone to ending up as a Gordian knot).
Earlier quoted context omitted.
Never write GUI code then.
Yeah that's the one downside of not doing OOP. OOP is the only way to do GUI stuff. Nobody on the face of the earth has ever used Functional Reactive Programming. It's a made up concept. In fact it's also definitely not one of the concepts that inspired the most popular pattern in React.
Of course it's relatively easy to build shiny clean wrappers around the dirty work that others have had to do on your behalf.