Re: [pygame] Trolls Outta Luckland - new release
On Tue, Dec 22, 2009 at 8:59 PM, Michael George wrote: > B W wrote: >> >> I'm not sure what you mean. >> >> > > If I move the mouse east, the cursor moves east. If I then start moving the > mouse west, the cursor immediately jumps to the west of the ship, even if > it's currently on the east. And what happens if you move the mouse east and leave it there? Ship keeps moving east until it hits the edge? Gumm
Re: [pygame] Trolls Outta Luckland - new release
B W wrote: I'm not sure what you mean. If I move the mouse east, the cursor moves east. If I then start moving the mouse west, the cursor immediately jumps to the west of the ship, even if it's currently on the east. --Mike
Re: [pygame] Trolls Outta Luckland - new release
On Tue, Dec 22, 2009 at 6:14 AM, Michael George wrote: > B W wrote: >> >> On Mon, Dec 21, 2009 at 9:33 AM, Michael George >> wrote: >> >> Nevertheless, because there's a lot of hand-eye involved in wielding >> an invisible mouse there probably needs to be a visual cue. But I >> think I get what you're saying. Correct me if I'm wrong. Picturing it >> this way... I nudge the mouse left, thrusters on the opposite side >> fire to move the ship in the direction of mouse motion. The farther I >> drag the mouse to the left, the brighter the thrusters burn. They die >> down over time, unless I give them another nudge with the mouse. Oh >> no, I flunked fizzix. :) >> >> That would definitely require more thought to control. I'd have to >> nerf the baddies quite a bit. But hey, if it gets the adrenaline >> pumping--yeah, baby. >> >> > > What about warping the pointer back to the center if the direction changes > (or changes significantly)? I'm not sure what you mean. I was thinking like a rubber band, which is pretty much what it's doing now, where the visual cue is a crosshair hanging in space: stretch the band in a direction, follow until the tension reaches zero. The difference I suggested would be no visible crosshair, rather a thruster that glows and dims depending on the proximity to the x,y destination (the invisible mouse cursor). The direction in which you are moving is indicated by the opposite side that's lit up. The remaining distance to cross until the ship rests motionless is indicated by the brightness of the burn. Honestly, it's just a cheap smoke-n-mirrors so you don't have to see the crosshair. :) Gumm
Re: [pygame] Trolls Outta Luckland - new release
B W wrote: On Mon, Dec 21, 2009 at 9:33 AM, Michael George wrote: Nevertheless, because there's a lot of hand-eye involved in wielding an invisible mouse there probably needs to be a visual cue. But I think I get what you're saying. Correct me if I'm wrong. Picturing it this way... I nudge the mouse left, thrusters on the opposite side fire to move the ship in the direction of mouse motion. The farther I drag the mouse to the left, the brighter the thrusters burn. They die down over time, unless I give them another nudge with the mouse. Oh no, I flunked fizzix. :) That would definitely require more thought to control. I'd have to nerf the baddies quite a bit. But hey, if it gets the adrenaline pumping--yeah, baby. What about warping the pointer back to the center if the direction changes (or changes significantly)? --Mike
Re: [pygame] Trolls Outta Luckland - new release
On Mon, Dec 21, 2009 at 9:33 AM, Michael George wrote: > I, for one, liked the mouse interface after playing a couple of games. I'm > of two minds about showing the cursor. On the one hand it makes it clear > what's going on in terms of the limited speed movement. On the other, it's > kinda distracting. Have you tried hiding the cursor during play? I agree, the visible mouse cursor really distracted me at first. But I got used to it. This was after trying with an invisible cursor. I found myself in a constant state of over-correction. You can easily try it and see what it's like: find the Pointer class in lib/ui.py, fill the image with Color(1,1,1) after it's loaded. > Another thought I had (and this probably needs experimenting to work out > well) is to try to use the mouse as a directional control rather than a > positional control. In other words, currently when I move the mouse to the > left, the desired position of the ship moves left; perhaps instead the ship > itself should move left. The problem with this is how to specify how much, > and also how to retain the speed limit. Mice are designed to be positional > controls, so that might be weird. I rassled with that for some time before I came up with a method. The ship moves to the mouse cursor by pathing along the points of a Bresenham line. I put a throttle on the pathing increment to keep the speed constant, simulating joystick motion. It definitely looks contrived, and distracting, and likely reduces the sense of immersion. Nevertheless, because there's a lot of hand-eye involved in wielding an invisible mouse there probably needs to be a visual cue. But I think I get what you're saying. Correct me if I'm wrong. Picturing it this way... I nudge the mouse left, thrusters on the opposite side fire to move the ship in the direction of mouse motion. The farther I drag the mouse to the left, the brighter the thrusters burn. They die down over time, unless I give them another nudge with the mouse. Oh no, I flunked fizzix. :) That would definitely require more thought to control. I'd have to nerf the baddies quite a bit. But hey, if it gets the adrenaline pumping--yeah, baby. > While I understand your concerns (I'm a perfectionist too on my games) I > think having a fullscreen option is the way to go. I modded the source and > changed it to use your fullscreen options in game_globals.py, and enjoyed it > that way. I think a menu entry to toggle fullscreen would be fine. Also, I > would probably lock the cursor inside the window in windowed mode. I took Bryce's suggestion to heart. I am looking into offering fullscreen as an option. I need to revamp my speed timings, though, to accommodate varying frame rates, something I realized in retrospect needed to be done anyway. This will exact a delay, but it's important. > A few other constructive comments: I like the way the high scores work > better than other games, where I quickly end up with Mike Mike Mike Mike > Mike. However, having to input a player name every time is kind of a pain. > Moreover, having to type with the mouse is a double pain. It would be > better IMO if you saved the player name (and maybe offered a "change player" > button in the menu). I agree. I will save you from that tedium. :) > There seems to be a glitch when the invaders return to their home - > sometimes they "teleport" from the end of their arcs to their stationary > positions. Perhaps a roundoff error getting multiplied out or something? I fixed that once. I think it was a symptom of pathing outside the playfield. Must have come back when I adjusted the paths' control points after widening the playfield. Must kill bug... > The stage counter increments immediately when you destroy the last guy, it > seems it would be better to increment it when the next stage starts. That bugs me too. I would not have tolerated it forever. Now I have greater purpose. :) > I got 27k and stage 8! Damn, you beat me. That puts you on top of the rock. The installed scores are fictitious, so COLGUMM, et al, don't count. (Some poor soul who doesn't read this will surely waste years trying to get 100,000 exactly. =) > Keep up the good work! I think this is a nice game (despite being refried > beans :)) > > --Mike > Great feedback, Mike. You gave me a lot to think about. Thanks so much for taking the time. Gumm
Re: [pygame] Trolls Outta Luckland - new release
> I don't think it would be possible to tune the game to swing both > ways. I will concede that point. Also, I was playing on a laptop, using a trackpoint pointing device, so that could have skewed my perception. (Although I still think keyboard+mouse would be better, you're right that it would be too hard to balance versus mouse-only or keyboard-only, difficulty-wise; all pointing devices are not created equally.) > > What size is your display? And is your eyesight good or poor? No > insult meant by those questions. They are factors I would want to > consider when interpreting your comment. And puzzling out how big is > too big, how small is too small. I played it on a 90dpi LCD monitor. My eyesight is not exceptional either way. > > Also, a large window and graphics means jumping sprites more pixels > per frame and the motion appears jerky or blurred to me, depending on > your frame and refresh rate. Unless the user has a very old computer, I don't know why this would be the case... It certainly seemed perfectly smooth to me, a 2x increase in graphic size (4x increase in number of pixels) should not drop the frame rate unacceptably low. You might want to look into how you are updating the window (flip or whatever) and see if you are doing it redundantly or something. > I guess I could consider knuckling down > and do scaling based on user-selected screen resolution. Not sure how > easy that would be... but I think not very. Probably not the way to go. Would look ugly, too, as you observe. I think you should just make bigger resolution graphics, about twice the size of your current ones would be fine in my opinion. > I was hoping someone wouldn't disparage an alpha > version of Trolls Outta Luckland for being akin to refried beans. But > I guess it had to happen. :) I didn't catch that it was an alpha, sorry. I forgot that people post alpha versions of things on the pygame website. Doesn't change my comments, though; it just means that it defiantly isn't too late to improve substantially. :) I guess people have different motivations for writing games; mine is either "There should be a version of X for linux!" (which tends to not last very long), or "Hey, wouldn't Y be neat in a game, why aren't there any games with Y?" "Z is fun, let's make another fun game like Z" doesn't really do it for me but if it results in a fun game, I suppose it's legitimate (just not very critically interesting even if well done.)
Re: [pygame] Trolls Outta Luckland - new release
B W wrote: wrote: Control scheme interesting and somewhat novel but a little difficult (probably to at least in part to unfamiliarity); there is potential there but it needs refinement. I think I would like mouse to aim, keys to move the ship, personally. Sadly for keyboard and joystick lovers, I'm too sold on the mouse for this one. The nimbleness of the mouse will be much needed by the time v0.0.5 rolls around. I don't think it would be possible to tune the game to swing both ways. If it's tuned for a keyboard, a mouse user would be bored after one-and-a-quarter stages (and give up more quickly than you seem to have). If the reverse, a keyboard user would get mauled (and give up more quickly than the mouse user). :) No, input mode is not going to change. But I might be able to tweak it if presented with some constructive feedback in that area. I, for one, liked the mouse interface after playing a couple of games. I'm of two minds about showing the cursor. On the one hand it makes it clear what's going on in terms of the limited speed movement. On the other, it's kinda distracting. Have you tried hiding the cursor during play? Another thought I had (and this probably needs experimenting to work out well) is to try to use the mouse as a directional control rather than a positional control. In other words, currently when I move the mouse to the left, the desired position of the ship moves left; perhaps instead the ship itself should move left. The problem with this is how to specify how much, and also how to retain the speed limit. Mice are designed to be positional controls, so that might be weird. The graphics are small and difficult to see. Better (larger, mainly) graphics would be a logical improvement at this point. What size is your display? And is your eyesight good or poor? No insult meant by those questions. They are factors I would want to consider when interpreting your comment. And puzzling out how big is too big, how small is too small. While I understand your concerns (I'm a perfectionist too on my games) I think having a fullscreen option is the way to go. I modded the source and changed it to use your fullscreen options in game_globals.py, and enjoyed it that way. I think a menu entry to toggle fullscreen would be fine. Also, I would probably lock the cursor inside the window in windowed mode. A few other constructive comments: I like the way the high scores work better than other games, where I quickly end up with Mike Mike Mike Mike Mike. However, having to input a player name every time is kind of a pain. Moreover, having to type with the mouse is a double pain. It would be better IMO if you saved the player name (and maybe offered a "change player" button in the menu). There seems to be a glitch when the invaders return to their home - sometimes they "teleport" from the end of their arcs to their stationary positions. Perhaps a roundoff error getting multiplied out or something? The stage counter increments immediately when you destroy the last guy, it seems it would be better to increment it when the next stage starts. All I'm hoping for is that this one, at the end, will offer enough flash and character and maybe challenge to inspire someone to play it longer than the first three player deaths, brag about a high score, and become intrigued enough to look under the hood to see how it was pulled off. Hm, reading back... heh, that is hoping for quite a bit. I got 27k and stage 8! Oh, and did I mention Trolls Outta Luckland is HALF-FINISHED? =) Thanks for the feedback, Bryce. There were some good points to it. Gumm Keep up the good work! I think this is a nice game (despite being refried beans :)) --Mike
Re: [pygame] Trolls Outta Luckland - new release
On Sun, Dec 20, 2009 at 10:39 PM, Bryce Schroeder wrote: My, that was quick. > Control scheme interesting and somewhat novel but a little difficult > (probably to at least in part to unfamiliarity); there is potential > there but it needs refinement. I think I would like mouse to aim, keys > to move the ship, personally. Sadly for keyboard and joystick lovers, I'm too sold on the mouse for this one. The nimbleness of the mouse will be much needed by the time v0.0.5 rolls around. I don't think it would be possible to tune the game to swing both ways. If it's tuned for a keyboard, a mouse user would be bored after one-and-a-quarter stages (and give up more quickly than you seem to have). If the reverse, a keyboard user would get mauled (and give up more quickly than the mouse user). :) No, input mode is not going to change. But I might be able to tweak it if presented with some constructive feedback in that area. > The graphics are small and difficult to > see. Better (larger, mainly) graphics would be a logical improvement > at this point. What size is your display? And is your eyesight good or poor? No insult meant by those questions. They are factors I would want to consider when interpreting your comment. And puzzling out how big is too big, how small is too small. I was going to go full-screen, but not all full-screens are created equal. My laptop kinda sucks at it, and Pygame crashes when I exit full-screen mode. Of such are my woeful choices made. I don't know that there is a way to get the desktop info and instruct SDL to open a maximized window, taking into account window decorations. If someone knows this trick and is willing to divulge it, I would be grateful. Also, a large window and graphics means jumping sprites more pixels per frame and the motion appears jerky or blurred to me, depending on your frame and refresh rate. I guess I could consider knuckling down and do scaling based on user-selected screen resolution. Not sure how easy that would be... but I think not very. On the other hand, scaled images look scaled. I am not an artiste and don't know their crafty tricks. Yet. Nevertheless, and circling back around, refresh-related artifacts greatly annoy me and I tend to tweak my displays (and game design) to reduce them. Options... features... work, work, work... > None of the aforementioned problems are really severe. > Overall, it's a competently executed but forgettable basic space > invaders style game; a quirky control scheme alone is not enough to > differentiate it from similar games. Granted, space shooters have been done into the ground. What uncharted territory is left in the genre to award distinction? If you can answer that question for me, I may write a game about it. Until then, you get a HALF-FINISHED competently executed but forgettable basic space invaders. Meanwhile I was hoping someone wouldn't disparage an alpha version of Trolls Outta Luckland for being akin to refried beans. But I guess it had to happen. :) All I'm hoping for is that this one, at the end, will offer enough flash and character and maybe challenge to inspire someone to play it longer than the first three player deaths, brag about a high score, and become intrigued enough to look under the hood to see how it was pulled off. Hm, reading back... heh, that is hoping for quite a bit. Oh, and did I mention Trolls Outta Luckland is HALF-FINISHED? =) Thanks for the feedback, Bryce. There were some good points to it. Gumm
Re: [pygame] Trolls Outta Luckland - new release
Control scheme interesting and somewhat novel but a little difficult (probably to at least in part to unfamiliarity); there is potential there but it needs refinement. I think I would like mouse to aim, keys to move the ship, personally. The graphics are small and difficult to see. Better (larger, mainly) graphics would be a logical improvement at this point. None of the aforementioned problems are really severe. Overall, it's a competently executed but forgettable basic space invaders style game; a quirky control scheme alone is not enough to differentiate it from similar games. On Sun, Dec 20, 2009 at 10:27 PM, B W wrote: > Ahoy, pygamers. > > v0.0.3 is posted. > http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2402.html > > Ain't this like the third space shooter out this month? Sorry... > promise, we did not conspire to flood you with shooters! :) > > Anyway, I'd been wanting to do a shooter for a very long time so here > it comes. A little tired of the joystick and keyboard scene with its > clumsy 2- to 8-way motion. Thought I would go mouse for a big change, > try and get N-way. And that seems to be working great. I poured many > hours in over the past few days, and it shows. Please check it out, I > hope you like. > > I haven't gotten any feedback yet. Not even a "first post1" Makes > me wonder if my stuff is broke. :) Let me know if you have any > problems with the site. And thanks for your interest. > > Gumm >
