Right; I’m saying that attaching properties to each endpoint of an edge isn’t fundamentally different from having edges with different weights in each direction. Mathematically speaking, they’re isomorphic.
It might be clearer to call them directional edge weights, but it’s not a concept that’s alien to graph theory.
Well, coffee cups and donuts are topologically isomorphic…but it probably still makes sense to treat them as different in-game objects anyway.
Not really. One is a container and the other is edible. Both can be thrown. One has a handle. One has a hole. Still just “things” at their base root.
I wouldn’t make them base objects. I’d still inherit from “Thing” that has many of the common properties of an IF object.
They both have a hole, but right. Donuts and coffee cups are both objects, and you presumably have a base object class. They’re both (probably) movable, and you probably have a subclass of object for that. The coffee cup is a container, and you probably have a class for containers, but not all containers are portable and not all portable things are containers, so you presumably have container-specific properties and methods on the container class, rather than on the general object class or on the portable object class. And so on.
One of the things I love about IF is the idea that you can create something that seems perfect, but if you look under the covers you realize there are a lot of smoke and mirrors.
As an established application architect, I also understand that perfection is not only impossible, it’s a net-negative in software engineering. I can’t count how many over-engineered systems I’ve come across in my 38 years in IT.
Your comments triggered warning bells because I started thinking about ILocationNode and IThingsWithHolesNode and realized that abstractions are just really bad ideas. It may help you think things through, but it’s a rathole you should avoid at all costs.
Flat, simple, reusable patterns are better served without complex object-oriented abstractions.
I’m using C# and a graph (which is just a List of Lists) because of Linq, which allows me to query the graph in any way I choose. I don’t need abstractions because Linq gives me a lens into everything in the graph. Here’s an example, though I’m not sure I’d ever use it:
public List<IThing> FindImmovableVisibleContainers()
{
return Nodes.Values
.Where(node => node.Data is IThing)
.Select(node => node.Data as IThing)
.Where(thing => thing.Properties.Any(p => p.Name == "container" && p.Value == "true") &&
thing.Properties.Any(p => p.Name == "visible" && p.Value == "true") &&
thing.Properties.Any(p => p.Name == "movable" && p.Value == "false"))
.ToList();
}
I get the urge to abstract everything, but I’ve learned not to do that and produce better, more readable, more maintainable code.
Yes, I think so too. Half of an IF framework is set theory.
All the things within reach. And which are currently part of the story. And which the player is not too encumbered to lift.
Those queries have to be completed first. Then pass them as objects to construct the inputs acceptable to the parser.
Well, that’s pretty strong. And in the end it’s your code, and I’m (still) not trying to talk you out of anything.
But what you’re saying is mostly true of application design (and almost all game design)…but as I understand it you’re not trying to write a game, you’re trying to write a game engine, a framework. That is, you’re not hammering a nail, you’re trying to design a hammer. Those are two different things, particularly if you’re expecting a lot of people other than you to use the hammer, and you want to accommodate them attempting to use the hammer in a variety of different ways.
Back in the late '79s implementing Zork by first designing a virtual machine would’ve been “over-design” if all they wanted to do was implement Zork. But I think it’s only because Joel Beres and Marc Blank decided to dive into that particular rathole that we’re even having this discussion.
Yes, a platform can have more complex moving parts. I just try very hard to simplify in making every design decision.