The White Laboratory

Here are some of the recent interfaces made to catch up the increased complexity of the laboratory system. These interfaces are a lot of work. The software code is very specific and the visual need to be laid out for each type. I will show some inside work later on in this post.

First, take a look at the interface page in the options menu. In most of the options tab pages an interactive preview is placed on the right side allowing you to check the effect of the settings you are working on. Imagine in graphics tab, the quality result can be previewed. In this case, interface tab, you check the delay of the block panel and the colors. This block panel is the kind of interface popping out when mouse hovering a block. Some might want it be quicker or sensitive and less in the way.

These grade colors represent different levels of blocks. Some of you might remember the old coloration of blocks in a version in 2010. That kind of coloration made the block look like solid high-tech metal. This was changed to a more saturated version to represent if a block is powered and functioning in 2012. This custom color option will allow you to choose any color you like, except for the really dark ones. People with moderate and slight color-blindness can choose colors that they perceive better. But ultimately the colorblind mode is there.

The game levels were made into maps which are longer and more complex. This “Select Destination” will be the place to start a new map by departure selection for the base platform. It has thrusters to push around. In the future multiple base platforms can leave and combine together. This is what follows next:

When the objective of the map is achieved, there is the completion dialog. That “Invention Database” as previously mentioned, will have the newly built structures displayed from the played session. Timeline is essentially a way to navigate the saved games by visualizing them as time line history, or a branch of events. More work is needed on this one yet. Also I did prefer not too much score metric, just like the older versions or the old demo. Because too much scores would be difficult to understand how the points are calculated.

And here we have the in-game pause menu. This is just needed to show the game will have help manuals embedded. It is done by a resizable web browser window. So the player can use it at corner of the screen in the middle of a game. Now in this particular example you can see it is even browsing this website! Well, just an offline copy actually. It will not require Internet for help documents. This browser also does not handle scripts at all. Who needs that in an embedded browser inside an ongoing game, and so no strange behavior from web pages. Overall this was a part that take took some time in development for integrating rendering CSS layout. And that is not including time making the actual documents.

For a window like this, the graphical assets are packed in a texture. Here is an example I put together for demonstration. For each piece it represents an interface component or a state. Information like the area, margin, etc of each are determined and put into the engine. The ones in the middle are the common components which I only need to care about them once. But the layouts of specific interfaces need some more attention. Because they also have different layer arrangement for engine rendering to obtain a very close look to the original concept.

Update: Some polishing is done one the Options and Departure screens to make them less generic.

This analyzer, a front end feature that collects high level metrics from a building, has been in development on and off for a while. Now it comes to a point that can be called done.

Before, it was hard to tell the actual firepower coverage in the area from a complex moving structure. Because shooters can be occluded, out of pitch angle, fast moving, etc. This analyzer system collects large amount of samples (65536) distributed across the nearby area of a unit. Each sample represents the possible damage that can be received, determined using ray testing from the shooter to the ground where the sample is at. All the info is then, put in to a large texture map, visually enhanced. The brighter a pixel on the ground is, the more damage it will receive relatively. And sure occlusion is also marked.

For any particular design, the analyzer can also emulate the damage/acceleration capability which may be constrained by the energy usage. The energy is stored in each block and transfers to other connected blocks automatically. Therefore a whole set of linked blocks is a complicated system. This analyzer assist player to see if there is any bottleneck that prevents supply and causes partial shutdown.

From all these data, 3 conclusive numbers are finally calculated.

• Destruction Coverage: This is the % of the area reachable by shooter. Right now this is just areaReachable/totalArea. In the future I may use DPS as a weight to this so the number is more accurate.
• Swiftness Rating: For those movable flying structures, this means the capability the structure can do fast moving and sudden turn/acceleration. This is not a percentage number so an opinion is given after it.
• Energy Sustaining: As discussed above, if there is any bottleneck causing low power, preventing maximum functioning. It is reflected here.

