Boxing - creating your own property system

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've heard something about reflection in the boxing of variables. I need to
create my own customized property system, and thought that I could just box
variables in objects, but the local MSDN page says that the boxed type and
the value type resides in different parts of the memoery - hence practically
two separate variables. How do I make the boxed type a reference to the first
variable?
 
Unlpt said:
I've heard something about reflection in the boxing of variables. I
need to create my own customized property system, and thought that I
could just box variables in objects, but the local MSDN page says
that the boxed type and the value type resides in different parts of
the memoery - hence practically two separate variables. How do I make
the boxed type a reference to the first variable?
Click to expand...

Could you give more context of what you're trying to achieve?
Especially why you want to do what you want to do, because there might
be other ways to reach the goal you want to achieve, e.g. property
descriptors.

FB

--
 
'course. This is for a game engine purpose, in which all gameplay-related
objects derive from a base class 'actor', hence they are all 'actors' since
they play out a part of the game play. For the following reasons I need to
address each object's public properties: To allow the user to change
variables (that are made visible), to save object states to a file (for
saving an edited level or saving/loading a savegame) and copy objects back
and forth between level wrappers. Now this might seem redundant and clumsy,
but as far as I know, using .NET object serialization will not suffice, as
actor classes are likely to change implementation very often, so that storing
variables by name and type is important.
The trick is to implement a virtual ExposeProperties() in each actor that
calls an AddProperty(object property, string name, string displayname, string
category, bool config, bool concealed, string description) function to add a
reference to each variable that the actor wants to make configurable (if
concealed=true it is not accessible to the user).
Further, I am aware of shallow vs. deep cloning. Therefore I implement my
own reference object that stores both an object reference and a ID number
that is uniqely assigned to each actor in a level. The strong reference can
update its reference by querying the level class for a reference by ID
number. Hence a bunch of actors may be copied into another level (level is
the livingspace for actors), and then their internal references may be
updated to mirror the references in the original level.
You can refer to the Unreal engine for my inspiration. Its property system
is probably based on its scripting support, so probing and analysing
non-value types like enums and structs like vectors is automatic.
I know that implementing all this is going to be hard, but for the start I
need to store reference in list to different variables.
 
Unlpt said:
objects derive from a base class 'actor', hence they are all 'actors'
since they play out a part of the game play. For the following
reasons I need to address each object's public properties: To allow
the user to change variables (that are made visible), to save object
states to a file (for saving an edited level or saving/loading a
savegame) and copy objects back and forth between level wrappers. Now
this might seem redundant and clumsy, but as far as I know, using
.NET object serialization will not suffice, as actor classes are
likely to change implementation very often, so that storing variables
by name and type is important.
Click to expand...

Isn't that old-skool OO like in the C days? I mean, with .NET you work
with inheritance and interfaces (through class types and/or additional
types defined through interfaces implemented on the classes).

The advantage of this is that you have compile time checked
correctness. This is always preferable over runtime-checked
correctness. For example, if a class has a property CanBeDestructed,
and it's renamed to CanBeBroken, you'll find references to it in code
at compile time, instead of at runtime.

So if possible setup your engine through inheritance, not through
property bags.

Furthermore, if you implemennt ISerializable yourself, you can deal
with changing interfaces very easily.

What's also an advantage is that because ever changing interfaces
bring more work to the table, it forces you to think a little more
before applying a change, which is always good practise. So I'd advice
strongly to go the inheritance route instead of the property bag route.
The trick is to implement a virtual
ExposeProperties() in each actor that calls an AddProperty(object
property, string name, string displayname, string category, bool
config, bool concealed, string description) function to add a
reference to each variable that the actor wants to make configurable
(if concealed=true it is not accessible to the user).
Click to expand...

Please don't go this route, it will give very unmaintainable software,
even for a game engine which is perhaps used once.
Further, I am
aware of shallow vs. deep cloning. Therefore I implement my own
reference object that stores both an object reference and a ID number
that is uniqely assigned to each actor in a level. The strong
reference can update its reference by querying the level class for a
reference by ID number. Hence a bunch of actors may be copied into
another level (level is the livingspace for actors), and then their
internal references may be updated to mirror the references in the
original level. You can refer to the Unreal engine for my
inspiration. Its property system is probably based on its scripting
support, so probing and analysing non-value types like enums and
structs like vectors is automatic. I know that implementing all this
is going to be hard, but for the start I need to store reference in
list to different variables.
Click to expand...

As you want to work with single objects and their custom properties,
you have to have some sort of hashtable with as index the name of the
property and as value the property object.

Though I'd advice against this, see above. The unreal engine was
written in C and had (if I'm not mistaken) a non-OO scripting language.
A modern OO based engine should offer OO-style development so game
developers can utilize the engine by creating subclasses of base
classes, overriding methods / properties of base classes to extend /
modify behavior.

FB

--
 
Thanks for your points.
The first explanation was a bit clumsy, but I was in a real hurry. To
summarize it down to one word, it is late-binding. Well, yes I use
inheritance, but I find the PropertyGrid control that comes with dotnet
superficial. I understand that if the PropertyGrid control is able to probe
and analyse .NET objects I should be able to do so myself. I'll take a closer
look at the ISerializable. Apparently it was the first articles I read on it
that put me off.
I stay away from property bags as in VB6 - because that's ugly.
When I said that actors would be subject to frequent change, I meant that
one maybe finds out one needs to add a variable to the class. If the object
was serialized without any variable names any levels using that object could
not have been loaded anymore.

Correction: Unreal engine is higly OO C++ and a scripting language that
surpasses C# because of its state support and serialization (for gaming
purposes though). In UnrealScript you declare a variable and add () or
(category) and it will popup in the built-in property grid.
 
Back
Top