LLEADERBOARD SYSTEM FOR

GAMING APPLICATIONS

A PROJECT REPORT

Submitted by

MURALI KRISHNA R P

in partial fulfillment for the completion of the course

EGB1121 – DATA STRUCTURES

in

ELECTRONICS AND COMMUNICATION ENGINEERING

K.RAMAKRISHNAN COLLEGE OF TECHNOLOGY

(An Autonomous Institution, Affiliated to Anna University Chennai and Approved by AICTE, New Delhi)

SAMAYAPURAM – 621 112

JUNE 2025

i
 LINKED LIST - BASED
ADDRESS BOOK APPLICATION

A PROJECT REPORT

Submitted by

MURALI KRISHNA R P (2303811710421030)

in partial fulfillment for the completion of the course

EGB1121 – DATA STRUCTURES

in

ELECTRONICS AND COMMUNICATION ENGINEERING

K.RAMAKRISHNAN COLLEGE OF TECHNOLOGY

(An Autonomous Institution, Affiliated to Anna University Chennai and Approved by AICTE, New Delhi)

SAMAYAPURAM – 621 112

JUNE 2025
i
 K.RAMAKRISHNAN COLLEGE OF TECHNOLOGY
(AUTONOMOUS)
SAMAYAPURAM – 621 112

BONAFIDE CERTIFICATE

Certified that this project report titled “LEADERBOARD SYSTEM FOR GAMING

APPLICATIONS” is the bonafide work of MURALI KRISHNA R P

(2303811710421030) who carried out the project under my supervision. Certified

further, that to the best of my knowledge the work reported here in does not form part of

any other project report or dissertation on the basis of which a course was conferred on an

earlier occasion on this or any other candidate.

SIGNATURE SIGNATURE
Dr. S. Syed Akbar, M.E., Ph.D., Mrs. M. Mathumathi, M.E., (Ph.D.),
HEAD OF THE DEPARTMENT SUPERVISOR
Assistant Professor Assistant Professor
Department of ECE Department of CSE
K.Ramakrishnan College of Technology K.Ramakrishnan College of Technology
(Autonomous) (Autonomous)
Samayapuram – 621 112 Samayapuram – 621 112

Submitted for the viva-voce examination held on …………….

INTERNAL EXAMINER EXTERNAL EXAMINER

i
 DECLARATION

I declare that the project report on “LINKED LIST - BASED ADDRESS BOOK
APPLICATION” is the result of original work done by us and best of our knowledge, similar
work has not been submitted to “ANNA UNIVERSITY CHENNAI” for the requirement of
Degree of BACHELOR OF ENGINEERING. This project report is submitted on the partial
fulfillment of the requirement of the completion of the course EGB1121 – DATA
STRUCTURES.

Signature

MURALI KRISHNA R P

Place: Samayapuram
Date:

ii
 ACKNOWLEDGEMENT

It is with great pride and gratitude that I express my heartfelt thanks to our
esteemed institution, K. Ramakrishnan College of Technology (Autonomous), for
providing me with the opportunity to undertake this project.
I am grateful to our honourable Chairman, Dr. K. Ramakrishnan, B.E., for
providing the necessary facilities and support throughout the course of my study at the
college.
I would like to express my sincere thanks to our beloved Executive Director,
Dr. S. Kuppusamy, MBA, Ph.D., for approving my project and offering the adequate
duration in completing my project.
I wish to thank our respected Principal, Dr. N. Vasudevan, M.Tech., Ph.D., for
giving me the opportunity and guidance to execute this project to the best of my
knowledge and abilities.
I wish to convey my heartfelt thanks to Dr. S. Syed Akbar, M.E., Ph.D.,
Head of the Department, Electronics and Communication Engineering, for his
constant encouragement and support in pursuing this project.
I wish to express my deep and sincere gratitude to my project guide,
Mrs. M. Mathumathi, M.E., (Ph.D.), Department of Computer Science and
Engineering, for her invaluable suggestions, creativity, assistance, and patience, which
greatly motivated me to carry out this project successfully.
I sincerely thank the Course Coordinator and all the faculty members of the
department for their valuable insights and support throughout the project.
I would like to extend my special thanks to the officials and lab technicians of
our department for their timely help and assistance during the progress of my work.

iii
VISION OF THE INSTITUTION
To serve the society by offering top-notch technical education on par with global standards.

MISSION OF THE INSTITUTION

We will strive to
M1: Be a center of excellence for technical education in emerging technologies by exceeding
the needs of the industry and society.
M2: Be an institute with world class research facilities.
M3: Be an institute nurturing talent and enhancing the competency of students to transform
them as all-round personality respecting moral and ethical values.

VISION OF THE DEPARTMENT

To create innovative and socially responsible Electronics and Communication Engineers with
design skills and research focus to meet Societal and Industrial needs.

MISSION OF THE DEPARTMENT

M1: To provide high quality education and professional ethics to students through enhanced
learning environment.
M2: To impart a creative environment towards centre of excellence in department with design
skill and exposure for research.
M3: To nurture required employable skills of students to satisfy the industry and social needs
with ethical and human values.

PROGRAM EDUCATIONAL OBJECTIVES

PEO1: Core Knowledge Development
Graduates will have enhanced engineering skills in the field of electronics,
communication and interdisciplinary areas to serve the society with global standards.
PEO2: Professional development
Graduates will apply the technical knowledge for continuous up gradation of their
professional skills to become an inimitable employee, researcher or entrepreneur.
PEO3: Analytical Thinking
Graduates will have analytic and thinking skills to provide the innovative solutions for
industry and societal requirements.

