Reflections

Cricket Manager - Devlog Entry #4

Sun, 26 Jan 2025 04:30:00 +0000

Cricket Manager - Devlog Entry #4

In my last devlog, I talked about how the game was close to being ready for a closed alpha release. We have moved past that and now are in a beta with about 60 users. In the meantime the codebase has expanded to over 50000 lines of code and the game is now in a state where most of the core features are implemented.

What’s done?

Of the core features the ones to highlight are:

A fully functional league system with relegation and promotion
A player training system with skill development and experience effects.
A knockout cup for all players in the game.
A youth player academy with the ability to recruit young players.
4 different types of pitches with its unique attributes.
3 different types of weather conditions.

Key Learnings

Make isolated changes

The last 6 months have seen a lot of changes to the codebase. Small changes can sometimes have a huge impact in games like this, while sometimes huge changes can have a minimal impact. A key learning is to ensure things that affect each other are done in a way that is easy to understand and modify. Pitches and weather conditions are a good example of this. Having released both together, it was a huge challenge to make changes to one without affecting the other and to figure out whether the changes worked correctly.

Statistical Analysis is hard

Statistical analysis is a hard problem. It is not just about the numbers, but also about the context in which they are presented. For example, a player’s batting average is a good indicator of their ability, but it is not the only indicator. A player’s performance in different conditions, different pitches, and different opponents can all affect their batting average as well as their Strike Rate. Most things take a lot of data to ensure that the results are statistically significant.

The importance of a good UI

The UI is the first thing that a user sees when they open the game. It is the first impression and the first thing that a user interacts with. A good UI is not just about the looks, but also about the ease of use and the functionality. The last 6 months have seen a lot of improvements to the UI and I am learning more as I go along. To that regard, I have invested in Refactoring UI to learn more about UI design and how to make better UI.

Challenges

As the game grows the main challenge is to ensure the infrastructure is scalable and cost effective. Vercel has been great so far, but now we are past the limits of the free tier. Turso continues to be a great option for the database and currently at 40% usage. The main problem area is Clerk which is a great product, but has certain quirks like turning the entire app to dynamic rendering or preventing indexing by search engines. While these are not insurmountable problems, the fact that they are hidden in the documentation makes it hard to figure out how to fix them.

What’s next?

The game is now beginning to enter the more interesting phase. The core features need to expandeded to make it more realistic and fun. To that regard, the Match Engine needs a lot of work to incorporate things like fitness, fatigue and fielding. A player traits system is also being planned to make the players more realistic and interesting.

Cricket Manager - Devlog Entry #3 Gaining Momentum

Sun, 30 Jun 2024 04:30:00 +0000

Cricket Manager - Devlog Entry #3 Gaining Momentum

In the last devlog, I outlined what was in the works for Cricket Manager. Things have moved fast in the last 4 weeks as I have been working pretty much full time on the game.

Write Once to Throw away

The classic Unix philosophy of “Write once to throw away” is perfectly applicable in my case. With the initial codebase being a messy mass of code written pretty much in ad-hoc manner, it was the perfect opportunity to put to good use the good old unix philosophy. It also allowed me to focus on the pure technology side of things without bothering about the core logic as that I have already worked on previously.

Changing the tech stack

With the decision made to rewrite things from scratch, changing the tech stack was easy. Now with almost a year of experience I was better equipped to make decisions, rather than pick what looks easy in the first Iteration. The new tech stack comes with production grade chops at various big companies, so the capabilities of the stack was not in question, only question is in my abilities.

NextJS

The crux of the app is being built in NextJS which is a very capable framework and has seen great updates in the last one year, especially with the app router and the React Server Components. NextJS is a perfect fit for the app as it the serverless patterns are great for a read heavy app like this.

ShadCn UI

ShadCN UI has taken the world by storm in the past year, with its beautifully crafted UIs which are open source. Built on top of RadixUI which takes care of accessibility, these components were a game changer as it allows us to develop fast with a great UI that is ready to use.

Clerk

Authentication is a hard problem, and getting auth right is even harder. The clever folks at Clerk has managed to create a beautiful solution which is super simple to integrate and takes away a bunch of headaches. Moving to clerk has meant we are able to support Google Auth and Email with OTP in the first version of our app.

Turso

Sqlite is a brilliant technology. I have been using it to develop locally since the beginning, with the thought that eventually it will be migrated to Postgres/MySQL. And then came Turso, a company with the aim of taking SQLite to production. With a generous free tier, they are a lifesaver and now we are using them.

Vercel

