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... ?

I have shading on non textured objects (the green box in the screen shot)

But once I texture it, the shading goes away... Im obviously missing some magical opengl command. :-/ *sigh*

(also note that the first object not being textured is another bug, but it just happens to help illustrate the problem :)

I did find a refernce to GL_LIGHT_MDOEL_COLOR_CONTROL, but that doesnt seem to be in my pyopengl library... hmm.

mutter mutter...

The first day went ok with my getting opengl rendering going quite easily.

The next two days were a loss with blending and alpha channels defeating me. *sigh* (Notice the lack of 'game logic' mentioned so far?)

Yesterday was mostly taken with convincing my ISP that our Australian telecom monopoly phone company broke my ADSL link. I had to eliminate everything at my end (including dragging the fileserver into the kitchen to plug directly into the main phone input) before they could even get them to look at it.

Today I made quite good progress. I stopped working on the opengl stuff and went back to a text interface for developing the game logic. Well now I have map loading, path finding and all sorts of goodies.

Its seen here determining what you can see from the room 'K'. It does other stuff too, like path finding along the room paths. Im not sure that it will be fast enough, but hey it works.

I did spend a chunk of time trying to work out why my paths were mostly too lon, only to realise that I was storing the PATH_SO_FAR list but then appending to it later. I should have been saving PATH_SO_FAR[:]. I cant believe I did that. Oh well.

Atlast I have some graphics. (no thanks to glBlendColorEXT :)

Now to put some units in my game... (well its not a game yet ;)

Lets make an FPS counter. Ill just make a draw method that actually draws the texture, rather than makes a display list. Easy, right?

Ok, code that up. Put it in my scene graph.. excellent. Seems ok.

So, lets put it on the HUD..

All my fonts turn into opaque squares. Huh? Weird.

Um. Well I did some changes to allow render time displaying (rather than making a scenegraph model), maybe I didnt turn something on. Nope. That code all looks fine. Um....

So, _Lots_ of code checking later... I finally discover that the glGenTextures call is returning a texture_id for the font of 24837324 (or something huge). Hmmm. Ok, thats before Ive loaded the font image... Um.

My _other_ textures still work fine (and have numbers like 1, 2, 3, 4).

Ok, so what if I call glGenTextures ore than once... 24837324, 0, 0. Hmmm.

3 Hours later... It seems that I initialised my textpage class _BEFORE_ calling mygame init, so opengl cant render a texture.

Augh!

I think thats my problem. Its not that I consentrate on graphics too much, its that I cant let bugs go without working out _why_ they dont work. And it just so happens that my newbieness to opengl translates into lots of bugs. :)