Chapter 222: The Game
16 May 1976 — ISMC Division; Gorakhpur Industrial Complex, Uttar Pradesh
The memo had arrived on Aditya's desk eleven days after the Star Wars premiere.
Not a formal memo. Karan did not write formal memos to his brother — there was no salutation, no reference number, no carefully worded bureaucratic preamble. It was a single page in Karan's handwriting, the spare, compressed handwriting he used only when he was absolutely sure of something, when the processing had already been done and what was left was only the recording of a conclusion.
The page said:
The Siddharth sells because it is useful. A typist uses it. An accountant uses it. An engineer uses it. The government uses it. We have sold 23,400 units in sixteen months. We will sell another 40,000 in the next eighteen months if nothing changes.
But the Siddharth only sells to people who already know they need a computer. The people who don't know they need a computer don't buy it because they don't know it exists for them.
There is a way to change this.
Games.
Not entertainment. Strategy. A child who plays on a Siddharth becomes an adult who cannot imagine working without one. A family that has a Siddharth for games has a Siddharth forever. A school that has a Siddharth for educational games has justified the purchase to every parent. An office that has a Siddharth for work discovers that the staff use it for Solitaire at lunch and want it at home.
We are not making games to sell games. We are making games to make the Siddharth indispensable to people who don't yet know they need it.
Separate company. Shergill Game Studio. Same building, different name, different mandate.
I want fifteen games ready for the Dussehra sale season. Six months. The best programmers from the ISMC software division. The brief is below.
The brief below was four pages, handwritten, describing fifteen specific games with specific design principles, specific technical requirements for the Siddharth-2's 3-micron architecture, and a specific philosophy about what each game was supposed to do to the person playing it.
Aditya read it twice.
Then he read it a third time.
Then he called Karan's Lucknow office.
"When did you write this?" Aditya said.
"The night after the Star Wars premiere."
Aditya was quiet for a moment. He looked at the memo again. The handwriting was clean. Not the handwriting of a man who had been up until three in the morning in an emotional rush. The handwriting of a man who had thought something through with great care and then written it down very precisely. "You watched Star Wars and came home and wrote a gaming company brief."
"I came home and understood something."
"Which was."
"That people will sit completely still for three hours," Karan said, "watching something happen on a screen. Not because they have to. Because they want to be inside what's on the screen. Because it becomes more real to them than the room they're sitting in." A pause. "The cinema screen. The television screen. The computer screen. They're all the same thing. Once you've made someone want to be inside a screen, the screen has won."
Aditya tapped the memo with his finger. "And games."
"Games go further than cinema. In a film you watch someone else make choices. In a game, you make the choices. You fail. You try again. The screen doesn't just take you in — it learns how you think and shows you back to yourself." Karan paused. "I want to be inside every middle-class home in India by 1980. The question I couldn't answer was: why would a family that doesn't need a computer buy a computer? Now I have the answer."
"Games," Aditya said again.
"Not games as entertainment. Games as the reason the machine exists for them. The machine becomes their children's classroom and their evening's entertainment and the thing the father uses on Saturday because the carrom programme is better than any carrom partner he can find at eleven at night." A short silence. "The machine becomes a member of the household. You don't throw out a member of the household."
Aditya set the memo down. He picked up the four-page brief. "You've named the company."
"The name was obvious."
"You've designed the controller." He was looking at the last page — Karan's engineering sketches, competent and precise, the kind he drew when he was describing something that needed to be built rather than persuaded into existence. A handheld device. Two thumb positions. Four face buttons on the right. A directional pad on the left. A cable connecting to the Siddharth's input port. "Nobody has built this."
"Nobody has needed to," Karan said. "The keyboard is wrong for games. It requires you to look at it. It requires two hands in the wrong orientation. You need something you hold — both thumbs doing something simultaneously, without looking down."
"I'm looking at your sketch," Aditya said. "The directional pad on the left."
"Four directions. Up, down, left, right. Diagonals inferred from two simultaneous inputs."
"The face buttons on the right."
"Four. A, B, C, D. The game assigns meaning. One game uses A for jump. Another uses A for fire. The button doesn't mean anything. The game gives it meaning."
Aditya was quiet. He looked at the sketch for a moment longer. "It's elegant," he said.
"It's obvious," Karan said. "All good designs are obvious after the fact."
"The software team." Aditya turned back to the first page of the brief. "You've listed six names. Vikram Nair."
"He wrote the OS kernel for the Siddharth-2. The best systems programmer in the division. He's the engine."
"Rajan Pillai."
"Graphics rendering library. The display work on the Siddharth-2 — the things the display controller wasn't supposed to do but does because Rajan found the gaps. You've seen what the Siddharth-2 can produce on screen. That's Rajan."
"Sunita Krishnaswami." Aditya paused. "She wrote the Siddharth-1 kernel, yes? Not the Siddharth-2."
"She wrote the Siddharth-1 kernel. Every kernel decision Vikram made on the Siddharth-2 started with a conversation with Sunita. She also wrote the audio driver for the Siddharth-2 — the sound on these games is as important as the visuals. Maybe more important. Sunita is the reason the machine sounds like anything at all rather than beeps."
Aditya wrote this down. "Deepak Sharma."
"Input systems. He's the one who'll make the controller work — the software layer between the physical device and the game. He thinks about the edges of systems the way other people think about the centers."
"Ravi Menon."
"Game logic. He's been building small games on the Siddharth hardware for six months on his own time. Nobody told him to. He just couldn't stop. He's the one who already knows what this work is."
"And Pradeep Srivastava."
"He studied mathematics education before he came to us. He understands how people learn through doing rather than being told. The educational games need him."
Aditya set the brief down. He stared at the ceiling for a moment. "Six programmers. Fifteen games. Five months."
"The platform first," Karan said. "Vikram builds the engine. Everything else runs on it. Then Rajan's graphics layer. Sunita's audio. Deepak's input. The individual games are built by Menon and Srivastava and whoever else they need from within the team. The mistake would be six people each trying to build everything. You build the common infrastructure once. You build the specific outputs as many times as you need."
"Like a factory."
"Like every factory we've ever built," Karan said. "The same principle. One jig, many parts."
Aditya wrote: Siddharth Computer Club — Dussehra package at the top of a fresh page in his ledger.
"October 22nd," he said.
"October 22nd."
"And the price."
"The games add two hundred rupees to the package. The controller adds one hundred and twenty. Total consumer package — computer, monitor, keyboard, controller, fifteen games — twenty-two hundred rupees."
Aditya did the arithmetic. "You're taking margin out of the package."
"I'm buying market share," Karan said. "The margin is irrelevant on the first sale. What matters is what happens to the family after they have the machine in their house. Everything they buy after that — the next model, the software, the second controller, the games we release in 1977 — that's where the return is."
"You're pricing it like a loss leader."
"I'm pricing it like a man who understands that the value is in the relationship, not the transaction." A brief silence. "A Siddharth in every middle-class home by 1980. That's the objective. Everything else follows from that."
"Set up the team meeting," Aditya said. "I'll arrange it for when you're in Gorakhpur for the infrastructure review."
"May 16th," Karan said. "Brief them then. And Aditya—"
"Yes."
"Don't tell them what the meeting is about beforehand. Let the reveal be the reveal."
Aditya smiled to himself. "You enjoy that."
"The first thirty seconds when someone understands something they didn't understand before," Karan said. "Yes. I do."
He put down the phone and looked at the brief for a long moment.
Then he thought about what it meant that the Chief Minister of Uttar Pradesh — twelve days after attending the global premiere of the most technically sophisticated Indian film ever made — had sat down at midnight and written four pages on a video game company.
He opened his ledger.
He began the financial architecture.
The Team
16 May 1976, 9:00 AM — ISMC Division Conference Room, Building Four
The six programmers sat around the table in the manner of people who had been summoned without explanation — which is to say, with notebooks open and professional composure and the particular alertness of individuals whose work involved precision and who therefore applied precision to the anticipation of the unknown.
Vikram Nair was the oldest — thirty-four, from Kerala, the kind of engineer whose presence in a codebase was felt more than seen, whose work formed the invisible foundations beneath everything the division shipped. He had written the OS kernel for the Siddharth-2. Before that, he'd spent two years working alongside Sunita Krishnaswami on the Siddharth-1 kernel, which had been his education in how to build something that would outlast the hardware it ran on. He was lean, wore glasses with thick lenses he'd never gotten around to updating, and had the specific impatience of someone waiting for a conversation to become precise enough to be worth having.
Rajan Pillai was thirty-one, from Trivandrum — the reason the Siddharth-2's display did what it did, which was considerably more than the display controller manufacturer had intended. He had large hands, which seemed like the wrong attribute for a man whose work involved pixel-level precision, but his sketches were always exactly right, the proportions instinctive, the sense of how something should look on a screen arriving before the calculations that justified it. He drummed his fingers on the table when he was processing. He appeared to be unaware of this habit.
Sunita Krishnaswami was twenty-eight, from Madurai. She had written the Siddharth-1's kernel — the version Vikram had learned from, the architecture that he'd built the Siddharth-2's kernel upon, improving and diverging and occasionally going back to her original decisions and realizing they had been correct in ways he hadn't initially understood. When the Siddharth-2 launched, she had moved into audio — the sound driver, the audio chip's capabilities stretched past their documented limits because she had spent three weeks understanding how the chip's internal state machine could be addressed in sequences that produced frequencies and timbres the chip's engineers had not intended. She was the only woman in the room. She had not brought a notebook because she didn't take notes the way other people did. She listened and recorded somewhere that was not paper, and later produced what she'd heard in complete and accurate form.
Deepak Sharma was twenty-seven, from Allahabad — quiet in a way that was not shyness but concentration, a man whose professional life was lived at the edges of systems, the places where the physical became digital, where a pressed key became an instruction, where the gap between hardware and software was either a problem or an opportunity depending on how carefully you looked. He was the one who had built the Siddharth-2's keyboard driver, the port communication stack, the entire input layer, and he had done it without anyone asking him to make it good, only asking him to make it work, and he had made it good anyway because he couldn't see the difference between the two.
Ravi Menon was thirty, from Ernakulam. He was the only person in the room who had been waiting for this meeting specifically — not because he knew what it was, but because he had been doing something privately for six months that was, in retrospect, exactly the thing that this meeting was going to be about. He had been building games. Not as an official project. Not with anyone's permission. Just — quietly, after hours, on the Siddharth hardware in the testing room on the third floor, because game logic was the most interesting programming problem he had ever encountered and he could not stop thinking about it.
Pradeep Srivastava was twenty-six, from Lucknow. He had a mathematics education degree that he had stopped halfway through to pursue computer science, which meant he thought about learning differently from the other five — he thought about the gap between knowing something and being able to use it, about the specific friction points where people got stuck, about the difference between information delivered and knowledge actually acquired. He was the youngest in the room and looked it, but he'd spent three years of those twenty-six years thinking about things none of the others had considered.
Karan came in at nine exactly.
He sat down, looked at the six of them without preamble, and said: "You're building a game studio."
A silence.
Then Ravi Menon said: "Oh thank god."
Everyone looked at him.
He held his hands up slightly. "I've been building games on the Siddharth for six months. In the third-floor testing room. After hours. I kept thinking someone was going to come in and ask me what I was doing and I kept not having a good answer ready."
"Was it bothering you?" Karan said.
"A bit, yes."
Karan looked at him with something that might have been amusement. "What have you built?"
Menon reached into his bag and produced a collection of paper tapes — the Siddharth-2 still used paper tape for programme distribution, each tape rolled carefully and labeled in his handwriting. He set them on the table. "Chess. Three difficulty levels. A falling-block puzzle — I genuinely cannot stop playing it, which I think means it's working. And the beginning of a cricket simulation that I abandoned because the bowling model is harder than I expected."
"Show me the chess programme first."
Menon loaded the chess tape into the Siddharth-2 on the conference room's side table.
The machine took about twelve seconds to read the tape. Then the screen came alive.
The Siddharth-2's screen was a twelve-inch CRT, monochrome, capable of 256x192 pixels at the division's custom display mode. Not high resolution by any standard that would matter in ten years. But it was a screen attached to a computer that was in people's offices and homes, and what appeared on it was what the programmer put there.
What appeared was a chessboard.
A clean, properly proportioned chessboard, with pieces drawn in the monochrome pixel art of someone who had spent two weeks figuring out how to make small arrangements of pixels look like specific things rather than abstract symbols. The king was recognizably the king — the cross on the crown, the height, the dignity of the piece. The queen had her crown. The pawns were unmistakably pawns, small and regular and numerous.
Sunita Krishnaswami leaned forward slightly.
"The bishop," she said. "The diagonal cut at the top."
"Three pixels," Menon said. "I spent four days on the bishop."
"It reads," she said. "Immediately."
Karan watched the board. "Move it."
Menon demonstrated — arrow keys to move the cursor, Enter to select, arrow keys to destination, Enter to confirm. The pieces moved. The board updated cleanly. The computer's response at the middle difficulty level took about four seconds.
"The calculation," Karan said.
"Minimax tree. Three moves deep on medium. At five moves deep — which is what I want for the hardest difficulty — it takes about twenty-five seconds. Which is too long."
"How do you fix it?"
"Better pruning algorithm. The alpha-beta implementation I have is basic. A proper implementation cuts the calculation time by sixty or seventy percent. The hardest level could run in eight to ten seconds instead of twenty-five."
"How long?"
"Two weeks if that's all I'm doing."
"It's not all you're doing," Karan said. "But it goes in." He nodded at the paper tapes on the table. "The block puzzle."
Menon swapped tapes.
What appeared on the screen had not previously existed in this form. Ravi Menon had invented it on a Tuesday evening in February, sitting in his dormitory room, starting from a question: what would a game look like that had no way to win — only ways to survive longer?
Blocks fell from the top of the screen. They fell in shapes — the shapes a programmer arrived at after two weeks of asking himself which arrangements of four squares created the most interesting spatial problem. The L-shape. The reversed L. The S and the Z. The T. The flat square. The line.
They fell and the player moved them and rotated them and they stacked and more fell and the stack grew toward the top, and the only way to push it back down was to complete a horizontal line with no gaps, at which point the line disappeared and everything above it dropped down.
That was the game.
No story. No final level. No villain. Just the next piece and the next placement and the stack breathing.
Menon had been playing it for six months and had not gotten bored.
The room watched him play. He played at a moderate pace — not showing off, just letting the game show itself. The blocks fell. He rotated and placed. A line completed and vanished. The stack lowered slightly. More blocks fell.
About ninety seconds in, Sunita Krishnaswami said: "Play slower. Slower than you're comfortable playing. I want to watch the stack."
Menon slowed down.
The room watched the stack go up and come down and go up again.
"It breathes," Sunita said. She was narrating an observation, not performing one. "The stack actually breathes."
"The difficulty," Vikram Nair said. He'd been watching with the specific attention he paid to code doing something he hadn't predicted.
"Increases every sixty seconds," Menon said. "The blocks fall faster. After about ten minutes at maximum speed, you're not thinking anymore. You're reacting. The thinking has to happen before the block appears."
Vikram was quiet for a moment. "So you learn to predict the future positions."
"You learn to see four or five blocks ahead," Menon confirmed. "The good players aren't better at placing blocks. They're better at building a board that can accommodate whatever comes next."
"That's not a game about blocks," Karan said.
Everyone looked at him.
"It's a game about managing uncertainty," he said. "You can't control what comes next. You can only control how you've arranged things so that whatever comes next can be handled." A brief pause. "The lesson isn't about blocks."
Menon looked at him for a moment. "I just built it because I couldn't stop playing it."
"The best lessons," Karan said, "are the ones that don't feel like lessons." He looked at the screen. "What are you calling it?"
"Block Fall. Internally. I hadn't given it a proper name."
Karan thought for a moment. "Karo."
"The Hindi word for 'do it,'" Pradeep said.
"It's an instruction," Karan said. "And a state of mind. The game is telling you: do it. Keep going. Place the block. Karo."
Menon wrote it down.
Karan looked at the group.
"I'm going to describe all fifteen games over the next two days," he said. "Then we'll go through the technical architecture. Then we divide the work." He looked at Vikram Nair. "You're building the engine. Everything else — every single game — runs on the engine you build. The engine is the first deliverable. Without it, nothing else can start." He looked at the rest of them in turn. "Two days for me to describe the games. One week for Vikram to define the engine architecture and share it with the group. One month for each of you to have the first working version of your assigned games. Four months of iteration and testing. Fifteen games packaged and ready by September 30th."
He opened the brief in front of him.
"We begin," he said.
The Games, One by One
May 16–17, 1976
Karo was first because half of it already existed and because starting with something real rather than something imagined set a particular tone for the two days — this is not a theoretical exercise, this is a thing that works, and now we are making it better.
Karan's additions: a persistent high-score table written to cassette storage. Three visual themes — pure geometric shapes, a stone wall pattern, and a Rangoli-inspired geometric design for the blocks. An opening screen carrying the Shergill Game Studio logo, which Rajan Pillai would design.
"The sound," Sunita said. She hadn't waited to be asked. "The block landing and the line clearing need to be completely different. The landing is a small percussion hit — I'm thinking mridangam timbre, very abbreviated, just the attack. The line clear is a rising tone. Two notes. The second note resolves up." She paused. "It should feel like relief. Not triumph. Relief."
"Is there music?" Karan said.
"There has to be," she said. "Not background music. Music that accelerates with the game. At the lowest speed you barely notice it. By the fastest levels it's the thing that's driving you."
"What kind?"
She thought about it for a moment. "Bhairav. Fast tempo. It creates urgency without panic — there's a difference. Racing music makes you feel like you're losing control. I want music that makes you feel like you're completely in control, so in control that you want to play faster to match it."
"Build it," Karan said.
The chess programme was called Shatranj — the name of the ancient game from which chess had evolved, a decision that Karan made immediately when Pradeep Srivastava mentioned the etymology.
"The game plays by chess rules," Karan said. "Standard FIDE rules. Five difficulty levels — the easiest that a child of ten can beat on the first try, the hardest that a strong club player will lose to. The difficulty must be consistent. Players need to be able to track their own improvement."
"The interface," Rajan said. "Text pieces or drawn pieces."
"Both. A standard monochrome text board as the default — fast, clean, works on any display. And a second mode with drawn pieces for people who want it. In the drawn mode—" Karan paused. "The pieces should look like Indian carved chess sets. The Rajasthani style. Elephant as rook. Horse as knight. Camel as bishop."
Rajan's pencil was already moving.
"The raja and the mantri," Rajan said. "Instead of king and queen."
"Yes."
"I'll make them look like actual pieces," Rajan said, not looking up. "Not stylized. Like the specific geometry of a turned ivory piece. The lathe marks."
"Can you do that at our resolution?" Vikram asked.
"I don't know yet," Rajan said honestly. "I'll find out."
"The rules," Karan continued. "No exceptions. En passant. Castling. The fifty-move rule at higher difficulty levels. Pawn promotion with a dialogue."
"The promotion dialogue," Deepak Sharma said. "That's an input system question. How does the player choose what to promote to?"
"Arrow keys to cycle through options. Enter to confirm," Karan said. "Simple."
Sharma wrote it down.
"And the computer should show its thinking," Karan said. "Not the calculation — not the tree. But the piece it's considering moving should be highlighted while it thinks. The player sees the machine considering. It's honest. It's also interesting."
"It makes the computer feel like a person," Menon said.
"It makes the computer feel like a worthy opponent," Karan said. "Which is different."
The snake game had been one of the simplest concepts in Karan's brief and had, over the two days of discussion, become something more considered than it had started.
"The snake grows by eating," Pradeep Srivastava said, leaning forward. "What it eats — does it matter what it eats?"
"Fruit," Karan said. "Standard snake game: a piece of fruit appears, the snake eats it, the snake grows, a new fruit appears."
"Can the fruit have value?" Pradeep said. "Different fruits give different amounts of growth?"
"Yes," Karan said immediately. "Lower-value fruit appears more often. High-value fruit appears rarely and disappears quickly if not eaten."
"Risk management," Menon said. "Go for the rare fruit, which means routing the snake into a more dangerous path. Stay with the safe fruit, which means slower growth but longer survival."
"The player is constantly choosing between speed and safety," Karan said. "This is also a teaching."
"You keep saying that," Rajan Pillai said, looking up from his notebook. Not critically. Observationally.
"Because it's true," Karan said. "Every game teaches something to the person playing it. The question is whether the teaching is intentional or accidental."
"And you want it intentional."
"I want it invisible," Karan said. "The person playing doesn't know they're learning anything. They just know the game is interesting. The learning is a side effect. But I am choosing what side effect."
Rajan looked at him for a moment. Then he went back to his sketch of the snake — a pixellated head with actual directional character, a sense of purposefulness in the way the segments followed.
"Three speeds," Karan said. "Slow, medium, fast. The snake starts at a fixed length and grows. The borders are walls — hitting the wall is death. The snake hitting itself is death."
"The death sound," Sunita said. "Not a harsh failure noise. Something with a little dignity. The snake is a symbol."
"Do what feels right," Karan said.
"I always do," Sunita said, without arrogance — just as a statement of her working method.
The brick-breaking game was called Rebound — an English name chosen because Karan said the Hindi options felt like translations rather than names, and the game's mechanic was primarily about the English word's meaning: the ball rebounding, the player's fortunes rebounding, the satisfaction of things bouncing back.
"The sound architecture for this game is the most demanding in the set," Sunita said, after Karan had described the mechanic. "The ball hitting the paddle is different from hitting a wall, which is different from hitting a brick. If all three sound the same, the game feels wrong. The player uses sound to track the ball — especially when it goes behind the remaining bricks and they can't see exactly where it is."
"Explain that," Karan said.
"At the point in the game where most of the bricks are gone and only a few remain in the top rows — the ball bounces around up there, between the bricks and the top wall, and the player can't see it clearly because the bricks are in the way. They're tracking by sound. The direction of the last bounce, the time since the last sound, the pattern." She paused. "The game is partly visual and partly auditory, and the player switches between them depending on what's happening."
"The sound is navigation," Karan said.
"At high speed, yes."
"Then design it accordingly."
She wrote in her notebook — the one she had produced partway through the first day, having abandoned her usual note-in-head approach because the specificity of the sound requirements was exceeding her internal storage.
"Rajan," Karan said. "The bricks."
"What about them?"
"They should look like they break. Not just disappear. Even a one-frame break animation — something that feels like impact."
"I'll try two frames," Rajan said. "The brick cracks, then disappears. I don't know if I can get two frames at game speed without the engine struggling."
"That's Vikram's problem," Karan said.
"Yes it is," Vikram said mildly.
Star Guardian — was the space invader game, and it was the game that produced the longest silence when Karan finished describing it.
The silence was Rajan Pillai's.
He sat with his pencil on his notebook and looked at the ceiling for approximately six seconds.
"The Garuda," he said.(not same to fighter jet)
"Yes," Karan said.
"Vishnu's mount. The great eagle. Divine fire." He looked down at his notebook and began drawing. "The player's ship is the Garuda — it doesn't have a gun, because Garuda doesn't have a gun. Garuda has divine fire. The weapon is light."
"The beam visual," Karan said.
"A column of light. Vertical. Very bright — I'll use the display's highest intensity setting for the beam. It should feel like something sacred, not a weapon." He was drawing the Garuda now — a stylized bird shape, wide-winged, the wings suggesting speed without depicting it literally, the head forward, the beak forward. "And the enemies."
"The Asura fleet," Karan said.
"The Asura fleet." Rajan's pencil moved. The shapes emerging were not flying saucers — they were something that evoked the mythological without quoting it directly, abstracted demon faces, the suggestion of fangs and crowns and ancient malevolence made geometrically precise. "They have to move like enemies," he said. "Not like machines. They should feel like they're hunting the Garuda, not just advancing."
"The formation movement pattern," Menon said. "Not a rigid grid. The formation can shift — columns moving forward while others move back. Flanking movements."
"They learn," Karan said.
"They adapt," Menon said. "Each wave uses the previous wave's surviving patterns. If the player always shoots from the center, the next wave advances from the edges."
"They're not machines. They're the Asura," Karan said. "They are cunning."
"The sound," Sunita said. She had been very quiet during this discussion, which meant she was processing at full depth. "The Asura fleet makes a drone as it descends. Not a beep. A sustained harmonic — multiple frequencies, slightly detuned, the kind of sound that makes you feel something is wrong before you consciously hear it."
"Tension before danger," Karan said.
"The drone gets louder as the fleet gets closer. At maximum proximity it should be slightly uncomfortable. Not painful — uncomfortable. And then—" She paused. "When the last Asura is destroyed, complete silence. Not a victory jingle immediately. A beat of silence first. The absence of the drone."
"The Garuda beam sound," Karan said.
"A harmonic tone. Rising. Like a temple bell sustaining. Not military. Sacred." She looked at Karan. "I want whoever is playing this game to feel, when they fire, like they're doing something right rather than something violent."
A pause.
"That's the exact distinction I wanted," Karan said. "And I didn't know how to ask for it."
Chandrayaan — Lunar Vehicle — was the game Karan had written the most explicit pedagogical rationale for, and also the game that Ravi Menon had been visibly waiting for since the brief had been distributed the previous evening.
"The physics," Menon said, before Karan had even opened to that page.
"Tell me," Karan said.
"Real lunar gravity. One-sixth of Earth's surface gravity. Real thrust — the player controls the burn rate of the engine, which means controlling acceleration rather than velocity. Real fuel consumption. The player has a finite fuel budget and has to reach the surface on what they have." He paused. "The problem they're solving is a real orbital mechanics problem. They're not solving it with equations. They're solving it with their hands and their eyes. But the underlying mathematics is the mathematics of space flight."
"ISRO uses this mathematics," Karan said.
"Yes."
"Children who master this game have developed an intuition for problems that ISRO engineers solve formally," Karan said. "The intuition comes first. The formalism comes later, when they encounter it in school or university. They recognize it. They've already felt it."
"There are educational psychologists who study this," Pradeep said. "The phenomenon of recognizing formal knowledge through prior physical experience. It significantly accelerates learning."
"I know," Karan said. He didn't elaborate.
The landing pads: Rajan Pillai designed three — a wide easy pad on the flat plain, a medium pad in a small crater, and a difficult pad on a narrow ridge. The ridge landing scored four times the points. The physics were the same for all three, but the available space to maneuver was different.
"The fuel gauge," Sunita said. "It has to be auditory, not just visual. The engine burn sound should change as fuel decreases. Slightly thinner at fifty percent. Clearly different at twenty-five percent. At ten percent there's a distinct change — not an alarm, just a change the player feels before they consciously register it."
"The player knows they're almost out of fuel before they look at the gauge," Karan said.
"The body knows before the mind," Sunita said. "That's what good sound design does."
Solitaire was the game Karan had described with a single sentence in the brief.
The mine-clearing game Karan called Sappeur — the French military term for a combat engineer who cleared mines. He'd chosen it because it was technically accurate, slightly mysterious, and created the implicit question that made people pick something up in the first place.
"The mechanic is pure deduction," Pradeep Srivastava said. He had straightened slightly when this game came up, the posture of a man whose subject has arrived. "You have partial information — the numbers revealed by safe squares — and you use logical inference to locate the danger. Every move is either a certain move, a probabilistic move, or a guess."
"Most advanced players never guess," Menon said. "You can always find a certain move if you look hard enough. Usually."
"Usually," Karan said. "And in the rare cases where you have to guess?"
"You accept the probability and play it," Menon said. "And if you're wrong, you start again. The game doesn't punish bad luck. It punishes bad reasoning."
"The game is about the quality of thinking," Karan said. "Not about luck. Luck is a small tax on the exercise of logic."
Pradeep was writing. "The grid size options. Small grid — 9x9, ten mines — for beginners. Medium — 16x16, forty mines. Large — 30x16, ninety-nine mines."
"The large grid can take twenty minutes to complete," Menon said.
"Good," Karan said. "Some people want to be absorbed. The office worker playing Sappeur at lunch is not playing for twelve minutes. He's playing until he has to go back to his desk. The game should be able to accommodate that."
"The flag mechanic," Deepak Sharma said. "Right-click on a keyboard, or secondary button on the controller. Places a flag on a suspected mine. Removes the flag on a second press."
"The flag is how the player annotates their thinking," Karan said. "They're making their reasoning visible on the board."
"Which means when they're wrong," Sharma said, "and they hit a mine they'd flagged as safe, they can see exactly where their logic failed."
"The game teaches you how you were wrong," Pradeep said. "Not just that you were wrong."
Carrom.
Karan had written the most in the brief about carrom, and had written the most carefully, in a way that suggested he had thought hard about the risk of getting it wrong.
This game must feel like carrom. Not look like carrom. Feel like it. If the physics are technically correct but the sensation is missing, the game has failed. If the sound is approximate and the player feels they're playing something close to carrom rather than carrom itself, the game has failed. Every person who plays this will know immediately if it is wrong. Every person who plays this will also know immediately if it is right.
He read this aloud.
The room was quiet afterward for a moment.
"The physics," Rajan Pillai said carefully. "This is the hardest technical problem in the set. Carrom physics involves friction, momentum, collision geometry. Each piece has mass — the striker is heavier than the pieces, which is heavier than the queen. The board surface has a friction coefficient. The pocket geometry affects how pieces enter — a grazing shot behaves differently from a direct shot." He paused. "I can simulate this. The Siddharth-2's processor is fast enough, barely, if the simulation is optimised. The question is whether a technically correct simulation feels right."
"What's the difference?" Karan said.
"Technically correct means the numbers are right. Feeling right means the player's hand and eye and ear all agree that they're playing carrom." Rajan thought for a moment. "There might be places where the technically correct result is slightly wrong for the feel. Where real carrom has a slight imprecision in how pieces respond — the powder on the board, the wear on the striker — that makes the game feel more organic."
"Build the technically correct version first," Karan said. "Then we see what doesn't feel right and we adjust."
"That could take months," Rajan said.
"You have four weeks for the first version and four months for the adjustment," Karan said. "That's enough."
"The sound," Sunita said.
She had said very little since carrom was raised. She said it now with the tone of someone who has been organizing something complicated in their head and is ready to describe it.
"Carrom is sixty percent sound," she said. "The crack of the striker hitting a piece. The slide of a piece on the board. The edge thud. The pocket rattle and settle." She looked at Rajan. "I need to go record a real carrom match. Not approximate the sounds — record the actual sounds. I need the specific timbre of that specific interaction, compressed and digitized."
"The sync," Rajan said, understanding immediately. "The physics simulation and the sound have to be in exact sync. The crack plays at the exact frame of impact, not one frame late."
"One frame late and the brain knows it's wrong," Sunita said. "Even if it can't say why. Even if it's never played carrom on a computer before and has nothing to compare it to. The brain knows."
"How does the brain know?" Sharma asked.
"Because we've been calibrating ourselves to physical reality for our entire lives," Sunita said. "Sound and contact have been in sync since the first time we touched anything. When they're not in sync, we feel it as wrongness. The body is the reference."
Rajan Pillai and Sunita Krishnaswami looked at each other across the table.
"We're going to need to work together on this one," Rajan said.
"I know," Sunita said. "I've been thinking about it since three in the morning."
"Me too," he said.
Ludo.
The game every Indian child had played on the floor of their parents' house. The crossed board, the four colors, the six-sided die, the specific drama of a piece getting sent back to start.
"The computer plays the absent players," Karan said. "One to four human players, the computer fills the remaining colors."
"The computer intelligence," Menon said. "For Ludo — what does it mean for the computer to play well?"
"Three things," Karan said. "Advancing your own pieces toward home. Avoiding leaving your pieces vulnerable. And — at the highest level — deliberately pursuing the human player's pieces when they're within striking range."
"The highest level plays aggressively," Pradeep said.
"The highest level plays to win," Karan said. "Not to make the human feel good. The human can choose the lower levels for a gentler experience. But if they choose the hardest level, the computer treats them as an opponent, not a guest."
"The piece getting sent home," Sunita said. "The sound of that moment — it has to capture two simultaneous feelings. The person who got sent home feels a small tragedy. The person who sent them feels a small satisfaction."
"Two sounds?" Menon said.
"One sound that carries both," she said. "A sound with the right shape. Dramatic enough to register as a significant event. Not so dramatic as to feel mean." She paused. "Like the sound of a soap bubble popping. It's gone, it's over, but it wasn't a disaster."
Rajan Pillai had been sketching the die animation. "The die rolls," he said, showing the notebook. "On screen. Not just a number appearing — the die actually rolling, bouncing, settling. Four frames of animation."
"Five," Deepak Sharma said. "The settling frame is important. There's a half-second where the die is almost still but not quite. That's the moment of suspense."
"The five-frame die animation," Rajan said, adding a frame to his sketch.
Typing Trainer — the name was straightforward and was chosen to be straightforward, because the game's purpose was its own advertisement.
"It is not a game," Pradeep Srivastava said. "Technically. But it belongs in the set because it is what justifies the Siddharth-2 to every parent who asks whether this machine is a toy or a tool."
"It's both," Karan said. "That's the point. The same machine that runs Karo at night runs Typing Trainer in the morning because the child's parents told them to. The computer is the bridge between what the child wants and what the parents want."
The structure: ten lesson sequences, each harder than the last. Home row first — ASDF, JKL. Common letter combinations next. Full sentences. Speed tests.
"Progress tracking," Pradeep said. "Visual progress. The student sees their words-per-minute improve across sessions. The graph goes up."
"The moment a student sees their own graph going up," Karan said, "they come back to move it higher. Self-measurement is its own motivation."
"Stars," Pradeep said. "Three per lesson. One for completing. Two for breaking seventy words per minute. Three for above ninety with high accuracy."
"The vocabulary comes from the school curriculum," Karan said. "The sentences the student is typing should be sentences about Indian history, Indian geography, Indian science. The typing lesson is also a content lesson."
Pradeep stopped writing and looked up. "That's... genuinely clever."
"The student practices typing by typing sentences about the Indus Valley Civilization," Karan said. "They learn to type. They also, incidentally, read about the Indus Valley Civilization repeatedly while they type." He paused. "Learning by repetition, disguised as skill acquisition."
"I want to write the sentence corpus," Pradeep said. "Personally."
"I expected you would," Karan said.
The mathematics practice game — Mission Control — was Pradeep Srivastava's design, developed from a seed in Karan's brief and expanded over the two days into something more elaborate than any single person had arrived with.
"The frame is ISRO," Pradeep said. "The student is a mission controller. Numbers are mission parameters. Correct calculations advance the mission — the rocket gets closer to its target, the satellite achieves orbit. Errors require recalculation — not failure, not an error buzzer, just: recalculate, the mission is paused."
"No punishment for wrong answers," Karan said.
"Redirection, not punishment," Pradeep said. "The mission needs the right number. The student provides a different number. The mission gently indicates this is not the right number. The student tries again."
"The levels," Menon said. "How does it adapt?"
"The programme assesses the student through an opening sequence of questions," Pradeep said. "Not a test — a conversation. The difficulty of each question responds to the previous answer. After fifteen questions, the programme knows roughly what the student can do. It then delivers problems just above that level."
"The edge of competence," Karan said.
"The zone where things are hard but possible," Pradeep said. "Too easy and the student stops trying. Too hard and the student gives up. The game has to live in the narrow band between boring and impossible."
"And the band moves as the student improves," Menon said.
"Continuously," Pradeep said. "The algorithm updates its model of the student with every answer. It's never delivering problems from a fixed level. It's always finding the edge."
Menon was writing. "I have an algorithm for this. The same concept I use for chess — the engine models the opponent's strength and adjusts its play to stay just above. I just need to invert the application."
"Share it with me," Pradeep said.
"After I've rebuilt it," Menon said. "It's in a state."
"When has your code not been in a state?" Vikram said mildly.
"It works," Menon said, with some dignity. "The state is internal."
The city-building game — Sheher — was the one that produced the most complex reaction in the room, because it was the game that most nakedly reflected the actual work Karan was doing as Chief Minister, and everyone in the room knew this.
"The player is the administrator of a new city," Karan said. "Budget, grid, population. The population wants water, power, roads, housing, schools, hospitals. Build the right things in the right order and the city grows. Build the wrong things or the right things in the wrong order and the city stagnates or fails."
"There's no enemy," Menon said. He was reading from the brief.
"The player is their own enemy," Karan said. "Or rather, the difficulty is internal. Every resource you spend on one thing is a resource you can't spend on something else. Every decision forecloses other decisions. The city is a constant negotiation between competing needs."
"This is governance," Pradeep said quietly.
"Yes," Karan said. "The person who plays Sheher for a hundred hours understands, at the level of felt experience, why roads have to come before housing, why a water system that serves two districts is better than two separate systems, why tax rates that are too high slow growth that would generate more tax revenue than the higher rate collected. They understand this because they made the mistake and their city failed and they started again."
"They learn from failure without the consequences of real failure," Pradeep said.
"The best kind of education," Karan said. "The tutorial — the first year of the city — has a guide. A voice in text, like a senior official talking the new administrator through the basics. After year one, the guide steps back. You're on your own."
"The economics," Menon said. "This is the technically complex part. Tax revenue, infrastructure costs, maintenance costs, population growth rates, happiness levels, service coverage. These all have to interact in ways that are realistic without being too complex to understand."
"Realistic enough to teach the real relationships," Karan said. "Simple enough that a fourteen-year-old can discover them."
"That's a narrow design target," Menon said.
"Yes," Karan said. "Hit it."
A short silence.
"There's a mechanic I want," Karan said. "Private-public partnership. The player can sell a piece of infrastructure — a power plant, a water treatment facility — to a private operator. They get immediate capital. They lose direct control. They retain a regulatory relationship." He paused. "The private operator runs it more efficiently but doesn't prioritise equity of access. The poor neighborhoods are less well served."
"So it's not simply a good or bad decision," Pradeep said.
"Almost nothing in governance is simply good or bad," Karan said. "The game should reflect that."
Menon looked at him. He didn't say what he was thinking, which was: you built this from what you're actually doing in Lucknow right now. He wrote it down instead, the mechanic, the logic.
Kho-Kho was the sports game, and it had been a deliberate choice to use kho-kho rather than cricket.
"Cricket is the obvious choice," Karan said. "Everyone knows cricket. Everyone wants cricket. We will build cricket — Menon is already thinking about it for the Siddharth-3 package. But cricket is also enormously complex to simulate faithfully. Kho-kho has a mechanic that translates to a screen."
"The pursuit mechanic," Rajan Pillai said. He'd been sketching the field. "The chaser and the runner. The moment of decision — when to change direction, when to let the chaser overshoot."
"It's a reading game," Karan said. "The player reads the chaser's momentum. They predict where the chaser will be in half a second and they move to where the chaser won't be."
"It's the same cognitive skill as Karo," Menon said. "Predicting the future position of a moving object."
"And Chandrayaan," Karan said. "And Sappeur — predicting where the mines are based on incomplete information. All of these games are exercises in prediction under uncertainty." He looked at the group. "I didn't plan that. But I notice it."
"You planned the games," Vikram Nair said. It was the first time he'd spoken in about an hour, having been listening with the specific attention of a man who was simultaneously designing the architecture that would run all fifteen of these things. "The pattern emerged from the games you chose."
"The games I chose because they were good games," Karan said. "The pattern is a property of good games, I think. They all train the same fundamental capacity — anticipation."
Rajan had his kho-kho field sketched. Top-down view. The nine sitting positions marked in their alternating-direction arrangement. The running space clear.
"Three versus three," he said, reading from the brief. "Simplified rules. But the essential quality — the alternating chase, the speed, the direction changes — preserved."
"The sound," Sunita said. "Running footsteps. The tag — that sharp, flat sound of a hand hitting a shoulder. The crowd." She paused. "The crowd is the challenge. A realistic crowd murmur at 1976 audio quality is — difficult. I'm thinking a repeated waveform that I modulate in volume and density rather than in content. The crowd doesn't have to be realistic. It has to feel present."
"Ambient sound as emotional information," Pradeep said.
"That's what all crowd sound is," Sunita said. "Even in real life. You don't listen to what the crowd is saying. You feel the crowd's energy."
Paathashaala — School — was the fifteenth item in the brief and the one that took the least time to describe and the most time to sit with afterward.
"It's not a game," Karan said. "It's the front door. The programme that appears when a child turns on the Siddharth-2 with the Computer Club package for the first time. It asks: what do you want to do today? It presents the options. It tracks what the child has done across sessions and makes suggestions. It knows their typing speed and their mathematics level and their high scores and their city in Sheher."
"It knows the child," Pradeep said.
"Over time, yes. It's not surveillance. It's memory. The way a good teacher remembers each student." Karan paused. "The tone is the critical design challenge. It must feel like a teacher who is genuinely glad you're here. Not a machine. Not a programme. A welcome."
"The visual design," Rajan said. "The font. The layout. Warm. A child's first experience with a computer should not feel clinical."
"The colour—" He stopped. "We don't have colour."
"We have contrast," Karan said. "Work with what we have."
"The opening sound," Sunita said. "This is — I want to get this right." She was quiet for a moment. "A short melody. Six notes, maybe. Something a child can hum without being taught it. Something that sounds like the beginning of something good." She paused again. "Let me think about it."
She was quiet for about a minute. The room let her be quiet.
Then she hummed something. Tentative. Four notes, then a pause. She tried a different arrangement. Then again.
Then six notes in sequence — a rising movement that curved slightly at the end, landing on a note that felt like an arrival.
She stopped humming and sat with it for a moment.
"That's it," Ravi Menon said.
She looked at him.
"The last six notes," he said. "In that order."
"I haven't finished deciding," she said.
"You don't need to," he said. "That's it. That's the one."
She hummed it again.
"Yes," Karan said.
She stood up without announcement, left the conference room, came back three minutes later with a sheet of music notation paper from somewhere — nobody asked where — and the six notes transcribed onto it. She pinned it to the wall beside the whiteboard.
The room looked at it.
May 17, 1976, 2:00 PM
Vikram Nair stood at the whiteboard.
He'd been sitting for the whole of the previous day and most of this one. He stood now because the whiteboard was the right surface for what he needed to draw, and because some things required standing.
He drew a rectangle at the top of the board. Labeled it: SIDDHARTH GAME ENGINE (SGE).
"Four systems," he said. "The engine does four things. Everything else is built on top of these four things."
He drew DISPLAY below and to the left. Drew SOUND beside it. INPUT beside that. PERSISTENCE at the right.
"Display: every game draws to the screen through the engine. No game writes directly to the display buffer. The engine manages the buffer, the refresh cycle, the sprite system, the animation timing. The sprite system is my primary technical risk — I'll come back to that."
"Input: every game receives player input through the engine. The engine translates physical input — keyboard, controller, both — into game events. A game doesn't ask 'was the left arrow key pressed.' It asks 'did player one move left.' The hardware abstraction is the engine's responsibility. A game built on the engine will work with a keyboard today and a controller tomorrow without changing a line of game code."
"Sound: every game plays audio through the engine. Sunita's sounds are assets. The engine manages the audio chip addressing, the mixing — because some games will play multiple sounds simultaneously — the timing, the volume. The game says 'play landing sound.' The engine figures out how."
"Persistence: every game's data that needs to survive between sessions — high score tables, player profiles in Paathashaala, Sheher save states, Typing Trainer progress — goes through the engine's data system. Reads and writes to cassette storage. One consistent interface. One consistent file format."
He stepped back and looked at what he'd drawn.
"Every game programmer interacts with exactly four functions: ENGINE.DRAW. ENGINE.PLAY. ENGINE.INPUT. ENGINE.SAVE and ENGINE.LOAD." He looked at Menon. "You don't write display code. You call ENGINE.DRAW with an object, an x position, a y position. The engine handles the rest."
Menon nodded. "The game is only about its own logic."
"The game is only about its own logic," Vikram said. "The engine handles everything else."
"How long?" Karan asked.
"Four weeks. Three to build, one to test with Karo as the reference implementation. If the engine works for Karo, it works for everything — Karo exercises the display system, the input system, the sound system, and the persistence system. If Karo runs cleanly on the engine, I'm confident in the engine."
"What's the risk?"
Vikram was quiet for a moment. When Vikram Nair was quiet before answering, you paid attention to what came next.
"The sprite system," he said. "The display controller was not designed for games. The way I'm using it — the way Rajan's graphics library uses it — is at the edge of what the manufacturer intended. The principle works. The integration at game speed I haven't validated."
"And if it breaks at game speed?"
"I build a different approach," Vikram said. "The fallback is slower but it works. The fallback costs an additional week."
"The risk is one week," Karan said.
"The risk is one week," Vikram said. "Though I want to be honest — the uncertainty is larger than 'one additional week' suggests. The uncertainty is: will this work. I believe it will. I don't know that it will."
A brief quiet.
"I respect that distinction," Karan said. "Proceed."
The First Game That Worked
June 3, 1976
Karo worked first.
Not perfectly — the speed increase from level three to level four was too abrupt, and Sunita's Bhairav theme was missing its fourth phrase because she hadn't finished it, and the high score table showed the same name on every entry because Menon had been testing with his own name hardcoded and hadn't gotten around to removing it.
But it worked.
The blocks fell. The player moved and rotated them. The lines disappeared when completed. The stack breathed.
Vikram Nair sat in the ISMC division's small testing room — three machines, a whiteboard covered in bug tracking notes, a smell of electronics and stale tea — and played Karo for four minutes. He played slowly and carefully, not playing to score but playing to observe.
He set the controller down.
"The sprite system holds at speed," he said. To the whiteboard, not to Menon. "The display timing is stable."
"It's been stable for two days," Menon said. He was sitting at the adjacent machine, watching Vikram play.
"I've been watching it for two days," Vikram said. "Today I'm satisfied." He paused. "I wasn't certain the timing would hold. I said the risk was one week. The real uncertainty was larger than that."
"You could have said so."
"I said what I knew," Vikram said. "The risk was one week — that was accurate. What I didn't add is that I genuinely didn't know if it would work at all. Because 'I don't know if it works' and 'one additional week' feel different to the person making the decision, even if they're the same information."
Menon looked at the Siddharth-2 screen, where Karo was still running — a stack of blocks growing slowly, waiting for no player.
"You were scared," he said.
"I was uncertain," Vikram said, with some precision. "Engineers are uncertain. Fear is for outcomes you can't affect." He picked up the controller again. "The speed curve. You said it was wrong."
"Level three to four is too sudden. The player doesn't have time to adapt." Menon had his notebook. "I need to add two intermediate speed levels between three and four. The step function should be smoother — more levels at the harder speeds, not fewer."
"How many levels total?"
"Twelve instead of eight," Menon said. "The same maximum speed. More granular progression to reach it."
Vikram played Karo for seven minutes. He reached level four — the speed where a block fell in under two seconds — and survived for about a minute before the stack topped out.
He set the controller down and looked at his score.
"I'm going to keep playing this," he said.
"I know," Menon said.
"This is a problem."
"I know," Menon said. "I've had this problem for six months."
In the corner of the testing room, Rajan Pillai was working on carrom.
The carrom simulation — the physics of it — had taken three weeks to get to a state where Rajan would let anyone else see it. He had rebuilt the collision detection twice. He had recalibrated the friction coefficients four times, using actual measurements from a carrom board he had borrowed from the factory break room and placed on the testing table, measuring the distance a striker traveled from various starting velocities, calculating backward to friction coefficient from first principles.
The current version of the physics was, as best as Rajan could determine, correct.
It felt slightly wrong.
He'd spent the last week trying to understand why.
He flicked the virtual striker. It crossed the board, struck a piece at an angle, deflected. The piece moved, struck the wall, deflected again, came to rest near the opposite pocket. All correct. All physically accurate.
But — something.
He watched the piece come to rest. It came to rest too smoothly. A real carrom piece on a real board had a very slight irregularity at the end of its motion — not visible motion, but a kind of tremor, the piece settling into the powder's resistance, finding its static equilibrium through a brief negotiation rather than arriving at it directly.
He opened his notebook. Wrote: Final motion — add micro-settling. Very small amplitude oscillation at velocity below threshold. Five frames. Decreasing amplitude. Should look like the piece is 'finding its stop' rather than 'stopping.
He would have to add this to the physics engine without breaking the collision detection. A three-hour problem, probably.
He flicked the striker again.
He watched the piece stop.
It was still wrong, but he knew exactly how to fix it now.
Sunita came back from the audio lab on June 14th with a cassette tape and a notebook full of frequency notations and what Rajan later described as an expression like someone who had done something they weren't sure would work and had found out it had.
She loaded the sounds into the Siddharth-2 through the audio driver.
"Run the simulation," she told Rajan.
He flicked the striker.
From the Siddharth-2's speaker — a small thing, approximately the size of a large coin, rated for frequencies that were a generous interpretation of its actual range — came the sound of a striker hitting a carrom piece.
Not an approximation of the sound.
The sound.
The specific, dry, satisfying crack of polymer on polymer on a board that has been lightly powdered, compressed to twelve kilobytes, played through a speaker that should not, technically, have been capable of reproducing it. And yet.
Rajan's hand stopped moving.
He stayed very still for a moment.
"Do it again," he said.
She asked him to flick.
He flicked.
The crack again.
He sat back slowly from the machine.
"This is carrom," he said.
Sunita picked up the controller. She flicked — a longer shot, the striker covering most of the board, the piece at the far end struck cleanly, spinning slightly as it entered the pocket.
The pocket sound played: the initial impact against the pocket wall, then the spin-and-settle, then the specific brief silence before the next player's turn.
"The silence," Rajan said. He was pointing at nothing. At the air where the sound had been. "The silence after the settle. You put a silence in."
"Four frames," she said. "The brain needs the silence to register that the piece has finished moving. Without the silence it blurs into the next sound."
"The silence is part of the sound," he said.
"The silence is always part of the sound," she said. She set the controller down. "The carrom is done. Physics and sound. Now we test with two players and see what breaks."
"What do you think will break?" Rajan asked.
She thought about it honestly. "The queen cover mechanic. The timing of the cover-piece requirement. The window for the cover is physically very short in real carrom — a fraction of a second. In the digital version, we've defined it as two seconds, which is too long but is the minimum for a human with a controller to actually execute. I think it's going to feel wrong."
"How do we fix that?"
"I don't know yet," she said. "We test it and we see how wrong it is and then we decide."
"That's not a plan," he said.
"That's exactly a plan," she said. "It's a plan for a problem we don't fully understand yet."
The Progress
July–September, 1976
By the end of July, nine of the fifteen games were in testable form.
Karo was in its third iteration — the speed curve smoothed, Sunita's Bhairav theme completed and integrated, the Rangoli block theme added by Rajan in a weekend of pixel work that he later described as meditative. The high score table worked correctly. The name entry worked. Menon had sat down to play it properly for the first time since the speed curve fix and had lasted until level seven before losing, which was the longest he'd ever gone.
Shatranj had five difficulty levels, the Indian piece set in Rajan's pixel art, the computer's consideration highlighted during its calculation time. The hardest level had beaten every programmer in the division who had tried it. Menon was satisfied with this.
Rebound had seven levels, Sunita's pitch-variable brick sounds, and a ball that behaved exactly as Rajan's trajectory calculations predicted. It was a very correct implementation of a well-established mechanic. It was not the most interesting game in the set, but it was not trying to be.
Gend had been completed quickly and then left alone, because it was a game that revealed its quality only in two-player play, and two-player testing had showed it was correct. Aditya had tested it twice when he was in Gorakhpur for budget meetings and had beaten Karan both times, which Karan had noted without comment.
Solitaire had its Mughal face cards, its complete solitaire ruleset, its win sound. Pradeep had played it for two hours during a bout of insomnia and had completed three games and felt exactly the small, complete satisfaction that Sunita had designed for.
Sappeur had its three grid sizes, its mine detection logic, its flag system. Menon had discovered that the large grid could sometimes generate an unsolvable configuration — a corner case where deductive logic was insufficient and the player had to guess — and had added a seeding parameter that minimized but could not eliminate this possibility. He had documented this as a known limitation and added a note to the Paathashaala help text.
Typing Trainer had ten lessons, Pradeep's carefully curated sentence corpus drawn from ISRO mission reports and Indian scientific achievements and passages from Jawaharlal Nehru's Discovery of India, and the three-star system. Beta testing with children of staff members had produced, in one case, a child who completed all ten lessons in a single three-hour session and then asked if there were more.
Pradeep had gone back to his room and written two additional lesson sequences that night.
Chandrayaan had Rajan's crater-marked lunar surface, its three landing pads, its physics that Menon had validated against ISRO's published documentation on lunar orbital mechanics. The first time a member of the testing group successfully landed on the narrow ridge pad — a process that took six attempts and fifteen minutes — he had looked up from the screen with an expression that nobody in the room had a word for.
Carrom had its physics, its sounds, its queen cover mechanic — which had needed significant adjustment to feel correct, and which had required three separate conversations between Sunita and Rajan and two between Rajan and Menon about the game logic — and was in its second full-game two-player test phase.
The remaining six — Kho-Kho, Ludo, Sheher, Mission Control, Nakshatra Rakshak, and Paathashaala — were in various stages of early development.
Sheher was the game that made the most unexpected demands on its programmers.
Menon had expected the economics simulation to be the difficult part. It was difficult, but it was a tractable kind of difficult — equations with known relationships, constants that could be tuned, a model that could be validated against simple cases.
The difficult part was the city's personality.
A city in Sheher was not just numbers. It had a texture. The residential zones in the north of the city were different from the residential zones in the south, not because the game assigned them different properties but because the player's decisions had resulted in different infrastructure serving different areas, and different infrastructure produced different growth patterns, and different growth patterns produced a city that felt lived-in rather than calculated.
"The emergent character," Pradeep said. He and Menon had been working late on the simulation parameters. "The city develops a character the player didn't consciously design."
"Which means the player feels ownership," Menon said. "This is my city. Not a generic city. Mine."
"The save state," Pradeep said. "When they come back the next day and their city is exactly as they left it — the investments they made, the problems they were solving, the mistake in the eastern district they hadn't fixed yet—"
"The city remembers them," Menon said.
"The player remembers the city," Pradeep corrected. "The save state is the city. The memory is the player's. And because the player remembers a city with a specific character — a city that has their fingerprints on it — they want to come back to it."
Menon was quiet for a moment. "This is a more sophisticated psychological mechanism than any other game in the set."
"Yes," Pradeep said. "Children will probably like Karo more. Adults will probably lose more time to Sheher."
Sunita's work in September was the sound integration across all fifteen games — not building new sounds, but ensuring that the sounds of different games were compatible in the way that rooms in a house are compatible, each with its own quality but all belonging to the same structure.
She moved from machine to machine in the testing room, listening to each game with her eyes closed. Not playing — listening.
Karo: the Bhairav theme, the block percussion, the line-clear resolution. Correct. The sound makes you play faster.
Shatranj: very quiet — the piece movement, the computer's consideration tone, the check alert. Correct. The quiet is part of it. Chess is a quiet game.
Rebound: the ball sounds, the pitch-variable bricks, the wall taps, the paddle contact. The paddle sound needs more weight. It's slightly thin. I'll adjust the fundamental frequency up.
Gend: two sounds only — the paddle contact and the point score. The point score is too celebratory. It should acknowledge the point without making the other player feel humiliated. Less is more.
She wrote these notes. She made the adjustments. She listened again.
Nakshatra Rakshak: the Garuda beam, the Asura drone, the hit confirmation, the wave-clear silence. The silence is perfect. Don't touch it.
Chandrayaan: the engine burn, the fuel-low frequency shift, the landing contact. The successful landing needs a sound. Not a celebration — an acknowledgment. Three notes. Ascending. The mission is complete.
She added the landing sound on a Wednesday evening. She played it back once and then didn't touch it.
Carrom: complete. Complete.
Sappeur: very sparse — the click of revealing a square, the flag placement, the mine. The mine sound. It's still slightly too harsh. One iteration.
Ludo: the die roll sound, the piece movement, the piece-sent-home sound, the arrival-at-home sound. The arrival-at-home needs warmth. Not just a tone. Something that sounds like reaching somewhere you've been trying to reach.
Sheher: ambient city sound — not specific sounds for individual events, but a background texture that changed as the city grew. A small settlement sound. A growing town sound. A city sound. This is the most technically complex audio work in the set. The ambient layer transitions between states without a seam. I need to test the transition logic.
She tested the Sheher ambient transitions for three days. She found two places where the transition was abrupt enough to be noticeable. She rebuilt those transitions. The city grew, and the sound of it grew with it, and you didn't notice the transition because it wasn't there anymore.
The Review
September 15, 1976
Karan played all fifteen games in a six-hour session, alone except for the six programmers who were present and specifically not explaining anything.
He played Karo for twelve minutes and reached level five, which was the level where the blocks fell fast enough that you weren't thinking about individual placements anymore but about the shape of the whole board. He set the controller down without comment.
He played Shatranj on medium difficulty and lost in forty-one moves. He restarted, played more carefully, and lost in sixty-eight moves. He restarted a second time and lasted ninety moves before a positional mistake cost him the game.
"The computer," he said.
"Medium difficulty," Menon said. "Corresponding to a moderate club player."
"Each game I'm surviving longer," Karan said.
"The algorithm is consistent," Menon said. "You're improving. The computer is the same."
Karan looked at the board for a moment.
"That's the game," he said. "That's actually the whole game. The computer doesn't get better. You get better. And one day you beat it and you want to beat it again on the harder difficulty."
"That was the design," Menon said.
"I know," Karan said. "I'm noting that it works."
He played the snake game — they were calling it simply Saanp in the test builds, though the name might change — until he'd reached a length that made the board complicated, the snake's body filling nearly half the screen, his own earlier movements now the obstacle course he had to navigate.
He played Rebound. He played Gend against Aditya, who had come in quietly halfway through the session and picked up the second controller without being asked. Aditya won the first game 7-3, the second game 7-5. In the third game Karan discovered the angle mechanic — the way a ball struck with the paddle's edge deflected differently — and adjusted his play. He won 7-6.
"When did you figure out the angle?" Aditya asked.
"Third rally of the second game," Karan said. "I didn't know how to use it yet."
"It's a real skill gap," Aditya said. He handed the controller back. "Someone who understands the angle mechanic beats someone who doesn't, every time, regardless of reaction speed."
"Deepak," Karan said.
Sharma looked up from the back of the room.
"The mechanic is never explained anywhere in the game?"
"Never," Sharma said.
"Good," Karan said. "The players who discover it feel smart. The players who discover it through being beaten by it want to understand why they lost."
He played Nakshatra Rakshak for nine minutes. On the first shot with the Garuda's beam, he paused.
The sound.
Not the visuals — the sound. The rising harmonic that Sunita had designed, the sacred-fire quality of it, the sense that firing the weapon was an act of rightness rather than aggression.
He fired again. Listened.
"The beam," he said.
"Yes," Sunita said from the back of the room.
"Every time I fire, I want to fire again," he said. "Not to destroy the enemy. To hear the sound."
"That's not accidental," she said.
"I know," he said. He played on.
He played Chandrayaan. Failed the first approach — came in too fast, underestimated the gravity. Failed the second — too much fuel spent adjusting the approach angle. On the third attempt he found the rhythm of it, the feel of when to burn and when to coast, and came down slowly on the large pad and the landing contact tone played — three ascending notes, quiet, final — and he sat with that for a moment before restarting to try the ridge pad.
He failed the ridge pad six times.
On the seventh attempt he made it. Very low velocity, right at the edge of the landing tolerance, the small ship settling onto the narrow surface at the edge of a crater.
The three notes.
"The landing sound," he said.
"I added it last week," Sunita said. "The mission completion acknowledgment."
"It sounds like arriving somewhere you've been trying to reach for a long time," he said.
Sunita said nothing. That was what she'd been trying to make.
He played Solitaire, lost three games — the deck configurations weren't solvable, or he couldn't find the solution — and won the fourth. The win sound played. Small, ascending, complete.
Aditya, who was still in the room, said: "That sound."
"What about it?" Sunita said.
"It's the sound you hear when something is finished," Aditya said. "Not defeated. Finished. It's a different feeling."
"Yes," she said. "That's the distinction."
He played Sappeur. He hit a mine on the third square of his first game, which was bad luck. On the second game he was more careful, working logically from the numbers, flagging his suspicions, not guessing until forced. He solved the medium grid in eleven minutes.
He played Carrom with Aditya.
Aditya was better at carrom than Karan. This had been true since they were children and showed no signs of changing. The digital carrom preserved this difference faithfully — Aditya's superior understanding of angles and spin, his ability to visualize the second and third effects of a shot, his patience with difficult positions, all of it translated into the simulation with accuracy that Rajan and Sunita had spent two months achieving.
Aditya won 24-11.
"The queen," Aditya said. He was looking at the board, where the queen had been sitting uncovered for three shots because Karan hadn't had a clear follow-up.
"I know," Karan said.
"You went for it too early," Aditya said. "You didn't have a cover lined up."
"I know."
"In real carrom you'd have—"
"Aditya," Karan said.
"Sorry."
"Play again," Karan said. "Don't give me advice."
Aditya won the second game 22-17. Closer, but still definitive.
"The physics," Karan said to Rajan and Sunita.
"Yes?" Rajan said.
"The physics is carrom," Karan said. "Not approximately carrom. Carrom."
"We had good source material," Rajan said, carefully.
He played Ludo. He won the first game against three computer opponents — the computer at level two, still developing its aggressive play. He played again at level three and came third, his most advanced piece being systematically hunted by the computer every time it reached the final stretch.
"The level three intelligence," he said.
"It identifies the human player's leading piece and targets it specifically," Menon said.
"It cheats," Aditya said. He was watching from the back. "In a real ludo game, the players are all trying to win, not specifically to destroy one player."
"The computer plays correctly," Menon said. "In ludo, the optimal strategy often involves sending opponents' pieces home. The level three computer prioritizes this against the human player because the human player is its most capable opponent."
"So it treats you as the primary threat," Karan said.
"Yes."
"That's flattering," Aditya said, dryly.
Karan played Typing Trainer. He completed five lessons, his speed climbing from 43 words per minute to 51 across the sequence. The progress graph appeared after lesson five — a simple upward line.
He looked at the graph.
"A student who has been playing this for a month," he said. "The graph going up. Their own improvement made visible."
"The graph is the game," Pradeep said. "The lessons are the method. The graph is the reason to continue."
He played Mission Control. The programme assessed his mathematics level — he placed at what it determined was the advanced secondary level — and began presenting problems. Algebraic equations, mostly. He worked through fifteen. Got thirteen right. The two wrong ones were careless errors, sign mistakes.
On the next batch, the programme delivered more problems involving negative numbers.
He noticed this.
"It knows I make sign errors," he said.
"The adaptive model updated after your first session," Pradeep said.
"So next time I sit down at this," Karan said, "it begins where my weakness is."
"It doesn't begin where your weakness is," Pradeep said. "It builds toward your weakness from a place of competence. It doesn't confront you with what you're bad at. It reminds you what you're good at and then moves toward the difficulty."
Karan looked at Pradeep for a moment.
"You've thought carefully about how people feel when they encounter their own limitations," he said.
"I studied education for three years," Pradeep said. "The moment when a student hits a wall is the most important moment in their learning. What happens in that moment — whether they try again or give up — determines everything."
He played Sheher for forty minutes.
The forty minutes were quiet. The room was quiet during them. The programmers watched Karan build a city — he built methodically, roads first, power infrastructure, then zoned residential areas near services. His city grew. He ran into a budget problem in year six, the public infrastructure costs exceeding his tax base. He tried raising the tax rate. Growth slowed. He lowered it. The budget deteriorated. He made the private-public partnership decision — sold the water treatment facility, retained regulatory oversight, used the capital for the hospital his eastern district urgently needed.
The city recovered.
By year ten of the simulation, his city had 47,000 residents and a functioning transit network and a school coverage gap in the western industrial area that he hadn't solved.
He stopped playing.
"The private-public partnership," he said.
"Added in week eight," Menon said.
"It's not a simple good or bad decision," Karan said. "The private operator runs it more efficiently. But the equity of access changes. The poor neighborhoods see less reliable service."
"Yes," Menon said.
"The game doesn't tell the player this," Karan said. "The player discovers it. Their western industrial zone has slightly lower service quality after the privatisation and they have to figure out why."
"The game teaches by showing consequences," Pradeep said. "Not by explaining them."
Karan looked at the city on the screen — his city, with its specific shape and its specific problems and its western gap.
"Children who play this will understand governance," he said. "Not as an abstraction. As something they've done and gotten wrong and done again more carefully."
"That was the intention," Pradeep said.
He played Kho-Kho for ten minutes, learning the movement timing. He lost several rounds — the computer's chasers were aggressive and he hadn't yet developed the sense for when to cut direction. He played more and began to understand it, the read of the chaser's momentum, the precise moment when a direction change would cause them to overshoot.
He finished with Paathashaala.
He loaded it and sat in front of the screen.
The Shergill Game Studio logo appeared — Rajan's design, clean and readable at the Siddharth's resolution, a book opening and becoming a circuit board and then a night sky, three stages, no wasted motion.
Then the six notes.
Sunita's six notes, played by the Siddharth-2's audio chip in a timbre that was not quite any real instrument but was warm and clear and precisely right in the way that things made with specific intention are right.
Then: Welcome. What do you want to do today?
And the options. Learn typing. Practice mathematics. Play a game. Build a city.
The room was quiet.
Karan looked at the screen for a long time.
He had built a great deal in six years. An aircraft engine. Steel infrastructure. A pharmaceutical distribution system that reached villages that had never had consistent medicine. Agricultural credit systems. Government programmes. An oil recovery operation. A cinema network. A Nobel Prize-winning material. A film seen in forty-seven countries.
This was a programme for children.
He sat with the six notes fading in the air — the specific fading quality of a note played by a machine that approximated warmth — and the question on the screen.
What do you want to do today?
"Paathashaala," he said.
"Yes," Pradeep said.
"The child who opens this on Dussehra morning," Karan said. "Their parents have given them the Computer Club package. The machine is new. The screen is new. This is the first thing they see." He looked at the options. "They choose one thing. They do it for an hour. They come back the next day. The day after that, Paathashaala remembers them. It knows their progress. It welcomes them back."
He was quiet for a moment.
"At the end of the year," he said, "they are better at mathematics than they were. They type faster. They've built three cities in Sheher and learned why roads have to come before houses. They've played Karo until they see shapes when they close their eyes. They've beaten the chess programme at medium difficulty and started learning what's different about the hard difficulty."
He looked at the options on the screen.
"The Siddharth is no longer a machine that does things for them," he said. "It's a machine that knows them."
He closed Paathashaala.
He turned to the six programmers.
Nobody said anything. The room had the specific quality of people who are waiting for what comes next and are also, simultaneously, aware that what has just happened was worth noting.
"Release on October 22nd," Karan said. "Dussehra."
He looked at them.
"Four things," he said. "One: the cricket simulation. Menon mentioned it at the first meeting. Begin design now. It releases with the Siddharth-3 package in 1978. Menon leads it."
Menon wrote it down with the expression of someone who has been waiting to be given permission for something they've been planning in secret for six months.
"Two: the railway management game. Sheher but for railways. I have a brief — three pages. It's in Aditya's office. Pradeep leads it."
Pradeep wrote it down.
"Three: the controller. Deepak Sharma finalizes the production specification this week. Every Siddharth-2 sold from Dussehra includes the controller. This is not optional."
Sharma wrote it down and then looked up. "The production run. How many controllers for the first batch?"
"Forty thousand," Karan said. "Matching the projected package sales."
"The controller tooling will take—"
"Talk to Aditya," Karan said. "He's working the production schedule."
"Four: Shergill Game Studio is a separate brand from today. The packaging says Shergill Game Studio. The games say Shergill Game Studio. The Shergill Industries relationship is in the legal footnotes. When a child in Delhi or Bombay or Madras opens the Computer Club package, they are opening something from a games company, not from an industrial conglomerate."
He stood.
The room watched him.
"The platform is the Siddharth," he said. "The games are why you need the platform. What we built in this room in five months — this is the reason a family that doesn't need a computer buys a computer."
He looked at the Paathashaala screen, which was still running, still waiting, the question still there.
What do you want to do today?
"Good work," he said.
He left the room.
Outside, the Gorakhpur industrial complex was doing what it had been doing for six years — the continuous, organized energy of a place that had found, in the building of things, the specific satisfaction of a machine that had learned its purpose. Turbine housings and pharmaceutical batches and software systems and, now, games. All of it made in the same place by people who had been given a clear problem and the resources to solve it and the latitude to solve it well.
Inside Building Four, in the small testing room, Ravi Menon played Karo.
The blocks fell.
He placed them.
A line completed and vanished. The stack lowered slightly. More blocks fell.
He had built this. This specific interaction between a person and a screen. This specific arrangement of falling shapes and the problem they posed to the person watching them. This specific experience of the stack breathing — rising and falling and rising again.
He hadn't known he was building it when he started. He'd been following a question.
He was still following the question.
He played until level six, which was the furthest he had gone since the speed curve adjustment. At level six the blocks fell in under a second. He wasn't thinking about individual pieces anymore. He was thinking about the shape of the board, the options it presented, the space he needed to preserve for the pieces that hadn't come yet.
He lasted four minutes at level six.
When the stack finally reached the top he sat back and looked at the score.
Then he loaded it again.
There was still more to understand.
There always was.
End of Chapter 223
