• Content count

  • Joined

  • Last visited

Community Reputation

306 Neutral

About lucentbeam

  • Rank

Personal Information

  • Location
    Portland, OR
  1. Nice article, but I would like to say that I object to calling Bob Ross "infamous" :)
  2. My suggestion is that now is the perfect time to learn about classes! You have two types of objects in the game, right now, that you'll want to be checking for collisions on. The "you" sprite (or rather, mouse_c object) and the dots represented by the r1, r2, etc. variables. Start with your mouse_c: there are a few things that can be merged, the 'you' string representing the graphic, the mouse_c image made by pygame, and the movex and movey variables. Make a class that combines those, and then work on doing the same for the dots (I assume that's what you want to pick up?). After that, figure out how to make both classes inherit from pygame.Sprite, and you can start using some of pygame's built in collision checking on each game loop.
  3. I'd be interested in a team project, too. Like Aspirer, I like to learn something new with a game... But that being said, there's a lot I can learn. I have only really used C++ and python, and I'd be happy to branch out. I've also never really used much version control (just very basic mercury), and have never been a part of a team project, so just being a part of something is already a win on my end.
  4. For anyone interested in playing the final version of my game on windows (that is, matching the Mac app I posted), I finally got a chance to sit down and package it! Not a lot of difference, but it at least shows a minimal win/lose screens, since that's what I focused on getting in last. Here it is   It includes a more prominently displayed readme, since it seems my controls ended up being far from intuitive.
  5. For those interested in playing the final package that was made for my game, but don't have a Mac, this is it:   This was the final version that made it to the Mac app, I just didn't have a chance to sit down at a Windows computer and compile it until after the weekend. The win/loss screens are minimal, but at least there. That's the primary difference.
  6. So apparently I left the readme out of the last windows package I made. I guess I was in too much of a rush. Combined with my bad control scheme, that's sort of a problem! Sorry, everyone... Here it is, incase you're trying to play my game and getting frustrated with it:
  7. I'm gonna throw in and just say that I think Python is amazing. I went from using a little perl (for scripting purposes) to heavily relying on Python, and did it all while learning about game-related concepts. I'd recommend the free book at .It's aimed at young audiences, so it explains every bit of code, and constantly works at the concept of core game mechanics.
  8.     Ahh - sticky keys! I forgot all about that dumb thing. I'm usually around my Mac, and so ended up doing 95% of my development on it (which is also why the windows binary isn't the most up-to-date version of the game).
  9. Aspirer, did you try the mouse control? I think it's a bit more comfortable, if you're okay with the latency of paddle speed versus mouse speed.   The arrow key setup was actually not a glitch - it's very intentional on my part, though I definitely understand the frustrating aspect of the choice. If you leave the paddle in one of the hemispheres for a long time (rather than instantly changing direction), I found that fixing left/right to clockwise/counterclockwise can be just as confusing, so it was an attempt to keep the arrow keys as always "making sense."  On the other hand, what you experienced, switching keys for a rapid change in direction is also confusing if you change hemispheres. I didn't really have people to playtest, but from the little response I've got it sounds like the latter is more common. Really I should put in a time buffer after stopping the paddle so that it uses both methods.   In retrospect, I realized pretty quickly in that my design posed something of UX problem... I got a late start (halfway through the month), so I just kept on with it. Still not sure what the best control scheme would be..     EDIT: Also, right shift and left shift are fixed to clockwise/counterclockwise, if you want to try that method. Though, there is a weird bug where the first time you press one of them in the game, it doesn't register. From what I can tell, that's something strange with SFML.
  10. Hey, Nocturnus pointed out that mine (the windows version?) may not be working. Again, it's incomplete anyhow, but I think this may fix it...   I'm completely new to C++ and SFML, and also haven't really packaged anything before. Hopefully it works 
  11. Alright, mine are below. Unfortunately, my win condition got screwed up at the last minute and I couldn't figure it out, so I guess I'm DQ'd :-/   Anyway, I'm not sure if there are enough judges for me anyway. The OSX build is my most up-to-date:   For windows, below, the build is a previous one with a lot less functionality. The gameplay mechanics are all in, but incomplete in terms of win/loss condition. Bah :-(       EDIT:  A little late on the competition, so I'll leave it up to the judges if they want to score or not. But I found my last minute bug (using < rather than <=... d'oh).  Here's what I believe is the fixed version, for completeness:
  12. Brand new to these forums, and relatively new to gamedev in general... But I'll participate!