Let’s take a loser look at a few scenarios.

1. Higher is not always better.

As you can see the square dark area is inside the bright circle. That is the occluded area where no line of sight exists from the sphere to the ground. Because the sphere is occluded by the cube below it, the higher it goes, the lower the sphere need to “look at” – more occlusion.

2. Gatling cannon that burns out quickly.

The Gatling has a very interesting and convincing distribution map. In the “Damage Output” graph, the red line drops significantly overall a few seconds off. This means the tower’s fires at full rate in the first a few seconds then when power runs low, given shooting requires a few power, it shoots slower. You can also check out the “Sustaining Time” under “Weapon Metrics”, that will be the time for full rate.

Unfortunately this analyzer cannot tell the accuracy for the bullet projectiles. It does not emulate real simulation and I would imagine that kind of simulation will get quite noisy and time consuming.

–

A few years ago in the early development of this game, someone suggested using “a different color for the enemy blocks, maybe black”. Before that there was also a feedback for the initial 2 month development of the prototype: “it was hard to tell the enemy”. Because at that time all blocks have the same color for the outer shield part(which can fall off), except subtle difference of inner shining intensity.

I accepted that suggestion using the contrast of color, without realizing the potential racism message that may have added to the game, until I have heard about people complaining about it. Wow, I am not a racist. But that idea just slipped through. Now the development has come along, I think a way to counter this effect is to introduce customizable size colors. But the challenge is, the aesthetic is designed in a way that the block’s shield should be neutral color so it is different from the inside colored core. So at best there are 3 side colors: black/gray/white. I did find gray a little challenging that blocks may look bad. So without challenges it will be black/white for sure then, but customizable: the player can choose the side color. I hope this is okay to start with.

The laboratory systems now have an automatic structure design tracking service. During each regular experiment (aka. game session), all your buildings will be analyzed and the forms will be put into the background database with additional metrics collected. After each session, the latest discoveries will be shown in this “Invention Database”, giving a chance for the user to mark down the meaningful ones and browse later easier under the Marked tab.

Our system also checks for duplication caused by facing in the case of ground structures. A same ground tower may face different directions and look different, but they will be treated as the same one here. For air units and isolated structures, no special handling is needed. Any direction will be treated as the same one.

Still, the total number of permutations out of these parts can still be huge. Thanks to a software library called sqlite, all the data will be stored in a database file on the disk where lab system is installed. Well I hope it would not use GBs of space unless playing really really hard.

The full functionality of this part of the game is actually still working in progress. And it is getting done in a piece by piece approach because of its technical difficulty.

• First of all, I made the background system that identifies and generates “fingerprints” as identification for the structures built by player. The fingerprint along with the info about the structure itself will be put in database.
• Second, I then made the “Structure Photo Renderer”. This part is like a camera that produces high quality visualizations of the subjects as you can see in the first screenshot.
• Currently the “Invention Database” is the one working in progress. I need to make sure a smooth experience for browsing potentially huge amount of items.
• Next, you probably never heard of this, but a rating analyzer will be built in to “Research Station 51″, a free testing facility. The rating analyzer gives rating info such as damage, energy use and accuracy distribution for these structures by testing them, kind of like testing a roller coaster in Roller Coaster Tycoon. The ratings will also be recorded, and displayed in the Invention Database. I hope this will help make better decisions.

During the last development month there are some more stuff than I expected. We have got quite a bit of audio work for the game. Thanks to the hardwork from sound designer Alessio Mellina and thanks Zeropage for their awesome electronic music. These audio works are going to push the game to the next level. Well you can imagine the game feature development would slow down a little bit as some time needs to be allocated for audio integration. We want them nicely fit.

Today is also the 4th fourth anniversary of The White Laboratory since the first SVN commit happened on May 30, 2010. It has been 4 years. But think about it in a different way, there are actually some pauses during these years, as you can see in 2011. So it is actually not that long.

