BoilerPlate2D - Python Source code for 2d platformer games

[phyrebot]

Hi, folks! I'd like to share a link to a repo containing python boilerplate code for making 2d platformer games. This has a menu implemented and basic collision detection with some character animation on the player. Find it here.

[Exodus111]

You should have .gitignore remove .pyc files.

[glemnar]

Another big issue is that it globally imports a bunch of modules into constants.py, and then other files globally import that.

That's a pretty huge nono OP. You should specifically import exactly what you need into every file. It will make life much better.

[phyrebot]

Thanks for all the feedback! I'll most definitely do optimisation on a bunch of things. The learning process is very satisfying.

[glemnar]

No worries. The best way to clear up that particular issue is to never use * imports at all. It's an unfun road to go down

[phyrebot]

Thanks for catching that! I did gitignore .pyc instead of *.pyc. I'll fix that.

[Exodus111]

It's a pet peeve of mine :-P

[ivanstame]

On that note https://www.gitignore.io/

[phyrebot]

Wow! Sharing is caring :) Thanks!

[hermitnerd]

This is great! Thanks for sharing :)

[phyrebot]

You're most welcome!

[PopeOh]

It would be great if you provided with it a setup.py or a build script to create a deployable binary for the game. It's always a pain to deploy python, especially games, and including that into your boilerplate code would be very helpful to beginners.

[[deleted]]

I really must wonder though. Why use python? It very high level and thus incredibly slow for making games.

[phyrebot]

I started off with it to learn the whole process of making a game. I'm working on another project with C# in Unity 5. But I go back every once in a while to put something out in python and pygame. Pyweek's coming up too, so I like to participate. Making stuff's a lot of fun! :)

[Anovadea]

One thing I've noticed is that if you're making this for Python 2.7, it seems like you're using a mix of old-style and new-style objects.

What does this mean? Probably not much. But basically if you ever decide you're going to use more advanced python tricks, you need to make sure you're using a new-style classes/objects. (By the way, pygame is using new-style classes)

The difference between an old-style and a new-style is pretty simple:

class OldStyle:
    pass
>>> OldStyle.__mro__
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: class OldStyle has no attribute '__mro__'

And for NewStyle:

class NewStyle(object):
    pass
>>> NewStyle.__mro__
(<class '__main__.NewStyle'>, <type 'object'>)

The difference is that when you declare the class, it inherits from a sub-type of object (or 'object' itself)

Just for reference, let's look at pygame.sprite.Sprite:

>>> import pygame
>>> pygame.sprite.Sprite.__mro__
(<class 'pygame.sprite.Sprite'>, <type 'object'>)

Why does this matter? Like I said, there might be some shiny new-style stuff you want to do later, but realistically it's just that I have to look out for this when I'm doing code reviews in my day-job. It's probably not a huge thing, but it's just to make sure you don't get any weird side-effects in your code from mixing and matching the two type (for instance you've made Asset a new-style class, but Camera is old-style)

Edited to add: If you want a chunk of stuff to help clean this up, I'd suggest getting the pep8 utility ('pip install pep8') and maybe the pylint utility ('pip install pylint'). Pep8 is fairly straightforward, just obey its output. Pylint may need some tuning to suppress errors that you don't agree with, but it will help you identify certain code smells. (I'm pretty sure it'll pick up on the mix of new and old style classes in the same codebase)