iv
PROGRAM OUTCOMES (POs)
Engineering students will be able to:
1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex engineering
problems.
2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences
3. Design/development of solutions: Design solutions for complex engineering problems
and design system components or processes that meet the specified needs with appropriate
consideration for the public health and safety, and the cultural, societal, and
environmental considerations
4. Conduct investigations of complex problems: Use research-based knowledge and
research methods including design of experiments, analysis and interpretation of data,
and synthesis of the information to provide valid conclusions
5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modeling to complex
engineering activities with an understanding of the limitations
6. The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, health, safety, legal and cultural issues and the consequent responsibilities
relevant to the professional engineering practice
7. Environment and sustainability: Understand the impact of the professional engineering
solutions in societal and environmental contexts, and demonstrate the knowledge of, and
need for sustainable development
8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities
and norms of the engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member or
leader in diverse teams, and in multidisciplinary settings.
10. Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give
and receive clear instructions.
v
11. Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member
and leader in a team, to manage projects and in multidisciplinary environments.
12. Life-long learning: Recognize the need for, and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.

PROGRAM SPECIFIC OUTCOMES (PSOs)

PSO1: To analyze, design and develop solutions by applying foundational concepts of
electronics and communication engineering.
PSO2: To apply design principles and best practices for developing quality products for
scientific and business applications.
PSO3: To adapt to emerging information and communication technologies (ICT) to innovate
ideas and solutions to existing/novel problems.

vi
 ABSTRACT

The leaderboard system for gaming applications abstracts the complexity of

ranking players by their scores into an efficient, scalable, and user-friendly solution,

utilizing a Max-Heap (implemented via Python’s heapq with negated scores for

highest-score prioritization) to manage real-time score updates and retrievals. This

Priority Queue ensures O(log⁡n) O(\log n) O(logn) time complexity for inserting

new scores or updating existing ones and O(klog⁡n) O(k \log n) O(klogn) for

fetching the top k k k players, where n n n is the number of players. A dictionary

tracks the latest scores per player, enabling lazy deletion to handle updates without

costly heap modifications, thus maintaining performance under frequent score

changes. Integrated with a Gradio interface, the system provides an interactive web-

based UI, allowing users to seamlessly add or update scores (via player ID and score

inputs), view the top k k k players in a formatted list, and reset scores to zero, with

robust error handling for invalid inputs like non-integer IDs or negative scores. The

abstraction encapsulates heap operations and data validation, presenting a simple yet

powerful interface for gamers and developers. Extensible for advanced features like

tabular outputs, dynamic visualizations (e.g., bar charts of top scores), or persistent

storage, this system ensures low-latency updates, scalability for large player bases,

and an engaging user experience, making it a versatile backbone for competitive

gaming applications.

vii
 TABLE OF CONTENTS

CHAPTER NO. TITLE PAGE NO.

ABSTRACT vii
LIST OF FIGURES ix
LIST OF ABBREVIATIONS x
1 INTRODUCTION
1.1. Purpose and Importance 1
1.2. Problem Statement 2
1.3. Objective and Overview 3
2 PROJECT METHODOLOGY
2.1. Introduction to System Architecture 5
2.2. Architecture Diagram 5
3 DATA STRUCTURES METHODOLOGY
3.1. Overview of Data Structures Used 9
3.2. Reasons For Choosing Max-Heap 10
And Dictionary
3.3. Comparison with other Data Structures 13
3.4. Advantages and Disadvantages 14
4 MODULES
4.1. Module Description 16
4.1.1. Add/Update Score 16
4.1.2. Get Top k k k Players 17
4.1.3. Reset Score 18
4.1.4. View Top k k k Players 18
5 RESULTS AND DISCUSSION
5.1. Conclusion 20
5.2. Limitation and Future Scope 20
APPENDIX A (SOURCE CODE) 22
APPENDIX B (SCREENSHOTS) 26

viii
 LIST OF FIGURES

FIGURE NO. TITLE PAGE NO.

Fig.2.1 Leaderboard System Architecture 7

Diagram

Fig.B.1 Output Screenshots 26

ix
 LIST OF ABBREVIATIONS

AVL - Adelson-Velsky and Landis Tree

BST - Binary Search Tree

ID - Identifier

GUI - Graphical User Interface

x
 CHAPTER 1

INTRODUCTION

1.1 PURPOSE AND IMPORTANCE

Purpose:
The leaderboard system is designed to rank players in gaming applications based on
their scores, providing a real-time, efficient, and interactive mechanism to track and display
top performers. By leveraging a Max-Heap (Priority Queue) for score management and a
Gradio interface for user interaction, the system ensures fast updates and retrievals while
offering an intuitive web-based UI for players and administrators. The purpose is to enhance
the gaming experience by fostering competition, enabling instant feedback on rankings, and
simplifying score management with minimal latency.

The leaderboard system is an essential component of gaming applications, designed

to rank players based on their scores and provide a real-time, efficient, and interactive ranking
mechanism. Utilizing a Max-Heap (Priority Queue) for score management and integrating a
Gradio interface for user interaction, the system ensures rapid updates and retrievals while
delivering an intuitive web-based UI for players and administrators. By fostering competition,
enabling instant feedback on rankings, and simplifying score management with minimal
latency, the leaderboard significantly enhances the gaming experience.

Its importance is underscored by several key factors. First, player engagement is

heightened as leaderboards serve as a motivational tool, encouraging players to improve their
performance and increasing retention rates. Second, real-time updates are facilitated by the
heap-based structure, ensuring efficient O(log⁡n) insertions and modifications, which is
crucial for dynamic and fast-paced games. The scalability of the system allows it to handle
large player bases, making it suitable for both small-scale and massive multiplayer online
environments. Additionally, the user-friendly interface powered by Gradio abstracts
complex backend operations, enabling non-technical users—including players and game
moderators—to effortlessly add scores, view rankings, or reset scores.