Vercel the company behind NextJS has been doing some great work in the ecosystem and another one with a generous free tier. Their services make it simple to deploy and make changes quickly. Setting these things up manually takes a lot of time, and I am really happy to have made the decision to move to them.

So where are we now?

At this point of time, we are fairly close to the closed alpha release. The bot vs bot games have been running successfully since 23rd June, 2024 and revealed a few bugs which are being resolved. The UI is almost done, with a few tweaks here and there. The game engine is working well and the bots are able to play the game.

What’s next?

User teams and friendlies are next up in line. And the match engine needs to be updated to take user orders into account. Once that is done we would be ready to play user games. I am expecting to be able to run friendlies by mid July,2024 and user leagues by end of July, 2024.

Cricket Manager - Devlog Entry #2

Wed, 29 May 2024 04:30:00 +0000

Cricket Manager - Devlog Entry #2

It’s been almost a year since I last updated you on the progress of Cricket Manager. A lot of time has passed, and the progress hasn’t been as fast as I would have liked. However, I’m excited to share with you the latest developments and where we stand today. The last few months have been extremely frustrating, with a lot of my ideas and experiments not yielding the desired results. But I’ve learned a lot from these setbacks and am more determined than ever to make Cricket Manager a reality.

What have I learned?

One of the key lessons I’ve learned over the past year is the importance of setting realistic goals and expectations. When I started working on Cricket Manager, I had grand visions of creating a fully-fledged cricket simulation game with all the bells and whistles. However, as I delved deeper into the development process, I realized that my initial scope was too ambitious for a solo developer like myself. Moreover I was trying to build a game that was too complex and feature-rich for my first project. I had also not budgeted enough time for learning new technologies and experimenting with different approaches. All these meant the features built were a hotchpotch of different technologies and approaches, leading to a lot of technical debt and bugs. Nothing worked in coherence and a lot of time was spent in debugging and fixing issues.

The importance of planning

Another important lesson I’ve learned is the importance of planning and breaking down tasks into smaller, manageable chunks. When I started working on Cricket Manager, I had a rough idea of what I wanted to build, but I didn’t have a clear roadmap or timeline. This led to a lot of wasted time and effort as I jumped from one task to another without a clear direction. I also didn’t prioritize tasks properly, which meant that I spent a lot of time on low-priority features while neglecting critical ones.

This effort has given me a new perspective on Software Engineering in general and I have started to appreciate the hard work that Project Managers and Software Architects put in to make a project successful. This has also made me realize that I need to be more disciplined and organized in my approach to development.

Starting with a blank canvas

Given the technical debt and bugs in the current codebase, I’ve decided to start from scratch and build Cricket Manager using a more structured and disciplined approach. I’ve spent the last few days planning out the game mechanics, features, and architecture, and I’m confident that this time around, I’ll be able to build a more robust and scalable game.

Also I am making a significant commitment to mysef to document my progress and learnings in this devlog series. I hope that by sharing my experiences with you, I can not only hold myself accountable but also provide valuable insights to other developers who may be facing similar challenges. As a result I will be updating this devlog series more frequently and will be sharing my progress and learnings with you.

What’s next?

In the coming weeks, I’ll be focusing on building the core game mechanics and features of Cricket Manager. I’ll be using a more structured approach this time around, breaking down tasks into smaller, manageable chunks and prioritizing them based on their importance. I’ll also be experimenting with different technologies and approaches to see what works best for the game.

Please follow Cricket Manager on twitter/X to get the latest updates and insights into the development process.

Cricket Manager - Devlog Entry #1

Fri, 14 Jul 2023 11:30:00 +0000

Introducing Cricket Manager - Devlog Entry #1

Introduction

Welcome to the first devlog entry for Cricket Manager, a new game that puts you in the shoes of a cricket team manager! If you’re a fan of cricket and have ever dreamed of running your own team, then this is the game for you. On June 16th, 2023, I announced the intention of building a game like this and was overwhelmed with the interest in our small group of cricket enthusisats. I’ve been hard at work since then bringing the vision of Cricket Manager to life.

Throughout this devlog series, I’ll provide regular updates on our progress, share insights into our development process, and give you a behind-the-scenes look at how Cricket Manager is shaping up. I hope to engage with our community, gather feedback, and incorporate your ideas into the game’s development.

What is Cricket Manager?

As passionate cricket enthusiasts ourselves, we wanted to create a game that captures the essence of this beloved sport. With Cricket Manager, our goal is to deliver an engaging simulation that combines the thrill of cricket matches with the strategic elements of team management. From selecting the starting lineup to devising match tactics, every decision you make will have an impact on the outcome.

Prototyping:

