This blog will cover the basics of serialization and the three most common methods of serialization in Unity: JSON, XML and Binary.

Serialization is the process of converting an object into a form that can stored or transported easily. 
Objects are instances of classes and they are converted to a stream of bytes. This stream can then be stored as a file, saved onto a database or sent over internet to a web service.
The reverse of this process, converting a stream which can be a file or a string into an object is called deserialization.

​It's easier to understand it using a simple example. In this example, the player details need to be saved, so that when the players replays the game, the details are already available to them. They don't need to provide it on every game session.

When the player inputs his details into PlayerData object the state of the object is serialized and stored as a file. In the next play session the saved file is deserialized  to recreate or clone the same state of our object. JSON and XML are two common standard serialization formats and both of them are shown in the image below. These standards have their own pros and cons and will be discussed later.

Serialization is used extensively by the unity game engine itself for things like saving data of MonoBehaviours and scriptable objects, editor scripting, prefabs, instantiation, saving and loading your scenes etc. This post will only focus on the use of serialization that you may encounter in a game.

• Saving Game Data

          Saving game related data like save files, entities data and game settings

• Web Based Services

          Using web based services like leaderboards, social features, facebook, twitter or google APIs

• Separation of Data from Code​

          Data can be separated from logic and it's easier for the designers to edit data files

• Creating Levels​

          Level Layouts, worlds and game scenarios can be saved in a compact form

• Modding​

          It is easier for modders to edit game entities or even add new entities or gameplay to your game

JSON is the most preferred data exchange format for the internet. Web browsers and servers continuously use JSON to communicat between each other.

• JSON stands for JavaScript Object Notation
• Syntax for storing and exchanging data
• JSON is text
• Language independent
• Lightweight data interchange format
• Human readable and easy to understand

JSON Serialization and Deserialization
​

​
JSON Output
​

​

XML Serialization and Deserialization
​

XML Output
​

​

​Binary serialization converts and object into a binary format, which is a byte stream.

• Serialization operation is faster
• The data file generated is compact and smaller is size when compared to JSON or XML
• The data file is Non Human readable
• Platform dependent, only works on .Net platform

Binary Serialization and Deserialization
​

​This blog post covers how emergent gaming tools and technologies have been used to make high-fidelity defence simulation, including LVC (Live, Virtual and Constructive) simulation which is the way ahead for most military simulators.
 
The LVC Simulation was done atop a high-fidelity terrain reconstruction which was mapped in-house via a Drone operation. The high-fidelity, one-to-one scale terrain already had about 30times the resolution available from Google earth, and was then made interactive and compliant with an LVC Simulation architecture where troops and tanks could train simultaneously. The concept was successfully demonstrated and highly appreciated, as part of CII & Indian Army’s Seminar on Simulation, conducted by the Army Design Bureau.
 
This is part 2 and concluding post on the entire exercise, and part 1 covers the aerial mapping of the terrain via a drone here. 

The attached graphic illustrates the entire pipeline of constructing the high-fidelity terrain for the simulation exercise. Major parts are further explained below.

The image below, shows the synthetic terrain (virtual) constructed via the above pipeline.

​LVC stands for Live, Virtual and Constructive Training.

• In Live training – real humans operate real systems. In Virtual training, real humans operate virtual systems, and in constructive, virtual operators drive virtual systems as almost complete AI. The mix-and match gives us the LVC system.
• Live training, is off course the best training for realism, but many scenarios, for example nuclear, chemical and biological warfare can’t be practiced live, and hence need to be simulated.  Live training is also costly, and has inherent risks to life and property in a military environment. Virtual training overcomes these aspects but can often lack proper realism. Finally, Constructive training is almost completely AI driven – where based on rules, the entities and needs to interface with live and virtual.
  • LVC training architecture thus requires various systems to be able integrate with each other and Compose and Operate together.

This is the major problem - This is a major problem as right now, how do various systems – say a human and a tank, operate together, especially when one may be live, and the other virtual, located hundreds of kilometres apart ? And that too in a cost-effective manner ? ​
 
This is where the rapidly transforming gaming technology comes in handy.

​This completes all the hooks, which are needed to interface between live and virtual participants, and can then operate jointly over a mapped terrain, with the game engine acting as the glue which holds everything together. The below diagram illustrates the interfaces. 

​An ounce of practice, is worth a ton in theory, and thus the above proposed scheme needed to be put to test, so we got on with it. A proposed setup was made, where geographically distributed participants from different systems could engage in a joint networked exercise. Here is how one such activity unfolded. 

