Wednesday, March 28, 2012

Hugging the terrain...face normals

Need to get the dozer to hug the slope of the terrain so it doesn't move up and down like an 'elevator' when moving across rough terrain.

Essentially that ray that I shoot down through the dozer to the ground to determine height, I am also going to determine the 'normal' (perpendicular) to the ground poly and rotate the dozer accordingly.  Theoretically I should sample ALL the ground under the dozer to determine the ultimate rotation, but this will work for now.

                oldrot = dozer.rotation.y;
                /store the old 'y' rotation because we are going to use it later...only X and Z will change to hug the ground
                intersects = ray.intersectObject(plane);
                if ( intersects.length > 0 ) {
                    dozer.position.y = (intersects[ 0 ].point.y);
                    // get the face normal in object space
                    var vec = intersects[0].face.normal.clone();
                     //  points up 
                    var up = new THREE.Vector3( 0, 1, 0 );
                    //  we want the dozer to face in the direction of the face normal
                    // cross will not work if vec == +up or -up, so there is a special case
                   if ( vec.y == 1 || vec.y == -1 ) {
                        var axis = new THREE.Vector3( 1, 0, 0 );
                    }
                    else {
                        var axis = new THREE.Vector3().cross( up, vec );
                    }
                    // determine the amount to rotate
                    var radians = Math.acos( vec.dot( up ) );
                    // create a rotation matrix that implements that rotation
                    var mat = new THREE.Matrix4().setRotationAxis( axis, radians );
                    // apply the rotation to the dozer
                    getRotationFromMatrix( dozer.rotation,mat, dozer.scale );
                    //put back to original y rotation.
                    dozer.rotation.y=oldrot;
                }



Tuesday, March 27, 2012

The Objects and The Logic

Essentially, here is how things work at the moment.

My 'ground' a single mesh (three.js object) that consists of a geometry and material.  The geometry is a plane 512x512 and is the material texturing comes from a GLSL (WebGL Shader Language) that uses a series of JPGs that represent grass, bare earth, dirt and bedrock.  The fragment shader (that applies the textures to the material) uses an array of vertex 'height's that I keep locally to 'merge' the textures together and show the right combination based on the 'height' of the terrain.  You can read more directly from the horses mouth who published the technique to me in: http://chandler.prallfamily.com/2011/07/dynamic-terrain-without-heightmaps/


When I 'deform' the terrain under the dozer, I simply change the 'y' value of the vertex(es) under the dozer and 'sync' that to the webgl side of the house (which talks to the GPU) by setting some dirty flags.  The display updates on the render animation cycle.  It's kind of a brute-force approach, however, to FIND the vertices under the dozer that I will optimize a bit later.

           var width = 8;
                for(var i = 0; i < plane.geometry.vertices.length;i++){
                    if(
                    (dozer.position.x  >  plane.geometry.vertices[i].position.x-width &&
                        dozer.position.x  <  plane.geometry.vertices[i].position.x+width) &&
                        (dozer.position.z  >  plane.geometry.vertices[i].position.z-width &&
                        dozer.position.z  <  plane.geometry.vertices[i].position.z+width)   
                )
                    {
                        if(bladeHeight <  plane.geometry.vertices[i].position.y)
                        plane.geometry.vertices[i].position.y=bladeHeight;     
                        plane.geometry.__dirtyVertices = true;
                        plane.geometry.__dirtyNormals = true; 
                        attributes.displacement.needsUpdate = true;
                }
            }
At the moment, the deformation occurs under the 'middle' of the dozer instead of near the blade.  Another thing to fix later.

The bulldozer is a mesh created by importing a model and I am applying no texture to it at the moment..just an off-yellow color.    Keeping the dozer 'on the ground' is done by shooting a ray (a three.js concept) with a starting point 1000 units 'above' the dozer straight down.  Wherever it intersects with the ground mesh is where the dozer y coordinate will be.

        ray = new THREE.Ray();
                ray.origin.y = 1000;
                ray.direction = new THREE.Vector3( 0, -1, 0 );
                ray.origin.x = dozer.position.x;
                ray.origin.z = dozer.position.z;  
        intersects = ray.intersectObject(plane);
        if ( intersects.length > 0 ) {
                    dozer.position.y = (intersects[ 0 ].point.y);
        }
At the moment, the dozer stays flat and level...regardless of the slope of the land under it.

Monday, March 26, 2012

Good Engines mean Good Progress

