[messages] [Module Design] Re: Ownership Model
viewport2heaven at yahoo.com
Mon Nov 7 22:44:56 MST 2011
> Getting more overwhelmed here. What seemed like a straightforward
> process of learning a development platform and creating a game module
> looks like it's turning into a much larger project ... how does the
> average newbie ever even get up to speed on all this?
The average newbie works around this. As I said, I noticed that newbies
simply bend themselves to fit the Vassal Engine, just as every veteran
> I've just spent an entire evening trying to implement one of the most
> unbelievably simple things: _how many cards are in each player's
> hand?_ Several hours later I am ready to throw the whole damned thing
> in the trash. I can't really express how frustrated I am right now.
As I said "don't workaround these things too much". Veterans hardly have
time to hand-hold a newbie through the convoluted maze (the oddball
Traits engine and bugs) they painstakingly navigated (and worked around
to limited success).
You're a newbie Game Designer. I'm a newbie Developer (no, I really
won't mess up Vassal Engine). I won't consider it rude if you told me
"make this thing work for my convenience". In fact, I'll consider it
inefficient if you tried to work around inconveniences. We want the
Vassal Engine to rival even the likes of GameMaker. So, please don't
waste anymore time on working around inconveniences in Vassal Engine.
Start telling me what you need. :)
> I've read the wiki. I've read the developers' guide. I totally get
> the concept of clearing a global to zero and then having each card
> that meets certain criteria increment that global. But that is just
> the tip of the iceberg ...
And... we should shortcut it right here, at the tip of the iceberg. Work
with me to incorporate __necessary__ enhancements to the Vassal Engine.
__Necessary__ because they just plain cripple the Game Designer if
> This required triggers that call other triggers that call set global
> property methods. Nightmare of keystrokes, but I mapped it all out in
> advance and documented it all in my 3D master Excel keystroke cube.
Again, I desperately implore you to use the latest builds and
NamedKeyStroke from here.
> I got all this working only to discover that "piece ending movement"
> only applies to mouse drag-and-drop. Seriously? If I use a keystroke
> to Send a card to the table, this apparently doesn't count as ending
> movement on the table.
We may not even need to address that __inconsistency in handling "piece
ending movement"__ if we just gave you a "Deck::CountCards" function.
Please, brave Jedi, your R2D2 is here! Don't let engineering defects
hinder your force powers!
> Fantastic; everything I've written is useless, unless I want to trap
> every possible keystroke that moves cards from one map to another and
> have all of those trigger the increment/decrement
> triggers-wrapping-triggers. I don't have the energy to even
> contemplate that.
Erm, that's how I gave up rewriting Pandemic. :) You're not alone,
mutant. Mutant and proud! (Wait, weren't you a Jedi before? Just
kidding, X-man. Great movie, that First Class, by the way.)
> Now, I'm sure somebody is thinking "dumb noob, that's what you get for
> having too many keys; should have just forced the players to drag and
> drop everything".
Yes, that is pretty much how the current Vassal Engine is to be used.
But you and us (Vassal community) are gonna change that. In fact, I
envision a better version of Civilization 5 done using Vassal Engine
(see my proposal here), just as how Transport Tycoon Deluxe was
infinitely improved by OpenTTD and Simutrans.
> But this is not practical.
Of course it isn't. Many veterans have successfully resorted to coding
custom Java classes (in place of Traits, look at VASL). The point is not
that we should not learn Java (or similar scripting tools), but that
Game Designers should not have to compile their custom additions.
If you're still up for it, we could add a new Trait that reads
beanshell (latest version actually is beanshell2).
> I suppose you'll tell me this is another reason to scrap Traits and
> invest in a scripting language.
No, we don't scrap the Traits engine. Never throw away something we can
Even as we do the scripting engine, we still require existing constructs
(read "Functions" by programmers), eg __Behaviors__ like SendToLocation,
CanRotate (should really be just Rotate), etc. And how these constructs
interact with each other (eg how SendToLocation may be influenced by
DoesNotStack) will need to be thrashed out now, way before we start on
the scripting engine.
Do realize that much of that work (relating Behaviors with Behaviors and
Traits) were already done, and their logics are existing in the current
Traits engine. The developers of Vassal Engine had done all that in the
As a stop-gap measure now, as well as an exploratory exercise, we can
start by correcting the Traits you are using. Shall we?
> Can it really be true that in the history of Vassal nobody said "hey,
> we need to expose a numPieces property for each map and board"?
Yes, it is true. Apparently, a group of Game Designers had gone the way
of the "custom Java classes", and never looked back. As can be expected,
there are virtually no limitations to that approach (it's like crafting
your own set of Traits).
As a programmer myself, I can tell you this bad habit that mean coders
often have (I speak for myself). We often feel so "usefully busy" when
doing repetitive work, that we actually miss opportunities to "cut down
amount of work". It is possible that we found the integrated circuit
boards (custom Java classes) approach so powerful that we forgot to turn
them into microwave ovens (scripting constructs, Traits constructs).
> I know everybody's working hard to make it better, and I appreciate
> that. But _holy crap_ am I sick of herding cats right now.
Leave the cats be. Let us create catnip for that. We need you to bend
the minds of greater threats, brave Jedi. May the force be with you. (I
know I am. :))
Read this topic online here:
More information about the messages