​The above mentioned exercise was prepared and demonstrated live, at SEMSIM 2015, a joint symposium by Indian Army and CII, organised by the Army Design Bureau. Two participants, one hosting the networked synthetic environment drove the tank via a PC, where as a mockup of a ATGM, once again networked via a kit participated with the join exercise and was again able to ambush the tank. A detailed paper on the entire exercise, and as an extract from the SEMSIM compendium, is attached alongside for download. ​

On the whole, the entire exercise demonstrated that existing gaming tools and technologies, and the rapidly evolving mediums of AR and VR, are able to deliver the LVC training as required.

​The technology demonstrator proved the live, virtual and the constructive elements were able to perform as per their objectives, and most importantly, able to co-operate over a synthetic terrain. 

This is a two part blog post. Part 1 talks about the background to the entire exercise, the Part 2 talks about the simulation exercise which was built on top of the entire Drone Op generated data.
 
The background to this entire operation were our simulation activities that we were doing for Defence. Our past experience had mostly been with the Indian Air Force, and recently had also done some aviation simulation works for the Indian Navy. However when we demonstrated the same to the Army, the feedback given was ‘Well, all this simulation, terrain recreation etc is fine for aircrafts flying thousands of feet above the ground, but we need something which can give a soldier a feeling of if he has the boots on the ground’. This needed a very highly accurate ground mapping which required two elements – a digital elevation map (known as DEM) and ground texture.
 
Now DEMs were available, but those in the public domain had extremely low resolutions, only suited for very high-altitude passes, like those available from NASA and Japan Space Systems. Higher resolution DEM imagery is either available only to military (including ISRO’s own DEM data – but we didn’t have access to that), or very expensive to buy for commercial use.
 
Google earth (including Pro) pack – while allowed you to export imagery, it didn’t allow you to export the elevation, and even imagery had to be stamped with Google earth’s logo. And the resolution wasn’t good that we wanted anyway.  
 
The target that had been give to us for the textures resolution was – 10 cm per pixel. A massively ambitious target. But audacious goals only embolden us to achieve them. We decided, we’d get our DEM via an aerial survey.
 

In order to do an aerial DEM, we obviously needed an unmanned aerial system (UAS), or commonly known as – Drone. There were many choices and factors

1. Fixed wing (like your typical aircraft configuration) or Rotory
2. Within rotory – tricopter/quadcopter/hexacopter/octacopter
3. Choice of frame – plastic, carbon fibre etc.
4. Choice of motors and propellers, and electronic speed drives to run them.
5. Choice of controller – This was a major choice, with top two contenders being DJI vs APM (Ardupilot). This is like a choice between Apple (proprietary, closed system) vs Android (open source system)
6. Payload – which cameras to take, including whether to use gimbals for stabilization or not.
7. Final processing – after the data has been captured, how to process it and convert it into useful format ? 

Just about when we were considering the above and buying the relevant parts – an important decision was where to actually execute the exercise. We were located in New Delhi, but flying a drone within Delhi was a serious no go – there had been reports of sighting rogue drones in news, including at the airport, and in such a charged atmosphere, we didn’t want to get a system airborne in and around Delhi. So we decided to head out, and choose a location which

1. More matched the typical terrain where army may actually have to maneuver, including with troops and armor.
2. A location which had far less security sensitivity, or where we at least knew the locals including the administration.
3. A location which could be positively identified both on ground, in maps, and in Goggle earth.

And we knew one such exact location – the meteorological laboratory in the middle of agricultural fields typical of the northwestern plains, in the city of Hisar – which also had an army cantonment with tanks units plenty. 
 
So we loaded our car with equipment, drone supplies, electronics elements, our PCs, and off we were, to see what we could come up with. ​

Now that we knew our systems parameters well, and with help from basic trigonometry, we were able to arrive on an optimized solution which ensured that we could cover the 50+ acres within our endurance flying time of 15 minutes. So the next morning was decided to be D-Day, and batteries were left to charge. ​

Having programmed the path along the GPS coordinates, with final testing of the UAV, gimbal and camera, batteries etc, all systems were go at the next morning and the mission was put into practice. The UAV took off beautifully, rose to the programmed height, oriented itself and started the scan. We were all positioned at the extreme corners of the 400m x 500m observing the UAV carry out its mission. It all seemed to be going as per plan.  However, the winds started picking up. The UAV had to move across the ground at about 20km/hour to cover the required area in the stipulated time (and the camera was also programmed to take pictures at a fixed frequency) so that image-to-image distance was within the ‘overlap-parameters’.  

