• Content count

  • Joined

  • Last visited

Community Reputation

277 Neutral

About mrpeed

  • Rank

Personal Information

  • Interests
  1. Is redrawing the entire screen every frame the common approach? Even if there are areas on the display that haven't changed? I'm using Pygame and I've read that you should only redraw the area of the screen that has been changed for performance reasons, though I'm not sure if this is unique to Pygame or even relevant to to Pygame anymore.
  2. Game Development Books/Videos (Mapt/Packt)

    Though not from Mapt/Packt, this is a good book to give a read (free online!).
  3. This function detects if a gameobject has moved or has had its sprite changed. It then calls one of two functions (or none), to draw a piece of the games background over the gameobjects current location or previous location. Should functions like this be avoided? Is this good or bad design? Does it violate SRP? Also, how would something like this be unit tested? #clean up the display... def blit_background_over_dirty_rects(self): for gameobject, data in self.relevant_data.items(): if data['location'] != gameobject.rect.topleft: #gameobject moved... self._blit_background_over_gameobjects_previous_location(gameobject) elif data['sprite'] != gameobject.sprite_manager.current_sprite: #gameobjects sprite changed... self._blit_background_over_gameobjects_current_location(gameobject)
  4. If I see no reason for something to be a property over a method should I favor making it a property or a method? For example, I can see no benefit in doing a "full" property over a "is_full() method", other than not having to write (). I can understand if full started as a regular variable and was expanded to a property later, but it wasn't. So in that case what would you say?
  5. Yes, I am initializing that in the __init__ method. And makes sense, I decided to remove the is_full() check from each method and have the inventory size enforced outside of the inventory class. This also removed a lot of clutter from my methods which is good. I was wondering if you can clarify when to use properties? I tend to avoid them because I feel like they are misleading. For example, @property def full(self): return len(self.items) >= self.max_inventory_size Doesn't this hide the fact that this is a method? Would a user not think this a regular variable and possibly try to assign to it? I have other methods labeled get and set throughout my code base that changes behavior within different classes. Would it be misleading to convert those to properties? Another example, would it be to misleading to make this a next_sprite property? def get_next_sprite(self): if self.current_count == self.max_count: #Time to switch sprites... self.current_count = 0 self.current_sprite = next(self.sprite_reel) else: #Increment and return the same sprite from last frame... self.current_count += 1 return self.current_sprite
  6. Makes sense to use a dict actually, not sure why I went with a list. Curious to why you decided to make this a property? Also, what's your take on using an exception? As in my second example.
  7. Here are 3 versions of a method from my inventory class that adds an item to the given inventory (or increases the items quantity). From a Python perspective, which approach would be best? Each method is followed by a sample of how I would use it in practice. I've been pretty interested in code design/architecture lately and I've been trying to get better at Python, so it may seem like a silly question but I'm just curious what you people think. Currently, I'm using approach #1, but I find it misleading that you could add an item and not actually have an item added. And if there's another approach not listed here that would be good please let me know. #1 prevent adding item if is_full(): def add_item(self, item): i = next((i for i in self.items if i.tag == item.tag), None) #Duplicate item... if i is not None: i.quantity += item.quantity elif not self.is_full(): self.items.append(item) player_inventory.add_item(item) #2 throw exception if is_full() and handle outside method: def add_item(self, item): i = next((i for i in self.items if i.tag == item.tag), None) if i is not None: i.quantity += item.quantity elif not self.is_full(): self.items.append(item) else: raise InvetoryFullException("Inventory can only hold 8 items.") try: player_inventory.add_item(item) except InvetoryFullException: pass #3 check if inventory is_full() outside of method: def add_item(self, item): i = next((i for i in self.items if i.tag == item.tag), None) if i is not None: i.quantity += item.quantity else: self.items.append(item) if not player_inventory.is_full(): player_inventory.items.append(item)
  8. Is there a way to combine all tiles into one so I can do something like self.displaysurf.blit(self.background.subsurface(gameobject), gameobject_location). How do I subsurface multiple tiles? Right now I just get a subsurface of my background image at the gameobjects locations and of the gameobjects size. I've heard of it and will definitely check it out in the future. Is Pyglet more difficult than Pygame? Is it just for graphics?
  9. I'm working on a 2D top down game in Python with Pygame. I was wondering if it is better to use one large image for a background or individual images? My problem with individual images is when I want to update a portion of the display without updating the entire display. How can I get a subsurface of multiple tiles if the location I need to update is between two tiles? Do I use layered surfaces?
  10. Ahh, this was my problem makes sense.   And thanks for pointing this out.
  11. Well for example with a move component I send in a reference of the game object so it can move the game object by modifying it's rect location. I figure for some components I need some way for the component to access members of the game object.
  12. pygame.event.pump() keyboard = pygame.key.get_pressed() if keyboard[pygame.K_UP]:     #move player... elif keyboard[pygame.K_DOWN]: #move player... elif keyboard[pygame.K_LEFT]: #move player... elif keyboard[pygame.K_RIGHT]: #move player... if keyboard[pygame.K_SPACE]: #shoot... for event in pygame.event.get(): if event.type == pygame.QUIT: #quit... elif keyboard[pygame.K_i]: #open player inventory... Currently, I'm using key to handle continuous move events and shooting and the events queue to handle events that should not be repeated if you hold down the given key. Is this sensible to do? I tried using events for player movement but I would get input lag.
  13. When exactly should I be using the pygame event module rather than the pygame key and mouse modules? Currently, I use key & mouse for most of my input and only use event to quit the program. So I was wondering if anyone can clarify the difference and the appropriate times to use event vs key & mouse.
  14. If I have a component that receives a game object (in which it's modifying) and which has it's own properties, should the properties be added to the game object or be part of the component? Does it matter? It's something I've been thinking about lately and was wondering if there would be a benefit to doing one vs the other. Code below is Python 3.   class Component:     def __init__(self, gameobject, x, y, z):         self.gameobject = gameobject         self.x = x         self.y = y         self.z = z   OR   class Component:     def __init__(self, gameobject, x, y, z):         self.gameobject = gameobject         self.gameobject.x = x         self.gameobject.y = y         self.gameobject.z = z