Why the break

Hello everyone who may be interested, which I'm guessing at this point is very few if any.  I stopped writing this blog several years ago because my professors were worried that if I posted my algorithms and or thoughts on game development that I wouldn't be able to get published in a journal(which is important for graduate students for some reason).  Since my masters project would essentially need to be such a paper I stopped writing my blog.  Well, I dropped out of school years ago, and I find myself unemployed once again.  So in the hopes that this will be useful to others I am going to go back over all of my posts and add my thoughts on how things changed after I have learned a great deal more about this.  So let the necroposting commence.

Collisions with triblocks

So I've run into another problem using triblock style voxels.  First a little background into how voxel engines work.  In games like minecraft it seems like there are millions of blocks that are all separate and independent, but the reality is that if each block had to be individually drawn it would slow the system down considerably.  To avoid these millions of draw calls the blocks are instead organized into chunks.  A chunk may be an area of say 16x16x16 blocks that will take into consideration whether the blocks are filled or not and then draws a mesh to represent all of the filled blocks that are next to empty blocks.  When the player interacts with the world and places or removes blocks then the chunk( or chunks in the case of being right on the edge) is redrawn.  Because the whole thing is a mesh together, the collision of the ray from the player's point of view (represented as the sight in the middle of your screen, usually a cross or box) has to determine which box in the chunk is being selected for change, and it accomplishes that in most systems by going halfway into a block and calculating where it is.  Because cubes line up with orthogonal directions fro x, y, and z in a 3d system then they use those directions to identify the block they are in and do the necessary change.  No matter where the collision occurs on the chunk the test will always find the resulting blocks.

My problem is that using equilateral triangles for one of the planes creates a system where sides will be facing directions other than the orthogonal directions of x, y, and z.  To complicate things further if I were to do the same test by going in a half block distance into the block or out from the block using the direction(or negative direction) of the normal vector and the collision occurs near one of the edges I will identify the wrong block for deletion/addition into the mesh.  This is kind of a big problem. One possible solution would be to have each mesh store a triangle list, with each triangle pointing to the block it belongs to and the block it is facing.  The problem with this approach is that even more will have to be stored in memory during run time, and voxel games are already huge memory hogs.  Another issue is that to cut down on the amount of drawing that has to be done if several faces are in the same plane often the triangles are enlarged to cover just the edges of what is showing.  

So what this means is I won't be able to do the large areas I was hoping for back when I first had this grand idea.  Unless of course I figure out how to overcome these obstacles.  Anyway if you are interested in a better explanation please visit https://sites.google.com/site/letsmakeavoxelengine/.  It had a pretty good explanation of what goes into a voxel engine.

Doing things wrong

So I've been enjoying a break from school ( I figure I should do that while I still have the chance) and in between I have been looking at tutorials for how to do a minecraft-like in Unity3D.  The particular video series I followed is by one Craig Perko and can be found at .
So what I have learned from this video is that I was going about creating my scene the wrong way.  I was creating a new mesh for every face that needed to get displayed, rather than making the faces all fit together into a larger mesh.  This would explain why it was performing so badly at my website http://apoidgames.web44.net/wedge.html, I had hundreds of very expensive meshes all trying to fit together.  Unfortunately building all of the faces into a single mesh is not quite so easy when using equilateral triangles for one of the planes.  Also unfortunately I am taking a class called computational geometry over the summer which will again take much of my time, so I will have to put this project on hold for now(again).  Anyway thanks Craig Perko for explaining how minecraft works a little more clearly.

The Algorithm for triangles and hexagons

So I thought that it might be a good time to share the algorithm I devised in order to create triangles and hexagons in a standard 3-space.  I'll share just the one for a triangle since the hexagon is just 6 triangles put together.

In order to do it you will need some variables that are important. This will be written in pseudo code and should be easily adapted to whatever language you wish to translate it to.

In order to do it you will need some variables that are important.

// This variable is the height of an equilateral triangle
float depth = Math.sqrt(3)/2;

//Then we need some counters for the loops
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw

// This first one is built in 2 space
for( int y = 0, y < 50, y++) //Note that the target number of loops is the same size as countstop
{
    count = countstart;
    while( count < countstop) // This is where the X element is drawn
    {
        Draw an equilateral triangle the uses the following vertices;
        Vertex1 ( x = count, y= y * depth);
        Vertex2 (x = count + 1, y= y * depth );
        Vertex3 (x =count + 0.5, y = (y + 1) * depth );
        count = count + 1;
    }
    countstart = countstart + 0.5;
    countstop = countstop - 0.5;
}

The one for creating triblocks in 3 dimensions is fairly similar

//These variable are used once again
float count = 0;
float countstart = 0;
float countstop = 50; // This can be for however large you wish to draw

//There are only slight variations to build blocks in 3-space
// This second one is built in 3 space
for (int z = 0, z < 50 , z++)
{
    for( int y = 0, y < 20, y++) //Note that the target number of loops is the same size as countstop
    {
        count = countstart;
        while( count < countstop) // This is where the X element is drawn
        {
           if( z=0)
           {
               Only draw a zpos triblock
           }
           else
           {
               Draw a zpos triblock
               Draw a zneg triblock
           }
           count = count + 1;
        }
    }
    countstart = countstart + 0.5;
    countstop = countstop - 0.5;
}

