• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

Andrew Nguyen

Python, Can it work?

14 posts in this topic

Hello... Can anyone tell me your opinion on Python? To get you UNBIASED!!! Go to these sites. www.python.org Vpython pygame Post you complaints and I'll tell Guido, the creator of Python... His Electronic Mail Destination Yes, it's true, there should be a Java-Python-C++ language called Japyc or (Jah-PIC) Edited by - Andrew Nguyen on December 21, 2001 9:30:20 PM Edited by - Andrew Nguyen on December 21, 2001 9:31:52 PM
0

Share this post


Link to post
Share on other sites


Here is some code to get you running...

from visual import *
# ruth chabay, carnegie mellon university, 2000-06
# rings may be dragged through stuff - a little surreal

scene.y=0
scene.width=800
scene.title="Tower of Hanoi"
print "Move the stack with mouse buttons up to the white pole."

maxradius=2.5
thick=.5
spacing=maxradius+thick
leftpole=cylinder(pos=(-2*spacing,-3,0), radius=0.3, axis=(0,6,0))
leftpole.color=(.5,.5,.5)
midpole=cylinder(pos=(0,-3,0), radius=0.3, axis=(0,6,0))
midpole.color=(.5,.5,.5)
rightpole=cylinder(pos=(2*spacing,-3,0), radius=0.3, axis=(0,6,0))
floor=box(pos=(0,-3.5,0), axis=(0,.99,0), height=23, width=5,
color=(.6,.4,0))

poles=[leftpole,midpole,rightpole]
rings=[]
hues=[(1,0,0), (1,1,0), (0,1,0), (.3,.3,1), (1,0,1)]

for y in arange(-2, 3,1):
rings.append(ring(pos=(poles[0].x,y,0), radius=.5*(3-y), color=hues[y+2],
thickness=thick,axis=(0,1,0)))

stack=[rings[:],[],[]] # list of rings on each pole
select=None
scene.autoscale=0
moves=0

while 1:
m=scene.mouse.getclick() # identify pole clicked on
mx=m.project(normal=(0,0,1)).x
pole=int((mx+floor.height/2.)/(floor.height/3.))
if select==None: # pick up a ring
if len(stack[pole])>0:
select=stack[pole][-1] # remove ring from stack
del(stack[pole][-1])
while not scene.mouse.clicked: # drag ring
select.pos=scene.mouse.project(normal=(0,0,1))
rate(60)
else: # put down a ring
if len(stack[pole])>0: # stack not empty
if stack[pole][-1].radius > select.radius: # legal move
select.x=poles[pole].x
select.y=-2+len(stack[pole])
stack[pole].append(select)
select=None
moves=moves+1
else: # illegal move
print "A ring may not be placed on a smaller ring."
while not scene.mouse.clicked: # keep dragging ring
select.pos=scene.mouse.project(normal=(0,0,1))
rate(60)
else: # stack empty
select.x=poles[pole].x
select.y=-2
stack[pole].append(select)
select=None
moves=moves+1
if len(stack[2])==5: # task completed?
print "You won in ",moves," moves."
flash=0
while flash < 6:
rightpole.color=(1,0,0)
rate(10)
rightpole.color=(1,1,1)
rate(10)
flash=flash+1
break



Well... I didn't write that code, it's really fun though...





Yes, it's true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)

Edited by - Andrew Nguyen on December 21, 2001 9:31:11 PM
0

Share this post


Link to post
Share on other sites
My opinion of Python.

It''s an awesome language for a beginner.
1) It''s easy to understand compared to other languages.
2) It forces you to indent and make your code look nice.
3) It has wide support.

Once you get higher up though, Python begins to get limited by its speed.
0

Share this post


Link to post
Share on other sites
... That''ll speed it up REAL GOOD!!! Also, 3d is prttty fast comparativly to other thing...

Yes, it''s true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)
0

Share this post


Link to post
Share on other sites
Well here is my opinion then:

pros:
1) it is very elegant and nicely designed,
2) it is easy and powerful,
3) it''s quite fast for a scripting language,
4) it still exposes a lot of system functionnality,
5) it has very good exception handling,
6) the virtual machine is stable.

cons:
1) it''s HELL to embed in C++ (see below),
2) portability isn''t guaranteed (some different functions names and scripts names on Mac, see below),
3) it''s still not as fast as, say, Perl (but easier to read)


Embedding (C++):

Not only is exporting classes to Python hard and almost totally undocumented (like 99% of the embeddabled languages, btw), it''s also impossible to link to the Python library without using some ''tricks'' because 1) you can''t assume a libpython.so (on *nix) ''cause the name changes with the version (libpythonxxx.so) 2) it is a static library on *nix, shared on windows (no idea about mac). I had to add ugly m4 macros to get autoconf to find the lib on all platforms. Using ''freeze'' to make it a binary would be an option, but it would mean distributing one different binary file per system (meaning you need to find one of the said platforms to compile on, or use some kind of crosscompiler). This hell of embedding made me go for Guile whenever it comes to embedding a language (Lisp rules when it comes to AI anyway). Sadly, Guile is hardly portable at all... Go figure..

Portability :

Still related to embedding: the Python interpreter is started with Py_Initialize(), but on Mac with PyMac_Initialize(). Why a different name? Ok, it''s nothing that can''t be easily worked around when you have a preprocessor, but I still find it weird. Also, why is ''freeze'' named ''macfreeze'' on Mac?

Speed :

I still find it (sometimes much) slower than Perl for about everything. Maybe is it me not writting the ''best'' Python code, but given the nature of the language, I think writting good Python code is pretty straightforward. Compiling it into a binary file will result on a *large* file on *nix (because of the static library), and you''ll have to pray that your executable finds the python lib on windows (it''s a dll on windows). If shipping your own python dll on windows, you still have to make sure than it will load yours. I''d rather keep the Python code viewable and open.

Finally, I totally dislike the Python way to handle regexps, but that''s probably because of my Perl background (so it''s biased).

--

I haven''t tried PyGame. All I know is that it runs on top of SDL. I won''t use it mainly because I like to do the lower level stuff better than the higher level (writting libs/API/engines is what I like the best).

So please, don''t get me wrong, I love Python, I use it everyday, but, IMHO, it still has to mature a bit to be truly usable for games as the main development language (it''s already embedded in a lot of products, like Truespace, Blender, CrystalSpace, etc). And it still can''t replace Perl in my heart .

Anyway, that''s my (unbiased) 0.02$.
0

Share this post


Link to post
Share on other sites
Yes, But, Python would be much faster if there were more people working on it... Heck, if it ever becomes faster than C++ then C++ would have to worked on... which do you choose...



Yes, it''s true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)
0

Share this post


Link to post
Share on other sites
quote:
Heck, if it ever becomes faster than C++ then C++ would have to worked on... which do you choose...


An interpreted language will never surpass the speed of compiled code since it has to be parsed at runtime.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
1) you can''t assume a libpython.so (on *nix) ''cause the name changes with the version (libpythonxxx.so)

You should always have symbolic links to your library files, so that you can link without ambiguity (this also allows you to maintain multiple versions on the same machine). Mesa, for example, would follow this pattern:
libGL.so->libGL.2.so->libGL.2.2.so->libGL.2.2.15.so 


quote:
2) it is a static library on *nix, shared on windows (no idea about mac).

I''m sure it''s possible to build shared objects under *nix. Currently I don''t run any of the *nixes, but I''ll be setting up a new workflow solution early next year and plan to investigate Python under Linux. You could email me so I''d have your address, and I''ll let you know how I fare (I''m the moderator of the Everything Unix forum).

quote:
Still related to embedding: the Python interpreter is started with Py_Initialize(), but on Mac with PyMac_Initialize(). Why a different name? Ok, it''s nothing that can''t be easily worked around when you have a preprocessor, but I still find it weird. Also, why is ''freeze'' named ''macfreeze'' on Mac?

*sigh* Mac... I agree with you there.

In regards to your other comments comparing Python with Perl, I agree as well. I have a definite preference for Perl (much more robust, doesn''t force any stylistic conventions on you, and embeds nicely in C/C++; plus, Perl is a valuable sysadmin tool - not so Python).

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
0

Share this post


Link to post
Share on other sites
One thing I hate is language advocacy. Anyway....

I doubt any interpreted language will ever be faster than C or C++. Python runs on top of the C library. The only way would be to massively optimize 1) the virtual machine 2) the C library 3) the compiler and to only distribute statically linked binaries (and kiss goodbye to portability). The faster the computers get, the less noticeable the difference will be, until it probably doesn''t matter anymore.

To answer your question, if Python ever became faster than C++, I''d use Python for time critical code. I''d still use C++ for the rest because it exposes more functionalities.

I know I probably sound like an anti-Python guy, but the truth is that a lot of ''new'' languages promised wonders and provided nothing at all, so I tend to have a very critical view on these (but I give them a long try before judging). And again, I use Python just about everyday. Its pros easily overcome its cons.

