Timeline System

This time line system resembles me the multiverse event branches. It is essentially a save game system, with the tracking of snapshots at past time points. It also allows branch a new series of time points. Think of at one point in the past you made another choice, then you have 2 time line of events from then on. Here is what it looks like when you try to load game from it. You choose a save point and load. Most of the time the save will not likely be this complicated with quite some branches. And most likely you will end up deleting useless ones. This is just a demonstration.


When combined with auto saving, this is perfect. Because it tracks your history and if you mess up at one point, you can go back and start a new branch from there. No need to worry about autosave overwriting the previous ones.

When saving, the system can suggest the default save point to be appended. You can also choose your own if you desire. If you try to save to a slot that is not the history of the current game session, it will be treated as overwrite, like that last slot below.


Notice the 2 similar slots in this image, the second one is a clone. You will only want to clone rarely, or clone from an autosave because it creates duplicated history and may confuse you. If you don’t like this kind of saving system, there is the Traditional Mode, which is just like common load/save as you see in other games.

This was yet another backlog in the development system. Cleared.

Everything Is Connected: The Crazy Serialization

Saving and loading the game is a fundamental feature in many video games. This saving process is a form of serialization, converting game states to a byte sequence that can be stored/transmitted.

In the case of a chess game, it can be quite simple: the chessboard, a plain surface to be saved. In some first person shooters the positions of players and NPCs are stored, perhaps with some extra level progression information. But in a strategy/simulation game, the information that need to be stored can be more complex. Such as in Roller Coaster Tycoon, there are many peeps in the park, all having different behavior and short term goals. And these goals are connected with other objects in the game, such as a ride, or the restroom when they need to go somewhere. The laboratory system had a similar challenge because everything is connected.


This is a visualization of a save for a simple scenario with 3 ground structures, which are just towers. The icons mean the objects in the game. And the lines are the connections. The items in the 3 gray area are approximately the items that make the 3 towers.


When parts stick together they will have connections to each other. Lets take a look at the smaller example shown above. A cube block has a port on each of its 6 faces. These ports connect to the ports on other parts. That is how parts build on other parts works. You can see many “BlockPort” surrounding the cube icons and connecting to each other. All together, the entire structure is considered a unit, which can follow commands the player gave based on its capabilities. Despite a ground tower can not move, one command is like move to a position, called a waypoint in the game system. As you can see the UnitObject and the WaypointNode on the left.

The software system rebuild these connections when loading a saved game. It does so by mapping old pointer addresess to new pointer addresses. And mostly due to the usage of objects from external libraries, the pointer resolution is a multistep process. I am not going to get into too much tech details about that. But it need to be reliable, because an unresolved pointer is invalid and will make the game crash.


In addition to the connections, each of these nodes has its own data. The number below the name means the size of the data in bytes. Think of parts have their health points, positions etc that need to be stored. Different types of items store different things, and can have vastly different sizes. A GridPlane consists of the grids on a buildable surface. It has information for each individual cell.

Here is another challenge. There are 100-200 different types of things and I need to write code to handle each one. And each one may have 10-100 different attributes(data member). Unfortunately, in c++ you do not have reflection information to do this automatically. So I wrote code to handle them all.  Here is the loading/saving code for a debris in the game:

void BlockDebris::deserialize(Deserializer* des, ObjectDataStorage* data)
void BlockDebris::serialize(Serializer* ser, ObjectDataStorage* data)

Just to give a simplified example. 2 operations, serialize and deserialize. 4 attributes in a BlockDebris. Occasionally I make mistakes. If I accidentally missed one attribute, some issues arise. This is what it looks like if I forgot to load the position. Things collapse to the origin point.


To make this easier, I wrote a meta data class to store meta data about these attributes, and select appropriate read/write routine at compile time using meta programming. How this class works is a different story. But the purpose of this is to merge the 2 repeated workflow to one. Then I will not accidentally miss one in one of operations. This meta data is stored by type, so no memory overhead on class instances.

const ClassDataFieldGroup BlockDebris::MetaData =
	MD_FIELD(BlockDebris, m_mass),
	MD_FIELD(BlockDebris, m_lifeTime),
	MD_FIELD(BlockDebris, m_level),
	MD_FIELD(BlockDebris, m_position)
usage: MetaData.ReadAll(this, data);

If things are not going well, I may take a step further by generating this list automatically using a tool. But that will need some extra work writing the tool and tagging data members in c++ headers.

This serialization challenge has been a backlog item for quite a while. Now it has been finally worked out. At this point there is no tricky features anymore, so gameplay development will be smoother next.

New Interface Set

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.

Structure Raytracing Analyzer, (side) Color Equality

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.


Invention Database


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).