Thanks for the fun new arena, CodeCombat team! I thought a dedicated thread for any issues worked pretty well the last time. Feel free to rename the thread if you disagree.
Just a couple small ones to report:
[Python] hero.findFruits() returns elements for which the “value” and “mana” properties are not accessible. Reproducible with this code which yields ‘TypeError’:
for f in hero.findFruits():
fruitValue = f.value
Cost and power of spells in documentation / hint is not updated. Is this possibly because it is still being tweaked?
The effects of “fire-burn”, “water-refresh”, and “earth-grow” are not described. Unless it is intended that their effects be something for participants to find out by experimentation (not a bad puzzle I think).
Spectate mode is not working for me in Chrome on MacOS, as well as on ChromeOS. Moving graphical elements (e.g. fruit, collectors, sorcerers) only appear as gray circles, and clicking the play button does not cause the timeline to progress.
Thanks for the quick response!
Hmm, something is wrong with my pre-existing code after the fixes, it appears to get TypeError somewhere in my fruit examining code. I’ll see if I can pinpoint the issue.
As for balance, I haven’t encountered anything that seems overpowering so far so that is good. I have not developed my code too far yet though, I’d say it’s still in the “covering more bases = better” stage, and not yet at the point where there needs to be a trade-off between different priorities, so I can’t say yet if some priority is clearly more advantageous than others.
I have faith that some of our other players will shortly be uncovering strongly balance-breaking strategies though, so fear not!
Found the issue, now it’s the .pos of a fruit that is causing TypeError in my previously working code.
UPDATED:
Also, found that returning a location for the collectors’ specified chooseItem function is not working (in Python at least). The collectors always go to the nearest fruit in that case.
In the hints, it says collector #2 takes 1 second to spawn, #3 takes 3 seconds, #4 takes 9 seconds, and so on, but it seems like collector #2 takes 3 seconds, #3 takes 9 seconds, and so on.
Sorry, @Smloh, there’s not a whole lot I can do about that while maintaining my strategy. For whatever reason, in what is definitely a bug, the blue hero is not allowed to access the opponent’s properties. I submitted a patch a couple of days ago here but it has yet to be accepted.
I’ve effectively disabled that part of my code; you can play against the nerfed version if you wish. You’ll find me 15-20 places down the leaderboard.
Oh dear, that’s a shame, hopefully it will be fixed soon.
Are you able to only disable it when you are blue, @Hydrobolic? I’d still like to be able to go against the full-fledged version of your code, if only in spectate mode.
Hmm, looking at your patch (the first time I’m taking a detailed look at something in the level editor), I agree that “.action” might be a good addition, as otherwise there is no way that I know of to tell if the opponent is making more collectors. Although there might be an argument that removing that part of the mystery leaves less room for strategy vs pure calculation.
I’m not sure how “.opponent” being missing for blue is an issue though. Aren’t you able to get that using “hero.getEnemyHero()”?
Good idea! I’ve done so, @Smloh, as red I should use the full AI.
Another bug: while the documentation references hero.color, it doesn’t seem to be defined, so I’ve used a workaround.
I don’t think withholding information such as .action leaves more room for strategy, it simply leads to hard-coding your AI to counter the opponent’s. A clever AI should be able to use all the knowledge from the game to make optimal decisions. I experimented a bit with watching the opponent’s mana values to predict if they’re building a collector or not, but it isn’t accurate enough to be useful.
Unfortunately hero.getEnemyHero() does not work either: it’s simply defined as returning hero.opponent.
(Referee line 364: h.getEnemyHero = () => h.opponent;)
Great! It’s good to see you deservedly back in the top spot, @Hydrobolic (for now!)
I’m afraid I still don’t understand why there is the issue for you when Blue though. Are you unable to access opponent properties completely? (I’d imagine so if you can’t get the opponent).
That’s strange to me because my strategy depends heavily on these lines in my code, and it works well whether I’m Red or Blue:
e = hero.getEnemyHero()
emana = [e.fire, e.water, e.earth]
eShield = e.getActiveShield()
Just noticed you’re using JavaScript while I’m using Python though. Wonder if that’s a factor?
I can’t say definitively what the issue is, but the issue definitely went away when not using hero.opponent. My code still depends on the values, but is just fed undefineds instead of numbers and so doesn’t quite do the right thing despite not throwing an error.
print out the values of those variables when blue, and check what they are in the console.
Further console.log testing shows that only getEnemyHero() works, not .opponent. I explicitly tested .getEnemyHero() before and found it did not function, but I may have made a mistake. I’ve reestablished my full AI.
Each collector should grow at a constant rate, but each consecutive collector takes longer to build, so collectors have diminishing returns. It’s not worth it to build collectors non-stop.
Something strange has happened, I noticed that @Hydrobolic’s code is no longer working even though the code was unchanged since the last submission which used to be at the top. Spectating it looks like the code now does nothing.
Similarly, I noticed that @kulawat’s code also now seems to be attacking very very rarely, building up huge reserves of mana. It has also fallen down the rankings quite a lot.
Did something change in the arena code that broke their logic?
Yes, .opponent and .collectors are now fully removed: the getter methods should be used instead. My code relied on .collectors directly. I’ll resubmit my AI once position-based collector control is fixed (I believe it’s currently being looked into).
