Open datahead8888 opened 10 years ago
Right side up - walk up and down right walls
I'm just going to point out that normally "right side up" is interpreted as "correct side up" and means the equivalent of what you call "normal". :P (Language quirks, don't you hate them?) Though I'm not sure if there's a better way to describe it.
I'm just going to point out that normally "right side up" is interpreted as "correct side up" and means the equivalent of what you call "normal".
Actually, as I originally posted it, it's probably wrong as it should be "left side down", since the left would be down relative to any object oriented with it. This would also avoid the association with "right side up".
Just go with "rotated by 90°" :-P
Vale, Quintus
Do these modes only affect the player, or the rest of the game as well? If such a mode is implemented, perhaps specific objects should have a flag as to whether they respond to this mode or not, so some enemies can be walking normal, some with anti-gravity, and so on. This may also require changes for collision detection since I think the current code considers the top of the block the "ground".
Do these modes only affect the player, or the rest of the game as well? If such a mode is implemented, perhaps specific objects should have a flag as to whether they respond to this mode or not, so some enemies can be walking normal, some with anti-gravity, and so on. This may also require changes for collision detection since I think the current code considers the top of the block the "ground".
What if we gave everything their own independent gravity settings? We could implement a Group ID field for objects then in the scripts say something like "GIDS[0].gravity=:inverted", which would apply that setting to all objects with that Group ID. Then if we have a powerup type that effects gravity, we could just add a little setting to say which Group IDs are effected.
I actually like the idea of having items in groups and being able to affect settings on all of them at once.
Groups is a good idea, though we'd want to put this to use for more than just gravity.
You mean as in "group these UIDS and forward all method calls on the group to each individual object"? That is, instead of
[obj1, obj2, obj3].each{|obj| obj.do_something}
You want
group.do_something
? We could easily implement this as part of the SSL:
class ObjectGroup
def initialize(*uids)
@objects = uids.map{|uid| UIDS[uid]}
end
def method_missing(sym, *args, &block)
@objects.each{|obj| obj.send(sym, *args, &block)}
end
end
group = ObjectGroup.new(14, 17, 23, 199) # these are UIDs
group.do_something
However, the level designer will have to take care what objects he places in such a group, because not all objects support the same methods (obviously). This will result in NoMethodError
exceptions.
And, is this really so much different from just doing
UIDS[14, 17, 23, 199].each{|obj| obj.do_something}
(which is not possible yet due to how the UIDS::[]
method evaluates its arguments, but this should be easy to add)
Vale, Quintus
This is a ticket to implement anti gravity
There would be 4 total gravity modes:
This requires: