Progress Report 1.1: Updated Grassland and Minecraft on the Wii U! But no Inventory Management on GamePad?

Progress Report 1.1: The Grasslands map has been updated with grass and bigger trees to supply more wood for our lumberjacks out there.

As for when the update will come, I’m fast working to get it done by Christmas, which would mean its release date will hopefully be in January. Please wait a little bit longer.

stone-shire-new-grassland-logo

In recent news, Minecraft is coming to the Wii U next week. I’m well aware of what it can mean for the game, but in a surprising turn of events, the game only uses the GamePad for Off-TV play and not for inventory management? That was pretty shocking, considering the crafting system would be superb with use of the touch screen interface. That’s why we implemented it in Stone Shire first and foremost. It’s a shame to see that Minecraft didn’t put in such an important feature. I’m sure everyone, including me, are disappointed about it. I enjoy Minecraft, and am glad to see it coming to the system, nevertheless.

I suppose it’s okay on the missed feature. Just another thing to make us distinct from Minecraft.

Stone Shire 1.1 10/20/2015 Progress

stone-shire-off-tv-mode
Things have been going well on the development of this upcoming patch for the game. Been making a lot of quality of life changes to the game. For instance, players will be able to play solely on the Wii U GamePad for those who like the comfy life of lying on the bed or couch with their handheld in their hands. And they can also play with a Classic or Pro Controller. So you can just place your GamePad on its dock and play it like a second TV or play it on your TV. The GamePad is still used as an inventory peripheral, so you still have to use it. I have a non-GamePad feature of navigating the inventory currently in development, but it probably won’t make it until multiplayer is implemented.

The jumping has been improved, so now the player can make more precise jumps. The problem on the live build is that when you make a jump, you’re committed to it, not able to change its direction mid flight. Now you can, which should make jumping on places you want a whole lot easier.

There is one issue I am dealing with right now, and that involves the speed of updating a chunk after mining a block. On my PC with a Intel Core i7 4790K, the block update process takes only 200 ms. This includes light propagation and generation of the procedural mesh. However, on the Wii U, whose CPU is not as good, the time to process is a whopping 5000 ms! That’s a 25x difference. And the process that takes the most chunk of this time is the mesh generation process around 2500 ms, where as the remainder is held by the light process, which is composed of two module processes. This is with limiting the processing to only a set amount of space around the block. Because light propagation requires multiple chunks to be updated due to the possibility of how light radiates, multiple chunks are updated at each cycle (which is limited again by a variable to keep the game at a steady enough frame rate). This may sound easy to optimize on paper, but I am using Unity for this project, and unfortunately, Unity has to build its meshes on the main thread. This means whenever a number of game objects with procedural building processes are active, the game essentially stops until they are done, resulting in chopping gameplay. This problem is solved by brute force with a better CPU, but with the Wii U, this is going to require some heavy ingenuity or cutting some corners. Obviously, these processes are put in their own threads, but the slowdown mostly comes from chunks being rebuilt. And the process itself in general creates a short time where the player mined the block, but the terrain doesn’t update until it has processed it.

There’s still a few more solutions I can try to get this up to better speed, such as further queuing the chunks that are rebuilt. I have a main queue of chunks that immediately have to be updated, for when the player removes or places a block for immediate feedback. So I can make a second queue of not so important chunks. It’ll mean that light and water will be updated slower visually, but it may be the price to pay to make this all stable. I have to be careful with this, of course, because the bigger the queues are, the more ram this can take. My game however doesn’t go above half a gig most of the time, so I should be fairly alright. There’s still the bug that the game crashes when in extended play reported by players, so I’m going to have to find that memory leakage that’s happening somewhere.

Stone Shire 1.1 Progress – Better caves and new block highlighter

Over the weekend, I managed to work on more things. One is that caves now look nicer after doing some refining of the cave generation algorithm. Took one weekend to do. Perlin noise is always fun (NOT). The other thing, a more minor but necessary change is that the block highlighter is a lot less obtrusively. This makes it look cleaner, as well, and doesn’t obscure the visuals too much like the older one.

Have a few more things on my To Do list to prepare for the 1.1 update. This includes pro controller support, classic controller support, and Off-TV gameplay that everyone wants. Being able to play only on the gamepad is a nice feature that I hate did not make it into the first build, but will surely be making it a thing this time around. Who doesn’t want to lie in the comfort of their bed and play a little block building? Or use their favorite control peripheral?

stone-shire-cave-update-1280

stone-shire-new-block-highlighter

Stone Shire – Water Progress Report

Read More

I’m one step closer to the first patch for my voxel game available on the Nintendo Wii U eShop. And let me tell you, this was quite the task. I took inspiration from the water techniques in Minecraft. It really is a handy game design feature for simulating water in a simple way. The water flow until it runs out of “flow,” but it resets when it starts falling, allowing creation of things like waterfalls. It’s handy mostly for not having to deal with actual water simulation like water pressure, which would be a challenge to get it working reliably on the Wii U alongside other CPU-intensive processes. I figured it was worth the sacrifice of realism.

The video below shows the use of the water. Update 1.1 will be coming very soon.