Game Development using Processing.js Workshop @ FSOSS2010 September 24, 2010Posted by Andor Saga in FSOSS, Game Development, Games, Open Source, Processing.js, webgl.
Update: The Wiki page which has links to the demos, examples and games can be found here.
Last year at FSOSS, Al MacDonald gave a presentation on Processing.js. He talked about its potential, the community, and he demonstrated how to develop a neat Twitter widget. Don’t get me wrong, Processing.js was still impressive even then, but it had a while to go in terms of language parsing, 3D (using WebGL) and bugs.
During that time there was a group of students (including me) who had recently started to contribute to the project—to fix those bugs and add those features. Since then we have resolved hundreds of issues making Processing.js closer and closer to the Processing language. We had a lot of help as well. Developers joined the IRC channel we created or forked our repository and began contributing too.
Sometime between last FSOSS and this coming one, my supervisors (Dave Humphrey and Cathy Leung) and I spread the word about the project at conferences like WWW2010 and OCE2010. It was great telling everyone about the language—especially the story of Seneca’s involvement—but there was something we hadn’t quite tapped into…So we kicked around the idea of having a Processing.js workshop.
This is what we needed.
It seemed Processing.js had matured over the few months since we started contributing to it. Having a hands-on, guided class at FSOSS would really demonstrate to the open source community the power of this library. It would be informative, interactive and fun.
There was also talk about having a Game Jam, so I wrote up a proposal which leaned towards game development and titled it “Game Development using Processing.js“. But the material learned during the workshop can just as easily apply to data-visualization or other interactive graphics.
I’m excited about conducting the workshop and I already began jotting down notes and ideas which could be covered. There’s about a month until the workshop…But I also have quite a bit of work ahead of me. So for the next few weeks I’ll be putting together source code, simple demos, links, games and wikis. If you have any suggestions or comments, feel free to comment!
Hope to see you there!
add a comment
We’re expecting the library to continue to grow in size and features. The problem is not all these features will be desired by developers using the library. If a user only wants to render a teapot with C3DL, why force them to load the library in its entirety, with a particle system, a bunch of shaders and collision detection? Cathy has suggested we could tackle this problem by modularizing the library. This would impact the internals of the library quite a bit, but it would also provide much more flexibility.
Firstly, it would allow developers to build the library—a bit like jQuery. The user would select what components they need and the library would be built containing only those selected options.
Secondly, it would allow other developers to create their own components and hook them into C3DL. This means developers could write their own model parsing code instead of being forced to use ours.
Another related change would entail offering release and debug versions. The debug version could include parameter checking at the start of each function, which would be omitted from the release build.
I’m not going to kid myself. There’s a significant amount of work required to make this happen—there’s also an immense payoff. So I’m excited to start working on this, but I know I’ll need some help. I’d love to hear from any developer who has had experience implementing something along these lines.
During the Summer I had the opportunity to work with some highly motivated and intelligent developers at Seneca’s Centre for Development of Open Technology. For four months we cranked out code for several exciting technologies such as for C3DL, NextJ, The Fedora ARM project, XB PointStream, Popcorn and Processing.js.
What made working in the CDOT environment actually work is communication. Our days began with a morning Scrum meeting where we exchanged problems we stumbled into the day before and also shared our success stories. The meetings were brief (only 10 minutes) but on a few occasions they were invaluable. As we stated our problems our colleagues gave their ideas and opinions, “Have you tried looking into something like this…?” or “You should read this blog…”. We didn’t always have the answers, but we were good at pointing someone the right direction.
And sometimes we did have the answers. Our cubicles were close so it made sense to ask the regular expression expert a question which would save us half an hour and only steal a few minutes of their time. Other times we posed questions to other developers on IRC or we received extremely useful suggestions on our blog posts.
We also took the opportunity to meet face-to-face with our industry partners. Developers at Arius3D gave us guidance, tips and valuable resources. Down at the Toronto Mozilla office we were given a WebGL walkthrough and help with relevant WebGL tools. We also worked closely with Brett Gaylor–a filmmaker working with us on the video tag. Others of us met with developers from NexJ and Fedora.
All these forms of communication were important for the development of the technologies we worked on. It only reminds me how crucial these are for open source development.
Now that the Fall semester has started I’m back in Seneca taking classes but I’m still excited to be working at CDOT on XB PointStream, C3DL and Processing.js.