So, I'm still playing with python. Not sure I'm going to write an entire roguelike in it, but figured I'd hack out to the step 4 (walking around a room) on the 15 steps to a roguelike.
I noticed the number of files/lines of code seemed to be much smaller than I remembered, so I pulled up the equivalent submission in magecrawl.
The python copy looks like this:
While the magecrawl looked similar to this (this was from a few weeks later, similar idea though)
Here is the comparision (excluding test code). This isn't comparing to the map generator picture above, just the walking around an empty room.
Python - 3 source files, 127 lines of code.
C# - 13 source files, 503 lines of code.
Much of that difference comes from the verbosity of C#. Some of it comes from the use of interfaces in C# compared to duck typing in python. The rest comes from an effort to implement the minimum needed and keep things simplier.
As a side note, pygame is pretty awesome. I might pull in libtcod for line of sight and pathfinding, but since I want "tiles" graphics, pygame made that crazy easy.
I noticed the number of files/lines of code seemed to be much smaller than I remembered, so I pulled up the equivalent submission in magecrawl.
The python copy looks like this:
While the magecrawl looked similar to this (this was from a few weeks later, similar idea though)
Here is the comparision (excluding test code). This isn't comparing to the map generator picture above, just the walking around an empty room.
Python - 3 source files, 127 lines of code.
C# - 13 source files, 503 lines of code.
Much of that difference comes from the verbosity of C#. Some of it comes from the use of interfaces in C# compared to duck typing in python. The rest comes from an effort to implement the minimum needed and keep things simplier.
As a side note, pygame is pretty awesome. I might pull in libtcod for line of sight and pathfinding, but since I want "tiles" graphics, pygame made that crazy easy.
4 comments:
Pygame does make things easy from the graphics side, and python in general is very fun & easy to code in. And I hate to be "that guy" who says python is slow, but as a developer of at least 2 partially-finished python roguelikes, I run into a "speed wall" at some point in the development.
I think for 80% of things python is fine, it is when you start doing fancy algorithms like djisktra maps and A* and FOV casting and all that.. seems to slow things down quite a bit.
If you look at almost every "python" RL, it is using libtcod, with which only the wrapper is python. The algorithms are not.
That being said, I still have a lot of profiling to do and the problem could even lie in pygame.
Will be interested to see if you have similar experience or if it's just me.
Heroic, your comment is doubly interesting to me, since in my head I've been planing a "pseudo-realtime" game, more active than the normal turn based roguelike. If python is too slow for a turn based roguelike, I'll run into it double time.
Well, I'm perfectly willing to admit that it is just my poor programming skills (algorithms class was a long time ago).
However, I am mostly using "industry standard" (e.g. roguebasin, r.g.r.dev, wikipedia) algorithms. And yeah, when I had lots of monsters on screen or overly wide dungeons (lots of light/fov casting) I saw a NOTICABLE lag in the game.
Psyco got rid of most of that but just knowing it was there still bothered me. Also psyco is not an option for all python distributions/machines. (Don't even ask me about my friend who tried my game out on his mac)
Shoot me an e-mail sometime if you run into anything similar, I am curious to know if it is just me whining or not. :)
Psyco does not support python 2.7 and above apparently, and thus won't be an option for me.
Post a Comment