Some of all the things
I struggled a little bit with what to write about this week, so I decided to do ALL THE THINGS or at least some of them. One of the pains of being out on creative adventures is that you end up in many lakes, bubbling with creative potential and interesting problem-solving. The most significant risk with that is of course shipping! However, if we look at it in another light and avoid the deadline stress it’s a continual progress of moving forward in all directions, forever expanding space and love... and back to reality:
The community translation experiment is moving quicker than we thought, some languages have all the poems translated already! Wow! Thank you for that! Many of you are anonymous, so make sure to join our translation channel at Discord so we can get in contact and give you a RymdResa key: https://discord.gg/morgondag
Lunar Soil - Rover that can hover
In Lunar Soil you can find yourself in some strange places like a crater where you need to extract liquid sulfur for your robotic AI overlord/friend (more about the AI in the future). To do that efficiently you need a way to move around quicker; we got to have some machines!
If you saw our old attempt of the failed rover, you could casually see the potential there. I took some time to iterate further on another way of solving it. Behold the ray-casted balance rover in its infancy:
This works quite simple by sampling a couple of points of the designated rover area represented by the balls in the video. Then aligning the rover’s angel based on an average between the points. In the video here, we only sample the middle and the front parts of the machine, thus resulting in the rover starting clipping through the ground, going upwards but handling downhill action like a champion. So it works pretty nice already, there are still some quirks to sort out.
However, we can now travel and explore new areas, and of course, get some quality hang-time jumping over cliffs. Soon we can start doing the visual parts and design some neat bikes/rovers/hover things and so on.
What kind of vehicle designs do you want to see in Lunar Soil?
Space shader in Vast Void
One of the core things you see in Vast Void and RymdResa is the starfields in the background. They set the tone of a scene - changing their colors and star sizes etc. depending on where in space you are (in what zone).
The original starfield in RymdResa is pretty straight forward; we pick a random set of pixels on the screen and paint them in the current zone’s size and color. Then we create a couple of layers of them. Finally, we move them in conjunction with your ship's movement at a different depth to generate a parallax starfield.
However, there are performance problems with this as we manually have to keep track of the pixels and draw them to the screen in each frame. We don’t have any shaders in RymdResa. It’s all drawn to a Canvas element.
For Vast Void, we’ve written a custom shader with basically the same principle but with the great flexibility that comes with shaders like tiling and materials. Now that we create the starfields’ layers with a shader, a texture and with a couple of simple, transparent quads we got a much higher fidelity with minimal performance implications. Instead of rendering a starfield to the entire screen we attach these quads to the camera and parallax them based on the players' velocity and depth.
By doing this, we also get performance “free” zooming capabilities for Vast Vod.
When building RymdResa, adding the feature zooming was impossible; as we didn’t have a camera object, everything was attached to the canvas, zooming meant scaling objects up and down and then try to render them.
Not being able to zoom in RymdResa can be a hassle when playing on smaller screens as you can't see incoming dangers ruining your day.
GDC is in full swing! What we consider most interesting is to finally see some aggressive push towards cloud gaming. Google announced their new service Stadia.
One of the best things with a future with cloud-based gaming is that we don’t have to care about hardware and strange console SDKs or API restrictions in the same way. It’s also one thing that is nice with consoles vs. phones and pc landscape. Mostly everyone's Nintendo Switch work the same. In PC there can be problems on someone's particular setup that makes it hard to navigate and troubleshoot problems. This can also mean a stronger push towards HTML5 canvas, WebGL and WebAssembly, which we think will benefit everyone.
We have signed up as developers but haven’t got any response yet. Will see if we get to tinker with their cloud-ware anytime soonish. We’re still waiting for the Pixel3 to ship officially to Sweden so who knows. We are happy that Unity is onboard already.
Custom Screen hardware
From cloud to hardware, so I have been tinkering a lot with traditional canvases and a way to fuse it with more digital art; one way is to make screenprints. However, the animations kind of gets lost in the dried paint. So I tried to do a project with the official Raspberry Pi screen. There is a couple of problems there already, there is no real support for Unity to run on an ARM Linux device, and hacking your way around that usually means terrible performance.
I got my hands dirty and wrote a simple engine in c++ for it. It works remarkably well; 60fps - no problems with lots of game objects rendering and animations at the same time. However, the official raspberry screen is so tiny, so small; I want a large Full-HD frame on the wall! So I started working on a prototype, teamed up with a tinker friend, and we are making some headway on it, more on that in the future.
None-blocking Bluetooth server in c++
One of the problems with having a custom raspbian configuration with a custom c++ application rendering custom art on custom hardware is: how do you control the stuff without any wifi or touchscreen or even UI?
You make a Bluetooth enabled server application and hook it up to a mobile phone!
The raspberry already is Bluetooth enabled so back into software land I wrote a simple Bluetooth server that would respond to any client I shot at it. Tested it as a standalone application and it worked great!
However I had missed one crucial part, when I integrated it into my engine I noticed that the entire screen froze! The sever was blocking the rest of the application doh! Per default, it’s blocking and when I configure it to be none-blocking some of the helpful functions started behaving in strange ways, like not detecting a client disconnect, pooling the old client, start blocking when reading from the client.
We are now officially approved for discord publishing, whatever that means nowadays. Discord announced their store before the big battle of Steam vs. Epic Games started. If you go into your Discord app right now and try to find a store you will likely see the Nitro subscriptions thing and no real store. So we are not sure what's going on there, but it seems that Discord Nitro tried to compete vs. Discord store and the Nitro thing won. So the question is should we spend the 25$ publisher price and the time it takes to set up each game on discord or wait until there’s something more clear than the official roadmap:
What do you think about the discord store and Nitro?
Some Love from Nintendo
We are building Lunar Soil, Vast Void, and all the free games with Unity right now, we like it because we don't have to care as much what kind of publishing requirement the next gadget or service will have. Also, it much easier porting to Switch and Xbox One. We push the publish-button, and we got the things on the devkits up and running in no time.
However, we always required Unity pro for our stuff and even more so with consoles. We usually pay for a yearly license in advance. Our license was just to expire and we were about to order a new one, but then by accident, we saw that Nintendo actually offers Unity licenses through their developer program! Wow! Thank you, Nintendo for making things simpler for us!