Abstract public member variales?

I have a rather awkward problem domain and I have found a potential
solution, but it is rather tentative and unsettling. The problem with
it is that it exposes member variables almost directly to the user,
almost as if they were public.

The domain I am dealing with is an adventure game that involves many
various items and creatures. Each item or creature will have many
properties that make it distinct from the others, but the nature of
these properties is not all known in advance.

The entities in the game will move around and have interactions which
will be affected by the properties of each entity in some manner and
each interaction might make use of any fixed set of properties, up to
all the properties.

Enough of these properties and interactions are known to make a
working implementation, but it is guaranteed that new properties and
interactions will be created in maintenance, enough so that I cannot
depend on any fixed set of properties.

The natural solution is to represent each of these amorphous entities
as an object and the properties of each object are dictated by the
class of the object. Using many classes all the possible combinations
of properties needed for the game can be created, and of course many
more classes would be added in maintenance.

Unfortunately, I don't know which entities will interact with which
and I have no means of creating a reliable class hierarchy to
organize them. In each interaction, each entity would need to be
dynamically analyzed to determine which class it belongs to so that
its properties could be accessed. I might do that with the visitor
pattern or a switch statement, but I found another way.

Since I cannot make any reliable relationship diagrams between the
entities, I represent them all as objects of a single class, like
this pseudocode:

class Entity {
Object get(Property);
void set(Property, Object);
}

In Entity I replace a potentially very large number of getters and
setters by a single parameterized pair. Entity has no encapsulation
and no real methods, but the great thing about it is that its public
interface will never have to change during maintenance.

The Property class is completely featureless, with no members of any
sort, so creating new properties is trivial.

At first I thought that this was a horrible design because it is
making everything public, but then I realized that the member
variables are not truly public because they can only be accessed when
the correct Property object is available. Since I will not be making
the Property objects globally available, what can access what will be
very strictly controlled.

Then I realized that I could create more complicated properties that
behave just like ordinary properties in that they get and set values,
but they are actually composed of other properties and use them to
compute a derived property. That realization suddenly makes this idea
all the more interesting!

Does this match some design pattern that I should know about? Is it
just a horrible idea?
.