RELOAD!

looking good for you @rolfl ^^

@Duga that's it?

@SimonAndréForsberg Slow day

@Marc-Andre It looks like STS already has JS stuff coming with it

hey

@Simon, don't forget to fix Facebook Graph 2.0 in Minesweeper for Android!

@Duga working on it

any opinions?

private boolean validatePassword(String userName, String password) {
    File dir = new File("players");
    File[] directoryListing = dir.listFiles();
    if (directoryListing != null) {
        for (File child : directoryListing) {
            try (BufferedReader br = new BufferedReader(new FileReader(child))) {
                String firstLine = br.readLine();
                String secondLine = br.readLine();
                if (firstLine != null && firstLine.equals(userName)) {
                    if (secondLine != null && secondLine.equals(password)) {

@bazola does the files contain anything other than usernames and passwords? What about hashing the passwords? Why not name the files to the same name as the username?

right now no, but i am thinking i will add the player data string on the third line. you are definitely right that I should just check the file name, as that is the same as the players username. I thought about using the encrypted value of the password instead of the decrypted version but I am still not totally sure of the best practice. I could implement something like bcrypt since this is on the server

using hash and salt is a good idea, really.

I am sure there's some library that works on LibGDX and GWT.

bah, Android is disturbing...

Error:Gradle: Execution failed for task ':app:dexDebug'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
	C:\Program Files (x86)\Android\android-sdk\build-tools\21.1.2\dx.bat --dex --force-jumbo --no-optimize --output C:\Users\Simon\Documents\workspace\minesweeper\TejpbitMFE\app\build\intermediates\dex\debug --input-list=C:\Users\Simon\Documents\workspace\minesweeper\TejpbitMFE\app\build\intermediates\tmp\dex\debug\inputList.txt
Error Code:
	2
Output:
	UNEXPECTED TOP-LEVEL EXCEPTION:

@sᴉɔuɐɹɥԀ Nice! But I'm sure you can have some extention to provide more support (maybe)

@SimonAndréForsberg one thing I have read is that it is pointless to hash the password on the client side

@bazola both yes and no. Preferably, it should be encrypted/hashed when sent to the server.

right now i am using a cipher encrypter so that at least it is not plain text. ssl would be best but that is complicated because of the websocket thing

@bazola Where did you read this ? I really think it's a good idea, the less time the password is in clear, the less time it is more vulnerable.

It protects against attack where you don't have access to the client machine but you can listen or orchestrate a MITM between the client and the server

@Marc-Andre i think the basic reasoning that I have been reading is that if you hash on the client side, then a man in the middle could use that hashed object to authenticate itself with the server without actually knowing the password

@bazola what if you don't hash the password, won't you still be vulnerable to man-in-the-middle attacks?

@bazola If you can make a MITM attack, you have many more things to worry than using the hash password for authentification... if the password is in cleared, what is the diffence ? At least if it's hash he does not know the password and can't use it on other sites

@SimonAndréForsberg have you thought about the implications of the code being open for viewing as javascript after GWT compiles it? i'm not sure if the code in that answer would be vulnerable to that or not

@Marc-Andre i admit that i wanted to build a simple cipher mostly as a learning experience, but isn't it mostly as effective as anything else at preventing eavesdropping attacks?

@bazola the code produced by GWT is heavily obfuscated. Besides, all JS-code is viewable in the browser.

@SimonAndréForsberg thats what i mean, so if you have your encryption code in the browser, if the hacker really wants that password he can reverse engineer that to get it

@bazola Overall, I don't think you need to worry too much about any attacks in this case. As long as you're not dealing with real money, or very sensitive user data, there is not much of a reason to attack you in first place.

yeah i agree its not really a concern here, as i will never have any payment information transferred with this system, but its still good to think about it

@bazola To get what? The method of encryption you use ? Who cares ? The password is not in the code, just as a content of a variable. He need to 1. do CSRF attack or 2. listen to the connection to intercept something somehow.

@SimonAndréForsberg Unless someone use the same password for another site...

@bazola still adds an additional layer of security compared to if the password is sent in clear text. Besides, hash-algorithms are one-way algorithms. Once you get the computed hash, it is computationally speaking impossible to get the real password back.

^^ that

Is the reason you don't care if he knows what you use for encryption.

@Marc-Andre We all know that there are so many users using the password "123", or "123456" anyway. Just pick a user and a site and start testing!

Anyway I can tell that any serious site is using bcrypt to hash the password... there you go

@SimonAndréForsberg All I'm saying is it's not because you don't any important data that you won't be targeted... weak site are targeted everyday because it's easy and doesn't hurt to have a password db to create hash

^^ that is also true

Monking

all good points

i guess i fully understand now, since what you save on the server side is the hashed version of the password and not a decrypted version

but, i would then need to ensure that the encryption is the same on multiple platforms, because different hashing algorithms would produce different results with the same password as input?

@Marc-Andre I'll see if JSDT can add functionality, haven't tested it much in STS to actually run and debug JS, assuming it can at least do the basic client-side stuff without even firing up Tomcat

right now the goal is that the user can use any device to play the game

@bazola in fact, the same hashing algorithm can actually produce different outputs, as many of them generate their own salts in the process.

Recommended reading btw:

@bazola Sure but you need to inform you're user if the password mechanism is not secure, so that they can use a password that will not affect other accounts

@bazola you should of course use the same algorithm on all the platforms. Common algorithms are often implemented in many languages.

nice answer @SimonAndréForsberg

@SimonAndréForsberg if this is true, how can you possibly deal with cross platform?

pass the salt back and forth along with the hashed password?

@bazola you just make sure to use the algorithm correctly.

i see

some algorithms (blowfish in PHP for example) store the generated salt inside the hashed result, so it is aware of its own salt, then you use that salt to make sure that the hashed password matches the non-hashed one.

Or you saved the salt on the db.

i appreciate the help

yes ^^

I appreciate that you want to secure your apps for your users!

^^that :)

Just don't salt too much, it's bad for your health!

there is a whole lot of code in this gwt-crypto, seems like lots of different ciphers

perhaps this should have been more commits:

> fixed compiler errors, increased version name+code, updated Facebook SDK, made gradle build

why does java even let you compare strings with ==, they are just setting people up for failure

okay, parts of my Minesweeper app works again, but parts of it seem totally broken.

Facebook name isn't retrieved in main menu, and local-player games doesn't work at all...

@SimonAndréForsberg BCrypt also does that afaik

@SimonAndréForsberg You're actually doing what @Duga told you?!

@bazola Why? Because == can compare Object. Why would you have a special case because beginner won't use the much better equals() or compare() ?

@skiwi as I said, "for example". there are likely many hash algorithms that do this

@skiwi yes, I actually am. trying to, at least.

@Marc-Andre i guess that is a good enough reason ;)

I get your point, but it's just really because we think == means something more than what it really is.

@SimonAndréForsberg Is the Cardshifter version in the js branch compileable, as far as you know? I couldn't figure out how to compile it in Eclipse last night, just wanting to make sure it's user error and that it is supposed to compile

@sᴉɔuɐɹɥԀ I think it is, yes.

I think you had the same problem as every user who start doing Java 8 in eclipse. There is a bug somewhere that you need an extention to fix.

Or there is something else

@Marc-Andre the compiler could also just warn that you are comparing strings that way so that you don't make the mistake

@Marc-Andre I'll do some research tonight, and if I get any specific Cardshifter-specific error I'll let you guys know

@bazola But it's not, there is some case where you want exactly that. That's the real problem.

@sᴉɔuɐɹɥԀ good

@bazola or programmers could just get in the habit of always using .equals for comparison of strings.

For me it is natural now to use .equals

^^that

@SimonAndréForsberg well pretty much every time i forget, i am stuck debugging :)

@SimonAndréForsberg I'm about to make these changes (change apply: from array to object) so the values can be referred without using indexes. See any problem with doing this?

@sᴉɔuɐɹɥԀ I see redundancy there

@sᴉɔuɐɹɥԀ for the health, use "health: 1" in the values section. creature type can also go to values section. no attack can also go to values (or elsewhere), name it whatever you'd like.

So... OK. Would anything need to go into an apply then? My thinking was that values would just be arbitrary data, while apply would be calls to functions

@sᴉɔuɐɹɥԀ between those two alternatives, I think using as array would be better. they don't need to be referred with indexes, the array could just be looped over. (the whole apply concept in JS would be a bit wicked though, as the methods would have to return something, which I don't yet know what...)

So would it make more sense to just use arbitrary data for everything, for the time being? e.g., noAttack: true

@sᴉɔuɐɹɥԀ hmm... actually, that might not be a bad idea after all. Then we'd just need to define what is value and what is function. However, calling functions on the entities can be done anyway, without putting them in apply: [ ... ]

@sᴉɔuɐɹɥԀ I think that makes sense, yes. Then some different functions can loop over the data and apply the values somehow...

the real 'problem' is about the effects though. Stuff like "Heal 1 HP at end of turn", "50% chance to draw an extra card at the start of your turn", "Take 1 damage at the start of your turn"....

You could also take a look at my issue183-json-effects-card-loader branch, but I don't have time for it these days :/

That was kind of my idea of calling functions by name within JSON. Once we iron out the code logic for the simpler effects, like noAttack it would lay down kind of a template to use for more complex functions, I think

Like applyHealthEOT(1) (or -1 or whatever) or applyDrawCardEOTChance(0.50)

@sᴉɔuɐɹɥԀ I don't think "noAttack" and "heal 1 HP at end of turn" are that similar....

@sᴉɔuɐɹɥԀ okay, I understand your thinking there... but it's... complicated. And things like applyDrawCardEOTChance is waaaaaaaaaay too specific of a function for my taste. It really consists of these parts: 1. At end of turn, do something. 2. A chance to do something. 3. A player should draw a card. 4. The player is you. (3 and 4 can be merged into one)

Effects of card could work something similar as cards.onSomething(function). You would define what the function is and can have access and the onSomething registered an event somewhere that need to execute it at the rigth which could depends on the onSomething(). (I've not read everything so I may be off in the discussion)

@SimonAndréForsberg Good point on the "too specific". There's always the option of writing a small function in the JSON card that would call the 3-4 specific functions in combination. Think that would be more flexible?

{
  name: "Some Card",
  values: {
    health: 1,
    attack: 1
  },
  onEndOfTurn: EOTDrawCardChance function() {
    var chanceOfAction = 0.50;
    var targetOfAction = "self";
    EOTAction(draw, chanceOfAction, targetOfAction);
  }
}

^^ Something along those lines perhaps

@Marc-Andre In the Java code, events work just fine. Are you talking about registering event listeners in JS code, or executing the actual events?

@SimonAndréForsberg Yeah pushing event from the JS to the Java, for the modding part.

@Marc-Andre okay, then I know what you are talking about.

@sᴉɔuɐɹɥԀ Better, I think. Not entirely syntatically correct and also a bit messy... (what if the action would have more parameters? you are only passing 3 parameters to the "EOTAction" call there). I can show an idea I got quite recently...

I'm all ears :)

Hm. I wonder if you can overload functions in JS...

{
  name: "Some Card",
  values: {
    health: 1,
    attack: 1
  },
  onEndOfTurn: {
      chance: {
          probability: 0.5,
          action: {
              draw: { target: "self" }
          }
      }
  }
}

@sᴉɔuɐɹɥԀ @bazola @skiwi @Marc-Andre What do you think about such a format for "effects"? ^^

That actually seems quite clear to me. Not sure how it would work on the back-end but I like it!

from a back-end perspective, I think it should be possible to accomplish. I have a few ideas for how it could be implemented on the back-end, and probably quite extensible as well... will probably bump into some problems along the way, but those should be solvable.

@SimonAndréForsberg I think I need to think about it. There are some things I don't like.... It limits what a modder can do.

Would all those different object references be passed and interpreted by the Java game server, or via JS?

@Marc-Andre not necessarily. A modder could add some hooks that can define the "chance" stuff, and it could also be done to work with POJSF (Pure Old JavaScript Functions) as well.

I really need to read the Cardshifter Code... damn

{
  name: "Some Card",
  values: {
    health: 1,
    attack: 1
  },
  onEndOfTurn: {
      chance: {
          probability: 0.5,
          action: function(eventObject) {
              // write code here
              eventObject.doWhateverYouWant();
          }
      }
  }
}

@Marc-Andre I'm not sure that would help much. It might just cause more confusion. :) messy

@SimonAndréForsberg How would I have acces to the board, others cards etc ?

in eventObject.doWhateverYouWant();

@Marc-Andre Perhaps look at this concept? Looks like the JS logic and Java core would be tightly interconnected throughout the game event

@Marc-Andre through the eventObject. It might be like eventObject.getGame()...

Well then you more advance in the concept of modding that I think you were. Nice. Still need to read the code... I need to understand more things, so that my input would mean something.

@SimonAndréForsberg it looks like it could work

@SimonAndréForsberg quick question... Would it be smarter for card values to use the same nomenclature as in the PhrancisGame.PhrancisResources enum? e.g., ATTACK_AVAILABLE: false vs. noAttack: true

@SimonAndréForsberg when you say "write code here", is it the nashborn thing that will convert that JS code to Java that ends up executing?

@bazola Nashorn doesn't convert into Java. It is a JavaScript engine written in Java. It will essentially call JS code from Java. But yes, it is the Nashorn thing.

ah. so there is more infrastructure needed to actually make the ECS work with that, correct?

as in everything ECS will have to be javascript?

@bazola Not really. Just like JS code is called from Java, Java code can also be called from JS. So the ECS core can continue to be Java.

OK, so would it make sense then to combine, like ATTACK_AVAILABLE: 0 === noAttack: true ?

@SimonAndréForsberg It would need to understand loads of different keys though

@sᴉɔuɐɹɥԀ It would make sense, yes. But there are currently other things interfering which doesn't make it possible at the moment. At the beginning of each turn, ATTACK_AVAILABLE is set to 1 for all creatures that can attack.

I'm not sure if what we want is really feasible, you can't capture all possible things to do in a game, on the other hand you can provide helpers

@skiwi That's not a problem.

@skiwi You can't capture everything, no. But you can provide helpers, and you can allow modders to make helpers themselves. And as a fallback, there is support for POJSF.

@SimonAndréForsberg OK. I'll stick with noAttack for now, seems to make the most sense with what you explained just now

onEndOfTurn: function(game, event) {
    game.withProbability(0.5).opponent().characters().pickRandom(1).dealDamage(8);
}

What are the opinions on this format though?

function getCards() {
    return [
        {
            data: {
                name: "Ragnaros",
                attack: 8,
                hitpoints: 8,
                keywords: ["cant_attack"]
            },
            events: {
                BattlefieldComponent: {
                    onMainPhaseEnd: function (game, event) {
                        game.opponent().characters().pickRandom(1).dealDamage(8);
                    }
                }
            },
            setupEntity: function (entity) {

The functions there are helper functions defined in Java

@skiwi Personally, I like the JSON way more. I think defining objects like in your code there and providing functions to them is a bigger hussle. (and as a side-note, game.withProbability(0.5).opponent() is a rather weird call chaining I think...)

Everyone OK with this JSON format for the time being, for the basic card data?

function loadCardLibrary() {
    var cardLibrary = {
        entities: [
            {
                name: "Spareparts",
                flavor: "Cobbled together from whatever was lying around at the time.",
                values: {
                    creature: "Mech",
                    noAttack: true,
                    sickness: 0,
                    manaCost: 0,
                    health: 1,
                    attack: 0,
                    scrap: 3,
                }
            },

@sᴉɔuɐɹɥԀ Fine by me. Just one two things: There's nothing indicating that the enchantment is an enchantment. If you want, you can remove the values wrapper and put all the values inside there, outside instead.

There's probably tons of ways we could reprsent this

^^ that, except for the typo

I guess the values wrapper doesn't really do much at all. How would you suggest to represent enchantments/effects? In a wrapper? Or just different naming?

@sᴉɔuɐɹɥԀ something like enchantment: true / type: "Enchantment" or similar.

Ah ok

{
    name: "Spareparts",
    flavor: "Cobbled together from whatever was lying around at the time.",
    creature: "Mech",
    manaCost: 0,
    health: 1,
    attack: 0,
    scrap: 3,
    effects: {
        sickness: 0,
        noAttack: true,
    }
},

^^ Does this look better?

@sᴉɔuɐɹɥԀ Not sure if the effects is really necessary there... I guess it's your new version of apply, huh?

Well, I don't know any more lol

Perhaps an attempt to make it look more "organized" but may be overcomplicating

@sᴉɔuɐɹɥԀ Anything can be implemented, I have no strong preference one way or the other. It might make things more organized, but it should be clear somehow which things to write inside the effects wrapper and what things to write outside.

Is it even some problem we can solve here?

Every time someone thinks up a design it can be countered by talking about feature X which another design could support

I agree. Once we decide on a format, I plan on writing some documentation in the file (kind of like I did for the .cards file) explaining all that. I see an "effect" as something that modifies the cards' behavior rather than just simple arbitrary values

@skiwi What problem?

@SimonAndréForsberg How we want to add effects to our data files

I think this is probably the closest we've ever got to something realistically flexible that would not be terribly high-maintenance once the main pieces are in place

[[Cardshifter/Cardshifter](null)] build #819 for commit [607dcbbb](null/commit/607dcbbb7d22d6fdd29fd0ffde0c9b9b3a7e10f0) on branch [js-json-test](null/tree/js-json-test) passed

I think it would be unrealistic that anyone could ever come up with a system that could cover every possible effect, so that's when a modder could use a POJSF

(or at worst, request one from us)

@skiwi Well, we need to decide on and implement something.

^ Please pin that!

@SimonAndréForsberg We've been deciding on this for ages already

I think the only perfect solution we can come up is an AI that can interpret text as effects

Which is way way way way way way over our heads ^^

So we'll need to settle with something sub-optimal

@skiwi the thought has occurred to me :) A simple version of it could be implemented with regex and/or some parsing techniques. But I think it would not be worth it (and definitely a pain to maintain and extend).

@skiwi but yet we haven't fully implemented something fully. Many things are semi-complete though.

The only situation we want to avoid is the HearthStone situation where things are coded again for every card

But with some method extraction that shouldn't be that difficult

Would this kind of demarcation be useful/make sense?

            creature: true,
            creature.type: "Mech",

Maybe not the only situation we want to avoid, but definitely a situation we definitely want to avoid.

(or creatureType: "Mech")

@sᴉɔuɐɹɥԀ ugh!

@sᴉɔuɐɹɥԀ yes!

LOL

@SimonAndréForsberg My brain is tired, you're correct

Right... GTA V: reddit.com/r/gifs/comments/34a7cw/…

Overall, I think the defining-cards-with-JS-and-JSON-like-structure-approach (anyone has a better name for it?) is among the best overall in terms of cleanliness, simplicity for modders to learn/use, extensibility, maintainability, and all other -ility's.

@SimonAndréForsberg We'll coin a name for it once we get it to work ;)

Right. Focus over naming!

So, now that we got the JSON format somewhat settled on, do you think we should first focus on getting the rest of PhrancisGame.java into JS, or try to implement some effects?

[Cardshifter/Cardshifter] Phrancis closed issue #190: Card data; what format to use?

[Cardshifter/Cardshifter] build #820 for commit a74c88b8 on branch js-json-test passed

@sᴉɔuɐɹɥԀ I think we could think a bit more about how some effects would be coded, to create more examples for the format. Maybe also think about how modders could from JS extend the available 'keywords' and the functionality. But getting the rest of PG.java to JS is also important, of course.

Hm... Realistically, would it be a monumental task to implement just the JSON/JS effects part so it could work with the current Java setup?

@sᴉɔuɐɹɥԀ depends on your definition of 'monumental task' :)

So the game server would pull CardData.js and say... CardEffects.js and leave the rest of PhrancisGame as it is

I could maybe get it done with about 8-12 hours of coding. (cannot guarantee the accuracy of that estimate)

Well that's pretty significant, which is why I'm asking :)

[Cardshifter/Cardshifter] Phrancis commented on issue #131: Add a card loader that can load JSON files

> Closing as duplicate. See #183 and #190 for reference

@skiwi How far did you get in building a JSON card loader?

[Cardshifter/Cardshifter] Phrancis added label in progress to pull request #192: Merge js-json-test into js branch

@SimonAndréForsberg ^^

@sᴉɔuɐɹɥԀ You think both creature: true and creatureType: "Mech" is needed? Doesn't creatureType imply that it also is a creature?

Well, yes it does indeed. Would you rather those combined together?

I had it as just creature: "Mech" which may be perfectly sufficient

@sᴉɔuɐɹɥԀ pick what you feel is the best. implementation-wise, it doesn't matter much.

OK

[Cardshifter/Cardshifter] build #821 for commit 8feb8b68 on branch js-json-test passed

[Cardshifter/Cardshifter] Phrancis commented on pull request #192: Merge js-json-test into js branch

> Small change to make

[Cardshifter/Cardshifter] Phrancis removed label in progress from pull request #192: Merge js-json-test into js branch

[Cardshifter/Cardshifter] build #822 for commit e5ec127c from pull request #192 to branch js passed

[Cardshifter/Cardshifter] Phrancis commented on pull request #192: Merge js-json-test into js branch

> Made changes, please review and merge @Zomis if you are good with it

[Cardshifter/Cardshifter] Phrancis reopened pull request #192: Merge js-json-test into js branch

@SimonAndréForsberg that time estimate is to have functions in javascript working in the current java game? or to have a way to define a mod in javascript that is the same structure as PhrancisGame?

i really like this game music youtube.com/watch?v=ZYayzrSj-L0

@Phrancis My vard loader works, if you're interested then you can hop on that branch and look at the commits

[Cardshifter/Cardshifter] build #823 for commit 95bd6e9e on branch js-json-test passed

[Cardshifter/Cardshifter] build #824 for commit 95f61d23 from pull request #192 to branch js passed

[Cardshifter/Cardshifter] build #825 for commit 95f61d23 from pull request #192 to branch js passed

@skiwi Wow that's way over my head.

@bazola just an estimate for only the cards being defined in the JS-format that @sᴉɔuɐɹɥԀ is working on. Not for the whole mod.

I'm going to start trying to define the cards using the JS you already wrote in test.js and then come up with logic for the existing effects and after that try a few new things

I'm guessing ECSResourceMap and ECSAttributeMap is what I would want to pass data to right?

Putting this where it belongs......

I hear you've all been struggling with how to define cards, and their actions and what not.

Have you guys considered creating a DSL with something like ANLTR?

[Cardshifter/Cardshifter] Phrancis added label gameplay to issue #193: Pass card attributes using JSON

[Cardshifter/Cardshifter] Phrancis opened issue #193: Pass card attributes using JSON

> This will be step 1 of converting game logic to JavaScript, to be able to pass values and attributes using JSON data to ECSResourceMap / ECSAttributeMap

[Cardshifter/Cardshifter] Phrancis assigned Phrancis to issue #193: Pass card attributes using JSON

@RubberDuck What would a DSL potentially look like/imply?

It would look however you want it, because you define it.

Hmm. So you just... make up your own language... And the code (e.g., Java, JS) just understands what to do with it...?

Kind of. Yes. First you define a grammar for your language, and then what actions happen when certain identifiers are found.

I wouldn't rule it out. It depends on how complex you need special effect actions to be.

If it's relatively simple, you might be able to provide a much better UX, but DSLs are definitely hard to understand.

@RubberDuck Well, we already have keywords in the JSON file. The idea was to define what to do with those keywords using JavaScript... It's not so much that it has to be really complex, but more that it has to be modular (e.g., "chain" multiple keyword/value pairs together to create a distinct effect)

Yeah. That sounds like a good use case for a domain language to me. Not for the faint of heart though.

You used that for your calculator right? Do you have a link?

Yeah. My calculator is a bit messed up, but give me a sec.

github.com/ckuhn203/Antlr4Calculator

[Cardshifter/Cardshifter] Phrancis pushed commit c0e5528c to js-card-data-loader: Update CardDataLoader.js

@RubberDuck with my recent calculator knowledge, I can see how that could be beneficial indeed. Definitely worth checking out.

TTGH. I really feel like we took a bit step today :)

[Cardshifter/Cardshifter] build #826 for commit 6fe101c4 on branch js-card-data-loader passed

@RubberDuck This is the ANTLR definition, right? github.com/ckuhn203/Antlr4Calculator/blob/master/…

That's the grammar @SimonAndréForsberg. The tool uses it to generate a lexer, parser, listener, and walker.

Then you would still need to inherit from and override the default "empty" behavior of either a listener or visitor.

perhaps I should learn the difference between a lexer and a parser...

A listener walks the entire tree root to leaf. A visitor let's you walk the tree however you like.

A lexer breaks a text stream into tokens defined in your grammar.

A parser interprets those tokens into "rules" or "contexts".

@RubberDuck Imagine the 'statement' "Deal 8 damage to a random opponent", could you give an example of how the DSL of that could look with ANTLR ? (not the grammar, but example code that uses the grammar)

[Cardshifter/Cardshifter] build #827 for commit c0e5528c on branch js-card-data-loader passed

@RubberDuck Aha, so a lexer is like taking the string "4 + 7 * abs(-5)" and converting it into the tokens [4, +, 7, *, abs(, -5, )] and the parser is like taking those tokens and doing the Shunting-Yard algorithm on it to convert into Reverse Polish Notation, or an Abstract Syntax Tree?

Yea! That!

At your code level, you would see something like.

card.SpecialEffect.Perform()

Where Perform is the action that walks the tree.

@RubberDuck that's Java code though, right?

Yes.

I'm more thinking right now about how the actual DSL code could be made.

And here is an implementation of a Visitor github.com/ckuhn203/Antlr4Calculator/blob/master/Calculator/…

Would it be possible to make a grammar to make the actual text "Deal 8 damage to a random opponent" work? (I assume yes here, actually)

Yes. That's exactly what a DSL is.

How extensible would you say that it is?

Should be very.

So... what tokens do we have there...

Action number health modifier target

something like that

Back

It would be some work (possibly a lot, I'm not sure), but you could definitely define a plain text language like that.

Given it's a card game, the rules have to be very precise to begin with.

A friend of mine came up with a significantly more complex card today...

Which is good, that lends itself to it.

lol

I'm sure.

the problem is that we want extensible/flexible rules....

This would be.

Because you can define an action as something that is that entire statement.

Or, a particular keyword, like "Deal"

Would the same DSL be able to interpret (using some of the same words) "Deal 1 card to your hand at the end of this turn" ?

Recursively define it kind of like this.

expression :
    expression MULTIPLY expression #Multiplication
	| expression DIVIDE expression #Division
	| expression ADD expression #Addition
	| expression SUBTRACT expression #Subtraction
	| NUMBER #Number
	;

@sᴉɔuɐɹɥԀ Action number target target whenModifier

So, I'm thinking words like to and at are special keywords that indicate direction.

taste that ^^ @RubberDuck

@SimonAndréForsberg Whoa.

It follows the rules, it's just defined in the terms of several individual actions.

Hmm. Very interesting.

So.. a rough stab that certainly wouldn't work.

Sounds like a PITA to make, but that could have huge benefits in the long term...

yes ^^

action:
    action target
    | action target modifer
    | target action (modifier)?

Yeah. Absolutely. On both counts.

I'm not pushing ya, because it's hard, but it is certainly one way to do it.

Could you show/link how Mug used DSL for RD, by chance?

TTGTB, I think at some point I should look into ANTLR more. I would like to discover more about its advantages and disadvantages, I think ANTLR-approach is something more for "Distant Future" (love that milestone) than 1.0 though.

^ Agreed we should at least take it into consideration

Thanks for the ideas @ducky :)

You guys are very welcome.

You'd have to ask @Mat'sMug about how it's done in RD though. I understand the grammar, but I don't quite grasp the listeners he wrote.

200_success vs. rolfl: 42 diff. Year: -663. Quarter: -506. Month: -506. Week: -312. Day: -13.

Loki Astari vs. Simon André Forsberg: 4114 diff. Year: -1652. Quarter: -353. Month: -353. Week: -50. Day: -5.