[messages] [Module Design] Re: Ownership Model

viewofheaven viewport2heaven at yahoo.com
Fri Nov 4 05:45:25 MST 2011


"JustaBill" wrote:
> Am I interpreting all of this correctly?  Sorry, I'm not trying to be
> obnoxious, but I'm sort of overwhelmed by all of this information and
> not really sure what it all means.

Spot on! You're as quick in interpreting messages as you are competent
in exploring the Vassal engine.

Spot on, with just a few exceptions...


"JustaBill" wrote:
> You've had trouble getting help from the other developers, but I have
> the help you've been looking for (not sure what that means).

Other developers are helping out just fine, we're all volunteers here.
Just that Vassal engine isn't quite as advanced as it __can__ be. There
are no animation threads possible (though quite a few here have asked
for it, and even conceptualized it correctly). Some of the code is just
plain oddball (Traits engine takes the lead on that). Let's just say, I
see Vassal engine becoming much much more. And I see you being able to
stretch our (developers') imagination and programming to healthy
lengths.

You have what I'm looking for. The drive to stretch the Vassal engine to
its limits, and the ability to do so too.

Also, you seem fresh, on Vassal engine, that is. Most Vassal veterans
are entrenched in doing things the Traits engine way, and may have given
up daring to dream up more for Vassal. Many veterans have been "beaten
into shape (and limits)" to conform to the Traits engine, not the other
way around. The Traits engine sure did unravel my Java programming
skills whenever I spent 1-2 hours with it. :/

Newbies who are non-programmers may or may not stick with Vassal,
depending on how fanatic they are about the games they are making.

Newbies who are programmers seem to come in quite hard and fast, doing
quite a lot with the Vassal engine right off the bat. Then they realize
there are limitations, then post for feature requests, then probably
leave once they got busy with something else.

I'm hoping you are that fresh driving force that will stretch Vassal and
us developers well. :) The ability to dream.


"JustaBill" wrote:
> You don't have any specific information for me on the ownership model.

I will, once I read your questions carefully. (I'll reread your original
post again right after this). I have neat access to the codes, so much
so that I can know most anything about the Vassal engine within 5-10
minutes of digging.

Also, if you'll phrase your questions neatly (not that you didn't),
it'll make it even faster for me to address them.


"JustaBill" wrote:
> You recommend I stop using traits and wait for a scripting engine to
> be developed, or collaborate with you to develop it.

I'm a little scared of this exercise (sizable), but I'm willing to take
the plunge. A main developer has decided on Python as the scripting
language. We can just start off with BeanShell2, fashion some convenient
tools (along lines of SendToLocation, and other Traits). Then when
Python comes to Vassal, we can easily port the tools over.

That scripting mechanism was already decided as the way forward. Our
collaboration here will add tremendously to the Vassal engine.

So, why not the Traits engine? The problem with the Traits engine right
now boils down to an "over-extension" of the Traits engine.

You see, the Traits are decorators wrapped layer by layer onto a game
piece. The innermost Trait's values (if set) are superseded by the
outermost Trait's values (if their variables intersect). "Inner" traits
are listed above "outer" traits in the Module Editor when you edit any
game piece.

As such, this layer and Traits concept works just as expected. In
programming any conventional language parser (PHP, C, Java, whatnot),
there are __declarations of variables__. The variables declared further
down supersede the onces above. (In programming variable scope, if
you're familiar with the concept, we also use this layer concept,
implemented in stacks usually).


Code:

declare varA = 1;
if (blah) {
  declare varA = 5;
  print varA; // will show 5, not 1
}




So how is the Traits engine "over-extended"? When we start coding
Behaviors as Traits. Before we get confused between Traits and
Behaviors... Traits are __properties__ (variable declarations) while
Behaviors are __operations__ (from value assignments to function calls
to maths operations).

You see, Behaviors should flow top-down. But since behaviors are coded
as layers of Traits as well, we see behaviors being executed bottom-up
(like peeling an onion). This goes against every single logical
programming language out there. HTML, Javascript, Java, C, PHP, you name
it. (Actually, as a quick fix, I believe I can reverse this flow, but
that would break every game module currently out there)

So, before you waste much time unraveling the Traits engine, and before
you feel you have thrown away enough of your life on Vassal engine, I
propose that we work together to get a proper scripting mechanism going
in place of the overloaded Traits engine.


"Justabill" wrote:
> You'd like me to help with writing tutorials and documentation.

Depends on who is faster at doing what. If you're stronger at coding,
I'll do the tutorials and docs. I'm just looking for collaborators. :) I
do have less patience designing games (if only because of the fact that
I can't offload the coding to a crazy hack and slash coder like myelf
:P). I did start out with Pandemic, but very quickly discovered too many
limitations requiring workarounds.

As a first step, we could get familiar with all the Traits. Then we will
be in a position to do the scripting tools quickly.

If you do wanna start building your game right away using the Traits
engine, you can, and I'll support you for that. Just make sure you
_still_ write your game logics in pseudo code (logical human-readable
scripts), then transfer your logic to the Traits engine. Otherwise, it's
easy to get lost working with the Traits engine.

_______________________________________________
Read this topic online here:
http://www.vassalengine.org/forum/viewtopic.php?p=26877#p26877


More information about the messages mailing list