Skip to main content

Python Defender 2 - 0.01

This game is a follow up to my original version of pythonDefender. It is another shoot em up, only I have added a lot more functionality.


Erik Martin
(neccarus)
I have learned a lot over the past months, and am applying what I have learned, to the creation of this game. So far there isn't a whole lot to do, but I have basic movement set up. All the menus will be custom made, primarily to suit my purposes. I currently have plans for 10 different playable ships that the player will unlock as the proceed through the game. Along with that, there will also be different types of equipment the player can attach to the ship, I am hoping to implement a tuning system of sorts, where the player can actually modify the different attributes of the equipment once it is on their ship. There is still a lot for me to work on, and I have plans of moving more of the code into class's and methods.

Changes

pygame 844 2d 783 arcade 744 game 397 python 342 shooter 268 space 153

Links

Home Page
http://www.revertedsoft.com/
Source
http://www.revertedsoft.com/python-defender-2.html

Releases

Python Defender 2 0.02 — 17 Nov, 2012

Python Defender 2 0.01 — 16 Nov, 2012

Python Defender 2 0.03 — 18 Nov, 2012

Python Defender 2 0.10 — 6 Jan, 2013

Python Defender 2 0.04 — 23 Nov, 2012

Pygame.org account Comments

  • Mekire 2012-11-17 01:34

    Couple initial things. First of all I don't think it says anywhere that you need to press 'm' after setting up your ship. At first I thought the game didn't proceed past the menu phase. I had to look in your code to figure out how to proceed. Next thing, when you are getting key events it is unnecessary to use ord as in ord('m'), pygame provides custom versions that are more clear. pygame.K_m (or just K_m if you are importing * from pygame.locals) is much clearer and essential if you want to use arrows and other keys like shift and control.

    The most important thing I noted however is that you aren't really using classes "properly". Your ships are not instances of class Ship; they just use a method that is written inside a class called ship. In fact, for this simple reason you lost compatibility with python 2.7. You call a class method without creating an instance. This works in python 3 but not python 2.7. It is also extremely easy to fix and avoid (and generally quite unnecessary).

    I edited your ship module to simply be the function getShip and adjusted the function calls appropriately, and 2.7 compatibility was restored. If you are invested in using python 3 rather than 2.7 there are valid reasons you might break compatibility, but this is not one of them in my opinion.

    (Note I am not suggesting that you don't use classes. Proper use of classes should make your code much easier to follow and edit. But when using classes anything that is lets say, a ship, should be an instance of class Ship.)

    Anyway, keep up the good work, I look forward to watching this grow,
    -Mek

  • Neccarus 2012-11-17 17:13

    Thanks for the feedback, to be honest the ships as method's were from a mess I had made when I was initializing all of my equipment, I moved all of the equipment over to classes (they were dictionaries before...). I just never got around to moving the ship over to a class either. As far as the controls are concerned, none of that is final, this game is still in a pretty early stage for me to be making things final, and I already know I will be changing a lot, including the flow of the main method. A lot of that is just there for me to do some initial testing to make sure I smooth out the little bumps now so I'm not trying to smooth out mountains later.

    Also, I will work on improving the menu interface to make things a little more clear. I did mention in my source page that you had to hit 'm' again to exit from the menu... but I can't expect people to actually read that, so I will work on making things a bit more user friendly.

    At any rate, I appreciate the time you put in, and will get around to fixing my ship module (i actually had intentions to just remove it all together in the first place).

    -Nec

    Mekire 2012-11-18 01:48

    You forgot to declare your currentID class attribute in your Player class in the version you uploaded so now it crashes in both 2.7 and 3 :P.
    Again after adding it directly below your class definition it works fine.

    But besides that... I really think you should look into how to declare class attributes. Every attribute you but beneath the initial class definition with the sole exception of currentID (which you forgot), should be an instance attribute, not a class attribute.

    For example they should be declared and initialized within your init like such:

    self.weaponList = []
    self.reactorList = []
    self.shieldList = []

    You might not be running into a problem with this at this time because I don't believe you are currently ever creating more than one instance of Player, but this is still what you should be doing. In the future this will bite you. Pretty much all you should be making general class attributes are things like ID numbers to keep track of instances (and even this is often unnecessary in most scenarios).

    -Mek

    Neccarus 2012-11-18 16:30

    Ya I am still learning how to use objects, and this was actually one of the things I cam to the realization of last night. Anyways, will be cleaning this stuff up very shortly.

  • Mekire 2012-11-18 11:55

    Starting to get interesting with the AI. I still strongly suggest you change that player class though. Here is a short example illustrating the type of gotchas that will occur if you don't:

    >>> class Player:
    ... weaponList = []
    ...
    >>> Player1 = Player()
    >>> Player2 = Player()
    >>> Player1.weaponList.append("Whatever")
    >>> print(Player2.weaponList)
    ['Whatever']

    Here I created two different instances of Player. Then I appended to the weaponList of one of them. As you can see the weaponList of the other Player was changed as well. Your game is currently one player so you don't see this behavior, but there is no reason that the class shouldn't be flexible enough to handle multiple players if you later decide you want to.

    Cheers,
    -Mek

  • Neccarus 2012-11-18 16:28

    Haha, I actually had that problem when I was creating multiple enemies and figured it out, I wasn't planning on allowing more than one player, but I guess it would just be good practice to initialize a new list for each player. Thanks again for taking the time to look through my code :)

    Mekire 2012-11-19 08:15

    That was essentially my point. It may not affect you in this current program at all, but learning the correct way will help you a lot later. As I said before, general class attributes are very rare to see (because they kind of defeat the whole point behind creating instances). This is why such attributes are generally only used for unique ID numbers and a count of how many instances of a certain class exist. Any other attribute that you could imagine being different between instances, should never be coded this way.

    I saw your comment on my current project. I had realized that you were modeling your program after my project's structure when I originally looked at it :P (keep in mind I'm an amateur myself though). It was one of the reasons I have been trying to offer critique. If you're interested in further thoughts, I think perhaps you do a little too much in your global module. Also, as you already seem aware, your main function itself desperately needs to be trimmed into separate functions. Since you are moving towards classes, you need to ask yourself if certain processing better fits within your classes themselves (in let's say, an update function).

    Anyway, not trying to be critical for the sake of it; just trying to give you a push in the right direction.
    I look forward to your next update,
    -Mek

    Neccarus 2012-11-19 16:17

    Well you do seem to have a little more experience than me, and I welcome criticism where need (in fact I appreciate it and have learned a fair bit). Anyways, moving that mess of a main loop into methods is near the top of my to do list, Especially anything considering the functionality of the projectiles. I still struggle with the whole "so I have this method, now where do I put it", but this project has definitely helped give me a better idea of how to handle that. In fact, this is my first project, that has really used objects and the such, so this whole thing has been a learning experience... which is why I did it in the first place.

    Once again, I appreciate you taking your time to critique my code, and it always gives me an excuse to go over my program and do a little buffing.

    -Nec

  • Cristian 2012-11-24 00:25

    Hi Nec,

    I have only played a bit with your game, and just want to notify you of a small bug before I forget it:
    - start game, select any ship, hit remove on any node type *before* adding anything on any node, game crashes
    I noticed you took into account the situation of adding something and then removing it and then further pressing 'remove' although all the nodes are free.

    Neccarus 2012-11-24 06:22

    Thank you for reporting the bug, this is actually one I am aware of, just haven't got around to fixing it yet. There are actually a fair bit of changes I want to make with how that menu works, so I probably won't get around to it after the changes.

    -Nec

  • David 2013-10-16 21:05

    Great Game :3