[messages] Edit: [Module Design] Re: Ownership Model

JustaBill martinson2005 at netscape.net
Sun Nov 6 21:40:07 MST 2011


[This message has been edited.]

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 ... learn a scripting
language, get familiar with two additional upcoming code branches,
compile a list of feature requests required to make my module work,
write documentation ... how does the average newbie ever even get up to
speed on all this?

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.

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 ...

First, I have seven different player hands and at least four other
maps/boards.  So, in theory, every time a card moves — _anywhere_ —
I have to have each of those hands clear its global and count all of its
cards, since I don't really know which hand the card has come from
and/or gone to.  Over one hundred cards each have to wake up and try to
increment some global based on where they think they live at the moment.
 This is horribly inefficient and causes a lag of like 20-30 seconds
every time somebody drags a card.  Total deal-breaker.

So to improve performance, I decided to update totals only for the cards
that are actually moving.  I wrote a bunch of traits to be triggered by
"piece ending movement on" at the map level.  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.  When a card
ends movement on any map, I check to see if its new board differs from
its old board, then increment a global associated with the new and
decrement a global associated with the old.  This generates a lot of
error reports since not every map has such a global, but I can fix that
later.  At least the counting works.

Or does it?  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.  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.

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".  But this is not practical.  Sometimes you have to
discard a lot of cards, taken from various places.  It's not possible to
do that with the mouse unless you drag them one at a time.  If you drag
the group to (say) the discard pile, only the one(s) that end up in
actual physical proximity to the discard pile actually land there; the
others land wherever they happen to be based on the deltas between their
starting positions.  So some of them land on top of a draw deck, or some
other stack of cards, completely corrupting the game state.  Thus, it is
absolutely essential to have a Ctrl-D Discard command that performs a
Send to Deck.  But of course, this completely thwarts everything I've
spent this evening crafting to count the cards in the hands.

I suppose you'll tell me this is another reason to scrap Traits and
invest in a scripting language.  Well, I've already invested weeks in
writing a module that's 95% ready to play.  I really don't want to
"start over" on the implementation of all my behaviors -- especially in
a development framework that hasn't been tested yet and (by definition)
is going to require yet another rewrite when it has to be converted from
the temporary scripting language to the "real" scripting language.

Sorry about the rant.  I'm just completely fed up right now with the
fact that it takes fifty-three steps to find out how many cards are in a
freaking hand.  (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"?)  Even worse, just about everything I try requires several
different attempts because the capitalization or naming isn't consistent
and the use of dollar signs isn't consistent and you never know in what
context you can and can't get to currentBoard or CurrentBoard or
oldBoard or oldLocation or whatever the hell property you _think_ you
need for the trait you're working in.  Things you think you can
logically infer from one part of the system simply do not work in
another part, as if every trait was written by a different developer.  I
keep writing Report actions to disclose out what I think my properties
are holding, and 90% of the time they spit out _blanks_.  I just want to
scream, so here it is ... my virtual scream.

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.

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


More information about the messages mailing list