41–50 of 70 posts
Nicely made. Some frustrations: - 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…
Nicely made. Some frustrations: - 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…
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.
Nicely made. Some frustrations: - 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…
I don't feel `.is_a?(Class)` is ever idiomatic ruby. You should always be coding to an interface, not an implementation. This prevents things like mocks and duck typing, making testing more difficult and adding complexity when you want to add AnotherEnemy that doesn't share the same inheritance tree. I try to avoid using `.is_a?(Class)` in all of my ruby code when possible. `.respond_to?` is much more responsible way…
#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.)
Nicely made. Some frustrations: - 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…
Hehe, i feel identified with some of these frustrations, but i think it's better the way it is. > 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.…
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.
kneel down before the warrior (all levels): https://gist.github.com/syasrebi/6097679
Earlier quoted context omitted.
Hehe, i feel identified with some of these frustrations, but i think it's better the way it is. > 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.…
Not just to you but to other comments too on the 'is_a?' issue: 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? 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.
Earlier quoted context omitted.
Hehe, i feel identified with some of these frustrations, but i think it's better the way it is. > 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.…
Not just to you but to other comments too on the 'is_a?' issue: 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…
{'enemy?' => 'attack',
'captive?' => 'rescue'
}.each { |test, response| self.send(response) and break if warrior.feel.send(test) }Cool idea, but I don't think it makes sense for there to be both a Player class and a warrior object. They seem like they are/should be one in the same. At the very least, I think behind the scenes, the Player class should look more like this such that the warrior object is always available, and I don't need to pass it around from method to method that I define. e.g.: class Player attr_reader :warrior def initialize(…
The player object would represent the current person playing the game, i.e. you. The warrior represents the object on the screen. The player tells the warrior to take actions, so it makes sense that they're different objects. If 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.
Earlier quoted context omitted.
Hey! You made ImpactJS? That's very cool, but it's really hard to commit $99 to buy an engine when I can't even try it! It looks super-rad and I'd love to give it a shot, but it's a bit high of a bar for a casual game dev.
If you buy it and don't like it for whatever reason, I can give you a full refund within the first month. That's easier for me to handle than a separate trial license.