Sep-27-2019, 04:01 AM
(This post was last modified: Sep-27-2019, 04:04 AM by xBlackHeartx.)
Honestly, I haven't been saving older versions of my program (if I did, I would probably have over 100 different versions due to the innumerable tweaks I've made). I do however have ONE older version from before I added in the start menu. The only reason I have this is I started saving it outside the default folder, so that I could actually run it from outside the idle (I hadn't figured out how to set my AppData folder to not hidden at the time).
Here's that code:
And yes, I did learn about classes in my c++ and java classes, I just couldn't really wrap my head around them. One thing I was taught though, is it was pointless to put the code for classes in programs that actually use them; you're supposed to put them in a separate module and then import that into the a program you want to use them in. I never saw the need to do make highly a module with highly specialized classes that would only be used in one game. I've only thought about making classes for things I plan to use in more than one program, such as making buttons, labels, code so you can actually close the application, you get the idea.
Here's that code:
import random import pygame pygame.init() screenWidth=500 screenHeight=500 mainWindow=pygame.display.set_mode((screenWidth,screenHeight)) pygame.display.set_caption("Snake") x=250 y=250 snakeSize=50 move="down" length=0 path=[] run=True def frandxy(): global posx global posy posx=snakeSize*(random.randint(0,screenWidth/snakeSize-1)) posy=snakeSize*(random.randint(0,screenWidth/snakeSize-1)) if (posx,posy) in path or x==posx and y==posy: frandxy() def closeGame(): pygame.quit() quit() def loseGame(): while run: for event in pygame.event.get(): if event.type==pygame.QUIT: closeGame() mainWindow.fill((0,0,0)) pygame.draw.rect(mainWindow,(0,255,0),(screenWidth/2-snakeSize*3,\ screenHeight/2-snakeSize,\ snakeSize*6,snakeSize*2)) font=pygame.font.SysFont('arialblack',20) textTop=font.render('GAME OVER',0,(0,0,0)) textBottom=font.render(('Your Length Was: '+str(length)),0,(0,0,0)) mainWindow.blit(textTop, (screenWidth/2-textTop.get_width()/2,screenHeight/2-snakeSize)) mainWindow.blit(textBottom, (screenWidth/2-textBottom.get_width()/2,screenHeight/2)) pygame.display.update() def game(): global run global x global y global move global length global path while run: pygame.time.delay(200) for event in pygame.event.get(): if event.type==pygame.QUIT: closeGame() key=pygame.key.get_pressed() if key[pygame.K_UP] and move != "down": move="up" if key[pygame.K_DOWN] and move != "UP": move="down" if key[pygame.K_RIGHT] and move != "left": move="right" if key[pygame.K_LEFT] and move != "right": move="left" path.insert(0,(x,y)) #move snake if move=="down" and y<=screenHeight-snakeSize: y+=snakeSize if move=="down" and y>=screenHeight: y=0 if move=="up" and y>=0: y-=snakeSize if move=="up" and y<0: y=screenHeight-snakeSize if move=="right" and x<=screenWidth-snakeSize: x+=snakeSize if move=="right" and x>=screenWidth: x=0 if move=="left" and x>=0: x-=snakeSize if move=="left" and x<0: x=screenWidth-snakeSize if x==posx and y==posy: length+=1 frandxy() if (x,y) in path: loseGame() print("You lose. Your length was", length) pygame.quit() break if length>=100: print("You won! The snake filled up the whole screen!") pygame.quit() break mainWindow.fill((0,0,0)) #draw snake if length>0: for i in range(length): pygame.draw.rect(mainWindow, (0,255,0),(path[i][0],path[i][1], snakeSize,snakeSize)) pygame.draw.rect(mainWindow, (0,255,0),(x, y, snakeSize, snakeSize)) #draw food pygame.draw.rect(mainWindow, (255,0,0),(posx,posy, snakeSize, snakeSize)) if len(path)>length: path=path[:(length)] pygame.display.update() frandxy() game()And yes, this is really sluggish. The reason for the input lag was it was only checking for key presses every fifth of a second, which meant that my button presses would fail to register if I didn't hold down the button for long enough. Even reducing the delay didn't really fix this. Replacing that line of code with an fps limiter completely removed the input lag problem.
And yes, I did learn about classes in my c++ and java classes, I just couldn't really wrap my head around them. One thing I was taught though, is it was pointless to put the code for classes in programs that actually use them; you're supposed to put them in a separate module and then import that into the a program you want to use them in. I never saw the need to do make highly a module with highly specialized classes that would only be used in one game. I've only thought about making classes for things I plan to use in more than one program, such as making buttons, labels, code so you can actually close the application, you get the idea.