Re: NullpoMino Version 6.9.0.2 (2010/05/0 I mirrored it on my server. http://nihon.se/NullpoMino/NullpoMino6.9.0.2.rar
Re: NullpoMino - now with netplay! Great game. Just some suggestions: how about some optional keys for double-rotations and double-tap (both left and right)?
Re: NullpoMino - now with netplay! I believe the key mapped to button E acts as a 180 rotation in rule sets that have it enabled. The double tap key, however, is an interesting request. I don't think I've seen that one before.
Re: NullpoMino - now with netplay! Oh yeah, my server is back up online since a few days back. 143.homelinux.com is alive again. Server up and running 24/7 on 6_9_0_2
Re: NullpoMino - now with netplay! Sorry didn't read the manual before posting. Should have enabled the double-rotation in the rule editor beforehand. The reasons behind my request are natural to me as they prevent misdrops caused by issues rather irrelevant to the lack of mastery of movement finesse. From the cognitive perspective, pressing one key is significantly easier to master than tapping two keys rapidly - not only does the latter doubles the muscular effort of the former, but it also forces player to perform fast, consecutive muscular exertions which are so mentally demanding that attention invariably shifts to the discomfort caused by them. Furthermore, by replacing double taps with single taps, we effectively utilize repetition to our advantage. As the result, these single taps are easily automatized so that the mental ressouces otherwise allocated to visualizing taps can be used more effectively.
Re: NullpoMino - now with netplay! I'd say avoidance of double tapping is a relevant aspect of mastering movement finesse. It is important to know which placements not only yield a sound stack, but are also cost effective and yield similarly fast placements for subsequent pieces. I'm not entirely sure how I feel about adding a tool to the set in order to sidestep this aspect of the current finesse model.
Re: NullpoMino - now with netplay! Also, double rotating is usually kind of a wash because double rotations are often performed using two different buttons (i.e. A and C). When one needs a double rotation the other way, then a double tap is required, but Amnesia showed a way of getting around it by using the index and middle fingers of the same hand one after the other on the B button of an arcade stick. Double tapping can also be avoided with smart use of firm drop, which can allow things like replacing one of the taps with a wallkick off the stack. That sort of placement is considered pretty standard in TGM. If you're trying to make it so that different types of taps are automated, you might as well look into something like KeyBlox or Typomino.
Re: NullpoMino - now with netplay! hm..actually my original motivation was to introduce the simplest mechanism for "double-right"/"double-left" movement. Yes, avoiding double-tapping was part of the motivation, but I actually want to eliminate double-tapping altogether with all other cognitively demanding key combinations. I do believe that this can improve gaming experience mostly by alleviating physical discomfort (sound funny but it's true ) To illustrate, suppose that every time you want to make a single rotation, you have to press left twice. We generally want to avoid double-tapping (same finger) and some will think of ways to bypass it. Personally, I would think the best solution is to implement a key performing the movement. Now, isn't that cheating? Well yes, but I think it's not only legitimate, but encouraged. Sorry, didn't clarify that I'm currently an SRS player (so the firm drops in TGM only applies to some extent). My current finding is that with "double-left" and "double-right" implemented, every hard-droppable movement will require at most 1 DAS+1 directional key+1 rotational key and not more. So optimal movement will not involve any double tap (same or different finger alike) Also, I'm playing with an ordinary keyboard and find it difficult to perform double-tap by alternating fingers - I can imagine that it's much simpler with arcade button, but with keyboard, different aspects come into play. (I think most arcade players would have preferred having buttons for "double-right"/"double-left" and they would find them to be ultimately easier)
Re: NullpoMino - now with netplay! Certain placements being difficult as the speed rises is supposed to be part of the challenge. Adding macros for doubletap left and doubletap right would be cheating. Instead of finding some way to make those moves easier, you are supposed to avoid having to do them in the first place.
Re: NullpoMino - now with netplay! I think there is even less reason for this if you're an SRS player. You have all those nice symmetrical S/Z/I orientations, so there are even fewer situations where you'll actually have to double tap.
Re: NullpoMino - now with netplay! Yeah. In SRS the I piece never needs double-tap, so the location of I's rotational center alone entails the elimination of around 4 potential double taps. I just think that double-tap is still performed somewhat frequently despite that. But if you consider that cheating then I don't know what to say, as my fundamental philosophy on tetris rules is quite different from yours. I just believe that a tetris game should involve minimal, simple muscular movement and cause no discomfort, so that players with any level of physical limitation (induced by anatomical difference?) are not disadvantaged. I also feel that it's unnecessary to introduce addition physical dimension to the difficulty of the game, as the mental stres on players under high speed is enough to make them top out.
Re: NullpoMino - now with netplay! I think our views mesh to some extent. I've always been glad that TGM is a game where physical execution is not the focus, as opposed to games like GB Tetris. I think all players should be striving to avoid placements requiring double taps, which is why I was mite skeptical of a double tap key's necessity. Only keyboard players really get to get away with multi-tap moves in the first place, as a stick doesn't lend itself well to this sort of maneuver. I think there are some problems that should preclude it from being enabled by default*, but I can definitely see arguments for it being an option for custom rulesets. Perhaps there is a way to shoehorn them in under keys E and F and not have to add additional keyboard mappings. (Can C be used as a double rotate?) I may give it a look this summer when I do some Unofficial Expansion work. *(It brings up the troubling old problem with how multiple shifts in a single frame should be defined with respect to gravity, and it may open up moves that aren't normally possible under 20G (see: Instant/9G DAS in Lockjaw). On top of that, it would give an unnecessary tool to players not coping with physical limitations that could double tap the double tap key and avoid having to manage DAS properly in some situations. A quad tap is definitely not a tool we should give to anyone by default, hahaha.)
Re: NullpoMino - now with netplay! I've personally always thought that, to avoid being able to skip over holes, Instant DAS should evaluate gravity after every movement. Easily skipping over holes kind of ruins the point of 20G... It would also look really weird and throw everybody who's had a lot of experience with 1G DAS off their game.
Re: NullpoMino - now with netplay! Yeah, I'm thinking that may be the way to go. I think a multi-tap frame should basically crunch multiple frames down into one. So, it should evaluate rotation, then loop over shift and gravity until there are no more shifts to iterate. I think if we're, say, TASing Final mode, we shouldn't be able to get in more shifts than there is lock delay. Does that sound like a valid way to do things?
Re: NullpoMino - now with netplay! Okay, here's how it should be. "instant" autoshift should really be 9G, which is sufficient to reach any wall from anywhere.. When gravity (20G) is in excess if the autoshift, then it shouldn't jump the hole. Now say gravity is 5G. Then you should be able to jump the hole with instant autoshift.
Re: NullpoMino - now with netplay! Well, if we don't allow hole skipping at any gravity above 1g, then we have a problem. Code: I | I | I | I | X | X | X | X | X X | X X | X | Lets say gravity is at 5g and DAS is instant. Now logic dictates that if sideways motion is faster than downward motion, this I piece should clear if it instantly went to the wall. Lets define instant as 20g sideways. If we actually do a full interpolation, we have these internal states not shown. Code: | I | I | I | X I | X | X | X | X X | X X | X | Code: | | I | I | X I | X I | X | X | X X | X X | X | Code: | | | | X I| X I| X I| X | X X | X X | X | Code: | | X I| X I| X I| X I| X X | X X | X | before finally being dropped 5 to end up at here Code: | | | X | X I| X I| X I| X XI| X X | X | However, if you special case forciing i to drop down into holes, it will not clear the last gap. Th question is when does lock delay start? If it starts on contact, then it will be unable to break away, and slide all the way down to the very bottom, even though it is moving faster sideways then down. If lock delay starts when gravity would lower the piece, and the gravity is buffered and applied when possible, it will instead get blocked by column 9. Now, we already have an example in TGM. When gravity is less than 1G, 1G DAS will consistently skip over the hole. I've gotten caught quite a few times by that. It won't decide to just drop in because the piece is in lock delay. if you are moving faster then the gravity, it will skip it. What I describe is simply extending this principle to higher gravity and DAS. And under that principle making sure that DAS even when greater than 1g never surpasses 20g will stop hole skipping in 20G. We can safely let instant DAS go all the way up to 20G, and holes will still be impossible to jump over when the gravity gets higher. I was proposing a smaller limit on the "Instant DAS". The fact that I failed to consider doubles mode is a valid point, though.
Re: NullpoMino - now with netplay! Zircean, since I didn't respond to your inquiry on IRC on PoochyBot, I'll just post the status update here again: PoochyBot's more or less ready for release. I'm still sticking to the previously announced June 10 release date. I'll probably spend the rest of the time from now 'til then adding more comments and whatnot to the source code to make it more readable. It can do fairly well on Speed Mania 2, except sometimes it can't downstack fast enough to drill down to the garbage on 500-1000 (mainly in the later sections in that range). I've also had it play Phantom Mania, and it just totally pwns that mode. XD In short, its two biggest weaknesses are I piece droughts and rising garbage. And to a lesser extent, droughts of a particular piece it needs (such as a J piece when there's a two-deep valley in the leftmost column). Also, it can't play big mode worth beans.
Re: NullpoMino - now with netplay! Time to derail this thread (sorry.) I was screwing around on netplay and nullpomino gave me the most ironic error possible. Code: 00:54:53,013 [main] ERROR StateNetGameSDL: render fail java.lang.NullPointerException at sdljava.video.SDLSurface.getWidth(SDLSurface.java:87) at sdljava.video.SDLSurface.blitSurface(SDLSurface.java:551) at sdljava.video.SDLSurface.blitSurface(SDLSurface.java:570) at org.game_host.hebo.nullpomino.gui.sdl.NormalFontSDL.printTTFFont(NormalFontSDL.java:52) at org.game_host.hebo.nullpomino.gui.sdl.RendererSDL.drawTTFDirectFont(RendererSDL.java:165) at org.game_host.hebo.nullpomino.game.event.EventReceiver.drawTTFDirectFont(EventReceiver.java:406) at org.game_host.hebo.nullpomino.game.subsystem.mode.NetVSBattleMode.renderLast(NetVSBattleMode.java:1060) at org.game_host.hebo.nullpomino.game.play.GameEngine.render(GameEngine.java:1429) at org.game_host.hebo.nullpomino.game.play.GameManager.renderAll(GameManager.java:230) at org.game_host.hebo.nullpomino.gui.sdl.StateNetGameSDL.render(StateNetGameSDL.java:145) at org.game_host.hebo.nullpomino.gui.sdl.NullpoMinoSDL.run(NullpoMinoSDL.java:372) at org.game_host.hebo.nullpomino.gui.sdl.NullpoMinoSDL.main(NullpoMinoSDL.java:240) It seems it was handling the exception or something weird though, because it kept going until my Java crashed (long log here http://freetexthost.com/gvaf6d3zww This is obviously a bug in the SDL driver. However, I'm only using SDL because this crappy Linux distro i'm using crashes whenever i run Slick. I'm sure the bug is actually in Slick or NullpoMino but this is the first Linux OS where i actually had a problem running Slick. Here's the log when attempting to run Slick: http://freetexthost.com/lbjsloyv3u (It might be important to note that i'm running on a non-rectangular multimonitor setup, in a 640x480 window.) Hope that's helpful.
