Here I’ve added the classic Perlin noise function, and you can see it’s starting to look like a terrain. I wasted quite a bit of time reinventing the wheel here looking for fast ways to generate band-limited noise, and came to the conclusion that Perlin’s is hard to improve upon. I looked at his Simplex noise implementation which is supposed to reduce grid-like artifacts but to my eyes instead I saw triangular artifacts and I didn’t think the noise was as nice looking at low octave counts. There will be lots of experimenting with fractals further down the line so I’ll leave this for now.

After implementing this and doing most of my testing using the latest developer preview of Firefox (Minefield), I then tried it on Chrome and nothing worked! What!? I was totally foxed as to why it worked in one browser and not another. Obviously Chrome had updated itself in the background but I was left scratching my head for why my code no longer worked in Chrome. It turns out to be very obscure in that I hadn’t bound the attrib location for the vertex position and colour variables in the vertex shader setup code. Took me ages to track that down. One of the perils of working on an experimental browser that’s implementing an unfinished WebGL spec is things do break! I was mighty relieved when I got it working again. I also found setting the —enable-accelerated-compositing flag on the launch icon gave a massive speed boost and Chrome is now my preferred WebGL browser.

Next I peturbed the heights of the verticies randomly. I was going to build a fBM fractal on top but discovered there’s no reliable way to set the seed value for the browsers random number generator so it’ll be different every time. *sigh* Okay, so I’ll have to implement my own random number generator too. I chose the Mersenne Twister. I’ve used it before in Virtari and there was a JavaScript version available online so that plugged in nicely.

Before I could work on the terrain I had to implement some camera movement. Handling keys isn’t so bad, but it’s a major problem not being able to get mouse deltas for panning the camera. And worse, you can’t hide the mouse pointer. As soon as your mouse hits the side of the screen panning stops. This is a serious problem for writing first-person 3D applications. (I’d like to see browser vendors implement a fix for this, maybe just let the browser take mouse control but display a little “Press Escape to exit” overlay for a second like they do on fullscreen flash apps. That should do it. In fact a fullscreen mode too while we’re at it!)  Another problem is how to get panning to work on touch devices. Some thought needs to be given to how to handle control input. Ideally you just move your mouse to look around and left-click to interact. In Virtari where I had both UI and mouse-look modes I simply had it so holding down the right-mouse hides the mouse and lets you pan, and releasing lets it work in the normal desktop mode way. But obviously there’s no right-click on touch devices. That’s going to need further thought, but for now I’ve implemented a right-drag panning mode that works well enough for testing.

Next I set up a grid within a vertex buffer for what will become a terrain. The vertices are coloured randomly for now, just so I can see something. I wanted to see what the frame rate was like to get some sense of if WebGL would be a viable platform. I thought it should be pretty simple to animate the scene using setInterval() to call an update function every 1/60th of a second, but no, it wasn’t quite so easy. Browsers still have god-awful timer event accuracy and it was jumping and dropping frames all over the place. In this day & age it’s pretty embarrassing that a computer that can execute 1,000,000,000 instructions per second can’t even keep up with the monitor that a Commodore 64 could 30 years ago with only 1/1000th the horsepower!… So I wasted a lot of time writing a special handler that tracks the timer latency error and subtracts it from the next scheduled tick event because it seems browsers can’t do this for themselves still. :/  That helped a lot, but would still drop or jump a frame now & then, so I locked it to every other frame at 30Hz and it became smooth again. :) One problem now though is if your monitor is set to 75Hz rather than 60Hz you’re not going to get a smooth experience. I’m probably going to need a manual setting for this because there’s no way for the browser to detect the refresh rate which would help enormously here.

(Note to browser vendors: Add the monitor refresh rate to the browser’s Screen object like you add the colour depth. And fix your timer event latency please!)

This is the very first screenshot from the current game in progress. I can tell you’re impressed! lol! It’s running in a browser using WebGL and takes about a couple hundred lines of code just to get to this stage of setting up the context, loading pixel shaders and vertex buffers to the 3D hardware, matrix and vector routines, timer events blah blah blah. Lots of work just to get your foot in the door, but worth it for the low level power and flexibility it offers. The man from Del Monte says yes! :)

Kudos to LearningWebGL.com for their helpful tutorials (based on NeHe’s originals). Although I already know OpenGL, these were very handy.

