Posts Tagged ‘webgl’
While working with WebGL for my Tsunami Cruiser postcompo, I suddenly got this idea for a new game. I noticed the number of Flappy Bird clones is getting silly, even on Ouya half the new titles are Flappy Bird clones. Since I have to produce something for 1GAM anyway, I created a game where you have to battle an endless onslaught of Flappy Bird clones with… Nyan Cat! Just attach a boxing glove to his rainbow tail… yeah right… then you have a great arena shooter, or should I say arena melee game! It’s only an alpha, so bear with me if there are technical problems.
Sorry, my gif grabber can’t handle subtle colours!
Finally, here it is: the first preview of the Tsunami Cruiser postcompo. It is written in WebGL. It reproduces the original gameplay, minus some bugs and quirks, with a major graphical makeover. I also added a piece of music I listened to while developing it Let me know what you think!
It works in Chrome, FF, and IE11, though there are still some technical problems which I did not get round to fix yet, so consider this a pre alpha version! Some known problems: My IE11 does a software fallback with glitching text. Sound implementation is still pretty crude. Chrome refuses to play music most of the time, it seems, and on some machines the music volume is very soft. There is still a lot of optimization to do as well. Then I can start adding enemies, pickupable bonus thingies, upgrades, etc. Ports to Android and Ouya are also planned.
There is no level select yet, but you can use the level cheat. Press L to advance a level!
My first Ludum Dare compo entry, complete with many minutes to spare!
- Gameplay first, shiny later.
- GAMEPLAY FIRST, SHINY LATER.
- This is way better than NaNoWriMo.
- WebGL is amazing.
In the end I think the decision to use Three.JS meant I got the look I was going for, but it made it pretty hard to deal with entity management, sound and all the other things not related to 3D graphics. I’d still use it again tomorrow though.
Here’s a picture of a virus (our protagonist) about to get scoffed by a white blood cell.
Looking forward to playing and rating as many games as I can now. Congrats to everyone else who’s finished and good luck!
Hey there! Adhesion from team RADMARS here with our tri-annual Ludum Dare battle report. This time we did a fast-paced music-based melt-face cube-smashing WebGL game called VELOCITRON which you can play here: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=18627
First up we got a timelapse and the long-awaited soundtrack to VELOCITRON:
First postmortem we got is Brendo‘s:
I’m quite happy with this LD. I didn’t plan to participate, as I usually don’t have the energy for it in the dark winter months – but I wanted to play around with WebGL so I figured what the heck. Only library I allowed myself to use was glmatrix to help with the vector/matrix math (Thanks Toji, I wouldn’t have pulled it off without it). I also used a single call to jquery, but that was totally not necessary (I change the background color when one gets shot).
In my time zone, the theme is announced at 3 AM – so I got to work a couple of hours before I hit the hay the first night. I managed to get a quad to render as if it was on the ground before me. That was it.
The next day I started making some code that dealt with the level itself – I built a 3d model from an array of strings, which also gave it the old Wolfenstein 3D look. I made some code that allowed you to walk around in the model – adding some poor collision detection code (it’s really bad) – and a door that worked approximately like in Wolfenstein 3D. Then I hit the hay again, this time also at 6AM.
Then the last day, with a little more than 12 hours to go – I made an enemy, some things you can pick up along the way, keycards, doors that require keys, a win condition, a lose condition – all the gamy stuff. The enemies will shoot at you if they’ve looked straight at you for two seconds. The enemies will never walk, as I haven’t implemented any path finding algorithms. With another day, I could probably have done A* or something.
So, at a couple of hours left, the game was complete – I spent the last hour improving a few textures and then I handed it in. My usage of the theme was incredibly poor, and was never mentioned in the game itself; One bomb, one life, one gun.
The reason I managed to pull this off at all, was to a large extent because I’ve worked with OpenGL a lot this year – my spare time project is currently to create a full version of a game based on my LD26 entry. Rewriting it in C++/OpenGL, and making it as good an experience as I possibly can. WebGL is too a large extent similar to OpenGL ES2, and anything you’ve learned from either can be used on the other. Especially understanding matrices have been useful to me.
I’m quite happy with my Wolfenstein 3D-clone, and can now cross “create a fps from scratch” from my bucket list. No matter what people rate me, this is a personal milestone.
All in all, the game has a lot of flaws. No pathfinding, it’s not very challenging, poor collision code, quite short – yet again. Happy
We managed to finish our mini Point and Click adventure called Going Around. It’s based on the life of one of the presenters of video game radio show One Life Left, who have talking about getting there own video game for a while. So we made one for them.
As is typical, it seems to be working perfectly for me, but as soon as I release it the technical issues become apparent. Firefox in particular seems to crash pretty often when running this game. I’m talking to Mozilla about that.
Also some people have reported a lot of slowness. I’ll be updating the post-submission version with any optimizations.
Still, I’m so pleased that we were able to make this game in just 2.5 days. It’s the most complete game I’ve made with any LD submission. Good old PlayCanvas.
A point and click adventure seemed like a good idea yesterday morning. Now I’m not sure sure. But we’ve made a ton of progress.
Our heroine Ann, is pretty much complete. The quests are in. Mostly we just need to prettify the environment.
Hoping to get it done before work tomorrow…
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.