Suggestions for expanding the API

[mattdiamond]

Not sure if we're supposed to be able to use this function, but the docs for the Space API don't indicate that you can inspect the unit on a given space by calling space.getUnit(). Is there a reason that was left out, or was that just an oversight?

[olistic]

Hey @mattdiamond, thanks for your interest in the project! This (and #71) is part of the private API players shouldn't be able to access to prevent cheating. I'm currently working on a fix.

[mattdiamond]

@olistic Gotcha! Hmm, guess I'll have to rethink my strategy for the last beginner level. It would be nice if I had some way of knowing which direction damage was coming from, now that I can't tell the difference between ranged and melee units (I was using getUnit for this). Should the API really be this limited?

[olistic]

Should the API really be this limited?

That's a good question. I'm open to revisit the Player API. Let's do this, once you finish the beginner tower, ping me on this thread or via email and we can talk about how we solved the beginner tower, and what would've made our lives easier if it was part of the API. Maybe it's clearer then what should be part of the API and what not. Sounds good?

[mattdiamond]

@olistic Sure. On the topic of "what would make my life easier", my difficulty on the final level is the task of prioritizing which enemy to attack first. The hero has a melee opponent a few spaces ahead and a ranged opponent a few spaces behind. I can obviously detect on the 2nd turn that I took damage, but the hero has no way of knowing if the ranged attack is coming from the enemy ahead of him or behind him (or potentially both). That's what I was using getUnit to solve (along with unit.abilities.has), so I'll have to come up with an alternative strategy for solving this problem.

Edit: Just throwing out ideas, but it would be cool if each turn presented the user with an array of perceptual Events that just occurred, potentially including a DamageEvent that indicates which direction the attack came from. You could even throw in SoundEvents and other kinds of interesting perceptual clues. But maybe that's giving the player a little too much information...

[olistic]

@mattdiamond I just released v0.3.0, which reorganizes the Player API a bit. This should align the codebase better with some additions that could come in the future, like .isMelee() and .isRanged() for the Unit API.

[mattdiamond]

@olistic Ah, so space.getUnit() is legal after all? Nice. I’m curious how other players programmed the warrior without this feature available. Is there a message board where people share their designs?

[olistic]

@mattdiamond Well, it's legal but it doesn't include anything that the Space API didn't include before. I just moved the methods that were related to units to the Unit API, and made that "restricted" version of the unit available through space.getUnit(). So you won't be able to access unit.abilities, for example (that's being enforced now in v0.3.0).

Is there a message board where people share their designs?

There is a Show & Tell in the Spectrum community, but I don't encourage people to share solutions, just their final score. If you want to see a solution for the beginner tower I can share mine with you. Just let me know!

[olistic]

I propose adding a function to the player API to check what body part has an arrow sticking out of it or has been burnt by magic. Currently to complete the beginner tower you need to make assumptions on the direction of the most lethal enemies. Currently adding an extra level and swapping two enemies would make epic near impossible. – @pigalot

[olistic]

I don't think the warrior can make proper decisions unless it knows what units it is facing. For example the warrior may be forced to charge into an archer or simply step away from a slime. – @GiantZOC

[mattdiamond]

I partially agree with the above comments. I think that the player needs to know at least one of two things:

1. the direction a specific attack came from, OR
2. the type of the units that are visible to the warrior

[pigalot]

I think damage type and direction would be needed. For example:

╔════════╗
║w  @  a>║
╚════════╝

One unit is far more dangerous than the other and attacking the wrong one would be nere instant death.

I think the unit type is a bad idea maybe something else like features. Holding a bow or a staff, that way it can be expanded later a red hat and a staff etc and would catch you out if you don't update.

[olistic]

Initially, I was thinking on adding a sense warrior.wounds(). This would return an array of the wounds gotten by the warrior in the last turn. Each wound would have a direction (forward, right, backward, or left) and a damage amount. That would allow the player to identify where the greatest damage is coming from and subsequently, where the greatest threat is located. Thoughts?

[pigalot]

Would that also include if a wound inflicted a effect like poison?

[olistic]

@pigalot Not at first because it will require some big changes, but when the need arises we can see what’s the best way to do it.

[olistic]

@mattdiamond @pigalot Can you send me the code in your Player.js via email? I’m working on this and it would be useful to have other people’s perspective and solutions. Thanks!

[mattdiamond]

@olistic sure!

[Pedr0Rocha]

I like the idea of .isMelee and .isRanged Have you ever discussed the possibility of character classes? Like Ranger: +spaces in .look(), +shoot dmg Knight: +hp, +.attack() dmg

[mattdiamond]

@olistic Was just checking out the code, I like what you did with the SensedSpace and SensedUnit concepts. Any plans to break those out into small classes? You could basically just copy the relevant as functions into constructors and call it a day... then again, since you only return those from single points in your code, I guess the only real benefit would be that the player could do instanceof SensedSpace and instanceof SensedUnit (which doesn't seem terribly useful). So... never mind.

Also, are you leaning towards including that warrior.wounds() function? And if so, do you have a ballpark estimate of when that might be released?

[olistic]

Hey @mattdiamond, I'm still considering options but I figured I could start some code in the warrior.wounds() direction. You can test it by checking out b21cf6c. (I HAVEN'T TESTED IT YET.)

[bbugh]

I came here to suggest that getUnit() have some kind of unit type as well. I was surprised that this wasn't already available, since players have visual knowledge of what kind of unit it is (W or a or S). wounds() sounds useful as well, though I'd prefer if I can actually get the type. It makes the strategy more interesting, in my opinion, and makes it less weird that I have knowledge that I can't pass on to my automaton warrior.

[akamuraasai]

Why not just expose the unit name in the as function as well? It seems to be the an okay solution, since you already see them in the map anyway.

[olistic]

Closing as I don't have time to work on this at the moment. Feel free to reopen if you want to help.