LUA or PyGame

I was wondering, me and my buds wanna start making a game and we wondering which language (LUA or Pygame) we should use for that. Any recommendations or information about these 2?

PyGame would be easier for starting out.

SEPPLES

What about LUA?? i've heard good things about it

LUA isn't really useful, while Python, however slow it may be, is a good all-purpose scripting language. You'll find more use for it.

why LUA isn't useful? I've seen a lot of games using it

Lua is great. Python is a nightmare.

Python is great. Lua is a nightmare.

Lua is a nightmare. Python is great.

Python is a nightmare. Lua is great.

Speak something useful

>>6
You can use Python the same way, as well as Scheme, Perl, even Ruby, ..., more or less any scripting language can be used to extend games.
And Python with PyGame or Pyglet is probably better to write games in. Also, it's better overall as a language and is a better tool for more areas.

>>7,10
Array indices starting at 1.

More advices? More info? We need some more info about the differences between these 2 languages

>>12

array indices starting at zero is usually really confusing for a beginning programmer, so making them start at one makes one less thing for a newbie to get tripped up on. Indices that start at zero are more important to have in a language that allows arbitrary pointer arithmetic. It makes more sense in that situation for a pointer to an array to point to the first element in the array. But this type of access isn't really allowed in python,java,ect, and there wouldn't be that much of a difference if the indices started at 1 instead of 0.

>>13
http://stackoverflow.com/questions/356160/which-game-scripting-language-is-better-to-use-lua-or-python

>>14
The only benefit indices starting at one have is to keep beginners from having to differentiate between ``first element'' and ``element one''. Most programmers learn to work with indices starting at zero in a matter of days, at most.
Also, starting with zero, it makes it easier to program. Just consider a for loop, wouldn't using something like for (i=1; i<=length; i++) to iterate over all of it look a bit strange? Or using i<=length to check if i is not out of bounds?
There's also the compatibility with more or less all the other languages. Is a tiny benefit for the absolute beginners worth it?

>>15
that link is from 3 years ago

>>17
Use your scroll wheel, please.

>>16

It is just a different way of doing things. Lua was originally meant to be used as a flexible form of data entry by people who didn't necessarily know how to program, so they tried to reduce the learning curve as much as possible. The beginning lua programmer will be in for a surprise when he/she moves on to a popular language that uses 0<=i<length indexing. But you could say the same about any unique characteristic of any language. A cprogrammer will be suprised by the use of tail recursion for looping in scheme. A java programmer will be surprised by the absence of public static void createFactoringFactoryFactory(FactoringFactory factory). There are many ways to do the same thing, and part of being a knowledgable programmer is understanding that there are many different conventions and ways for doing the same sorts of things, each with their own advantages and disadvantages.

>>19
That's true enough, but it's still mostly unnecessary, since getting used to such a minor detail is far easier than switching between 0-start and 1-start indices all the time (you'll just get your algorithms mixed up if you aren't careful enough).

Also,
public static void createFactoringFactoryFactory(FactoringFactory factory)
Why void, if it's a factory?

Lisp is shit.

>>20

wups thanks you:


public static FactoringFactoryFactoryable createFactoringFactoryFactory(FactoringFactory factory)

That's true, porting back and forth between zero indecies and 1 indices is annoying and error prone, and could be completely avoided with a different design decision for the language. You could always introduce your own indexing functions:


function zset(table, index, value)
  table[index + 1] = value
end

function zget(table, index)
  return table[index + 1]
end

function zipairs(table)
  return coroutine.wrap(function()
    for i,v in ipairs(table) do
      coroutine.yield(i-1, v)
    end
  end)
end

Although that zipairs could be more efficient. I always use closures for my iterators so I can pass them around as arguments to functions.

>>22
I'm not that good with Lua, but I think I heard that the start index is the one you manually set, 1 is just the default. Or am I confusing Lua indices with something else?

the best part of python is guido

>>23

lua is really flexible in that a table functions both as an array, and as a hash table. So internally, there is an array section that is indexed by integers, and a hash table part that is indexed by arbitrary keys. I'm not sure what the defined behavior is if you where to start assigning values into into high indecies. But on my lua:


Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
a = {}
a[6] = 9
for i,v in ipairs(a) do print(i,v) end
for i,v in pairs(a) do print(i,v) end
6       9
a[1] = 34
for i,v in ipairs(a) do print(i,v) end
1       34
for i,v in pairs(a) do print(i,v) end
1       34
6       9