1
 Furthermore, the system's extensibility supports future enhancements such as
visualizations, persistent storage, and integration with distributed architectures, ensuring
adaptability to evolving game requirements. Robust error handling mechanisms, including
validation checks for inputs like player IDs and scores, bolster reliability and prevent
inaccuracies that could disrupt rankings in production environments. Overall, this leaderboard
system is pivotal in creating a competitive, transparent, and engaging gaming ecosystem,
driving player motivation while ensuring optimal performance and usability.

1.2 PROBLEM STATEMENT

Managing a leaderboard in gaming applications presents significant challenges in
achieving efficient, real-time, and scalable score tracking while maintaining user accessibility
and system reliability. Traditional data structures, such as sorted lists, are inefficient for
frequent score updates and retrievals, with O(n) O(n) O(n) insertion times that become
impractical for real-time games involving thousands or millions of players. Players expect
immediate leaderboard updates when they achieve new scores or when new players join,
necessitating a system that processes insertions and updates with minimal latency. Scalability
is critical, as the system must handle large, dynamic player bases without performance
degradation, particularly in multiplayer games with frequent score changes.
Additionally, both game developers and players require an intuitive interface to
interact with the leaderboard—whether adding scores, viewing top players, or resetting
scores—without needing technical expertise. Invalid inputs, such as non-integer player IDs
or negative scores, risk disrupting the leaderboard, leading to incorrect rankings or system
failures. Efficiently managing score updates and handling ties (e.g., multiple players with
identical scores) is essential to avoid redundant computations or complex modifications to the
underlying data structure. Furthermore, presenting the leaderboard in a clear, engaging
format, such as displaying the top k k k players, and ensuring seamless interaction for players
and administrators are vital for user satisfaction.
The challenge is to design a leaderboard system that delivers efficient score
management, real-time updates, scalability, and a user-friendly interface while ensuring
robustness and extensibility for diverse gaming applications.

2
1.3 OBJECTIVE AND OVERVIEW
Objective: The objective is to develop a robust and efficient leaderboard system for gaming
applications that leverages a Max-Heap (Priority Queue) to manage player scores and a
Gradio interface to provide an interactive, web-based UI. The system aims to:
• Enable O(log⁡n) O(\log n) O(logn) time complexity for adding or updating scores
and O(klog⁡n) O(k \log n) O(klogn) for retrieving the top k k k players, ensuring
real-time performance.
• Support real-time updates for new players and score changes using lazy deletion to
handle updates efficiently.
• Provide a user-friendly interface for adding scores, viewing rankings, and resetting
scores, with input validation to prevent errors.
• Ensure scalability and extensibility for large player bases and future enhancements
like visualizations or persistent storage.
• Deliver a seamless, engaging experience for players and administrators, fostering
competition and simplifying leaderboard management.
Overview:
• Core Data Structure: The system uses a Max-Heap (simulated via Python’s heapq
with negated scores) to prioritize high scores, coupled with a dictionary to track the
latest scores per player. Lazy deletion ensures efficient handling of score updates by
marking outdated heap entries as invalid, avoiding costly heap modifications.
• Key Operations:
o Add Score: Inserts a new score or updates an existing player’s score in
O(log⁡n) O(\log n) O(logn) time, storing the latest score in the dictionary and
adding a new heap entry.
o Get Top k k k: Retrieves the top k k k players in O(klog⁡n) O(k \log n)
O(klogn) time, skipping invalid entries (e.g., outdated scores) and formatting
the output as a ranked list.
o Reset Score: Sets a player’s score to zero in O(1) O(1) O(1) time, relying on
lazy deletion to invalidate old heap entries.
• Gradio Interface: A web-based UI built with Gradio provides three main sections:
o Add/Update Score: Input fields for player ID and score, with a button to
submit and display success/error messages.

3
 o View Top Players: An input for k k k and a button to display the top k k k
players as a formatted text list (extensible to tables or charts).
o Reset Score: An input for player ID to reset their score, with feedback on the
operation’s success or failure.
• Error Handling: Validates inputs (e.g., ensuring integer player IDs and non-
negative scores) to prevent invalid operations and ensure reliability.
• Extensibility: The system supports enhancements like:
o Visualizing top scores with charts (e.g., bar charts using Chart.js).
o Persistent storage via databases for data durability.
o Scalability through distributed systems or asynchronous updates for large-
scale games.
This leaderboard system abstracts the complexity of heap-based score management and user
interaction into a cohesive, efficient, and engaging solution, ideal for competitive gaming
environments. It ensures low-latency operations, robust error handling, and an intuitive
interface, while remaining flexible for future enhancements tailored to specific gaming
needs.

4
 CHAPTER 2

PROJECT DESCRIPTION

2.1. INTRODUCTION TO SYSTEM ARCHITECTURE

The leaderboard system for gaming applications is architected to deliver efficient,
scalable, and real-time score management with a user-friendly interface, addressing the
challenges of ranking players in dynamic gaming environments. The system comprises two
primary components: a backend built around a Max-Heap (Priority Queue) for high-
performance score processing and a frontend powered by a Gradio interface for intuitive
user interaction. The backend leverages Python’s heapq module to simulate a Max-Heap (by
negating scores), enabling O(log⁡n) O(\log n) O(logn) time complexity for inserting or
updating scores and O(klog⁡n) O(k \log n) O(klogn) for retrieving the top k k k players,
where n n n is the number of players. A dictionary complements the heap to track the latest
scores per player, utilizing lazy deletion to handle score updates efficiently by marking
outdated entries as invalid, thus avoiding costly heap modifications. This ensures real-time
updates and scalability for large player bases.
The Gradio frontend provides a web-based UI with three key functionalities: adding
or updating scores via player ID and score inputs, displaying the top k k k players in a
formatted list, and resetting scores, all with robust error handling for invalid inputs (e.g., non-
integer IDs or negative scores). The architecture abstracts complex heap operations and data
validation, presenting a seamless interface for players and administrators.
Designed for extensibility, the system supports enhancements like persistent storage,
tabular outputs, or visualizations (e.g., bar charts of top scores), making it adaptable for
diverse gaming applications while maintaining low-latency performance and user
engagement.

