A rules question.....

korg on 2006/03/19 05:06 of korg

Hi everyone!

I have a beginning idea for a game (theme vote permitting) but I want check if its 'legal'.

Im going to write my game logic in python (well, duh, obviously) but I want to write my user interface (graphics, input etc) in plib (http://plib.sourceforge.net/) which is a c++ graphics library.

Part 1 is that there _ISN'T_ a python interface for plib. Now from reading the rules, making one in the contest would be ok. (Under the bit that says: "doesn't preclude the use of supporting languages (eg. C or C++ libraries")

(Writing some C++... yes, I am insane, thanks for asking. :-)

My problem is that if Im going to write code to do some of the UI, Id much rather write:

all the game stuff (mapping, unit control, game logic, what to display etc) in python 'game code'
all graphics, key/mouse input, user interface and actual display (maybe even collision detection) in C++ plib 'client/UI code'

The idea is that the python engine could just do "begin burst_steam_pipe animation at x,y" and the C++ engine would draw and animate it and python could keep on with the game logic leaving C++ doing 'grunt' work.

The thing is that that would be more than just a 'simple' interface to the library, rather it would handle more complex stuff like animation and things like that which is why I'm posting here.

The key points seem to me to be:

The source would have to be released with the game (duh).
It wouldnt have any 'game logic' in it (plib is _just_ a graphics layer, UI, scene graphs and collision detection and other stuff)
Does 'collision detection' count as game logic? It seems to me that game logic is what you do with the collision once you detect it (and that part has to be in python, naturally).
Richard mentioned that using other languages for optimization (which this kind of fits) but its hardly mentioned in the rules.
The rules say: "This is a Python programming challenge, but that doesn't preclude the use of supporting languages".. well ok...
... but the other hand, the line continues "eg. C or C++ libraries" which seems to point away from writing much non python code yourself.

It _feels_ ok to me (as the C++ code is for 'grunt' work only, graphics, collision crunching, all which seems to fall under 'optimization' and not game logic) but I thought Id ask....

Maybe we should insert into the rules (at point 2) something about languages and not roll it into "Entries are to be written 'from scratch'" section?

Opinions... ?

(log in to comment)

Comments

TenjouUtena on 2006/03/19 08:03:

Apart from being against the basic spirit of the competition. (i.e. look what you can do in python) You're basically opening a slippery slope that ends up with you could have one call in python that runs the rest of it in C++. Now, if you were to build a library for everyone to use before the competition and provide it to everyone to use equally, then I think it would be a different story.

dbickett on 2006/03/19 08:08:

I don't know how everyone else would react, but I'm of the opinion that this is pushing the limits.

This is a Python programming challenge, but that doesn't preclude the use of supporting languages (eg. C or C++ libraries, Javascript in HTML web pages, and so on).

I think it's possible that "libraries" there might refer to existing, known codebases. I also think it's a mistake to downplay graphics and collision detection -- these are important sections of code. Furthermore, if you write (for example) collision detection in C++, that is not optimization (of the game or the concept); That is actual code.

Optimization is supplementary by definition: "The procedure or procedures used to make a system or design as effective or functional as possible...". In other words, if you wrote a given feature in C++, you would be improving the game in the sense that you have employed the speed of C++ where Python might be slower. You would not be optimizing an existing Python feature. (I can't even find the section in the rules where it mentions optimization, to be perfectly honest.)

I don't mean to seem contentious, but I'm surprised by how many people have been challenging the Python limitation. It's understandable that Richard should supply the elbow room -- being too strict could prevent any number of things (i.e., use of C/++ bindings). But I think we should try our best to honor the title of this competition rather than use the wording, or lack thereof, of the rules to broaden the scope.

After all, everyone agrees that one is more creative when limited. Consider Python's speed one of them.

dbickett on 2006/03/19 08:11:

Silly me. In my previous post, ignore the first sentence, following quote, and second sentence. :) I took so long to write that I actually forgot one of the points made in the post ;)

korg on 2006/03/19 09:31:

Yeah, all valid points.

I had been working my way through the library list and some libraries (like panda3d) do all of this stuff already (opengl in c++, scene graphs, collision detection, audio etc) and others are just wrappers around pyopengl.

Performance wise, a panda scene graph rendered in c++ is going be a tad quicker than a pythonic pyopengl, and that made me less sure about performance being an issue.

Im just unsure where people are drawing the line, but judging by the posts so far the line is 'existing python libraries only'.

*shrugs*

I mean panda does all that I want, but I was just a little off put by the 40M download. :)

DocTiger on 2006/03/20 01:29:

Doing things in a C++ Extension that Python can do as well (especially gui things) would in my opinion void the "python" part of PyWeek.

For me, part of the challenge is actually respecting the limits Python imposes on you.

If you want to have an eyecandy particle system that is not crucial to gameplay... well I wouldn't object but it wouldn't make me give you a higher vote either!

BTW, you can use quite elaborate 3D graphics in python-only. I once had a game with a very nice blender-modeled space ship with subsurfaces (e.g. a lot of polys...) the trick is simply to put the polys into a calllist....

ataraxia on 2006/03/20 10:49:

Let's not rule out writing extensions in other languages altogether. There are a good many "Python" modules that are actually written in other languages.

If a contestant chooses to burn time on writing modules in other languages but making them accessible to Python, then why not? After all, part of the goal of PyWeek is to make available more tools to Python game programmers.

Personally, I would rank Python>Pyrex>C, and it's faster to write in pure Python anyway, but if you get partway through writing a game and find that you really need some functionality that isn't readily available via Python, then by all means, extend the language.

Just remember to write your code so it's re-usable.

shang on 2006/03/20 11:38:

Of course C/C++ extensions aren't completely ruled out. It's just that they should be available well before the competition (and with documentation). The question was about writing a new extension during the competition, and as others have said, that would be a bit against the spirit of what PyWeek is about.