Three.js is a really neat framework.  I haven't had this much fun since coding with JavaFX's scene graph and doing my DemolitionFX game .   I don't have a lot experience with the 3D world.  I read the posts by John Carmack back in the day talking about shaders and textures and it all went in one ear and out the other.  I Spent the last several days taking apart that terrain deformation example and learning about vertex and fragment shaders.  I learned about 3d models.  I learned that Three.js can import a pre-defined 3d model and USE it quickly and easily.  I worked through some of the math and found a simple bulldozer (really more of a back-hoe)  and got an initial prototype up and running. I was ecstatic with the results.  Full 3d, abiity to rotate and zoom to your heart's content, ability to apply lighting and textures and shadows  Attached video below showing some primitive 'digging' prototyping. Note that the dirt doesn't actually 'go' anywhere yet.. and the dozer doesn't 'know' about the height changes yet (floats on the surface)....but I am pleased as pie.

Tuesday, March 20, 2012

Depression about Isometric and new hope

Isometric slopes and height based terrain are hard things to do.  The free HTML5 engines aren't even close.  The commercial engines aren't there either (the one (Aves Engine) that WAS got purchased by Zynga...go figure  There ARE some flash options...but I really don't want to code in actionscript and get locked into flash.
Depression sets in.
Then I stumbled across this post:












Holy cow.  In my BROWSER, I was raising and lowering the terrain height...and the textures were changing accordingly....WOW.  What technology was behind this?  WebGL. And more specifically, the Three.js framework.  I start to read.  And to study. And experiment.  THIS was what I was looking for.  While it is not 100% cross browser compatible (only Firefox and and Chrome support WebGL...Safari and Opera are coming soon and IE will NEVER support it), this would be perfect for some prototyping and game mechanics...and it could look GOOD.  I always get excited when my projects look GOOD...gives me drive to work more on them.   In the back of my head I figured that anything I can code in javascript and webGL should be convertible to one of the cross-platform tools like Unity or directly to IOS if needed.

Saturday, March 17, 2012

Isometric engine options


I had seen some neat work done with dealing with depth (down) in an isometric view and I had high hopes for getting something to work for my game.  The seeming simplicity of using tilesets and tilemaps and an engine that supported them well would give me a real boost.  Plus...all the Zynga 'ville' games are isometric.










The Crafty engine has an isometric component...it appears to be fairly primitive and limited to 45 degree viewing.    I did a little playing with it trying to deal with multiple layers of height as one of the premises of my game is expected to be the ability to dig down.  I got frustrated pretty quickly as the 45 degree angle made it difficult to tell where certain blocks were in relation to others, plus I wasn't impressed with the rendering speed (simply adding 2 additional layers of tiles to the demo they provided gave me performance fits.
Isogenic (commercial engine) appears to be a bit more robust.  The documentation is nearly non-existent.  It appears to be phenomenally performant (as evidenced by the demos on their site) but the lack of documentation and examples had me stymied very quick.  I still couldn't see how my terrain deformation would look/feel in an isometric-only environment until I caught wind of some work they were prepping for a future release.


  "Jan Klopper who runs our Netherlands office has been hard at work integrating height-based maps into Isogenic and has shared the latest progress with us here in the UK so we thought we’d share it with you too!
Take a look at the procedurally generated, height-map based terrain in this beautiful screenshot. Isogenic Engine has never looked so good!"    This was exactly what I needed...isometric but with heightmaps.  The dates on those posts was almost a year ago and I saw nothing in the docs on them nor any updates, so I emailed the Isogenic team.  Sadly, this was the response:
"Regarding the height-map stuff it hasn't moved forward that much. I had a second guy who I brought on to write the height-map based stuff and he kinda disappeared on me for a while which made it difficult to proceed. It's a feature that I do really want the engine to support but right now it's just not there.
Really sorry about that... I'm keen to support all the most awesome features that people want but as you have pointed out, I'm a one-man show and my time is so limited because of that I have to focus on the low-hanging fruit and iterate in smaller stages to maintain any sanity! :)"

Experimentation with Crafty and vehicles

Have nearly decided to go with overhead view for initial prototyping to get game mechanics worked out.
Was experimenting with (free) Crafty game engine and whipped up a demo of showing difference in steering between wheeled and tracked vehicles.  Most RTS games I have seen use 'tracked' vehicle movement in that they point in a direction...move...stop briefly to rotate then move again.  Crafty had a GTA style (overhead) view that included driving a car that implemented handling and steering, so I thought I'd whip up a demo of showing the difference.
The code for the 'wheeled' steering looks something like this:


                if(keyLeft){
                    dozer.rotation.y += _speed * _handling 
                }
                if(keyRight){
                    dozer.rotation.y -= _speed * _handling 
                }
                if(keyUp){
                    startScanning = true;
                    _speed += _acceleration;
                }
                if(keyDown){
                    _speed -= _acceleration;
                }
                _speed = _speed * 0.98;
                if(_speed > _maxSpeed) {
                    _speed = _maxSpeed;
                }
                if(_speed < -1) {
                    _speed = -1;
                }
                dozer.position.x -= Math.cos(dozer.rotation.y ) *( _speed);
                dozer.position.z -= Math.sin(dozer.rotation.y ) * -_speed;