making assignments to the next index in the array inserts it into the array section (which gets iterated by ipairs), and the other assignments go into the hash table section. You actually could just use zero indexing, and the zero would be treated as a hash table key, and would be indexed there. The only glitch is that the zero key would not show up if you used ipairs to iterate. You could use pairs, which iterates over both the array and the hash table, but then the zero key isn't necessarily processed first. You could make your own iterator, which first returns 0, a[0], and then continues with ipairs.

>>25
Ah, I see. Interesting.
Does Lua also have a list/array in the built in types, like Python? What if I only want that and not a hash table?

>>3 is right, you others can go to hell.

>>26
If you want things to be ``like python'' use python you enormous faggot.

>>28
There's a difference between wanting Lua to be Python and wanting to use a list instead of a hashtable.

>>26

no there are no lists unfortunately. People typically implement lists using tables like structs,


a = {}
a = {item='data1', next=a}
a = {item='data2', next=a}

If you wanted more efficiency, you could use try using c extensions to create a simple list for lua, but I'm not sure how you could get your C list to register its references with lua's garbage collector. It might be possible, but I haven't looked into it yet.

>>30

nevermind, according to these people, you can't

http://stackoverflow.com/questions/3034247/lua-userdata-gc

It doesn't look like you can refer to lua objects from your c code. This seems unnecessarily limited to me though. It's not like it would be difficult to register some userdata with a custom marking function written in c, that could get called by the garbage collector to mark the userdata object's references. also my list was wrong. First line should have been a = nil

>>31
The point of lua is to be a simple, lightweight scripting language. If you want something more robust, there are options. Every scheme distribution I can think of is made to do this sort of thing. Of course, using them becomes that much more complicated, which defeats the whole point of selecting a lightweight, simple scripting language in the first place.

Enjoy.

Lua is really fun to use.

>>33
oh you never had to write for awesome window manager

(actualy it's it's awful standart library, BUT NEVERTHELESS)

>>32
Lisp is shit.

>>31
To keep a reference to a lua object use
http://www.lua.org/manual/5.1/manual.html#luaL_ref
to get an unique key for it, and insert it into a table.

When it's time to release the reference, use luaL_ref again
but this time remove from the table.

Requiring you to do it in this kind of indirect way instead of having an equivalent to Python's Py_INCREF() and ability to call custom destructors for values of types other than table and userdata is a major Lua weakness, specially when version 5.2rc1 goes live with the new continuation based API for yielding out of CFunctions.

If it ain't Lisp, it's crap.

Luajit. http://luajit.org/

Python is fucking shit.

>>36
Reference counting is a major python weakness.

>>39
What abount absence of uniform syntax, leading to inability to extend it though macros?

>>1
'>LUA

>>30
nigga are you kidding me


herp = {">>30-san", "is", "a", "fgt"}
for _, val in pairs(herp) do
    print(val)
end

>>33
one has to know that the Lua defs refuse to add a sane "class" syntax to Lua, despite the fact that Lua supports class-like statements just fine. it seriously boggles the mind

apart from that, Lua is meant to be embedded, hence why it's so small. if it were meant to be used like Python, it would be hyperbloated with at least 2340235340508345895736958739056356346 billion standard libraries (each reading XML files in different ways, because reading XML is what the cool kids to these days!).

so cram it, haterz

www.love2d.org

>>42
You could say the same thing about C structs. Make Lua++ if you are so in love with syntax.

>>42
one has to know that the Lua defs refuse to add a sane "class" syntax to Lua

class "Anus" ("Haxable")
    :init(function (self) print "hax my anus" end)
    :destroy(function (self) print(self.haxed and "haxed" or "not haxed") end)
    :method "hax" (function (self) self.haxed = true end)
    :method "shit" (function (self) collectgarbage() end)
Terrible!

Forget about Lua and PyGame.  Go with SFML 2.0 with C++.  It's very easy to use, and your binaries will work on Windows, Mac & Linux.

