As we’ve just prototyped ArchStone, I will be just explaining the gameplay. So ArchStone is a Craps and Roulette like dice & betting game designed for mobile platforms. It can be played as single-player, against an AI or even against other players. A game takes few turns before it’s completed.

Step 1 – ArchStone Betting

In this step, every player in the game starts betting to ArchStones – which are the brown stones in exterior. Bets assigned to ArchStones will be kept through the game until that stone is hit or broken.

Within this step, every player can make more than one ArchStone bets – though it’s limited by table rules (ie, a table with max 5 archstone bet’s).

Step 2 – Inner Stone Bets

When every player in the game finishes ArchStone bets, next step will be betting inner stones (actually inner stone betting is repeated in the start of every turn). Inner Stones are the stones you see in yellow above. So basically, ArchStone bet’s are done once per game in the very first start where as Inner Stone bets are repeated in the start of every turn.

Step 3 – Rolling the dice

Once all players are done with Inner Stone betting in every round, 3 dice’s will rolled onto table. Depending on the total value, type and colors of the dices rolled, stones will be highlighted and bet profits will be calculated for each player.

Step 4 – New Round

Next in the line, new round will start and players will be re-betting in Inner Stones. This is a keypoint where I would like to explain an important concept of the game. So as you can see from above screenshot, in last round an arch-stone was hit & broken and now it’s visualized with an arrow;

  • Whenever dice rolls hit a ArchStone within the game, the stone will be first paying bet’s over it and will get broken.
  • Within the next rounds, if same ArchStone is hit again, as it’s already broken – it’ll be skipped to next (or previous one) in the arrow’s direction and that neighbor ArchStone will get broken which will not pay the bet’s over it.

So the game will continue like this until the game collapses (with an average of 7 or 8 turns per game).

Step 5 – Table Collapse

Whenever either of ArchStones 3 or 18 (base stones) — or 10 and 11 (keystones) together gets broken, the game (table) will collapse ending the game. The players will be then getting their money or paying their debts to vault. You can see above a collapsed table as base stone 3 was broken.

I was working on basic tree generation last few days which allowed me to discover a sneaky bug in block texturing. While applying textures for blocks, textures of all but top faces were applied correctly. Though as I was mostly using homogeneous textures for testing purposes (rock, sand, grass) it was really not possible to see the problem.

It was the non-homogeneous tree-top face texture that revelead it. So I dig deeper in texture-UV mapping code and it wasn’t really easy to spot the actual bug. I further decided to roll back my changes through git to see
the commit that introduced — to my surprise it was a really really sneaky, old bug which even existed in very first git commit (that I moved the project from bitbucket to github). As I had deleted the bitbucker project and didn’t have earlier history backed up, it wasn’t possible to track it back.

So there was nothing left but to verify all uv-mapping code. Few hours later I spotted it at last; wrong uv-mapping indexes were applied for Y-increasing faces!

There we go! I had just fixed a major sneaky bug that was lurking in git repository for a long while and it really really feels good to fix one!

So it have been a while since my last post and I wanted to give a quick heads up. First, the work on voxeliq engine continues and we’re pushing for an Android port based on monogame/develop3d branch. Though as develop3d is somewhat problematic now, I’m following the project and trying to find a possible solution.

Meanwhile, we’ve started working on our new title “ArchStone”, which is primarily targeted for mobile platforms (android, iOS, windows-phone).

So ArchStone is a betting game where you bet on arch-stones or inner-stones and so. The game is still in very very early prototype stage so it’s quite hard to understand what’s going on within the gameplay video;

Prototype Video I

Keep tuned for more soon!

If you aren’t aware yet, those great guys over Mono project works on creating an OpenGL based implementation of XNA framework which can target MacOS, Linux, Android and IOS (those latter two of course will require MonoDroid and MonoTouch). So their website already mentions the ever first 3d game powered by MonoGame and I couldn’t resist giving it a try to get Voxeliq running over MonoGame! Here goes the story;

It took me a few hours to figure things out. At the very first I tried my chances on wrong branch – MonoGame/develop – which at the time being is the furthest branch. Though I got my answer on #monogame, which ‘develop’ did not have support for MojoShader – which allows HLSL shaders to run over GL (it converts them actually).

So I checked out the develop3d branch as mentioned in irc channel, which was the correct branch to go for 3d games. Within my initial try, I got lots of error messages from compiler complaining about missing HalfVector2.cs. So I put in the XNA implementation, fixed a few bits here and there and all the errors were gone! When I hit run button, things started up but I got an exception where MonoGame was complaining about threaded creation of GPU resources were not supported yet (which will be fixed later). Bingo! It was all okay and I was able to run Voxeliq over MonoGame using OpenGL. So Voxeliq is not the first 3d game/engine running over MonoGame but I guess it’s one of the very earliest ones