A last thing: I''ve noticed after chatting with some people that they don''t want to use high level languages (as in ''interpreted'') because then they won''t look as ''leet''. Stupid, I know, but sadly a lot of people neglect these languages because of that.

my (long again) 0.02$
0

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
You should always have symbolic links to your library files, so that you can link without ambiguity (this also allows you to maintain multiple versions on the same machine). Mesa, for example, would follow this pattern:
libGL.so->libGL.2.so->libGL.2.2.so->libGL.2.2.15.so  




Sadly, the Python directory also differs with the version (eg /usr/lib/python2.2). Creating a symlink in /usr/lib might work, but it wouldn''t be safe to assume than a given user on another platform will have that link, since Python doesn''t set it up.

quote:

I''m sure it''s possible to build shared objects under *nix. Currently I don''t run any of the *nixes, but I''ll be setting up a new workflow solution early next year and plan to investigate Python under Linux. You could <a mailto:seyisonaiya@hotmail.com>email me</a> so I''d have your address, and I''ll let you know how I fare (I''m the moderator of the Everything Unix forum).



Yes, it is possible but raises new problems: most people will just build it with a static library. While not a problem when running interpreted code, it once again becomes annoying when embedding (yes, my main complain is about embedding ).

Thx for the offer but, IIRC, building Python with shared lib support is just a matter of building it with -fpic and enabling ''shared'' in the setup file.

quote:


(...snipped...)
In regards to your other comments comparing Python with Perl, I agree as well. I have a definite preference for Perl (much more robust, doesn''t force any stylistic conventions on you, and embeds nicely in C/C++; plus, Perl is a valuable sysadmin tool - not so Python).



I personally find Python great for prototyping applications but wouldn''t use it for administrative tasks either.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Sadly, the Python directory also differs with the version (eg /usr/lib/python2.2). Creating a symlink in /usr/lib might work, but it wouldn''t be safe to assume than a given user on another platform will have that link, since Python doesn''t set it up.

In regards to this and the fact that most people build static libraries, perhaps you should advocate on the Python mailing lists that the standard makefiles be modified to set up the symbolic link and build a dynamic library? I assume the reason only the static version is being built cirrently is because most people use Python purely as a stand-alone scripting language. As more and more people embed it and advocate its use as an embedded solution, this step (modifying the makefiles) will become a necessity.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
0

Share this post


Link to post
Share on other sites
You know, I use python for games... sssslllllllooooooowwwwww games... Oh well...

Yes, it''s true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)
0

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Well here is my opinion then:

pros:
1) it is very elegant and nicely designed,
2) it is easy and powerful,
3) it''s quite fast for a scripting language,
4) it still exposes a lot of system functionnality,
5) it has very good exception handling,
6) the virtual machine is stable.

cons:
1) it''s HELL to embed in C++ (see below),
2) portability isn''t guaranteed (some different functions names and scripts names on Mac, see below),
3) it''s still not as fast as, say, Perl (but easier to read)


Embedding (C++):

Not only is exporting classes to Python hard and almost totally undocumented (like 99% of the embeddabled languages, btw), it''s also impossible to link to the Python library without using some ''tricks'' because 1) you can''t assume a libpython.so (on *nix) ''cause the name changes with the version (libpythonxxx.so) 2) it is a static library on *nix, shared on windows (no idea about mac). I had to add ugly m4 macros to get autoconf to find the lib on all platforms. Using ''freeze'' to make it a binary would be an option, but it would mean distributing one different binary file per system (meaning you need to find one of the said platforms to compile on, or use some kind of crosscompiler). This hell of embedding made me go for Guile whenever it comes to embedding a language (Lisp rules when it comes to AI anyway). Sadly, Guile is hardly portable at all... Go figure..




Most version of Unix and Linux hae these libs have links to the correct verison so you don''t need to worry about it and you can just call libpython.so

I''ve tried it on these Linux Distro: SuSE, Mandrake, Slackware
and on Sun''s Solaris 8.0

it worked without any problems...



"And that''s the bottom line cause I said so!"

** I WANT TO BE THE MODERATOR FOR THE LINUX FORUM **

Cyberdrek

Resist Windows XP''s Invasive Production Activation Technology!

"gitty up" -- Kramer
/(bb|[^b]{2})/ that is the Question -- ThinkGeek.com
Hash Bang Slash bin Slash Bash -- #!/bin/bash
0

Share this post


Link to post
Share on other sites