2.2. ARCHITECTURE DIAGRAM

To visually represent the leaderboard system's architecture, I'll describe the
components and their interactions, then provide a textual representation of the architecture
diagram in a format suitable for inclusion in a document. Since I cannot directly generate or
embed images, I'll create a Mermaid diagram (a text-based diagramming tool supported by
5
many markdown renderers) to depict the system architecture. This diagram will illustrate the
flow between the Gradio frontend, the backend logic, and the data structures (Max-Heap and
dictionary), capturing how user inputs are processed and results are displayed. The diagram
will be wrapped in an <xaiArtifact> tag as requested, using a new UUID since this is a distinct
artifact from the previous one.

The architecture diagram highlights:

• User Interaction: Via the Gradio web interface, where users input player IDs, scores,
or k k k values for operations like adding scores, viewing top players, or resetting
scores.

• Frontend (Gradio UI): Three sections for adding/updating scores, retrieving top k k
k players, and resetting scores, with input validation and result display.

• Backend Logic: Handles requests using a Leaderboard class that interfaces with the
Max-Heap and dictionary.

• Data Structures:

o Max-Heap: Manages scores for efficient ranking and retrieval.

o Dictionary: Tracks the latest scores per player and supports lazy deletion.

• Data Flow: From user input to backend processing and back to the UI for output.

Below is the Mermaid diagram code, followed by a brief explanation of its components and
flow.

6
 Fig.2.1:Leaderboard System Architecture Diagram

Explanation of the Diagram

• User: The entry point, representing players or administrators interacting with the
system via a web browser.

• Gradio Web Interface: The frontend, built with Gradio, hosting three UI sections:

o Add/Update Score UI: Accepts player ID and score inputs, with a button to
submit and a textbox for results (e.g., "Success: Added score 100 for player 1").

o Get Top k Players UI: Accepts a k k k value input, with a button to display the
top k k k players in a formatted list.

o Reset Score UI: Accepts a player ID input, with a button to reset the score and
display the result.

7
• Result Outputs: Textboxes in the Gradio UI that display operation results or the
leaderboard.

• Leaderboard Class: The core backend logic, implemented in Python, handling three
operations:

o add_score(player_id, score): Inserts or updates scores in the heap and

dictionary.

o get_top_k(k): Retrieves the top k k k players from the heap, validated against
the dictionary.

o reset(player_id): Sets a player’s score to zero in the dictionary.

• Max-Heap: Implemented using heapq with negated scores to prioritize higher scores.
Stores tuples (-score, player_id) for efficient ranking and retrieval.

• Dictionary: Maps player_id to the latest score, enabling O(1) O(1) O(1) lookups and
supporting lazy deletion by validating heap entries.

• Data Flow:

o User inputs trigger backend operations via the Gradio UI.

o The Leaderboard class processes inputs, interacting with the Max-Heap and
dictionary.

o Results (success/error messages or leaderboard rankings) are returned to the UI

for display.

• Styling: The diagram uses distinct colors to differentiate the frontend (Gradio UI) and
backend (Leaderboard logic and data structures) for clarity.

8
 CHAPTER 3

DATA STRUCTURES METHODOLOGY

3.1 OVERVIEW OF DATA STRUCTURES USED

In the development of the Leaderboard System for gaming applications, the primary
data structures employed are a Max-Heap (implemented as a Priority Queue) and a
Dictionary. These structures are chosen for their efficiency in handling dynamic score
updates, retrieving top players, and ensuring scalability in real-time gaming environments.
The system is designed to support operations such as adding or updating scores, retrieving the
top k k k players, and resetting scores, all while maintaining low latency and robustness.
• Max-Heap (Priority Queue):
o Structure: Implemented using Python’s heapq module, which provides a Min-
Heap by default. To prioritize higher scores (as required for a leaderboard where
higher is better), scores are negated, creating a Max-Heap. Each heap entry is a
tuple (-score, player_id), where score is the player’s score and player_id is a
unique identifier.
o Components:
1. Data Part: The negated score (-score) determines the priority, ensuring
the highest score is at the heap’s root.
2. Identifier: The player_id associates the score with a player and resolves
ties (e.g., identical scores are ordered by player_id).
o Operations:
▪ Insertion: Adds a new (-score, player_id) tuple to the heap when a score
is added or updated.
▪ Top k k k Retrieval: Extracts the top k k k valid entries by repeatedly
popping the heap’s root and validating against the dictionary.
▪ Lazy Deletion: Handles score updates by adding new entries and
validating old ones during retrieval, avoiding direct heap modifications.
o Purpose: The Max-Heap enables efficient sorting and retrieval of top scores,
critical for displaying leaderboards in real time.
• Dictionary:

9
 o Structure: A Python defaultdict mapping player_id to the latest score,
