RubyWarrior - Bloc
bloc.io
bloc.io
Totally stealing that idea.
(At least from an end-user standpont. Obviously, you should do your own testing for conversion rate/etc.)
- while, until, retry (and others?) not allowed.
- not being able to see the class of something. Its more ruby style to do 'space.is_a?(Enemy)' than 'space.enemy?'. This would also help to build case statements rather than lots of ifs.
- no 'print' or 'puts'. How am I supposed to know what 'look' returns when it never really tells me?
- I prefer a single set of rules rather than adding rules as you go. When first I have to use :backward but later this becomes basically redundant as 'pivot' is added, it just makes me frustrated in having to refactor. Same thing for feel/look.
> Its more ruby style to do 'space.is_a?(Enemy)' than 'space.enemy?'. This would also help to build case statements rather than lots of ifs.
But that would require to explain that an Enemy class/module (and possibly others) exists. With the presented interface you can/should only care about Warrior and Place. Much simpler.
> no 'print' or 'puts'. How am I supposed to know what 'look' returns when it never really tells me?
With Ruby's Array methods. Warrior#look returns an Array of at most 3 Places. What else should you know?
> I prefer a single set of rules rather than adding rules as you go. When first I have to use :backward but later this becomes basically redundant as 'pivot' is added, it just makes me frustrated in having to refactor. Same thing for feel/look.
That happened to me too, but i think it adds to the sense of progress and discovery throughout the game. Like most games, you don't start with all the tools and abilities at your disposal. And you can always ask respond_to? if you want an algorithm that works for all level ;)
The basic issue is that this is supposed to be a 'learn ruby' tool but rather than use the ruby class system (a fundamental thing to learn for beginners) to define what is in a Place they have used a custom non-class-based system instead. The result of this is that rather than allowing the user to choose their own way to do things (remembering that ruby is a 'there is more than one way to do things' language), it prescribes certain ways of working (or at least makes them easier than others).
I'm not saying everyone should program the way I do but I want to write a simple 'case warrior.feel; when Enemy;x; when Stairs;y; when Empty...' statement which is usually pretty clear and logical ruby but is prevented by this structure.
#is_a? is generally considered a code smell in Ruby. It should not matter if the object is of type Enemy, it responding to the message #enemy? is an interface that any object of any type can implement.
{'enemy?' => 'attack',
'captive?' => 'rescue'
}.each { |test, response| self.send(response) and break if warrior.feel.send(test) }As a Rubyist for a decade now, please avoid is_a? if at all possible. It defeats the awesome flexibility that is duck typing. Also, I have no idea why you feel that would be better for cases, my code ran in a case statement for brevity.
'look' told me that it returns an array of Spaces. They're the same type as the Space feel returns.
Agreed on pivot though.
:)
I try to avoid using `.is_a?(Class)` in all of my ruby code when possible. `.respond_to?` is much more responsible way of probing whether an object has the interface you are looking for.
#is_a?(class) is a much more specific check of semantics than #respond_to?(method_name). is_a? is the more cautious approach (least likely to produce false positives at the expense of being most likely to produce false negatives) whereas respond_to? is the less cautious approach (least likely to produce false negatives while most likely to produce false positives.)
But that really isn't the only way to do things. Read up on http://en.wikipedia.org/wiki/Duck_typing
Well, java was one of the languages I used before Ruby, but I've done more Ruby than Java.
> Read up on http://en.wikipedia.org/wiki/Duck_typing
I am well aware of duck typing, and rarely use either #is_a? or #respond_to?
That doesn't change that, if you have a reason to use that type of inquiry to check interfaces, #is_a? is the more safe of the two (more likely to reject an object that provides the semantics of concern and less likely to accept one that does not) and #respond_to? is the less safe (more likely to accept an object that does not provide the semantics of concern and less likely to reject one that does.)
- Obfuscating the class is intentional... you are being given a limited set of "sensors" with which to interact with the world. Those are intentional rules by which to play the game.
- The original game is plain old Ruby run in the terminal and has full access to #puts or #print
- I think the point is to increase the complexity of the api slowly for those new to ruby and or programming in general. Not to beat a dead horse, but in the original there is the notion of epic mode where you do have access to all the rules and can attempt to run the entire tower with the same code.
def play_turn(warrior)
m = warrior.methods.grep(/.!$/).sample
warrior.send(m, *([nil, :backward].sample if m != :rest!))
end
It's kind of amusing to see the warrior do random stuff like shooting arrows backwards and pivoting back in the worst possible moments. Too bad that Run button repeats the same movements if you didn't edit the source code somehow.
Great game and concept BTW!
This way you could see your own progress, and see what solutions other came up with without bugging them.
if not warrior
return nil
end
Ok default sound way too loud, and at least on Safari the little speaker icon in the top left doesn't seem to do anything.
As a web-rubyist, this forces me to think in a different way than I normally would.
Thank you for making this.
I saved a `health_change` variable in my code, and decided what to do based on that, but the warrior did the wrong thing. I wanted to see if my variable was being set correctly by printing it each turn, but I couldn’t. My normal tool for understanding what was going on is missing, so I was forced to guess at the bug. I finally got it to work by reversing the order of two terms in my formula for `health_change`, but it was a lot harder to understand what was going on when I could only guess at or simulate the values of the variables.
class Player
attr_reader :warrior
def initialize(warrior)
@warrior = warrior
end
def play_turn
# I can now access `warrior` here or in any other methods I write
end
endIf there were multiple warriors then your code would no longer make sense, as the control logic would have to be changing the player_instance.warrior object.
You need to keep previous state about warrior. E.g. delta health.
I especially loved this: "warrior.feel.empty?". Allova sudden my RubyWarrior's getting all existential!
if warrior.feel.enemy?
warrior.attack!
else
warrior.walk!
endhttps://github.com/ryanb/ruby-warrior/tree/master/towers/int...
Marvelous