I’ve done a lot of R&D work over the past year on purely 2D HTML techniques for fast animation suitable for games. It’s been a total nightmare trying to coax browsers into shifting images around fast enough to do something useful, and the lengths you have to go to do even the simplest things like regular 2D sprite animation let alone fake 3D was a major support headache. At one point I was seriously considering writing a software 3D animation renderer coupled to a dataURI loader via a PNG encoder in JavaScript! Simply just to allow for avatars to change clothing without having to pre-render every possible combination of clothing item on the server. Totally crazy!

About this point I heard about Dextrose’s Aves Engine which used exactly the same kind of DHTML-only techniques I’d been working on but was a bit further along. Very nicely done too. :)

It didn’t surprise me that someone else was doing the same thing. This happens a lot. Programmers often independently come up with the same tech by taking things to their logical conclusion; the problem domain shapes the solution. What did surprise me was Zynga acquiring them soon after!

Now, I’d started working on DHTML animation methods as a way to hopefully get a one-up on Zynga and all the bloated Flash-based games half the net is currently playing on Facebook. But now the top dog had just bought whatever game engine advantage I might possibly have over them to carve out my own distinctive niche. Bugger! And worse, if I’d have not dragged my heels and been so distracted this past year I’d have been way ahead, and who knows maybe Zynga would have picked up mine instead? What a missed opportunity that might have been. Too late to worry about that now.

Something else was bothering me too. I known for a while that 3D in a browser is just around the corner and I’ve been torn between taking two different directions. I know that anything I make that’s 2D will have a short lifespan and is soon going to be eclipsed when the new 3D capabilities come out. The only reason to go 2D is because it’ll definitely work on everyones browser, and a larger market means greater chance of success. I really really really wanted to work on proper 3D, but part of the success of Zynga and the phenomenal rise of casual games on Facebook is how accessible they are to the average housewife who’s not normally your typical gamer. It’s gone mainstream.

However I think the main gating factor is going to be publicity and getting noticed in an increasingly crowded market. I sure as hell won’t be making a FarmVille clone. Though I could certainly write a better implementation with better gameplay on the farming motif, it’s gonna be going up against half a dozen other people also aiming for a slice of that pie. As a small indie developer there’s no way I can compete with the advertising budgets or cross-promotional muscle of the larger dev studios. So I’m going to aim for a niche slightly off-centre midway between the casual masses and the hardcore gamers. Something hardcore gamers can really buy into and enjoy, yet is still easy to play and accessible to the more adventurous mainstream casual gamers (who’re also getting more sophisticated over time).

The biggest decision I’ve made is that it will be uncompromisingly 3D and definitely HTML5. It will require a modern browser. I’ve looked at the numbers and about half of all browsers will have this capability within a few months. The developer previews of both Firefox and Chrome have WebGL baked in. It’s coming. I think the timing is about right, or maybe a little early, but hardcore gamers will be ahead of the mainstream on this so I think the advantages of being able to make a great game and draw attention outweigh the disadvantages. It’s a bit of a gamble. :)

The screenshots posted up to now are from my older projects over the years. Going forward, my intention is to journal the development of a new WebGL game. There are no guarantees though - projects & priorities change all the time, and other things might crop up, but that’s my intention at this point in time.

I can’t say exactly what the game will be about yet. I have some firm gameplay ideas that will need testing to see if they’re actually fun. But it will be 3D and involve construction like my old Ingenium and Virtari games. I want it simpler this time. Maybe some kind of block stacking like Minecraft rather than full polygonal mesh editing as before. Seems like the best trade-off between simplicity and creative freedom for most people. I’m heartened by the success of that game because I always firmly believed in sandbox type games (and Second Life). I love environments where you can make things in-world and influence it. My old Jet Tanks game let you dig tunnels too! It’s great to see another indie developer do so well. I’m eager to do things a little differently though so as not to draw too many comparisons, but we’re all influenced by what has gone before (as was he from Infiniminer and Dungeon Keeper). The important thing is to add something new to the mix. I have a long list..

I’m writing the game in JavaScript using WebGL which currently is too new to be supported out of the box by any major browser, but should be available within months. I think it will be fast enough. The upside being it should soon run in about half of the worlds browsers (more if Microsoft supports WebGL). I want it to be ‘social’ so will probably do something with Facebook Connect. I’m also mulling over the idea of it being a downloadable app sold via some app store, and/or a free version supported by virtual object sales. I haven’t decided yet. Either way I’m hoping there will be enough interest to support fulltime development on it, which would be fantastic. :) Part of the reason for setting up this development blog is to begin the process of whoring for attention building interest. :P  So any exposure you can send this way would be greatly appreciated. :)