Ohayou! Beginner’s Japanese Completed, Stone Shire Patch 1.2, and Nintendo Switch


It has been a grueling five months of work, but we have finally completed Ohayou! Beginner’s Japanese for the Wii U. The game took a lot less time to make than Stone Shire, that’s for sure. We’re excited to finally have it done and are now waiting on approval for it from Nintendo. After that, we’ll be able to say a release date for it. We may release a patch in a month or two that will add vocabulary, based on how long it takes to implement. But with the Nintendo Switch now a thing, we may just delay it until then. We’ll talk about Nintendo’s new system in a moment.

In the meantime, the 1.2 patch of Stone Shire has also been completed, which took only a weekend. To improve frame rate, the water flowing process has been removed, and lighting updating has been optimized. Players should see a large difference once the patch is deployed. Its release shall come as soon as it’s done being approved.


Now, on to the big topic of the week: the Nintendo Switch! I’m happy they announced it, because it’s very significant for the future of Finger Gun Games’s development. Hearing that Unity will also be supporting the system, porting our current games to the new system is now possible. In addition, I’m very curious of the Switch’s specs. At the moment, Nintendo will not release any, but based on the hardware it’s based off, the Nvidia Shield, we can garner a clue to its construction. Based on a couple of studies, it could be that the system is using the Tegra X2 chip. To compare its performance, the hardware has been known to be able to play games at 1080 @ 30 to 60 fps, or 720 @ 45 to 60 fps. Apparently, it’s a 64-bit six-core chip, with two main cores that are considered the major haulers of performance. The Wii U had three based on tech studies, so the only thing we will have to see is if the version in the Nintendo Switch is as fast, if not faster.

I wasn’t disappointed by the GPU in the Wii U, so I’m sure it’ll be just as reasonable around this time. If anything, my only gripe about the Wii U was always the CPU, so it’s the one thing about the hardware I’m curious to see the full specs for as a programmer. I will say one thing: having a good GPU means having a large module with good cooling. The Switch looks a lot smaller and slimmer than the Wii U’s hardware. This has me skeptical of performance, mostly because we all know in the computing world, the more powerful a GPU is, the more heat it will generate, and thus the more cooling you will require. That’s why cellphones are like microwaves when you try to play app on your phone. You never felt any heat from the Wii U GamePad because it doesn’t harbor this kind of hardware, but this time around, the Nintendo Switch will. So the hardware is probably optimized to be as least disturbing as possible. I’m also curious if the docking mechanism actually has another GPU we aren’t aware of. If it’s meant to be a console hybrid, I’m assuming that having that component isn’t just to hook the tablet to a TV while charging it. I’m sure that thing holds a lot more inside it.


As you can see above, there’s vents built into the top of the Switch handheld device, so Nintendo has prepared for that scenario where the thing is going to be running games that could cause quite the heat-up. If there’s anything to take from it, it’ll probably be no worse than the PS Vita. That handheld holds fine for playing good graphical games, so the Wii U probably won’t have too much of a problem. The size of the device seems to put it at bigger than a vita, so if anything, it’s probably better at its job, too. This is Nintendo, after all. I’m sure they already solved this problem.

So in summary, I am looking forward to the Switch. The only thing left is to see its specs and its touchscreen (which is rumored to be multi-touch), but it’s very likely Finger Gun Games will be continuing support for Nintendo’s next system.


Stone Shire 1.1 10/20/2015 Progress

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.