During this month, myself and a group of decicated cricket fans spent significant time to brainstorming and prototyping various ideas for Cricket Manager. We aimed to establish a solid foundation for the game mechanics and core features. Through experimentation and iteration, we explored different ways to simulate the management aspects of cricket.

Tech Stack Evaluation:

In the early stages, I chose to use AdonisJs as the framework for building Cricket Manager. However, as I progressed with development, I realized that AdonisJs did not align with our preferred development approach. I found its custom nature and conventions to be less suitable for our project requirements and personal preferences. After evaluating various options, I found that RedwoodJS aligned perfectly with our development goals for Cricket Manager. RedwoodJS is a full-stack JavaScript framework that incorporates React , GraphQL, Prisma, and other proven technologies. This combination not only ensures a modern and efficient development workflow but also provides a robust ecosystem for building scalable web applications.

API Development:

Creating a robust and efficient API is essential for enabling smooth communication between the frontend and backend of Cricket Manager. As a result a lot of time and effort went designing and implementing the API endpoints using RedwoodJS and GraphQL. This allows us to define the data structure, query capabilities, and mutations required to support the game’s functionality.

What’s Next?

As we progress into the next phase of development, we will continue refining the API and UI integration for Cricket Manager. We will focus on implementing additional features, enhancing the UI visuals, and ensuring smooth interactions between the frontend and backend.

Testing plays a vital role in identifying and addressing any issues or bugs, ultimately enhancing the overall quality of the game. As a result we will be implementing automated testing to ensure that the game functions as intended.

Conclusion:

As I reflect on the past month of development for Cricket Manager, it has been a rollercoaster ride filled with both joy and frustration. The journey has been marked by significant learning experiences and countless opportunities for experimentation. I have grown as developer, and I am excited to see what the future holds for Cricket Manager. Thank you for joining us on this incredible adventure so far, and I can’t wait to share more updates and progress with you in the coming months.

Stay Connected:

Screeps AI: State of the world at the beginning of 2023

Sun, 15 Jan 2023 14:00:00 +0000

The Screeps OS I had been writing has been writing in the previous part was good enough to deploy at the beginning of October. The nascent AI began with a new spawn and slowly started to gather energy. Quite a few bugs in the OS came up and as fixes rolled in, the stability improved. The OS doesnt add much benifit to the AI yet, which is something I hope to improve in future.

The AI itself is fairly autonomous till RCL3. Its not efficient but does a decent job till RCL3. Beyond that it is dependent on manual input for all buildings. Once the construction sites are laid though it manages to build them and use them.

Logic overview

General Economy

The AI logic is very simple at the moment. It starts off with generic moving harvesters at the beginning and then moves to Continuous harvesting. The harvesters are using drop mining at the moment so the maximum efficiency of energy mining can be 90%. In practice it is about 78%. After drop mining starts, haulers, builders and upgraders are created and they just are the same creep structure but run different role code. Each Room runs about 8 upgraders, 4 haulers, 4 builders and 2 harvesters with a creep count of 18. This takes about 6 CPU per room so the AI is almost using 17-18 CPU for the 3 rooms. There is not much potential for growth in this AI.

Defense

We are using a passive defense at the moment. We have towers which shoot the enemy as soon as they are in the room. Again not the most efficient but keeps the creeps safe. A few creeps die though everyday if they are close to the enemy.

Storage

Storage is not very efficiently used. The only good use is a container near the upgraders who pick energy from it reducing movement. There is a lot of potential for improvement in this part of the AI.

Claiming New Rooms

I had reached GCL3 in the previous iterations of the AI so claiming rooms was something I could do. Claiming is a manual process with a flag called “claimThisRoom” and the spawns creates a claimer. The claimer than walks over and claims the controller. After that Spawn is created with a builder being sent from the nearby rooms. There are a few bugs in this but works well enough that I was able to claim 2 new rooms by mid november.

Performance

The 3 rooms are fairly stable and at the time of writing in mid January all of them are at RCL7. Our GCL is up to 6 so we can pick 3 more rooms when our AI improves.

The results of the last 3 months in the leaderboard are below:

December 2022, was the best month so far for us, with the rank of 388 with 18.5m control points. The code upto this point is here.

Future Plans

In the next iteration, we would love to work on the following parts of the AI:

Get room CPU usage down to 5 so we can pick up our next room.
Use of specialised creep body structures for efficent energy usage
Improve towers to be able to repair.
Improve to Container Minining and if possible to link mining.

Screeps AI: Building an Operating System

Sun, 21 Aug 2022 14:00:00 +0000

After playing through for some time in screeps, it is abundantly clear that CPU management is an important part of the game. I have been ignoring it for the most part because I was still far away from the original 20 CPU limit but I was beginning to see how it would be a limiting factor.