You can check the full statistics of the source code history here www.labtd.com/report. The lines of source code is not accurate. The real number at the time of writing is 104725 lines(without comment and blank lines).

First of all, this is not rocket science. This is about controlling the disc block’s output of its lifting force and making a softer landing when all disc blocks on an aircraft is being turned off.

Results: (a little bit concerned if the 200% playback speed will tell the difference. )

One of the most challenging aspects of make this game is dynamically control the physics objects rather than a prebaked animation applied on them. This way the object will keep full physics interaction resulting in many interesting situations, like some abstracted robotics. Most of objects in this game are dynamically controlled. For contrast, one of the exceptions is the base. When it flies off it just follows a path, pushing everything away in its path which is determined when given a destination.

When I try to land a cargo aircraft on a ground structure to lift it up for transportation purposes, the cargo aircraft will more look like crashing instead of landing. I found this annoying because you will likely miss the target and have to try again. What happened is when a disc is off, it cuts its lift force like this:

The lift force begins dropping quickly and when it is below a certain point that cannot counter the gravity, the unit will just strike to the ground. Anyway, this is better than suddenly dropping to zero because at least a little gravity is reduced during the process. I have been wondering what if I reduce the lift to somewhere relative to that certain point rather than doing this on a 100% scale. So I can have more precise control dealing with the gravity.

And I have already got the numbers. From the info in this image, we can tell the lifting is being 50% used (4/8). So the idea would be if the lift is at 50% the structure will feel like in orbit, staying at the altitude without gravity.

In order to make it descend first, I should reduce the lift below this point for a small amount of time. The gravity wins over the lift during this period and the descent will begin.

Then in order to remain a reasonable descending speed, I should increase the lift back close to the 50% point countering the gravity. With damping considered in addition, the unit should just be able to smoothly maintain at a consistent speed. (actually in reality it tends to slow down)

Finally, I drop the lift as usual since the disc(s) are eventually to be turned off.

So I came up with something like this: when a disc is being shut down, it will modulate its lift as follows but have that load level % calculated first.

The good thing about doing in this way is its openness: it also works like it was when in a situation only some of all discs are being turned off. In that case, the ship will change its weight balance. (well I imagine the player has a good reason to do that)

Fortunately this is not as hard as the translational controller, the essential component of disc-driven flying units. I had done it almost a year ago when I was working on this project part-time.

With the introduction of these railway tracks, the cylinder block has a new use: wheels. The cars made using these cylinder motors are just like regular flying units, except on ground and less relying on the propeller discs. These vehicles cannot just run on a flat ground. If you observe carefully, the center body falls in the gaps between the inner tracks, making the structure lower so the cylinders will touch the tracks well. This will not happen on a flat ground.

This is my train departure. The tracks are carefully designed so the train car will not get stuck at turnings unless it is too big. You can notice the wider gap between the inner tracks here. Also in the above scenario, there are actually three shorter ones. The ones behind will push the front one forward.

These prebuilt tracks in the map provide strategic opportunities. For this one it is actually like a mine railway connecting to a location with scraps, a resource for gathering. And the track is circular so the “mine carts” on it will automatically come and go in loops.

Encountered some enemy defenses. Unfortunately no weapon is installed so I am just taking damage.

Notice the enemy prism block can hide in the wall of cubes or extended out to attack. This is done by using a piston block.

When set in automatic mode, this block can extend to allow other blocks to fulfill their wish.(In this case, the prism attacking target). Otherwise it will be retracted hiding inside for safety.

My debug bomber has arrived and taken them out.

Compared to aircraft, train is more suited for heavy (industrial) use. They move relatively slow and it would be a huge disadvantage against some sneaky fasting moving drones. Well, unless well defended.

Here I have built one to push heavy materials – a few dozens of cubes to slide on the track. The strong pushing power come from cylinders. If using discs, I would need quite a few of them just to lift up.

So, similarly it is probably a good idea to push some heavy weapons armored with walls of cubes forward.