Stardog - 0.2010.11.30.1

Thanks Mieze! Very thorough. I'll have them fixed in a release this week.

Some (critical) bugs: http://pastebin.com/5b4ra41K

I wrote some stuff here, but pygame logged me out, so meh.

Stardog - 0.2011.01.18.1 available at same link. Fixes a glich where scripts tried to affect player ships after they died and had restarted, causing the game to crash. Fixes a glich that caused a crash when looking at FlakCannons in the menu. Thanks to shundread on #pygame IRC for feedback.

Big update! Hopefully you will find the gameplay actually fun now (at least for a little while). There should be updates frequently now.

I was using 1.9.1 in Windows. I have 1.8.1 on a virtual Ubuntu machine, and it gets the same error (and it's Rect has no copy()). I made a note in the docs and I'm putting up a version that uses Rect(rectToCopy) instead.

I really thought .copy() would not be a new feature.

Everytime i tried the game. I have python 2.6 and pygame 1.8.1 which version do you use?

masterlee: I am not able to reproduce this crash, and the error does not make sense: a pygame.Rect object should have a .copy() method. Did you get the error more than once?

I shot down a small ship tried to collect the loot but the game crashe:

lee@leenux:~/Downloads/stardog0.2010.11.20.0$ python stardog.py
/usr/lib/python2.6/dist-packages/pygame/sysfont.py:139: DeprecationWarning: os.popen3 is deprecated. Use the subprocess module.
flin, flout, flerr = os.popen3('fc-list : file family style')
this game may run faster if you install psyco.
Traceback (most recent call last):
File "stardog.py", line 180, in <module>
game.run()
File "stardog.py", line 148, in run
self.curSystem.update()
File "/home/lee/Downloads/stardog0.2010.11.20.0/solarSystem.py", line 92, in update
SolarSystem.update(self)
File "/home/lee/Downloads/stardog0.2010.11.20.0/solarSystem.py", line 34, in update
collide(floaters[i], floaters[j])
File "/home/lee/Downloads/stardog0.2010.11.20.0/solarSystem.py", line 179, in collide
ship_freePart_collision(a, b)
File "/home/lee/Downloads/stardog0.2010.11.20.0/solarSystem.py", line 243, in ship_freePart_collision
ship.game.menu.parts.inventoryPanel.reset() #TODO: make not suck
File "/home/lee/Downloads/stardog0.2010.11.20.0/menus.py", line 272, in reset
Rect(0,0,PartTile.width, PartTile.height)))
File "/home/lee/Downloads/stardog0.2010.11.20.0/menus.py", line 218, in __init__
rect = rect.copy()
AttributeError: 'pygame.Rect' object has no attribute 'copy'

Now that I built a prototype of such a parser, I realized that it doesn't work just by using + on methods, but they can be assigned with = or setattr() (which is what I used).

It's certainly possible. I don't know if I can give any help that's anywhere near optimal coding, but the technique I'm thinking about involves OOP and Python's nifty feature of using + and - operators on classes to change their methods. So you could define functions for all the basic behavior blocks of every possible actor in the game and the .cfg file would act as a guideline (or list) on which of those to add into the custom game element class that's needed for whatever is going on. They'll fit right into any of the classes if they have self as the first call argument. Well, that's only if you decide to go with that route.

I'm not sure if that came out very clearly, so just an example that could be used in a similar game: .cfg file has the line "ENGINE:Ion Thrust Engine;BASEHEALTH:100;SLOTS:4;ATTACH:PART:Ion Thruster:PART:Shielding"

Then it's only a question of building a parser that can step through that line, with "".split(';') and such. Save that info to a dictionary and run it through a classgenerator method that returns the proper class, of course recursively running itself for whatever parts it needs to create. If it gets really complicated, you could just use a master parts dictionary where generated parts are saved and checked against before running generation.

That kind of parser takes quite a bit of work to create (and manage when extended with new stuff), but it'll be worth every moment of its development if find your part files being bloated to several hundred kilobytes and up. Plus it'd be easier to develop an independent parts database manipulation program.

However, if the game will present only a hundred or so parts, this would probably involve a lot more effort than it gives in return.