providing O(1) O(1) O(1) access and updates.
o Components:
1. Key: The player_id (an integer) uniquely identifies each player.
2. Value: The latest score for the player, used to validate heap entries and
store reset scores (zero).
o Operations:
▪ Update: Sets a player’s score in the dictionary when adding or updating
a score.
▪ Validation: Checks if a heap entry’s score matches the latest score
during top k k k retrieval.
▪ Reset: Sets a player’s score to zero in the dictionary.
o Purpose: The dictionary maintains the ground truth for player scores, enabling
fast updates and validation for lazy deletion.
The system handles the following operations:
• Add/Update Score: Validates inputs, updates the dictionary with the latest score, and
inserts a new entry into the heap.
• Get Top k k k Players: Traverses the heap to extract and validate the top k k k valid
scores, formatting them as a ranked list.
• Reset Score: Sets a player’s score to zero in the dictionary, relying on lazy deletion to
handle outdated heap entrie .

3.2 REASONS FOR CHOOSING MAX-HEAP AND DICTIONARY

The selection of a Max-Heap (Priority Queue) and a Dictionary as the primary data
structures for the leaderboard system in gaming applications is driven by their ability to meet
the system's core requirements: efficient score management, real-time updates, scalability,
and seamless integration with a user-friendly Gradio interface. These structures were chosen
for their performance characteristics, simplicity, and compatibility with the dynamic nature
of gaming leaderboards, where frequent score updates and top-k k k player retrievals are
critical. Below, we outline the specific reasons for selecting these data structures and their
combined benefits in addressing the system’s needs.
• Max-Heap (Priority Queue):

10
 o Efficient Top-k k k Retrieval: The Max-Heap ensures that the highest score is
always at the root, enabling retrieval of the top k k k players in O(klog⁡n) O(k
\log n) O(klogn) time, where n n n is the number of heap entries. This is essential
for displaying leaderboards in real-time gaming environments, where players
expect immediate access to rankings.
o Fast Insertions and Updates: Adding a new score or updating an existing one
takes O(log⁡n) O(\log n) O(logn), making the heap suitable for frequent score
changes, such as when players achieve new high scores or new players join the
game.
o Simplicity of Implementation: Using Python’s heapq module, the Max-Heap
is implemented by negating scores (e.g., storing a score of 100 as -100),
leveraging a lightweight, built-in library. This reduces development complexity
compared to custom heap implementations or more intricate structures like
balanced trees.
o Support for Lazy Deletion: The heap pairs effectively with the dictionary to
handle score updates via lazy deletion. Instead of removing outdated scores (an
O(n) O(n) O(n) operation), new scores are added, and old entries are validated
during retrieval, maintaining efficiency for dynamic updates.
o Tie Handling: The heap stores tuples (-score, player_id), allowing ties
(identical scores) to be resolved by player_id, ensuring deterministic ordering
without additional complexity.
• Dictionary:
o Constant-Time Operations: The dictionary, implemented as a Python
defaultdict, provides O(1) O(1) O(1) time complexity for updating and
retrieving a player’s latest score. This is critical for validating heap entries
during top-k k k retrievals and for resetting scores to zero.
o Support for Lazy Deletion: By maintaining the latest score for each player_id,
the dictionary enables the system to skip outdated heap entries during retrieval,
avoiding costly heap modifications and keeping update operations efficient.
o Minimal Memory Overhead: Each player requires only one key-value pair
(player_id: score), making the dictionary scalable for large player bases while
keeping memory usage low.

11
 o Simplified Player Management: The defaultdict automatically initializes new
players with a default score of zero, simplifying the handling of new entries and
reducing edge-case errors.
o Error Handling Support: The dictionary facilitates validation of player
existence (e.g., during reset operations) and score consistency, enabling robust
error messages (e.g., “Error: Player not found”) in the Gradio interface.
• Combined Benefits:
o Complementary Strengths: The Max-Heap excels at maintaining sorted scores
for efficient ranking, while the dictionary provides fast score validation and
updates. Together, they address the need for both real-time ranking and dynamic
score management.
o Optimized for Real-Time Updates: Lazy deletion, enabled by the dictionary’s
validation, ensures that score updates remain O(log⁡n) O(\log n) O(logn),
critical for games with frequent score changes.
o Scalability: The combination scales well for large player bases, as the heap’s
logarithmic operations and the dictionary’s constant-time lookups maintain
performance even with thousands or millions of players.
o Integration with Gradio Interface: The data structures abstract complex
operations (e.g., heap insertions, validations) into simple function calls
(add_score, get_top_k, reset), which the Gradio UI exposes as intuitive input
fields and buttons, ensuring accessibility for players and administrators.
o Extensibility: The structures support future enhancements, such as periodic
heap cleanup to manage memory, integration with databases for persistent
storage, or visualization of top scores via charts, without requiring significant
redesign.
The Max-Heap and Dictionary were chosen for their ability to deliver high performance
(O(log⁡n) O(\log n) O(logn) for insertions and updates, O(klog⁡n) O(k \log n) O(klogn) for
retrievals), simplicity through Python’s built-in libraries, and robust support for real-time,
scalable leaderboard functionality. Their integration with the Gradio interface ensures that
these technical advantages translate into a user-friendly experience, making them the optimal
choice for gaming applications where efficiency, responsiveness, and ease of use are
paramount.

