It also showed pass without me having to change any code. That’s probably because of the boss star I had equipped. Disable the player’s income to fix that. Also restrict the golden wand.
I also noticed that it is possible to walk far off-screen. Is the lack of boundary walls intentional? It could make viable a strategy where peasants with overly long tails walk away from view. (The original snake game would be less fun if you could do that.)
I didn’t try killing the neutral peasants, but that should not be allowed to happen.
Otherwise it’s the most interesting weekly level I’ve tried in a while. (At first I thought there was going to be a new enemy, maybe the serpent-things in the email’s adventurer image?)
Edit: There seems to be more emphasis on sending out more peasants compared to controlling less peasants but with with longer tails. The longer tails also make the simulation more laggy.
What if the goal checked for current unspent gold instead of total gold collected?
One strange thing that seemed to happen is the peasant’s target getting changed. For example, I could command him to move to a point on other side of the view, but then his target would set to a closer point and continue adjusting to be in front of him.
Confirmed. Wearing the Boss Star IV will produce all the necessary gold to pass the level. I believe the boss stars could be banned from the level (more on that below).
It is in their To-Do list to write the documentation part. This is usually one of the last steps.
Same. I took a quick look at the level’s referee code, and it looks like the "1000-gold" goal state is never set to "success". I’m not sure if this was an oversight from the author, or if they intentionally avoided awarding this goal due to a possible lack of rewards/difficulty balancing. I’m assuming the former, so I’ve submitted a patch to fix it here: http://codecombat.com/editor/level/serpent-savings
I believe summoning should be forbidden. Perhaps it would make sense to ban all forms of summoning and start the level with a fixed amount of peasants already available in the map.
Yep, the level really lacks some polishing here. I would expect the whole area to be surrounded by walls that would kill instantly on contact (maybe lazer walls?), similarly to the original Snake game. Or, perhaps, make it so moving off an edge of the screen “warps” the units to the other side (e.g. leaving to the left of the screen would warp the unit to re-enter from the right), as was popular in several Snake remakes (on second thought, wouldn’t this make the level too easy?).
That is intentional, as far as I can tell. It is explicitly coded in this level’s referee code. Remember how in the original Snake game, when you change the snake direction (e.g. press right) it will keep heading that way until you turn it to another direction? I believe this was the author’s intention here.
However, I’ve found what could be considered a bug regarding this logic. It is possible to stop the peasant where he is standing with:
this.command(peasant, 'move', peasant.pos);
More specifically, the referee’s code is not prepared to handle the case when peasant.pos.equals(peasant.targetPos) is true.
I believe there are already a couple levels where you have to rotate a vector and add it to an unit’s position. They may require a subscription, though. This level that we are playtesting will also require a subscription, so that shouldn’t really be a problem.
One issue I’ve noticed that I find quite annoying is when coins spawn in the same position as a snake’s tail. In the original Snake game, items would not spawn in a position that is occupied by the tail. I believe the level could either make the neutral peasants able to collect coins or not spawn coins that would be too close to them.
Overall a pretty fun level, but there’s a lot of polishing to do.
A variation of the level with only one snake has no need for allied peasants. The hero could be the one leading the snake. That also eliminates the need for any boss stars (and maybe the API finding the head of the snake).
(Another potential variation could make simple boots a requirement.)
If not one snake, an alternative could be to make the goal check for current unspent gold instead of total gold. Each peasant summoned would slow progress.
I tested the this.command(peasant, 'move', peasant.pos); and it caused the whole snake to halt, which is not ideal. Fixing this would either require making the neutral peasants continue moving, which should kill the head peasant if he ever stops moving. Or there should be logic that prevents the head peasant from ever stopping.
I recommend adding ice walls around the four sides of the level. If the neutral peasants would continue moving, then it shouldn’t need any fancy killing mechanisms because any head that runs against it at a near-perpendicular angle would slow down enough to get hit by the peasant behind it.
Edit: tested the walls. The first peasant stops but the ones behind also stop.
When the player income is set to 0, the goals will have to be adjusted to lower values.
Thanks for your feedback. I went through and started knocking out some of those little edge cases.
Killing any part of the snake now kills the whole snake.
The player should always have access to a peasant. If the last one dies, a new one will spawn by the hero.
The peasants are now trapped within the level by obstacles (but they don’t die if touching them (I will add this in the next day or so)) Peasants now die if they get too close to the edge.
Players start with 0 gold and have 0 gold income.
When a snake dies, the player loses totalGoldEarnedByTheSnake / sqrt(totalLengthOfSnake).
Goal values are low currently, until I settle on which method is most likely to be employed by the players. It is mostly a ‘for fun’ level, this should help everyone place on the leaderboards early on.
That should cover most of the changes. I’m always open for more suggestions, and I appreciate all your feedback on the early level.
It is possible to trap the tails by building fences.
I’m not really sure what you mean by “low”. Even with my, erm, “overly optimized” strategy above, it is very hard to even get to 350~400 gold. The 500 gold goal seems practically impossible, unless I’m overlooking something.
Also, perhaps it would be useful to expose an API on the coins to know how much time they have left until they disappear. This way, we could divide the time left by the distance to the coin in order to determine whether it is even worth pursuing it.
edit: The referee code is still checking for @inventorySystem.teamGold.humans.earned > 100. Shouldn’t it be >= instead of >? Ditto for the 500 gold goal.
Note the amount: the level now requires 200 gold to pass the level, and 350 for the bonus goal.
Also note the term “coins”: it seems to refer to a fixed amount of coin items, instead of the coins’ value. I believe it would be more suitable to say “gold” (as in, the in-level currency) rather than “coins”.
One more thing: the leaderboards’ scores are still showing submissions from the very first (playtest) version of the level. I’m not sure if you guys have the tooling to fix that yet, but removing those outdated scores would be a neat thing to do (some submissions are even using the golden wand!).
And, oh damn it, I just found a critical exploit. Seeing as this level has already been released to the public, I’ll refrain from posting the exploit publicly and PM the interested parts (@Serg and @nick) instead.