Posts Tagged ‘webgl’
Yeah, I’m in.
I’ll most likely make a browser based 3D game, using my company’s game engine Goo Engine, which will be released publicly before the competition. The other tools I’ll probably use are:
Development environment: Windows 7
Programming: Sublime Edit, CoffeeScript
2D graphics: Gimp, Inkscape, Photoshop
3D modeling: Blender
Just like last time, there’ll be a real-world gathering at Goo Technologies office in Stockholm, so that’s where you’ll find me.
Hoping for an inspiring theme.
Wow, that was closer than it should have been. Last minute fixes to the server, crazy audio explosion bugs on Windows, cross-browser compatibility. We did it all, and all in the last hour too.
But really, I’m just so happy with what we made, and a huge thanks to Philippa, Ben, John, Tom and Simon, who made the artwork and audio and helped with design. Having that talent has made such an enormous difference since our last entry.
Also, seriously, can you believe this is a browser game, it’s the future! PlayCanvas has come on so much since our last entry.
We’re down to a single artist from 3, and she’s is working flat out to get everything ready. We’ve lost one team member to noro virus. But our Jam Entry is shaping up to be a real treat, as you can see by the four horsemen here!
Entering the final stages, putting in the game transitions, hooking up the world server, as there is MMO element(!). Generally hoping that we don’t hit any major hurdles in the next few hours.
I’m looking forward to sharing this one with you.
Like my last two games, this one will also be HTML5. I’m not yet sure whether it’ll be canvas2d or WebGL, but I’m leaning towards the simplicity of canvas2d.
- SCSS is compiled into CSS, using Compass for its CSS3 mixins (which automatically add vendor prefixes like -webkit- and -moz-).
- Inkscape SVG files are exported to PNG files.
This makes for the quickest development cycle: just save the file, and refresh the page.
I have three rough game concepts. Here’s to hoping one of them can be bent to fit the theme.
Good luck everyone!
My previous <shamelessplug>entry</shamelessplug>, for LD22, being a resounding success, I’m now back for more! I used to be known as ThomasTC, but now I’m Frozen Fractal on here, frozenfractal on IRC, @frozenfractal on Twitter, and frozenfractal.com on the web at large.
Like last time, I’ll be using HTML5 and canvas. Unlike last time, rather than plain 2D canvas, I’ll be using WebGL! It’ll be all fancy-like, with shaders and stuff. Maybe even 3D.
This post is also a kind of base code declaration. “Kind of”, because I’m spending my free time this week writing my “base code” up into a nice open-source WebGL library!
It’s called Gladder (GL-adder, or G-ladder, or just more glad, take your pick). Gladder is…
- … opaque. It does not expose WebGL, but rather aims to wrap it in a straightforward way.
- … thin. Many Gladder classes are direct equivalents of WebGL constructs.
- … light. It has no dependencies, other than WebGL itself.
- … flexible. It tries to make as few assumptions about your application as possible.
- … unobtrusive. It does not change default behaviour of anything.
- … cross-browser. It abstracts away browser differences.
The only similar library I could find was Glow, but I found its documentation lacking (read: nonexistent), the website yellow, and the code messy. I’d rather write my own bugs than inherit someone else’s; that way, I have at least a sporting chance at fixing them.
Another drawback of Glow, as with many other OpenGL wrapper libraries, is that it still forces you to deal with OpenGL and its state changes. Gladder aims to abstract all hidden state away and let you deal just with objects and draw calls. Here is an example; there’s still one gla.enable() call, but no code to bind shaders, programs, buffers, uniforms, attributes… all of that is handled behind the scenes. The advantage of not exposing OpenGL at all is that the library has full knowledge of the GL state, so it can skip expensive state changes whenever possible.
Since I don’t yet know what type of game I’ll be making, I’m forced to keep Gladder generic. To do that, I’m working top-down from code samples. First, I come up with something I’d like to be able to do, like render a spinning cube. Then I’ll write the code that I would like to result in a spinning cube being rendered, but it won’t work because I haven’t implemented those parts of the library yet. Finally I write the library code that does the actual work behind the scenes. I might iterate a few times, cleaning up the example code even further. I hope this approach will result in a straightforward, easy to use API.
You can get Gladder on GitHub. Several important things are still missing (e.g. modifying buffer data, loading textures from images), but I’m going to push hard to make it usable before LD24 starts.
Note that the interface is still in flux while I improve things and make them easier to use. If you would like to use Gladder for the compo or jam, let me know and I’ll focus a bit more on adding JSDoc comments and more examples. During the compo you’ll be on your own though, because I’ll be busy making a game!
I wrote about my experiences from Ludum Dare 23 on my blog. Have a look there to see the technology I used to create my WebGL-based game.
If you’re only interested in food, here are some pics:
As you can see, I spent most of my time at cafés.
I’ve been in competitions before, but this is my first Ludum Dare. I’m Martin Vilcans from Stockholm, Sweden. I’m hoping to gather a few other local participants for a meetup during the compo.
WebGL is new and exciting, and this could become a great tech demo and an excellent game. Or a lousy tech demo and a crappy game.
Or I’ll just chicken out and use PyGame to create something simple but be sure to finish something. We’ll see when the compo starts.