>>32

Adding a custom destructor for userdata is a feature, that if you didn't need, you could simply not use it. You could use a language without ever knowing about such a feature, and then things would be just as simple. It would require maybe a few additional lines of code to the garbage collector. There would be no additional run time cost, as userdata with a custom collection function could be marked with a new type tag that would get switched off of. You could implement state of the art data structures in C, and use them to store lua objects. This would be nice, for people who wanted to achieve the satisfaction of using a list that is really as fast as possible. With lua as it is, there is no way to bypass at least some kind of table access when traversing a list. This table access could be optimized though. Like if the jit or whatever could detect that you always use constant values keys to index into a table, it could just treat that as a compact structure. If you could eventually get the same performance as C, then this wouldn't be very necessary.

This would have a big disadvantage though, in that it would need to completely expose how the gc worked. If the gc implementation was to change, then all the c extensions with collector call backs would need to be rewritten. Or if different implementations of lua used different collection methods, it wouldn't work at all. There is also the issue of buggy c code doing weird stuff with lua, like incrementing a reference count too many times, or decrementing something too many times. This could be very difficult to trace.

Lua is a shitty language and I really don't understand why Mike Paul spent the time to make a great JIT for it. It should have been SchemeJIT.

>>45

dat currying. It takes creativity to come up with something like that.

here's what I do:

-- inside of anus.lua

local Haxable = require'Haxable'
local oo = require'oo'

local Anus = {}

function Anus:init()
  print "hax my anus"
end

-- I don't have destructors..    :destroy(function (self) print(self.haxed and "haxed" or "not haxed") end)

function Anus:hax()
  self.haxed = true
end

function Anus:shit()
  collectgarbage()
end

oo.class(Anus, {Haxable})

return Anus

class "Anus" ("Haxable")
    :init(function (self) print "hax my anus" end)
    :destroy(function (self) print(self.haxed and "haxed" or "not haxed") end)
    :method "hax" (function (self) self.haxed = true end)
    :method "shit" (function (self) collectgarbage() end)

>>48
Lisp is shit.

Lua with LÖVE is just as viable as Python with PyGame.

>>45
don't make me punch you

>>49
this is fucking awful and you should feel awful for writing it

>>52
punch my anus

>>52
problem?

>>39
How so? Ref counting is fast, memory gets freed right after it's not needed. And it has a backup cyclic detection GC if you are dumb enough to make cycles.

>>55
Ref counting is fast, memory gets freed right after it's not needed.
I'm a die-hard C advocate but I must say that is absurd. If you're going to have automatic memory managment for everything don't use a half-baked solution that will botch the cache up even more than a real GC. Not to mention Python is shit.

>>56
How do you explain the super speed of Vala (almost identical to C speed) and using auto_ptr for everything in C++?

>>52
fuck you faggot, I'll POOP in your shitty scheme if I want to

>>57

I think that what >>56 wanted to say is that there are some things for which you don't need automatic memory management, and it would be a waste. OTOH, if you do want automatic memory management for everything, a proper GC is better than solutions which are intended exactly for the first, more selective, case.

>>55
Ref counting is fast
memory gets freed right after it's not needed.
Why not free it when you have nothing else to do, instead of rightnowrightnowrightnow?

>>59
Let's forget about C++ for a second and simply concentrate on Vala. I'm fairly certain Vala uses ref'd gc for everything, and all objects are allocated on the heap- yet the benchmarks[1] show it's pretty much on-par with C and C++ in terms of speed.

Just skimming a few of the benchmarks shows they are using objects and writing pretty much idiomatic Vala code, so I'm not sure what the problem with ref counting actually is.

Are saying is with a real GC scheme, Vala would be even faster?

[1] http://code.google.com/p/vala-benchmarks/wiki/BenchResults

>>61
No. Maybe >>56 would say that, but I wouldn't. I believe that reference counting schemes, despite inherent problems they may have, are fairly good, simple schemes.

The typical problem involving refcounting is related to circular references between objects. I'm not sure whether this occur with C++-based shared pointers, though, because of the presence of destructors.

>>62
You know what's simple? Using a garbage-collected language. If you're going to roll your own shit you have already given up simple.