12
3.3 COMPARISON WITH OTHER DATA STRUCTURES
Several alternative data structures were considered for the leaderboard system,
including sorted lists, balanced binary search trees, arrays, and databases. The Max-Heap and
Dictionary were chosen for their optimal balance of efficiency and simplicity.
• Sorted List:
o Description: Maintains scores in sorted order, updated on each insertion.
o Pros: Simple to implement, inherently sorted for easy top-k k k retrieval.
o Cons: O(n) O(n) O(n) insertion and update times due to shifting elements,
inefficient for frequent updates or large player bases.
o Suitability: Only practical for small, static leaderboards with rare updates,
unlike the dynamic requirements of gaming applications.
• Balanced Binary Search Tree (e.g., AVL or Red-Black Tree):
o Description: Stores scores in a balanced tree, supporting ordered traversal and
rank queries.
o Pros: O(log⁡n) O(\log n) O(logn) insertion, deletion, and top-k k k retrieval.
Can support rank queries (e.g., a player’s position).
o Cons: More complex to implement than a heap, with higher constant factors.
Unnecessary for basic leaderboard operations where rank queries are not
required.
o Suitability: Useful for advanced features like rank queries, but overkill for
simple top-k k k retrievals in gaming.
• Arrays:
o Description: Store scores in a fixed-size or dynamic array, sorted on demand.
o Pros: Simple for small datasets, direct access to elements.
o Cons: O(n) O(n) O(n) insertion and update times due to shifting or resorting.
Fixed-size arrays require pre-allocation, wasting memory, while dynamic arrays
incur resizing costs.
o Suitability: Inefficient for real-time updates and large datasets, unsuitable for
gaming leaderboards.
• Databases with Indexing (e.g., SQL or Redis):
o Description: Store scores in a database with an index on scores for sorting.

13
 o Pros: Persistent storage, supports complex queries (e.g., filtering by region),
scalable for large datasets.
o Cons: Slower than in-memory structures due to disk or network I/O. Adds
complexity for real-time updates in small-to-medium games.
o Suitability: Ideal for persistent, large-scale leaderboards but less efficient for
in-memory, real-time operations.
• Max-Heap and Dictionary:
o Pros: O(log⁡n) O(\log n) O(logn) insertions and updates, O(klog⁡n) O(k \log
n) O(klogn) top-k k k retrievals. Simple implementation with heapq and
defaultdict. Lazy deletion optimizes score updates. Scales well for in-memory
operations.
o Cons: Heap requires lazy deletion to handle updates, increasing memory usage
over time. No direct support for rank queries.
o Suitability: Optimal for real-time gaming leaderboards requiring frequent
updates and top-k k k retrievals, with simplicity and performance outweighing
minor limitations.

3.4 ADVANTAGES AND DISADVANTAGES

The Max-Heap and Dictionary in the Leaderboard System offer significant benefits for
gaming applications but also have limitations.
Advantages
• Efficient Operations: ( O(\log n) ) for score insertions/updates, ( O(k \log n) ) for top-
( k ) retrievals, and ( O(1) ) for dictionary operations, ensuring real-time performance.
• Dynamic and Scalable: Grows dynamically, handling large player bases without pre-
allocation.
• Lazy Deletion Optimization: Avoids costly heap modifications, maintaining
efficiency for updates.
• Simple Implementation: Uses Python’s heapq and defaultdict for ease of
development.
• User-Friendly Integration: Abstracts operations for intuitive Gradio UI interaction.
• Robust Error Handling: Validates inputs for reliability and user-friendly feedback.
Disadvantages

14
 • Memory Overhead: Lazy deletion increases heap size until cleanup.
• Sequential Access: Heap retrieval (( O(k \log n) )) slower than direct access.
• No Rank Queries: Inefficient for finding a player’s rank.
• Limited Persistence: Requires database integration for durable storage.
• Basic Tie Handling: Resolves ties by player_id, limiting custom rules.
The structures are ideal for real-time leaderboards, with limitations addressable via cleanup
or additional features like persistence.

15
 CHAPTER 4

MODULES

4.1 MODULE DESCRIPTION

The leaderboard system is structured around three core modules that manage player
scores and rankings, all accessible through a Gradio interface. These modules utilize a Max-
Heap to maintain sorted scores and a Dictionary to track the latest scores per player, ensuring
efficient operations and real-time updates. The following operations are supported to enable
users (players or administrators) to interact with the leaderboard effectively:
• Add/Update Score: Allows users to add a new player’s score or update an existing
player’s score, dynamically inserting entries into the Max-Heap and updating the
Dictionary.
• Get Top k k k Players: Retrieves and displays the top k k k players based on their
scores, formatted as a ranked list.
• Reset Score: Enables resetting a player’s score to zero, updating the Dictionary while
relying on lazy deletion to handle outdated heap entries.
These modules are integrated with the Gradio interface, which provides input fields,
buttons, and output displays for seamless user interaction. Each operation includes input
validation to ensure robustness, preventing errors such as non-integer player IDs or negative
scores.

4.1.1 Add/Update Score

This module allows users to add a new player’s score or update an existing player’s
score in the leaderboard system. When a user inputs a player_id (a unique integer identifier)
and a score (a non-negative integer) via the Gradio interface, the system performs the
following steps:
• Input Validation: Ensures that the player_id and score are integers and that the score
is non-negative. If invalid, an error message is displayed (e.g., “Error: Score cannot be
negative”).

16
 • Dictionary Update: Updates the Dictionary (player_scores[player_id] = score) with
the latest score in O(1) O(1) O(1) time, ensuring the ground truth for the player’s score
is maintained.
• Heap Insertion: Creates a new tuple (-score, player_id) and inserts it into the Max-
Heap using Python’s heapq module in O(log⁡n) O(\log n) O(logn) time, where n n n
is the number of heap entries. The negated score ensures higher scores have higher
priority.
• Lazy Deletion: Instead of removing outdated scores from the heap (which would
require O(n) O(n) O(n) to locate), the system relies on the Dictionary to validate entries
during retrieval, keeping the operation efficient.
• Output: Returns a success message to the Gradio interface (e.g., “Success:
Added/updated score 100 for player 1”) or an error message if validation fails.
The Max-Heap and Dictionary enable dynamic score management without
reorganizing existing entries, making this module efficient for frequent updates in gaming
applications. The Gradio interface provides a simple input form (textboxes for player_id and
score, with a submit button), ensuring accessibility for non-technical users.