After going through the discord channel of Screeps, I decided to develop an operating system for the AI. The operating system model is used by quite a few top players so developing it early seemed a good idea.

Writing an Operating System for screeps

At the very least the operating system system needs a Kernel, which will be responsible for running the various processes in the AI. The processes are scheduled by a Scheduler and there is also a process framework.

Kernel

The Kernel is a very simple class which launches the base AI process. It is also responsible for running the processes that are scheduled by the scheduler. The Kernel also looks after the CPU limits. The rudimentary kernel is sufficient for now but will need to have more features as the OS evolves.

Scheduler

The scheduler of our OS is inspired by Quorum, an opensource bot for Screeps. Though Quorum’s scheduler is much more advanced, I have only implemented the basic parts needed for the OS to start working.

Current Features of the Scheduler

The scheduler can launch new processes as a parent or a child process.
There are multiple queues with a ReadyQueue, RunningQueue and CompletedQueue.
At every tick the scheduler will reschedule completed processes for the next tick.
Provides the kernel with a new process PID when the kernel asks.
Stores metadata about a process so it can create the process on a tick.

Additional Features useful but not yet implemented

Ability to suspend processes.
Ability to kill processes
Cleaning up of memory for killed processes.

Processes

At the heart of any OS is the ability to run user processes. The implementation of process in our OS follows the ideas of Java threads. Each process when launched can do some work for initialization and is analogus to how constructors work.

The runnable part of the process comes from the kernel calling it’s main function. As a result all our process must have a main function. This is enforced by the OS by having all runnable process inherit from a base Process class and having the main method abstract in the process class.

The code upto this point can be seen here

Screeps AI: First Rewrite and moving to Typescript

Mon, 01 Aug 2022 14:00:00 +0000

This is the second part of my journey in screeps. In the first part I spoke about how the use of javascript in writing the AI was extremely errorprone. So based on that the plan was to use Typescript and create a functioning AI. This proved to be hard as learning Typescript was not as simple as it seemed initally. The language has its own interesting features and tooling so it took me some time to figure out how to get things working in Typescript.

Screeps-Typescript-Starter is a really good point to start building the AI in screeps.

Design on the AI

At the base of the AI is the the concept of Managers who decide and control the activities of the entire system.

The Room Managers are responsible for all the functions of the room.
The Worker Managers are responsible for the working of the creeps.
The Building Managers are responsible for building of infrasructure.

The three managers have been quite good in helping us progress in screeps.

Different Types of Creeps

Harvester: These creeps are the most basic and their job is to harvest energy from the sources and pass them to the spawn and extensions.
Upgraders: These look to upgrade the room controller.
Builders: They build all the infrastructure needed for the room.
Continuous Harvester: They are specialized harvesters which only have WORK and MOVE parts. Their job is to harvest the energy.

Features of the AI:

The AI at the moment tries to go up to RCL level 2 and then create 5 extensions and roads to the spawn to the energy sources. This helps speed up operations and from there it grinds up in levels. All other structures have to be placed manually and the AI will build it.

Defense

The AI has basic defense code as well as long as we can manually create a tower and the AI will use it to defend against the NPC attackers that spawn from time to time.

Future Plans

The next target for the AI is to be automatically creating more extensions at RCL3. Also I will be looking into container mining as it is considered more efficient.

Screeps - An MMO for Programmers

Fri, 04 Feb 2022 14:00:00 +0000

Hello World!!! Been a long time. I recently found about the MMO game Screeps, its a game with a unique twist. Its unique in the sense that it is a MMO that needs the players to code to run their empire. There is a CPU limit of 20ms to run all the code on every tick, which means efficiency plays a huge role in this. This is an attempt to make an AI and I will be cronicling the journey on my blog

Beginning steps

The tutorial of the game gets us up in a fairly quick manner and it seems simple and easy. Well as we dip our feet in the game, it becomes abundantly clear that there is a lot to learn in the game and we are the bottom of the pile.

The discord group for the game is a very helpful bunch and I ask a lot of questions. As I get my first bot up, it is a slow and steady progress.

Familiarizing with the API and basic tasks

The first iteration of the bot came up as very basic modification of the tutorial and there is not much going on otherwise. The basic bot is a single worker who is jack of all trades- harvesting energy, hauling it to the spawn and then upgrading the structures. While this is very easy to get up and running, it runs into its limitations very soon. More specialized workers is where I reach in a couple of days.

The bot is performing fairly well but coding in Javascript can be errorprone. Also the fact that there is no real way of “running” the code without actually uploading the code makes it hard to catch bugs.