Thursday, March 15, 2012

Platform? Framework? Server-side?

I am 90% sure that this will have a server-side component and not just be a casual client-side game with no persistence.  Regardless of client-side technology, I'm also 90% sure the server side component will be done using Node.js. Node.js is a server-side framework that uses javascript. I got a chance to see some vids and experiment a bit with it and I am more than impressed with the flexibility and ease of use.  For storage, I will probably try something new...like MongoDB (a noSQL database option).  I have plenty of experience with a traditional stack (like java and postgresql or mysql) but it's time to branch out and give some other technologies a whirl.

As far as client-side goes, since my server side is expected to be javascript, I will probably do all my initial prototyping and game mechanics experimentation in javascript as well.  I've had LOTS of fun (and VERY rapid development) with Raphael and Processing...but I think I am looking for a larger game engine (that gives me more than just drawing).  Crafty.js (free) looks interesting, as well as Isogenic (commercial).  I don't know what the final client technology option(s) will be.  Depends on the target platform....IOS, Web, etc.

Monday, March 12, 2012

Game Features List

Must have features:

  • persistent claim (when you quit for the day and fire it back up later, you everything is how you left it
  • Equipment purchases and upgrades (and selling equipment)
  • pre-calculated gold distribution (in depth.
  • Water pumping. Required for washplant and maybe also flooding of deep digging.
  • 2D (top down? Isometric?)
  • Equipment maintenance and breakage (and repair)
  • Nuggets (ultimate goal is to find rare nuggets which might have real-world prize associated if we can get any monetization)
  • Ability to buy with real world money
  • fuel usage and cost

Could have features:


  • Persistent world (neighbors are always your neighbors)
  • Claim jumping (mining other people's claims)
  • core sampling (determine where to start digging)
  • trees (clearing)
  • water seepage
  • deformable terrain
  • isometric or 3d view
  • Safety regulations
  • Weather ? Storms? Ice?
  • Explosives
  • Bears and other animals
  • Real world prize nuggets
  • Different ground hardnesses
  • Gold price changes and sell gold strategy
  • Multi-owner claims
  • Find stuff OTHER than gold...Oil? Dead bodies?  Jimmy Hoffa? Alien spacecraft
  • Stolen gold

Sunday, March 11, 2012

The original concept

I really LOVE the idea of dynamic terrain deformation.  Red Faction (the original) that used the GeoMod engine kept me enthralled for hours on end.
I was looking for for project...casual game probably...that implemented at least SOME aspects of terrain deformation.  But I also wanted some kind of 'original' game that doesn't have a saturated market.  One thing I normally HATE is RTS games....I hate resource management (as a player) and micromanagement.  BUT...others seem to really LOVE them.  Heck...look at Zynga and the 'ville' games..making billions.  My thought process was that with a simple RTS-style game (that didn't require a whole lot of multi-player networking stuff) was within my capabilities.

I thought a game that had a tie-in to the VERY popular show Gold Rush (about gold placer mining in Alaska) would be the right fit.  While I can't exactly call my game Gold Rush, I figured that I could model the game after all the activities I see on the show.  And with the rising popularity of the show (I think it's currently the #1 cable show), I might be able to get some traction.  And who knows...maybe I can get Discovery Chanel to feature the game on the website or maybe buy it (they have games for some of their other shows).


Believe it or not, there are ZERO mining games out there....there are plenty of Dig Dug clones...which is about as far away from real mining as you get.   My concept would center around the fact that you get (lease/buy?) a claim in the Alaskan Klondike.  You need to buy/rent equipment, chose locations to dig, set up the machinery to 'extract' the gold (like washplants) and find as much gold as possible.

Now, Zynga could probably CRUSH me with some sort of  'MineVille' game but I can't run from every potential risk.  I also figured that the social aspect could/should be integral.  Would have ability to join or work other claims (those belonging to friends) or maybe share equipment or even (as the title implies) have to deal with others poaching your gold by mining your land without your permission.