Oh and I had to disable few bits / components (bloom effect, my music manager implementation and console which uses Digital Rune libraries that was compiled against XNA4) of Voxeliq which may need fixes – though that’s for another story I’ll be updating you guys on the progress.

PS: If you need HalfVector2 fix, you can find my patch here.

So I continue my optimization on engine and recently have worked on vertex builder a bit. Results are again brilliant! Vertex builder is now 5x to 7x faster!

Test Parameters:
* View range: 5 chunks.
* Total chunks in view: 121 chunks.

              Old #1        |           Old #2          |           New Technique
 #1          4497 ms        -          3237 ms          -              728 ms
 #2          4419 ms        -          3066 ms          -              623 ms
 #3          4520 ms        -          3089 ms          -              627 ms
 #4          4576 ms        -          3340 ms          -              679 ms
 #5          4413 ms        -          2832 ms          -              613 ms
 #6          4215 ms        -          3022 ms          -              597 ms
 #7          4451 ms        -          3463 ms          -              631 ms
 #8          4790 ms        -          2989 ms          -              627 ms
 #9          5117 ms        -          3442 ms          -              599 ms
#10          4624 ms        -          3191 ms          -              640 ms
AVG.         4562 ms        |          3167 ms           |             636 ms

* Old #1 = Old vertex building technique with block arrays per chunk.
* Old #2 = Old vertex building technique with single huge block array.
* New Technique = New vertex building technique optimized for single huge block array.
It's ~7 times faster then old #1 and ~5 times faster then old #2 technique.

Even better there are still more rooms for optimization which I’ll be working on them until I get a perfect point. Here’s a speed demonstration video. Note that in video there exists nearly ~960 chunks and ~30 million blocks.

Bonus Screenshot

In one of my previous DevLog entries I had mentioned that I was switching to a single huge block array technique instead of array per chunk which eventually simplifies access to block data. Now I’m done with upgrading my lighting code to take advantage of new block array technique and results are great!

With the latest updates, ligthing is now 3.2 times faster! Wow, that’s a really great optimization which worth every single seconds I’ve worked for it! Here’s test results;

Test Parameters:
* View range: 5 chunks.
* Total chunks in view: 121 chunks.

     Old Lighting Technique - New Lighting Technique
 #1          1316 ms        -          498 ms
 #2          1291 ms        -          384 ms
 #3          1338 ms        -          384 ms
 #4          1293 ms        -          389 ms
 #5          1278 ms        -          387 ms
 #6          1324 ms        -          386 ms
 #7          1284 ms        -          377 ms
 #8          1281 ms        -          380 ms
 #9          1288 ms        -          389 ms
#10          1299 ms        -          381 ms
AVG.         1299 ms        -          395 ms ~ 3.2 faster!

So what changed?

First, the old technique was optimized for old block array per chunk storage. So within this to access a neighboring block, it had to access using chunks – as a neighbor block could be in another chunk. The below propagation functions first need to resolve the chunk that owns the asked block (as block arrays are per chunk) and then need to progress on.

PropagateSunLight(chunk, (byte) (x - 1), y, z, light);
PropagateSunLight(chunk, (byte) (x + 1), y, z, light);
PropagateSunLight(chunk, x, (byte) (y - 1), z, light);
PropagateSunLight(chunk, x, (byte) (y + 1), z, light);
PropagateSunLight(chunk, x, y, (byte) (z - 1), light);
PropagateSunLight(chunk, x, y, (byte) (z + 1), light);

Where as the new lighting technique really doesn’t care about which chunk does the block resides in and can directly access the block data from our single huge block array!

PropagateSunLight(blockIndex + BlockStorage.XStep, propagatedLight); // propagate light to block in east.
PropagateSunLight(blockIndex - BlockStorage.XStep, propagatedLight); // propagate light to block in west.
PropagateSunLight(blockIndex + BlockStorage.ZStep, propagatedLight); // propagate light to block in north.
PropagateSunLight(blockIndex - BlockStorage.ZStep, propagatedLight); // propagate light to block in south.
// DO NOT repropagete to upper block which we don't need to do so and may cause loops!
PropagateSunLight(blockIndex - 1, propagatedLight);   // propagate light to block down.

So What’s Next?
I’ll be also optimizing terrain generation & vertex-building code similarly.

Bonus Screenshot
Nothing new & fancy