4.1.2 Get Top k k k Players

This module enables users to retrieve and display the top k k k players based on their
scores, formatted as a ranked list. The operation is triggered via the Gradio interface, where
users input a positive integer k k k. The process involves:
• Input Validation: Ensures that k k k is a positive integer. If invalid, an error message
is displayed (e.g., “Error: k must be a positive integer”).
• Heap Traversal: Iteratively pops entries from the Max-Heap, extracting (-score,
player_id) tuples in O(log⁡n) O(\log n) O(logn) per pop. Each entry is validated
against the Dictionary to ensure the score is the latest for the player
(player_scores[player_id] == score). Invalid (outdated) entries are skipped, leveraging
lazy deletion.
• Result Collection: Collects up to k k k valid entries, storing them in a list of (player_id,
score) pairs. A set tracks seen player_ids to avoid duplicates due to outdated heap
entries.

17
 • Heap Restoration: Temporarily stores popped entries and re-inserts them into the
heap in O(klog⁡n) O(k \log n) O(klogn) time to maintain the heap’s state.
• Output Formatting: Formats the results as a ranked list (e.g., “Rank 1: Player 1 -
Score 150\nRank 2: Player 3 - Score 75”) and displays it in the Gradio interface’s
output textbox. If the leaderboard is empty, it returns “Leaderboard is empty.”
The Max-Heap ensures efficient access to the highest scores, while the Dictionary
validates entries, making this module suitable for real-time leaderboard displays. The Gradio
interface provides a textbox for k k k and a button to trigger the operation, presenting results
in a clear, user-friendly format.

4.1.3 Reset Score

This module allows users to reset a specific player’s score to zero, effectively removing
their ranking from active leaderboard displays until a new score is added. The operation is
initiated via the Gradio interface by inputting a player_id. The process includes:
• Input Validation: Ensures that the player_id is an integer and exists in the Dictionary.
If invalid or not found, an error message is displayed (e.g., “Error: Player not found”).
• Dictionary Update: Sets the player’s score to zero in the Dictionary
(player_scores[player_id] = 0) in O(1) O(1) O(1) time.
• Lazy Deletion: Outdated heap entries for the player are not removed, as this would
require O(n) O(n) O(n) to locate them. Instead, the system relies on the Dictionary to
invalidate these entries during future retrievals (e.g., in get_top_k).
• Output: Returns a success message to the Gradio interface (e.g., “Success: Reset score
for player 1 to 0”) or an error message if validation fails.
The Dictionary’s constant-time updates make this module efficient, while lazy deletion
avoids complex heap modifications. The Gradio interface provides a textbox for player_id
and a button to trigger the reset, ensuring simplicity for users.

4.1.4 View Top k k k Players

This module, closely related to the “Get Top k k k Players” operation, focuses on
presenting the leaderboard in a structured and user-friendly format through the Gradio
interface. Upon retrieving the top k k k players (as described in 4.1.2), this module ensures
the results are displayed clearly for reference or further actions. The process involves:

18
 • Input and Retrieval: Uses the same input and retrieval logic as “Get Top k k k
Players,” where the user specifies k k k via the Gradio interface, and the system extracts
valid top k k k entries from the Max-Heap, validated against the Dictionary.
• Structured Display: Formats the retrieved (player_id, score) pairs into a ranked list
(e.g., “Rank 1: Player 1 - Score 150\nRank 2: Player 3 - Score 75”) for display in the
Gradio interface’s output textbox. The format is designed to be easy to read, with clear
labels for rank, player ID, and score.
• Error Handling: Displays appropriate messages for edge cases, such as an empty
leaderboard or invalid k k k, ensuring users receive meaningful feedback.
• Extensibility: The module can be extended to display results in alternative formats,
such as a table (using a pandas.DataFrame) or a visual chart (e.g., a bar chart via
Chart.js), enhancing the user experience.

The Max-Heap ensures efficient ranking, while the Gradio interface presents the data
in an accessible format, making this module vital for maintaining an engaging and informative
leaderboard. The clear presentation of rankings fosters competition and allows users to
quickly verify top performers.

19
 CHAPTER 5

RESULTS AND DISCUSSION

5.1. CONCLUSION
The Leaderboard System successfully demonstrates the application of a Max-Heap
and Dictionary to address the challenges of real-time score management in gaming
applications. By utilizing a Max-Heap (implemented via Python’s heapq module with negated
scores), the system achieves O(log⁡n) O(\log n) O(logn) time complexity for adding or
updating scores and O(klog⁡n) O(k \log n) O(klogn) for retrieving the top k k k players,
ensuring efficient performance for dynamic gaming environments. The Dictionary
complements the heap by providing O(1) O(1) O(1) score updates and validation, with lazy
deletion optimizing score updates by avoiding costly heap modifications. Integrated with a
Gradio web interface, the system offers an intuitive UI for adding scores, viewing top players,
and resetting scores, complete with robust error handling for invalid inputs (e.g., non-integer
player IDs or negative scores). The modular design, supporting operations like add_score,
get_top_k, and reset, ensures maintainability and extensibility. Thorough testing of these
operations confirms the system’s reliability in handling real-time updates and delivering
accurate rankings. The project reinforces key concepts in data structures (heaps and hash
tables), modular programming, and UI integration, providing a scalable and user-friendly
solution for competitive gaming leaderboards.

5.2. LIMITATION AND FUTURE SCOPE

