Talk:Physics Jam

Meeting Wed Aug 13, 1700 EST

• potential physics themes for games
• volunteers needed : supplies coordination, press contact, art / music coordination, postering, t-shirt / swag production
• student testing at the end of the Jam
• how the Physics Jam might tie into other jams (including the CEIBAL Jam happening at the same time in Uruguay, and Game Jam Peru coming up in mid-October)
• coordinating games@ with the new activities@ mailing list, and with independent groups focusing on activity review

  ( see for instance http://olpcgames.org/ | http://www.spitting-image.com/OLPC/ )

Online participation?

I hear (murmerings at OLPC HQ) that it will be possible to join in online. But this page needs to make that clear, and point out the channels for doing so. If that's clear, then I'll mention it by blog. --Chriswaterguy 06:45, 16 August 2008 (UTC)

Hi Chris, done and done! We will use Justin.tv for video broadcasting (which I have tested on my computer and seen used at GrassCon with great success) and IRC for collaboration.

Any other collaboration technologies we should consider? A gobby server might be nice for notes and collaborative programming/documentation during the conference, and ditto with a skype conference. What are your thoughts?

--Bjordan 04:08, 28 August 2008 (UTC)

thoughts on toolkits and future physics jams

So the Cowsome Loneboys, with a relative derth of both Python and Box2D experience, had a rough time, bouncing from using Physics Activity as a base, to X2O, back to Physics. SJ encouraged me to write up my our experience, along with suggestions for the toolkits (in short, I think Elements is the most promising, but more work remains)

Here is what I wrote:

Friday night, the box2d intro was pretty inspiring and useful in terms of getting the lay of the land along with a few details. The odd thing was being told about the different engine wrappers, but no ida what the criteria for choosing between them should be. And that turned out to be a big problem the next day.

A disclaimer: some of these critiques may not be "valid", in that they reflect my ignorance and/or lack of study prep/laziness rather than actual current limitations of the wrappers. Which brings up the idea

• The optimal situation for another physics jam, or another, would have one of the wrappers tweaked up and documented w/ a selection of simple examples, and then links to that in the announcement wiki pages.

Another disclaimer: I'm not particularly clever at learning new systems. My mind is better at thing tangentially and tends to lack a good memory for picking up details quickly. Also both Jon and I were Python novices... not n00bs, but novices.

Saturday morning, we started with Elements from a Physics base. I started trying to draw platforms and "seed" the level with boxes. By the time the first frustration sent in, I did get that far, but in retrospect (actually something I noticed right when we switched to X2O) I realized "LOL IM DOING IT WRONG"... I was hacking on elements.py to add in a "ground" class, for example...

• users of elements should probably be encouraged to not hack elements files unless they know what they're doing... like if they're making new "objects" that wrap the built in elements rect, circle, etc, they should be encourged to just make their own myelements.py, rather than put it in elements.py itself, and/or put it in the base activity .py

(Come to think of it I don't know how well things are documented on the wiki, but I know our team really coasted on the vets for bundling the app and lots of general OLPC/Sugar knowledge...)

One problem with my first attempt was Elements used a different scale system internally, and while later I could find some things that used pixels, other things used this odd scaled and negatively inverted on the y axis system. Later I thought I saw the logic of the inversion, but still... Jon had to do a lot of mathery to get the "how tall is your tower?" red line.

• everything elements exposes should be potentially doable in pixels, and/or a conversion from Meters to Pixels, clarity on which to use (I know Meters are preferred in many ways, but there are so many times you just want to draw to the screen rather than put in objects into the world... maybe a good conversion could handle that)

• maybe something could wrap basic pygames drawing functions for text and graphics, for when you want to draw things outside the "physical world" of elements. And sound. (Some of this might have been done)

Random thoguht, we really weren't able to employ artists, and/or level designers even. Well our game wasn't about multiple levels, but also we didn't know how to blit graphics to the screen, and especially we didn't know how to wrap a Elements object w/ a rotatable graphic...

• elements w/ the option to slap a graphic onto a circle and/or rect would be WAY COOL

The big thing, though, was I started to panic about the "mode" system I hoped to have for the game (building mode, destruction mode, winning screen, etc) Physics is just a wrapper to a running Elements world, w/ all the state delegated to the control buttons... this isn't a good model for games, and when we returned to Elements, our simplified model made it clear we could just rip out most of the buttons (we hacked on tools.py , keepign in most of the button definitions for reference, but having the AllTools or whatever function only return the one we wanted (grab) plus our own new reset button)

• a good example of how to to do modes/stages/game logic would be helpful

Saturday afternoon: So at this point we switch to X2O as a base... in retrospect probably a mistake, On the one hand, I liked its game loop better, it seems like its design mode / run mode was much more akin to what I had in mind for KingSling than Elements sandbox model, but in general I didn't find the "ok here's how we add a rect" as easily as i had w/ Physics, and in general it was full of elements like fans etc not really relevant to my game, and I would have had to remove

Also there was that file save format...

• the X2O file format would be better if it was more human readable.. this shouldn't be hard... i'd suggest tab delimited or csv rather than XML, tho that's just my bias ... and/or maybe I'm talking abotu a format Elements should have

So Saturday night we switched back to Physics as a base. But our approach was a lot clearer, our changes were limited to the central .py file and tools.py, we figured out how to keep track of objects and destroy them

• tell people not to try and destroy objects twice :-)

• the mouse joint tool is awesome and should be even more easily wrappable...

Sunday morning/afternoon... Babel is coming together. But our logic for height of the tower was a bit sketchy (our app doesn't ignore a brick being held... we had the idea of forcing a "let go" and waiting 5 seconds before calculating the tower height, but didn't have a chance to implement) sadder was our attempt to Know if the tower was clear of bricks... we got some fairly straight forward code for doing a contactlistner but ANY ATTEMPTS TO ACCESS THE "SHAPE" OF AN ELEMENTS BODY, EVEN JUST FOR PRINTING, LED TO BIG SWIG ERRORS. That was brutally discouraging at that point!

• In general more should more clearly exposed from Elements elements -- in particular a good, high performance, clear mechanism for knowing what objects are in contact, or how many are in contact, would bring to life MANY game options ... including sound events, which would be useful for letting other people chip in to a development jam effort.

Sunday evening, Jon and I went back to add in a sling shot. At that point we knew how to get done what we wanted to, avoiding the pitfalls... there may have been a few things I couldn't do easily, because I didn't know if I could reliably get pixel coordinates for balls etc, so I couldn't do an idea for making the elastic look snappier, etc, but over all it wasn't too bad

So that's it... unfortunately I don't have the cycles to volunteer for helping w/ actually updating elements (which, if it's not clear, I DO think is a much more promising base than X2O) but this is a fairly complete list of what I think would make it better for future activities...

Sorry, one last thought... Like I said, I think Physics activity is probably the best base right now. In particular, we were able to roughly prototype some of our gameplay ideas by drawing in some shapes and tossing them around... that's how I knew the mousejoint to build tool felt good, and had some idea about the plausibility of the slingshot mechanic...

Internally, Physics seems to delegate a lot of functionality inside tools.py, the toolbar code (calling each tools event handler, really) -- this makes a fair amount of sense for a sandbox like game, but was one of the things that scared me off it when trying to install a gameplay mode on top of it...

• a "building base" Physics activity should probably decouple the button handling toolbar code from the sandbox event handling...

I tend to be too much of a "put everything in one file" guy for small applications, but still if I saw how each mode was handled, I would have been less scared to stop ripping out modes that weren't a part of our game and adding in new modes that were.

I don't know if this suggestion goes against any "best practices" for Sugar apps, and know there's a lot i don't understand about that toolbar in general, but still...

...one last last thought, I kind of forgot about the complexities where the view point was either scaled or shifted , you might not have the same pixel mapping... but most of what I said is still valid I think

Kirkjerk

This was great, btw, I found this useful again just recently. Thanks Kirk :) --Sj talk