In this particular example, I don't see why. Player and Warrior are conceptually different entities: one is the player of the game, having properties and methods related to controlling gameplay (e.g. a player might play as alternate warriors at different times), the latter is the avatar, having properties and methods related to that fictional characters attributes within the world of the game.
The differences in purpose of the two entities aren't really anything to do with fp vs oop; I don't see what's fp-ish about the first example, and your last example is potentially a weird mix of fp and oop (depending on what "warrior" is, and I can't figure out what use it would be in that context if it wasn't an object with encapsulated methods)
It would be awesome if there was a way to gain information about your enemies. For example, sometimes (when facing a sludge), it's better to run away, heal, and come back to finish it off at full health. When facing an archer, it's often better to power through and kill it before healing. There's no programmatic way to know which enemy is attacking your warrior, so I'm often finding myself writing custom, non-reusable code for a specific level, which isn't great.
I stopped playing at the level where this became critical for exactly this reason. My warrior presumably has eyes, so why can she not tell the difference between a sludge and an archer? If the goal was ultimately to write a player that could succeed in any arbitrary level ("Epic Mode"), I did not feel like I could accomplish that without being able to know what I was up against. If I have to hardcode decisions based on known levels anyway... might as well just hardcode exact instructions on which actions to take based on a counter. But at that point, it doesn't really feel like programming an artifical intelligence anymore.
Hello, I'm sorry you feel that way. I think that being able to determine what enemies your warrior is facing is something valuable. However, it's possible to succeed in epic mode (and get a perfect score) without hard-coding any instruction.
Can't you infer what enemy you're facing based on the damage they do to you?
In the original, [ruby-warrior](https://github.com/ryanb/ruby-warrior), you can `listen` (at some point) to get an array of occupied spaces and then you can check if a space contains an enemy. If you're not immediately adjacent to an enemy but your warrior is taking damage you can infer you're being attacked by an archer (or another enemy with a ranged attack).
This is a really good idea that somehow I totally missed. I stopped playing at a level where this became important (as @elefantastisch noted above), but now I kind of want to pick it back up again. It's not guaranteed to work (different enemies might deal the same amounts of damage), but maybe location could help in those cases (i.e., if my warrior is being dealt a certain amount of damage and the space in front and behind the warrior is empty, one could infer the enemy is an archer).
Something for basic enemy assessment would allow for more tactical action, though. For example, checking armor and weapon types to switch between your own equipment (hammers vs heavy armor, swords vs cloth armor, spears vs spearmen or beasts with tough hides) - or putting together different signs to decide if an unarmored enemy is a wizard or a thief.
Screeps does that, and it doesn't have "classes" per se, but modular bodies... so you can look at an enemy and see that they have some HEAL body parts, so you know they are a healer. You can even calculate how much healing per turn they can do to influence your fight or flight, or target priority decisions (you have multiple units, after all).
Perfect! A game that I can play at work while not working but looking like i'm working. Rename warrior to latest project name and boom, I code all day.
But in all seriousness, the floor map idea is pretty neat.
`console.log()` does nothing. `debugger` does nothing. How am I supposed to figure out why 'this.isTakingDamage' function isn't working? Just look at it real hard?
I'm not some sort of deity who can just write perfect javascript the first time around.
On a side note, running with `entr -p warriorjs --time 0.4 <<< Player.js` is quite convenient. (Run the warrior through the level on save of file.)
Hello DDR0. You're right, you're not a deity, you're a person. Same as people on the other side of the project, who can't just write a perfect game the first time around.
I stumbled across this yesterday and had a great time implementing all sorts of interactions for my character. If you're the kind of person who enjoys puzzles or problem solving, this is definitely the game for you.
Thanks, and good you ask. The online version is in the works, going to be available soon at warriorjs.com. Follow @warrior_js on Twitter to be notified about the release.
Its more of a large inconvenience - I don't develop on my computer, I write all code on servers in my company's cloud. My choice would be to either clone this onto company hardware in the cloud or install node and the associated tools on my desktop.
Is there a particular reason that playing this game on your employer's hardware (and, presumably, on your employer's time) is better than installing it on your computer and playing it at home?
I do agree, and this is how I evaluate a lot of tools, but wouldn't it be easier just to have a web page? I'm not saying that I can't use this, I'm saying that it would be far more convenient for me (and likely many others).
Off the top of my head: http://codingame.com/ - They support a lot of languages, even Rust!
I also remember an old Java application where you would write AIs for dueling bots, but I don't recall the name.
The folks at https://codegolf.stackexchange.com/ also host several games like that, more often than not competitively, however, and not open-ended or "singleplayer" games. Most accept any language that can take stdin and print stdout.
I found this to be an issue with Node 10, did you happen to be running that version? It was already fixed and a new version will be released soon (meanwhile you should be able to play with Node 8).