pygame vs löve

[farvardin]

Hello,

what would you said to advertise your system? What would you say to favor löve? For what I've seen, löve's code seems to be simpler to read and understand, and the manual has a better presentation, giving me more interest for löve. Pygame seems to be more complete, but harder to master.

[cag]

pygame has an impressive track record, and from what I've seen and heard, python is a very fast (read: not fast executing, but fast coding) prototyping language, so pygame is easy to use. It's been around for quite some time now (1.7.*), so it's a lot stabler than love right now, I would think.

love, on the other hand, is rather young right now, so it's bound to grow. Also, it uses lua. Lua's an amazing language, and I'm surprised it hasn't been used for scripting in more open game engines, and honestly, python looks bulky to me.
love also has a load of dlls...
OK, fine, so it makes exchanging one system of foobar for another a breeze, and it's modular. Ignore the dlls comment, I'm just spoiled.

[Merkoth]

Deploying a pygame-based game also requires a load of shared libraries. In general terms, deploying python apps in Windows is a chore (as most other tasks, hehe), because you have to bind your sources, the python binary (or "runtime" if you like) and all the needed libs in one huge .exe file (you cant's ask your users to download the python interpreter and the needed libs by themselves).

Functionality-wise, the only important thing I think LÖVE currently lacks is something like pygame's sprites and spritegroups. Both are fairly easy to implement, though.

[rude]

Sorry, I'm afraid I've never used PyGame (or touched Python), so I am unable to compare the two. You'll just have to try both and judge for yourself. PyGame is pretty famous though, so it's probably more feature-rich and stable, like cag says.

the manual has a better presentation, giving me more interest for löve

That's really good to hear. By the way, if anyone has suggestions for improvements in the manual, the time is now. I'm currently rewriting the documentation tool. (In Lua <3)

[farvardin]

I don't think the manual needs much improvements. It's very precious to have small working example, and longer demos as well (like we have now, but more would be welcome of course). For the manual, I'd say more examples if possible for each function, or at least some default values. For example for love.graphics.setMode I can read:

Code: Select all

love.graphics.setMode( width, height, fullscreen, vsync, fsaa )

Arguments
width Display width.
height Display height.
fullscreen Fullscreen (true), or windowed (false).
vsync True if LOVE should wait for vsync, false otherwise.
fsaa The number of FSAA-buffers.

what is supposed to be this fsaa number? I assumed 1 would be ok, but one cannot be sure...

A searchable index would be a nice addition too.

[score100]

Hey guys,
just reviving this as I have the same question and the thread seems quite old by now. I've been getting into love now for some weeks, but I feel tempted to switch to pygame (without having tried yet).
Reason is, that there are more complete manuals for a further developed framework it seems. Another one is that it would be the first time to learn a 'real' programming language to me (only done scripting within game creation software and visual programming so far) and it seems that Python is an already widely used language with loads of applications that I could use in different areas than just game making once I've mastered it. This is at least what I got from browsing the webs and talking to some people.
Last but not least, from what I understood there's the possibility to play back video in pygame via an external library. As someone who's been making films himself I'd really like to incorporate those within games.
Let me know what you think.

[kikito]

My advice is try both. The worst that it can happen is that you learn some things

Python is a good language to learn. And, Python as a language is used in lots of other environments - web development, some scientific stuff, etc.

I tried Pygame years ago and it seemed like an entangled mess. But that could have changed. LÖVE, on the other hand, is much more terse - there's less things to learn, so you can start doing things faster, but the tradeoff is that the framework comes with less "batteries included".

[OttoRobba]

My advice is try both. The worst that it can happen is that you learn some things

This.

I recently ported part of my game to Javascript just for kicks and this taught me a lot and made me a better programmer, as a whole.

PyGame has really good learning material (inventwithpython.com) - I do think it is a bit of a messy engine, like Kikito pointed out.
You might also want to check Kivy, it is a cross platform engine made with Python and is fairly more organised than PyGame.

Hello World in Kivy:

Code: Select all

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Hello World in LÖVE:

Code: Select all

love.draw = function()
    love.graphics.print("Hello World", 400, 300)
end

I love LÖVE's simplicity but Kivy doesn't seem too hard

[gestaltist]

I have started my adventure with games with pygame and moved on to pyglet then to cocos2d then to Löve. Pygame is OK at best. Its strongest feature is the amount of tutorials and examples on the web. But it’s no longer actively developed and it shows. E.g., it doesn’t support 64bit, it has problems with Retina displays on the Mac, and I couln’t get it to work with Python 3, either. I liked Pyglet and cocos2d (which is built on Pyglet) much better, but they aren’t very actively developed either and especially cocos2d had weird bugs and inconsistencies. It is also difficult to bundle an application to a distributable format (.exe or a Mac app). You have to use external tools (like py2exe) that aren’t guaranteed to work.

To sum up: I like Löve better because:
- it is actively developed
- there is really good documentation
- the physics engine is very good (with pygame you would have to learn and integrate an external library like pymunk or pybox2d)
- it is modern: has support for Retina screens, I don’t have to dabble with its settings, it just works
- it has a great way of bundling applications

I have much more experience with Python than with Lua, so would like to offer some thoughts, as well.

Python isn’t any more “real” than Lua. It is just used in different scenarios. To give you an example, check out the Wikipedia pages for the games scripted in Lua and in Python:
http://en.wikipedia.org/wiki/Category:L ... ideo_games
http://en.wikipedia.org/wiki/Category:P ... ideo_games

As you can see, Lua is much more widely adopted by the game industry for various reasons. Neither language is suitable to write a game engine, but as a scripting language in games, Lua is more of a “real language” than Python is: it is lightweight, it is easy to bundle it with a game, and it originated as a data description language, so it is well-suited for both data description and game logic.

On the other hand, Python is more widely adopted in web development (Django et al.), scientific/mathematical programs (see the scipy library for an example), etc. Python is a great language and worth learning - if you want to go beyond games. If you just want to program your own Tetris/MarioBros/whatever, stick with Löve.

[Jasoco]

what is supposed to be this fsaa number? I assumed 1 would be ok, but one cannot be sure...

A searchable index would be a nice addition too.

Google "FSAA". It's Full-screen Antialiasing. It smooths the edges of shapes drawn on the screen. Good for when using Löve's circle, rectangle and polygon functions. It looks especially nice when using the HiDPI on a Retina display.

Some graphics cards support different values. Löve will not error if the wrong value is used, but will throw a warning to the console, but it's not a problem because the GPU will simply jump down to the closest proper value.