Ownership Model

[viewofheaven]

@JustaBill

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

@JustaBill

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.

@JustaBill

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

@JustaBill

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.

@JustaBill

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!

@JustaBill

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

@JustaBill

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.

@JustaBill

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

@JustaBill

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

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

As a stop-gap measure now, as well as an exploratory exercise, we can start by correcting the Traits you are using. Shall we?

@JustaBill

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

@JustaBill

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