Donpachi- Ghosting: it looks like the ghosting is caused by something like an integer overflow in pygame. I could make the sun ghost reliably if I was at about (6200,0), (0, -6200), (6200,-6200), etc. pixels of it. It is fixed when I fixed my code to only draw sprites that should be on the screen (also a small speed up!) thanks!
Dynamic content creation: There are two cases: parts that require different functions (gun vs. engine) and parts that just have different variables/images (big gun vs. little gun). I'm not sure if the first case is possible, and I haven't figured out a good way to do the second case. Maybe you'd be willing to help me?

Works in Ubuntu without critical problems. The only annoying thing in the game was that I found a lot of planets and ships that were 'ghosts' - You could float over them as much as you wanted but no collision could be made with them either by ramming or shooting. You could consider moving the parts stuff and all the other data used in dynamic content creation into separate .txt or .cfg or some such files. It's easier to do now rather than 20 versions further down the road, but on the other hand it's not exactly critical either.

Josef,
Thanks! I'm excited to get such technical feedback.
The framerate should be self-regulating (the constant does almost nothing). Did it create problems for you? (I agree that over 60 does not matter).

The display mode was sloppy on my part; I'll fix it.

Hardware surfaces - I'm in Windows, and now I can't see any difference in performance with or without this flag. I'll test it on OSX and Ubuntu when I get the chance. Maybe this is why it flickers so bad fullscreen on OSX?

I think that dirty rect animation will have little effect since my background is animated. Do you mean Surface.convert? I do that most places, but I'll look through and see if I can improve. I think I was not doing it for surfaces that are only drawn once- is that good?

Sound- Thank you! Not my field at all; I think it sounds better now, but am not sure I can tell. I know other people will notice.

Next update (maybe later tonight) should implement these.

I'm interested in seeing how this will evolve. A few tips for you though:

First, the you've got an FPS setting in there and you have it set at 200. There's no reason to run a game like this that fast... it looks fine at 20 (which is what it does on my machine, more on that in a minute) and you probably don't need more than 60.

Second, your set the default resolution by running pygame.display.list_modes() and picking value 6. The output of that function is very different on different platforms; on mine your code picks 640x512, which I doubt you intended.

I notice you use a lot of hardware surfaces. They don't always work on all platforms (I've heard pretty much that they work nowhere but Windows). So there are a few other things you can do to speed things up, like dirty rect animation and converting your images to the display pixel format. (There are tutorials about this in the Pygame documentation).

Finally, I've noticed your sounds are sampled at 44100 Hz. Pygame's mixer defaults to 22050. So... if you want the sound to sound less scratchy (at least it sounds scratchy to me) change line 79 of utils.py from "pygame.mixer.init()" to "pygame.mixer.init(44100)"

Frapa - what do you think of the health bars now? They only show up when a part has under 80% life, and they are dim circles instead of bright lines.

Gogoplex - if you are interested, I'm sure you could help. Start by criticizing, maybe.

Nice idea!!

I think you should reduce the number of health bars, maybe you can move them in a corner of the window.

Neat. I had great fun modifying the spaceship, and experimenting with all the pieces.

I'm not sure I can do anything to help with my actual level though.

Controls are in the readme:
Game:
enter: pause/menu (the Parts and Keys menues are implemented!)
delete: self-destruct, restarting the game
esc: quit

Default ship controls:
w/up: thrust forward
s/down: thrust backward
a/left, d/right: turn
q, e: thrust sideways
ctrl: shoot all guns

These can be changed in the 'keys' menu.

Oops. Enter opens the game menu. The error is from a debug statement I left in. Fixed it in the version up now, or you can delete lines 395 and 396 from menuElements.py .

looks good from a start off, you may want to add the controls though. I also got this traceback when I clicked on parts after I pressed enter:

Traceback (most recent call last):
File "stardog.py", line 183, in <module>
game.run()
File "stardog.py", line 164, in run
self.menu.draw(self.screen)
File "/home/timothy/Desktop/stardog prealpha 10-25-10/menuElements.py", line 89, in draw
panel.draw(self.image, rect)
File "/home/timothy/Desktop/stardog prealpha 10-25-10/menuElements.py", line 55, in draw
panel.draw(surface, rect)
File "/home/timothy/Desktop/stardog prealpha 10-25-10/menus.py", line 115, in draw
Selecter.draw(self, surface, rect)
File "/home/timothy/Desktop/stardog prealpha 10-25-10/menuElements.py", line 395, in draw
if stardog.debug:
NameError: global name 'stardog' is not defined

Not sure what exactly what it was, I'll take a look.