We’d carried enough spares with us including alternate platforms to get back on the job. So we took the parts which were functioning, and assembled them on a new frame to have a new working APM drone, and also parallelly assembled a DJI one. Our house turned into a drone repair and maintenance depot, with all types of mechanical and electronic spares related to drone lying around. 

DJI’s phantom drone is the easiest available commercial drone – and you can see the same being flown even in weddings. When we were shopping for parts – we happened to open a DJI and look inside – and it seemed like a bad job of engineering, including cables running without order and poorly assembled. We instead decided to keep our own frame, motors etc, and go for DJI control boards – known as the Naza. However, the Naza wouldn’t fly by GPS coordinates (only manually), so we had to invest in some more upgrades – notably the Bluetooth control module - one end connected at the drone and the other connected with either the PC or an iOS device, with which you could control it via a DJI app.
 
While by now we had enough experience building/breaking/maintaining a drone – the DJI proved itself quite challenging when it came for the telemetry to work. The radio modules wouldn’t just pair with each other – they had some very complex sequence of starting up which wasn’t explained very well in manuals, and after searching through numerous online forums, and by one all-nighter from Joshua – did we end up getting the remote telephony and telemetry work – but after that, we could fly the DJI powered drone with our iPad.

Meanwhile, the APM was also refurbished, and was up and running – so it was back to the meteorological center, where once again, the drones took to the air. ​

We are able to perceive depth because of our two eyes (called stereo vision). Similarly, DEM data is generated by satellites by having sensors looking at earth separated by a long boom, and the parallax between the two sensors is what gives the perception of depth. In our case, while we didn’t have stereo cameras – we did have image of the ground from multiple angles, and for each shot (after syncing the clock of camera and the drone), for each image we also had its exact position and orientation in space. Between the three drones, and multiple passes at the target area – by now we had enough imagery, and drone fly pass data, that we could now put it into post-processing.

​Now to do this entire data-processing, the options including commercial software as well as open-source. While open-source softwares  were a feasibility, we decided to test a proprietary software called Pix4D, which offered a trial version of two licenses. One license was used on a laptop at the field to quick test the data, and the other license was used at our amazingly powerful PC called Janus – which had a server level motherboard, with two Xeon processors each with 6 cores, and a 512 core GPU (Pix4D can harness parallel processing power of CUDA compatible GPUS).  Such massive computation power is needed for complex vision processing requirements like stitching such large number of images, and generating point cloud data in 3D.

Here are the results of the ortho-mosaic (stitched image data) overlaid on top of Google Maps and compared. You can see vivid details of the buildings, the marks of the furrows, and even the surf in the freshly irrigated field.  

And here is the point-cloud data - which is 3D reconstruction of the scene. You can easily establish the features of the terrain - the depth of the ditch, the height of the trees - even the measurement of the car parked there. 

On the whole – it was mission successful ! Thanks to the enduring efforts of the duo of Joshua and Karan. ​

While the entire operation was a huge learning exercise, here are a few things which we’d do differently the next time:

1. We’d use a flying wing – the huge surface area gives good lift, so the motors and propeller are working to keep the UAV flying through air than working against gravity. Thus, we can get a far higher endurance for the same battery.
2. No need to use a gimbal – since the flying wing mostly flies parallel to the ground (without tilting the was a quadcopter does), we don’t need secondary stabilization on the camera. In any case, the flight data has the ‘orientation’ of the camera, something which is taken care in post-processing.
3. Very importantly – we’d use Pixhawk. This is advanced version of the APM and is much more stable and fool-proof, and has more features (one of which will be an airspeed sensor).
4. We’d use a camera of even higher resolution – thus allowing us to go higher, cover more area, reduce our needed offset between the combing runs, and further increase the area that can be covered in a flying run.
5. And we’d time our run and finish it before the winds pick up (ideally, as early in the morning as possible)
6. Can even consider going for a drone that is officially endorsed by Pix4D – to get a joint proven package (but is costly). 