The Leaderboard System, while effective for real-time score management in gaming
applications, has limitations that impact its functionality and scalability. The Max-Heap’s
sequential access for retrieving the top ( k ) players, with ( O(k \log n) ) time complexity, is
less efficient than direct-access structures like indexed databases for large datasets or specific
queries. Lazy deletion, used to optimize score updates, causes outdated heap entries to
accumulate, increasing memory usage until periodic cleanup is performed. The in-memory
Max-Heap and Dictionary do not persist data across sessions, losing scores on application
restart, which limits long-term leaderboard use. Tie handling relies on player_id, which may
not suffice for games requiring custom rules (e.g., timestamp-based tie-breaking). The system
lacks support for advanced queries like a player’s rank, and the Gradio interface’s text-based
output, while functional, misses opportunities for engaging visualizations like tables or charts.
20
Future enhancements could address these by integrating persistent storage (e.g., SQLite or
Redis) for data durability, implementing periodic heap cleanup to manage memory, and
adding custom tie-breaking with additional fields like timestamps. Incorporating balanced
trees could enable efficient rank queries, while extending the Gradio interface with tables,
charts (e.g., bar charts via Chart.js), real-time leaderboard refresh, or player search would
enhance user engagement. For large-scale games, distributed systems like Redis sorted sets
or asynchronous message queues could improve scalability, and stricter input validation (e.g.,
for duplicate IDs or game-specific score ranges) would boost robustness. These
improvements would transform the system into a more comprehensive, scalable, and user-
friendly solution for diverse gaming scenarios.

21
 APPENDIX A

SOURCE CODE

import heapq
from collections import defaultdict
import gradio as gr

class Leaderboard:
def __init__(self):
# Max-Heap for scores (negated for max-heap behavior)
self.heap = []
# Dictionary to track player scores
self.player_scores = defaultdict(int)
# Track invalidated entries (for lazy deletion)
self.invalid = defaultdict(int)

def add_score(self, player_id, score):

"""Add or update a player's score."""
try:
player_id = int(player_id)
score = int(score)
if score < 0:
return "Error: Score cannot be negative."
if player_id <= 0:
return "Error: Player ID must be a positive integer."
self.player_scores[player_id] = score
heapq.heappush(self.heap, (-score, player_id))
return f"Success: Added/updated score {score} for player {player_id}."
except ValueError:
return "Error: Player ID and score must be integers."

def get_top_k(self, k):

"""Retrieve the top k players and their scores."""
try:
k = int(k)
if k <= 0:
return "Error: k must be a positive integer."
temp_heap = []
result = []
seen = set()
22
 # Extract top k valid entries
while self.heap and len(result) < k:
score, player_id = heapq.heappop(self.heap)
score = -score # Convert back to positive score
if player_id not in seen and self.player_scores[player_id] == score:
result.append((player_id, score))
seen.add(player_id)
temp_heap.append((-score, player_id))

# Restore the heap

for item in temp_heap:
heapq.heappush(self.heap, item)

if not result:
return "Leaderboard is empty."
# Format output as a string
output = "Top Players:\n"
for i, (player_id, score) in enumerate(result, 1):
output += f"Rank {i}: Player {player_id} - Score {score}\n"
return output
except ValueError:
return "Error: k must be an integer."

def reset(self, player_id):

"""Reset a player's score to 0."""
try:
player_id = int(player_id)
if player_id <= 0:
return "Error: Player ID must be a positive integer."
if player_id not in self.player_scores:
return f"Error: Player {player_id} not found."
self.player_scores[player_id] = 0
return f"Success: Reset score for player {player_id} to 0."
except ValueError:
return "Error: Player ID must be an integer."

# Initialize the leaderboard

leaderboard = Leaderboard()

# Gradio interface functions

def add_score_interface(player_id, score):
23
 """Wrapper for adding score via Gradio."""
return leaderboard.add_score(player_id, score)

def get_top_k_interface(k):
"""Wrapper for retrieving top k players via Gradio."""
return leaderboard.get_top_k(k)

def reset_score_interface(player_id):
"""Wrapper for resetting a player's score via Gradio."""
return leaderboard.reset(player_id)

# Create Gradio interface

with gr.Blocks(title="Leaderboard System") as demo:
gr.Markdown("# Game Leaderboard System")
gr.Markdown("Manage a gaming leaderboard with real-time updates using a
heap-based system.")

# Add/Update Score Section

gr.Markdown("## Add or Update Player Score")
with gr.Row():
player_id_input = gr.Textbox(label="Player ID (Integer)",
placeholder="Enter player ID")
score_input = gr.Textbox(label="Score (Integer)", placeholder="Enter
score")
add_button = gr.Button("Add/Update Score")
add_output = gr.Textbox(label="Result")

# Get Top K Players Section

gr.Markdown("## View Top Players")
k_input = gr.Textbox(label="Number of Players (k)", placeholder="Enter k")
top_k_button = gr.Button("Get Top Players")
top_k_output = gr.Textbox(label="Leaderboard")

# Reset Score Section

gr.Markdown("## Reset Player Score")
reset_player_id_input = gr.Textbox(label="Player ID (Integer)",
placeholder="Enter player ID")
reset_button = gr.Button("Reset Score")
reset_output = gr.Textbox(label="Result")

# Bind functions to buttons

add_button.click(
24
 fn=add_score_interface,
inputs=[player_id_input, score_input],
outputs=add_output
)
top_k_button.click(
fn=get_top_k_interface,
inputs=k_input,
outputs=top_k_output
)
reset_button.click(
fn=reset_score_interface,
inputs=reset_player_id_input,
outputs=reset_output
)

# Launch the Gradio interface

demo.launch()

25
APPENDIX B

SCREENSHOTS

Fig.B.1 Out Screenshots

26