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.
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).
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.
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.
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).
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).
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.
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).
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.
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.
`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.
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)
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).
54 comments
[ 2.9 ms ] story [ 118 ms ] threadBut in all seriousness, the floor map idea is pretty neat.
"Dude about what you pushed yesterday.... what is this swordOfDestiny function you keep using on customer records?"
https://github.com/ryanb/ruby-warrior
> This project was born as a port of ruby-warrior. Credits for the original idea go to Ryan Bates.
I was sure of it based on how (almost exactly) similar this was.
`npx @warriorjs/cli`
Lunch at your desk and "nothing to do if nothing breaks" server-monitoring shifts are both common, and that's just in the tech world.
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).
Probably because if it's going to be in the browser, they have to do a large chunk of the work in JS anyways
and of course, everything is JS these days
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.
Sounds like Robocode.
I played this like 17 years ago and to my most pleasant surprise, the project is still alive.
I'm sure there are other ports for other languages too. I'm pretty sure there's a Python one for one.
If you know python and had never written JS before, you could probably still play this with a bit of trial and error.
I couldn't find anything about when "Show HN" is expected in submission titles. What're the rules or conventions?
Me and a friend built this in 2013, built on top of ideas from the original ruby-warrior.
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.)
If you're interested in proposing a solution for the issue you describe, there's already people discussing it here: https://github.com/olistic/warriorjs/issues/69
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)
I worked around it by just copying the class as described in the website.
-> So, it is for god players already...