Saving and retrieving data is something that every Unity Developer has to struggle with at some point of time. By the nature of how Unity and how computers work, most of your data change is volatile. Even changes made in Editor Play mode are not permanent.
We need to save data in order to track progress and record important values, which are critical to the gameplay.
Data is lost between scenes because on every scene load Unity will destroy previous scene’s game objects, except when it’s explicitly specified. This in turn leads to destruction of MonoBehaviours and thus the data.
Data is lost between gameplay sessions because the memory allocated on RAM for a Unity application at run time is freed up by the OS when application is closed.
So the problem of saving and retrieving data can be broadly classified into two categories

• Saving data between Scenes
• Saving data between gameplay sessions

There are a number of ways of tackling each of these problems, some solutions are listed below:
Scene to Scene

• Static class
• Singleton pattern
• Scriptable Object

Gameplay Session to Session

• Player Prefs
• Serialization to file
• Database
• Online

In part 1 of this article, methods of achieving data persistence between scenes will be discussed in details. Code snippets will also be provided when required.
In part 2, methods of saving data permanently will be discussed.

Static classes have number of special properties:

• Can’t extend MonoBehaviour
• Can’t be attached to game objects
• Can’t be Instantiated
• All members must be static
• Private constructor

They are mainly used as classes holding helper functions like System.Math class.
Since they are not attached to a game object they are safe from scene cleanup (deletion of every game object at scene load). They also have a global access. These make them suitable as data holders. Accessing data stored in static classes is very easy.
Since static classes can’t extend MonoBehaviour, they have a few downsides

• Can’t utilize MonoBehaviour functions like Start (), Update () etc.
• Can’t inspect stored data in Unity Inspector

​It is a popular design pattern with widespread use in game development. The main criteria of a singleton class are:

• Only single instance
• Global point of access

These features make it a good candidate for use as scene wide managers.
Singleton is basically a unique static instance of a class. Due to a global point of access no reference is needed for saving or retrieving data, this makes them very convenient to use.
One of the methods of implementation of singleton pattern is provided below.

Scriptable Object is a class that lets you create objects that don’t need to be attached to a game object. Their primarily used as data containers. As data containers they are extremely helpful in using the programming principle of “Separation of data and code”. Numerous benefits of this principle include safety of source code, ease of editing, scaling and maintenance.
Scriptable objects create data container assets. These assets are what hold data. Since these are assets, they are immune to scene cleanup and they also preserver their values during a scene load.
The only downside of scriptable objects is that they don’t have a global point of access. However in conjugation of either singleton pattern or static classes, it is possible to use scriptable objects for cross scene data holder which also have global access.

Guardians of the Skies, the official game of the Indian Air Force was launched about two years ago, and has gone on to be downloaded more than 3 million times, and won a couple of awards. Here is looking back at its story, which not only captures how it came into being and what went behind the scenes, but also a brief 'coming-of-age' of the small team which made it. 

You can get the game for Android, iOS and Windows. 

​Games are supposed to be an escape from the reality, in a world of dreams. Where we can be what we wanted to be before we got caught up in the daily grind. 

As the first few of us got together in early 2013, we had limited experience in even basic 3D modeling, forget about making a full fledged game with all its programming challenges. We didn't even have an office, and weren't even located in the same cities. We anyway decided to learn things as we go along, and started with some smaller projects initially. 

Everything was made in Blender - an open source 3D software. Blender's new GPU based rendering engine - Cycles was put to test by purchasing a second hand cycles compatible GPU installed in an old PC. Many shots were left to render overnight. The entire effort took about a month, and was released on 28th May 2013, the anniversary of the attack.

The short was received very favorably, gathering about 100,000 views quickly, and we got great feedback from audience, and comments from veterans as well - and we decided to now combine 3D modeling with programming - and create an interactive game, where you not only see the story, but get to live it. ​

2. Operation Morning Glory
By now we had sort of an office, a makeshift place, where for furniture we had few chairs, beanbags and a table, which also doubled up for meals during lunch. We had walls with newspaper stuck with tapes, so that we can put post-it notes on top as we generated ideas. Operation Morning glory was conceived during a meeting held over a mattress, where Sameer elaborated the concept and Bharat and Anurag digested with some samosas. 

We got good feedback, and requests for a mobile game, so we decided to do a mobile port. The game proved quite demandeing on performance and was barely playable. We spent about another month tweaking the inputs, and optimizing the graphics, and finally made it playable on mobile.
We decided to just release it for android, and see what we could learn out of it. With no marketing budget, the game on its own, pulled about 100,000 downlaods quickly. We realized we were on to something now. You can get the game here: Operation Morning Glory. ​

