I have been playing around with writing some simple card games in Python for fun and I would like to add a graphical user interface (GUI) to the games. Which library would you recommend for writing the GUI for a simple card game?
If all you want is a GUI, wxPython should do the trick.
If you're looking to add sound, controller input, and take it beyond a simple card game, then you may want to use pygame.
I haven't used wxPython, but Pygame by itself is rather low-level. It allows you to catch key presses, mouse events and draw stuff on the screen, but doesn't offer any pre-made GUI controls. If you use Pygame, you will either have to write your own GUI classes or use existing GUI extensions for Pygame, like Phil's Pygame Utilities.
Generally, PyGame is the better option for coding games. But that's for the more common type of games - where things move on the screen and you must have a good "frame-rate" performance.
For something like a card game, however, I'd go with wxPython (or rather, PyQt). This is because a card game hasn't much in terms of graphics (drawing 2D card shapes on the screen is no harder in wx / PyQt than in PyGame). And on the other hand, you get lots of benefits from wx - like a ready-made GUI for interaction.
In Pygame you have to create a GUI yourself or wade through several half-baked libraries that do it for you. This actually makes sense for Pygame because when you create a game you usually want a GUI of your own, that fits the game's style. But for card games, most chances are that wx's standard GUI widgets will do the trick and will save you hours of coding.
The answers to this related question may be very useful for you:
What can Pygame do in terms of graphics that wxPython can't?
I'd say pygame -- I've heard it's lots of fun, easy and happy. Also, all of my experiences with wxPython have been sad an painful.
But I'm not bias or anything.
pygame is the typical choice, but pyglet has been getting a lot of attention at PyCon. Here's a wiki entry on Python Game libraries: http://wiki.python.org/moin/PythonGameLibraries
Related
Let´s say I want to create a game in Python, where a lot of cars will move in canvas, and I still (while they are moving) want to be able to make some actions, like buying items from a shop and so on. Is this possible to do in Python, without any game library import?
Short answer: Yes, but it's not recommended.
Long answer:
For the first part of your question is doable. You can use the tkinter module to create multiple moving objects on your canvas. This is done by using an object oriented program which makes different classes for your cars, in this scenario, and sets them to move. If you want a link for that, here it is. Adding functionality can be a bit annoying, but again, it's tkinter. However, putting these together? It sucks. Based on a lot of articles I've read, making a game in tkinter, is, to put it simply, a very long and painful experience. I highly recommend you to use a game library such as pygame or pyglet, but you technically still can do it in tkinter. So, in conclusion: don't make a game in tkinter, but you still technically can.
There are many questions dealing with pyglet and pygame, but what I want to know is difference in theses two, in simple terms.
Not in technical terms, not experimental features and all that.
They are both libraries, both API, both for creation of games and multimedia apps, right?
Just in plain English, for someone like me, relative begginer, who has finished course about Python in Codecademy and read Head first Python book.
Pyglet is a wrapper around OpenGL, while Pygame is wrapper around SDL.
OpenGL is primarily concerned with 3d rendering, while SDL
is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D.
PyGame is low-level library. You have to do all on your own - starting at mainloop and all functions called by mainloop. You can do it in different ways.
(And you can learn something about mainloops in Pyglet, Tkinter, PyQt, wxPython and other GUIs, not only in Python)
Pyglet is framework - it has already mainloop and you can't change it and you can't see how it works. You override functions which mainloop calls. You have to keep its rules.
I've tried pyglet and pygame and rate pygame as the best .
My goal is to capture frames from a webcam as efficiently as possible using OpenCV. At the moment I'm able to capture 30FPS 6408*480 drawing directly onto a wxPython panel using the standard drawing context (BufferedPaintDC), with about 15% CPU usage (older Core Duo processor). What I'm curious is what sort of performance boost (if any) I'll see if I embed a PyGame canvas within a wxPython frame, and draw directly to the PyGame canvas.
What I'm not sure about is whether the bottleneck is the wxPython frame, and if embedding a PyGame canvas will actually do anything. Or does the wxPython frame act simply like a container and has no influence on the PyGame canvas? I'm hoping I'm making sense here.
The other option would be to use PyGame exclusively, however I really like the functionality of the wxPython widgets, so I'd hate to lose that.
Or is there a faster canvas that I can integrate into wxPython that I'm not aware of?
Thoughts? Thanks.
I don't know why you'd want to embed a gaming library into wxPython in the hopes of gaining a performance boost. Personally, I don't think that will happen. You should take a look at the currently supported drawing canvases that wxPython provides instead or explain what you're trying to do. People have done in games in wxPython...
Anyway, the main drawing interfaces for wx today are wx.GCDC / wx.GraphicsContext, cairo, FloatCanvas, or GLCanvas. Of course, there are also wx.DC, wx.PaintDC and the one you found as well.
my question is quite simple, but I can't move on until I solve it. I want to develop a card game, something like Magic the Gathering. I suppose there will be just a little of animation, but much work with images, image transformation and special rendering - some kind of things, that every unit has now attack plus 2 so cards on table will adapt.
I thought Python will be best for it, because it easy to develop with it and I know it pretty well. Also I have a little of experience with PyQt and Pygame. But I can't decide which one is better for that purpose. What do you think will be easier to use: PyQt, Pygame or something else?
if you want just a simple animation and want to finish your game fast. use the pyqt's scene view. refer to (Rapid GUI programming using python and pyqt) book if you want to learn more about scene view.
PySolitaire is a collection of more than 300 solitaire and Mahjongg games. So maybe if you browse around, perhaps you can get some idea.
What is better? If you are developing games, PyGame I guess.
Both pygame and pyqt will work for what you want to do, but I'd recommend pyqt: you'll be able to use standard widgets (like listboxes, textboxes, menus, buttons, ...).
I've never worked with pyqt myself, but I image that drag 'n drop is something built-in, which will be really useful for a card game.
With pygame on the other hand you'll have to make everything yourself. This will give it more of a game feel as you can draw everything exactly like you want it to look like, but it'll take more work as you have to implement basic stuff yourself.
What is the best way to use PyGame (SDL) within a PyGTK application?
I'm searching for a method that allows me to have a drawing area in the GTK window and at the same time being able to manage both GTK and SDL events.
I've never attempted it myself, but hearing plenty about other people who've tried, it's not a road you want to go down.
There is the alternative of putting the gui in pygame itself. There are plenty of gui toolkits built specifically for pygame that you could use. Most of them are rather unfinished, but there are 2 big, actively maintained ones: PGU and OcempGUI. The full list on the pygame site is here.
You may be interested in this message thread. Looks like they recommend against it.
PyGame works much better when it can manage its own window, or even better, use the whole screen. GTK has flexible enough widgets to allow creation of a drawing area.
This page may help, though, if you want to try it.
There's a simple solution that might work for you.
Write the PyGTK stuff and PyGame stuff as separate applications. Then from the PyGTK application call the PyGame application, using os.system to call the PyGame application. If you need to share data between the two then either use a database, pipes or IPC.
http://faq.pygtk.org/index.py?file=faq23.042.htp&req=show mentions it all:
You need to create a drawing area and set the environment variable SDL_WINDOWID after it's realized:
import os
import gobject
import gtk
import pygame
WINX = 400
WINY = 200
window = gtk.Window()
window.connect('delete-event', gtk.main_quit)
window.set_resizable(False)
area = gtk.DrawingArea()
area.set_app_paintable(True)
area.set_size_request(WINX, WINY)
window.add(area)
area.realize()
# Force SDL to write on our drawing area
os.putenv('SDL_WINDOWID', str(area.window.xid))
# We need to flush the XLib event loop otherwise we can't
# access the XWindow which set_mode() requires
gtk.gdk.flush()
pygame.init()
pygame.display.set_mode((WINX, WINY), 0, 0)
screen = pygame.display.get_surface()
image_surface = pygame.image.load('foo.png')
screen.blit(image_surface, (0, 0))
gobject.idle_add(pygame.display.update)
window.show_all()
while gtk.event_pending():
# pygame/SDL event processing goes here
gtk.main_iteration(False)
I tried doing this myself a while ago, and I never got it to work perfectly. Actually I never got it to work at all under Windows, as it kept crashing the entire OS and I ran out of patience. I continued to use it though as it was only important it ran on Linux, and was only a small project. I'd strongly recommend you investigate alternatives. It always felt like a nasty hack, and made me feel dirty.
The Sugar project has several Activities built with PyGTK and PyGame.
They wrote a support lib to achieve this, called Sugargame. You should be able to modify it for regular PyGTK apps instead of Sugar.
Here's a chapter in Sugar's development book about how to use it.
The lib allows for communicating events between GTK and PyGame.
Enjoy!