Posts Tagged ‘webgl’
My entries to LD25 (Under a bloody sky) and LD26 (Not Complex) now have touch support, and work properly on my Nexus 4 Android device. Those two project use WebGL so few thing where realy necessary to make them working. For an unknown reason,, “Not complex” only work with firefox, not with chrome. It’s the same with every THREE.JS samples i could test.
“Under a bloody sky” use the framework PlayCanvas, and was very very simple to port. In fact, nothing needed changes except adding touch control. It work on Firefox beta and Chrome on my Nexus 4. The layout is prety simple, with only one touch event supported, dragging horizontaly will rotate the camera, and if you are above half the screen, you will go forward, and below 1/4 you will go backward.
“Not complex” was, well, not so simple to port. First, chrome doesnt seem to handle THREE.JS webgl, and some graphics bugs were visible in Firefox (changing an alpha value from 0 to 1 magicaly fixed it) and the control are a lot more complex. I also needed to attach keyboard event receiver to document, and touch event to the welGL canvas to make it work properly.
The controls use two distinct hidden zone. When the mobile is vertical, it’s the top and bottom, while horizontal use left and right, so you can put your left thumb and your right index. Draging on the bottom/left zone will make the character start moving in the specified direction, and tapping will make the character jump. The top/right zone make camera rotate by dragging, and tapping will make the character punching. The control are a little bit slugish for now, mainly with the jump, and it realy need a GUI to be user friendly.
Here is a small abstract of the layout for “Under a bloody sky” and “Not complex” horizontal and vertical.
If you have any advice or tips about touch handle and layout, it’s realy wellcome.
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.