Once the contract was awarded, after that it was literally lying taking off in a jet. The throttle was opened full blast, and it was not held back for the next 9 months till which the production lasted. 
By now the team had expanded to include more members, and immediately, the lead developers/designers became 'Centurions' - those who were putting in more than 100 hours a week - i.e, 7 days a week, 14 hours a day, notably Bharat, Joshua and Anurag. 

Learning to fly
While Sameer off course was a veteran of the IAF, and Anurag knew how to fly as well, the lead designer - Bharat had never flown, and he was in charge of designing the entire look and feel of the game, so it was important that he got a perspective from the air. So he was made to sit in a cockpit, and bounced around till he had enough. When he got out, he’d never appeared happier to have his feet planted firmly on the ground !

​And in the HUD, there had to be a lot of controls and information, similar to what a pilot might be seeing, but it should not clutter the scene and not come in the in the way of the player. This was additionally compounded by the accuracy of flight controls – since the game was being made for a person who might have never flown before, yet the game was being testing for accuracy by fighter pilots who always demanded more and more accuracy of the flight envelope. It was a tight rope walk where flight controls were kept as a good balance between approachability and accuracy. 

Optimizations
​An added level of optimization which was required was keeping the target hardware in mind. The game was aimed at an Indian Audience, who had a budget phone and was vary of large download sizes as well. So that game had to be rich in graphics, without being heavy on download size or RAM and CPU consumption. A lot of optimization techniques were used, like

• LODs
• Occlusion culling
• Texture atlassing etc

And resultantly, the game was able to packaged around 60 mb, while a comparable game at that time – Storm Raiders, was around 800mb. 

​The workhorse of the entire production was Unity3D, here is a brief peek under-the-hood. 

Multiplayer version
At that time, in Unity3d the support for multiplayer gaming was very limited and the game required a multiplayer mode which could be played on the local wifi without needed an external game lobby server. For this, a local multiplayer protocol had to be implemented, where one player created a game and the game broadcasted over a specific port its IP address, which another game over the same wifi network could find at attach to – a totally custom implementation.  

​After a production run of about 9 months, where majority of learning was gathered by the team on the go, the game was finally ready to be released. The game was scheduled to release in December 2014, and was released by the Chief of the Air Staff – Air Marshall Arup Raha at IAF auditorium. 

​The game has been received very well. It quickly rose to the top of charts, accumulating downloads. The first store where it crossed million downloads was the Windows App store. Android came next. To date, it has been  downloaded more than 3 million times, with an average rating of about 4.3 on various app stores. Typically, games from the Scandinavian countries were featured in Indian Stores, now it was an Indian game getting featured in the Scandinavian and other app store across the world, including ahead of the games released by Disney, which had been a competitor in the IAF game’s bid. 

​The user feedback was overwhelming. Some of the most rewarding feedback points where when people talked about how they felt like a real IAF pilot flying jets for their country, or how the game became a bonding point between a father and a son, or how someone who had once been a game but left, was brought back to gaming by this game. 

Few of the several awards the game went on to win have been

• Best mobile application (game) in 2014 from Microsoft India.
• Features and trended as the top ‘Make-in-India’ category game on Android by Google India
• Awarded by Unity3D and Microsoft ID@Xbox 

​Why we make games ? In our case, as a tribute to the Indian Armed forces.
​Shortly after the game was released, the Indian forces launched a successful extradition of citizens stuck in the war zone in Yemen, coming to the aid of not only Indians nationals, but from other countries as well, for which they were justifiably applauded as heroes.
​Our games, are but a small acknowledgement and appreciation of our forces from a grateful citizenry.   

Dear Readers,

The official game of the Indian Air force - Guardians of the Skies, since its first release in July 2014, has gone on to achieve a total of more than 2 million downloads across various platforms, it has been featured on app stores across the world, and also won awards under Best-app and Best-game categories. 

We'd like to express our kind gratitude to all the patrons who've downloaded and played the game, and for those who wish to paint the sky with the Tricolour on the event of India's Independence Day on 15 August 2015, a special limited version of Guardians of the Skies has been uploaded on the Google Play Store with the mighty Su30 of the Indian Air Force in the Indian Tricolour Livery.

https://play.google.com/store/apps/details?id=com.threye.iaf.gots&hl=en

We hope that Guardians of the Skies has helped you feel the pride and the thrill of flying for the Indian Air Force, and hope that you continue to aspire to touch the sky with glory, and to help you keep close to that aspiration, are attached a few wallpapers to grace your screens.

Yours truly,
Team Threye.