ADMIN: on late library releases

richard on 2007/03/09 22:04 of Fluffy Menace

OK, I guess I have to put my foot down here. The challenge rules state:

If you do have a library you must release it within a reasonable amount of time before the challenge starts so that others may have the opportunity of using the library

I've previously stated to people who've asked that in my books 1 month is the minimum "reasonable amount of time".

This amount of time is now to be included in the rules to make it absolutely clear. PyWeek is entirely predictable - it runs every 6 months, and is generally announced about 3 months out. That should be plenty of time for library devs to hawk their wares.

(log in to comment)

Comments

steveth45 on 2007/03/20 21:00:

Just so it doesn't cause anyone stress later, I'm going to make a Python binding for Irrlicht and use that in the competition. Since I didn't have the foresight to make it well in advance, I'll make if from scratch _during_ the week of the competition. From my reading of the rules, that's acceptable behavior. Don't worry, I'll release Linux and Windows binaries as well as source code and project files. I'll be using Boost::Python to make the binding. All the game play logic will take place in the Python code. I just found Panda3D to be bloated, and PyOgre not well supported in Linux. PyOpenGL/PyGame don't have enough functionality to easily make a 3D game.

ripter on 2007/03/20 21:46:

Sweet! I can't get PyOgre to run on my Mac and Panda3D doesn't seam to be active outside of the classroom.
Just out of curiosity (I don't know much about either) Is there a reason to use Boost::Python over py++? (maybe their completely different?)

richard on 2007/03/20 23:14:

steveth45: geez, that's a fair bit of work. Good luck!

steveth45 on 2007/03/21 21:48:

Just so you don't think I'm insane, I'm not doing a full wrap of all Irrlicht classes and functions. I'm going to create a simple C++ class that hold some pointers, like the Irrlicht device, and does the interaction with the engine through a bunch of functions that will be wrapped with Boost::Python. An example would be adding world objects, creating the Irrlicht device, moving the camera around, moving objects around, and getting input data. So in Python, I'll just have access to the functionality of my class, which I can add to as necessary for this competition. That way, with the wrapper code, I don't have to mess around with trying to wrap virtual classes and all that craziness. All the game play code will exist on the Python side, with the wrapper class existing for quick and easy Python binding to core Irrlicht functionality.