Please note that the y loop can have as many iteration as you wish since the triangle is in the z  and x portions.  Again to create a hexagon one would need 6 of these triangle formations.

Early Wedge in Html5

Ok after a long time I finally have a playable demo I can share with everyone via the web.  Just go to

http://apoidgames.web44.net/wedge.html

The controls are basic and it may run a little slow as I only have one type of the two types of triblock showing.  There is also no collision detection so you can walk right through all of the blocks.  I built it using three.js, and I'm hoping to get to the point where it can be edited.  It at the very least will give everyone an idea of what I am going for in the landscape.  Just imagine lots of these triangles put together into one large field.  Anyway I'm back to figuring out how to make this even more interactive.

Working on Web Programming and Three.js

So I've been doing some soul searching and trying to determine what to teach myself in programming relating to graphics.  I learned a bit about GLUT (an open GL library not really used much these days) and rather than learning older technology I am going to work on understand HTML5, javascript, and WebGL.  I hope to put something together that runs in a browser (probably Chrome, upgrade if you haven't yet) by the end of the semester.

To this end I am learning about an interesting library called THREE.js by one mr.doob.  He has been instrumental in getting several chrome experiments up and running and I feel that the library is approachable as the novice I am.  The cool thing would be that I could share whatever I make on the internet, so hopefully you all can experience it too.  Thanks for reading as always.

The power in WebGl

I recently stumbled upon a pretty amazing demo showing just what can be done with javascript and Webgl.  You can check it out at https://developer.mozilla.org/en-US/demos/detail/bananabread . Basically they took a full game engine written in C++ and OpenGL and ported it to javascript and webgl.  It's open source, so I will be able to study it out and get a good idea of where I could go to start my own game later on.

Firefall review

So I recently had the opportunity to try out Firefall and I must say that for a free to play game it was very impressive.  I liked the ability to swap out battleframes, which is very similar to the idea I have for switching roles.  There was a definite PvE (player vs environment) push, with PvP(player vs player) being almost an afterthought.  The PvP matches were basically 5v5 team deathmatch style with the possibility of 10 v 10 on different maps, but there is not the persistent open world pvp I was kind of hoping would be there.  There are a kind of simple tower defense type situation where you and your squad defend a thumper (a type of mining device) from wave after wave of overgrown bugs and other mutated wildlife, which provides a challenge of it's own.  Finally there is the Chosen, who are evil incarnate NPC (non player characters) who come to take over watchtowers and generally make life difficult.  Some of them are quite powerful, leaving me roasted a many a time as I tend to walk around alone.  Even so I was able to take out dozens of them single handed, and I'm sure that even with improved AI players will eventually figure out way's to kill them easily.

As for what I would hope to see,  I would say that player controlled chosen would make the game very interesting.  That way large scale open world pvp could be realized, though that also introduces some problems as to how would tech and other items work.  That and if you have the "good" side and the "bad" side developers often will unconsciously favor the good side.

Product vs Service

As I continue to study the art of game creation I came across an interesting and thought provoking concept, that we are moving away from games as a product to games as a service.  I certainly would say that I hope to create a system for the latter, but I suppose I should explain the differences before I go into that.

In the past games were required to be in a complete state (meaning completely coded, put into a package to be sold in retail outlets, etc..) before they got to the consumer.  Often once it had shipped the developers would no longer have anything to do with the product other than wait for one of two outcomes, success and the opportunity to make more games or rejection by the masses which usually meant the end of said game development company.  With every "product" shipped there was a definite gamble,  and since publishers who were funding the product from the inception and who also are very concerned with making a profit were pretty much in control, any failure to produce said profit was a death sentence to any game developer who didn't perform well.

Now switch to games as a service.  MMO's are a great example of how this mindset works.  A game is created and then costumers are brought in before the game is complete (usually in beta) and they give feedback as to what they would like to see in the game as a finished product.  The thing is that the game is never really finished, as things keep getting added on.  Costumers also don't do the one time purchase as in the other model, rather they pay on an ongoing basis either through subscription costs or via micro-transactions.  The game developer and the consumer then have this continual relationship where there are feedback loops and opportunities for creating an experience that players enjoy and game developers are happy to provide.  It also means that game developers are able to work with a product long after it has reached the hands of the consumer.

I think the second option has a better chance of creating communities around a game, and also gives developers a chance to polish and work out games to become the very best that they can.  I look forward to the change in paradigms that is already occurring.

Marching Cubes

As part of my algorithms class I need to present an algorithm that I have looked into and analyzed.  For this assignment I chose the marching cube algorithm.  It's a nice straightforward algorithm that was designed to display 3d volumetric information and it was originally presented in 1987.  Anyway I am learning quite a bit about voxels through this, and apparently this algorithm or something very similar is commonly used in place of height maps for creating the base landscape in many games.  The reason why is that it make negative spaces like caves and overhangs possible.

So a quick explanation is that you take a large set of cubes put into a 3d array like 512x512x512.  Then going through each of the smaller cubes you determine whether one of the 8 corners is either inside or outside of your volume.  The program then repeat this for all of the remaining cubes keeping track of which ones are inside and which ones are outside and drawing triangles based on the intersections.  In the end you have a rough 3d representation of the volume being measured.

Now I need to go and write a 20 page paper on this, and I find myself wondering what fillers to use to stretch this out.  Wish me luck.