So we decide to end V0 of our bot and rewrite everything in Typescript to be able to work in the relative safety of OOPS and Type safety.

The code at this point is here

Murphy's Law takes me for a ride

Sun, 08 May 2016 14:00:00 +0000

Murphy’s Law “What can go wrong, will go wrong” has a nice ring to it except when it hits. Then you have no option but to be frustrated and think “come on, this can’t get worse” and it would just go worse. It hit me today, just as I was about to leave to visit a few friends. I was in Koramangla, Bangalore and as I was about to leave the Bangalore weather gods decided it was time to rain. As always happens when it rains, cabs of Ola and Uber go into surge faster than the droplets of rain.

So the smart ass in me decided to take an Ola Share. Destination is 30 minutes away as per Google maps, which by now has got hang of the Bangalore traffic and gives pretty good estimates. Despite a plethora of cabs in the one minute vicinity, Ola gives me one in that’s about 10 minute away. Fifteen minutes later the cab arrives and I get in. Google Maps shows a nice little shortcut that we take only to see it is blocked off due to repairs. A round of asking and we reach Ejipura Signal from where a right turn means my destination is 7 Km away.

But we need to take right, for there is another rider who is 1.5 km away. We navigate the mains and crosses like a pro(Thanks to Google Maps), pick the passenger and we are on the way. We reach the place where I was waiting about 20 minutes earlier and this time smarted by the goof-up last time we don’t take the shortcut but the well-known road to Ejipura Signal.

Oh we need to take right again, for my co-passenger’s destination is 3 km to the right and being nearer will be dropped off first which makes sense. Another 15 minutes later we reach the destination but then the person doesn’t have change and needs to get it from home. Change is retrieved pretty soon and we move forward when a person lets us know it is a dead-end ahead.

Now we need to turn but the road is narrow for bikes and cars are parked on it. We move ahead but no clearing in view to take a turn. Finally we find a kind soul who lets us use his parking lot to take the turn. As I think, finally now we can move, we see another car behind has had stalled in its attempt to turn. That car is a hatchback and can manage to turn but the driver is not very experienced and struggling not to hit a bike and still turn. His friends help him out by pushing the bike out somehow and my driver who shouts off some expert advice. He turns finally and his friends hop in and all is well in the world.

Or is it, the bike they pushed has now blocked our path and as we are about to get down to remove the obstacle, rain returns in full force. Luckily the owner arrives in the nick of time and saves me the trouble of pushing a bike in the rain. We start our journey again but we have not yet got out of that narrow road when a reversing water tanker greets us and we are forced to get back. We can only watch as the tanker provide water to the houses in the area. Ten minutes later a car pulls out of the roadside parking and my driver with the expertise of driving cabs in Bangalore for years manages to squeeze the car out. So after just over an hour in the car and further from my destination then when I started, frustration is enough to start writing this blog.

The rain and traffic ensured the journey was longer and in the next fifty minutes of traveling and writing, my destination is near. Oh wait, why has my driver taken a wrong turn. “Sorry Sir, galti ho gaya”(Sorry Sir, it was a mistake). We take a U-turn but as Murphy’s law would have it right turns are prohibited from there and we have to go to the next signal which is over a kilometer away and the road is full of traffic.

Finally have got through the signal to get back on the correct route and it is now over 2 hours into the journey. There are no more hiccups as I reach my destination five minutes later. Rain has also stopped. Probably all is well now. Or is it….

The Season of Goodbyes 2

Sat, 12 Sep 2015 00:10:00 +0000

Since the last post in this season of goodbyes, Kumar Sangakkara has played his last test and Brad Haddin has retired as predicted in the last post. Ian Bell and Shane Watson has also said adios to the formats they were least effective.

Kumar Sangakkara, like old wine, got better with age as he developed from a wicket keeper batsman to the mainstay of the Sri Lankan batting and then to one of the legends of Cricket. His sublime touches, with the lazy elegance that makes left-handers look special was a joy to behold. As the prized wicket in the lineup, (no disrespect to Mahela Jayawardene, his partner in crime on many occasions) he was often the difference between victory and defeat. As a neutral watching him was one of the delights of the day in cricket.

Ian Bell and Shane Watson are two players who on their days could be world beaters but almost unselectable on the others. Watson never quite mastered the Tests and Bell was similar in ODIs, but both provided some fine displays. Watson opening the bat in Tests was exemplary in how a batsman could curb his natural game. For Bell the occasional bursts of aggressive intent when he opened in ODIs showed his stroke making ability. It’s ironical how both performed well while opening in their least preferred formats. But then that’s life.