Projects | 정진영의 포트폴리오

Pacman

Sat, 01 Mar 2025 00:00:00 +0000

This is the UC Berkeley Pacman AI project I completed as part of my Artificial Intelligence and Data Structures coursework. The core objective of this assignment was to implement fundamental Graph Search algorithms from scratch and apply them to solve tangible problems within the Pacman game environment.

My work involved implementing generic search algorithms in search.py and defining/solving specific Pacman problems in searchAgents.py.

1. Core Search Algorithm Implementation (search.py)

First, I implemented four fundamental search algorithms that can be applied to any search problem.

DFS (Depth-First Search): Using a Stack, this algorithm explores nodes as deeply as possible first. It was implemented as a graph search, using an explored list to prevent cycles.
BFS (Breadth-First Search): Using a Queue, this algorithm explores the shallowest (closest) nodes first. It guarantees the shortest path when all edge costs are uniform.
UCS (Uniform Cost Search): Using a PriorityQueue, this algorithm prioritizes nodes by their total cumulative ‘cost’. It always explores the path with the lowest cost first, guaranteeing the shortest cost path.
A* (A-Star) Search: Also uses a PriorityQueue, but its priority is the sum of the ‘cumulative cost to date’ ($g(n)$) and an ’estimated cost to the goal’ (heuristic, $h(n)$). This function is $f(n) = g(n) + h(n)$. As an informed search, it finds the optimal solution far more efficiently than UCS.

2. Defining and Solving Pacman Problems (searchAgents.py)

Beyond just implementing the algorithms, I modeled complex problems Pacman faces as formal ‘search problems’ and solved them.

📍 The Corners Problem (CornersProblem) The challenge is to find a path for Pacman to visit all four corners of the map.

State Definition: To solve this, the state space couldn’t just be (x, y). I defined the state as (currentPosition, (visitedCornersTuple)). For example, a state might be ((5, 5), (True, False, False, True)), tracking both the position and the visit-status of each corner.
Goal Definition: The goal state is reached when all boolean values in the tuple state[1] are True.
Successor Function: As Pacman moves, the function checks if the new position is one of the corners. If it is, it generates a new state with the corresponding boolean in the tuple updated to True.

💡 Corners Problem Heuristic (cornersHeuristic)

I designed a heuristic for solving the Corners Problem using A* search.

Design: A heuristic must be admissible (never overestimates the true cost).
Logic: The function calculates the Manhattan Distance from the ‘current position’ to ’every unvisited corner’. It then returns the maximum (max) value among these distances.
Justification: This is admissible because Pacman must travel at least as far as the farthest remaining corner to complete the goal. This value serves as a safe lower bound on the true remaining cost.

🍔 All Food Heuristic (foodHeuristic)

This heuristic was for the FoodSearchProblem, which involves finding a path to eat all the food dots on the map.

Logic: Similar to the corners heuristic, I calculated the actual maze distance (mazeDistance) from the ‘current position’ to ’every remaining food dot’ and returned the maximum (max) value.
Using mazeDistance: Unlike Manhattan distance, mazeDistance is a helper function that runs a BFS to find the true shortest path considering walls, providing a much more accurate (and still admissible) estimate.

🎯 Closest Dot Search Agent

Finding a path to eat all food is very complex (NP-hard). Therefore, I implemented a greedy algorithm that repeatedly finds and eats the closest food dot.

findPathToClosestDot Implementation: I defined a sub-problem called AnyFoodSearchProblem (where the goal is to reach any single food dot).
Using UCS: I applied UCS to this sub-problem. This finds the path to the food dot with the lowest cost (i.e., the closest dot). (Since costs are uniform, BFS would also have guaranteed the same result).

Phone Book Application

Fri, 20 Dec 2024 00:00:00 +0000

This is a simple mobile app I created for my “Mobile Programming” course in the 2024 fall semester. This project is a phonebook management app that utilizes fundamental Android features and a database.

First, I designed a database named phoneDB and a table named phoneTBL. This table stores a name (VARCHAR(20)) and a phone number (VARCHAR(20)). I set a UNIQUE constraint on the name column to prevent duplicates. I included two initial data entries: “Hong Gil-dong” and my own contact information.

The main features I implemented are as follows:

Main Screen (Read Data): On app launch, the app queries the database and displays all saved user names in a ListView. An “Add” button and an options menu are placed at the bottom.

Add Contact (Create): Tapping the “Add” button opens a separate Activity to receive name and phone number input. Upon completion, this information is passed back to the main Activity, saved to the database, and the ListView is immediately refreshed.

Database Initialization (Delete All): Selecting “Initialize” from the options menu displays a confirmation dialog. If the user confirms, all content in the database is deleted, and the list is refreshed.

Data Backup (Export): Through the “Backup” feature in the options menu, I implemented a function to save all names and phone numbers from the database as a .txt file (named after my student ID) to the /sdcard path.

Phone App Integration (Intent): When a specific item in the list is clicked, the app retrieves that item’s phone number and uses an Intent to immediately launch the default Android phone app with the number pre-filled.

Update & Delete: A long click on a list item navigates to a separate Activity where the selected item can be modified or deleted. I implemented confirmation dialogs for each action. Upon completion, the changes are reflected in the main Activity’s database and ListView in real-time.

Linux TCP chat program

Wed, 26 Jun 2024 00:00:00 +0000

Based on what I learned in my Linux System Programming class, I implemented a simple multi-client TCP chat program as a project.

It was a meaningful experience to directly apply the concepts of C socket communication and multithreading (pthreads). I’d like to summarize the project’s structure, core operating principles, and the key takeaways.

1. Project Overview

This program is a simple console-based (terminal) chatroom that allows a single server and multiple clients to chat in real-time over the TCP/IP protocol.

Key Technologies: C Language, TCP/IP Socket Programming, pthread (Multithreading)

Core Features:

Server: Manages multiple client connections simultaneously.
Broadcasting: Transmits a message from one client to all other connected clients (except the sender).
Multi-Chat: Allows multiple users to send and receive messages at the same time.

2. Core Architecture: How Concurrency is Achieved

The core challenge of a chat program is handling multiple requests simultaneously. Functions like accept(), recv(), and fgets() are blocking by default. This means the entire program pauses and waits for an operation to complete before moving on.

I used multithreading to solve this problem.

⚙️ Server: Thread-per-Client Model The server needs to handle connection requests and receive messages from multiple clients at the same time.

The main thread waits for new client connections using the accept() function.
When a new client connects, it calls pthread_create() to create a new, dedicated thread (client_chat) just for that client.
This dedicated thread waits for messages from its client using the recv() function.
The main thread immediately loops back to accept() to wait for the next client.

In effect, the “connection handling” thread (main) and the “per-client message receiving” threads all run independently and concurrently.

When a thread receives a message, it calls the send_msg function, which iterates through the clientList to broadcast the message to all other clients.

💻 Client: Separation of Sending and Receiving Threads The client has its own major challenge: it must be able to receive messages from others in real-time, even while the user is typing their own message.

If it were single-threaded, the program would block on fgets() (waiting for user input), making it impossible to call recv() and receive incoming messages.

To solve this problem, the client program is also split into two threads:

Main Thread (main function): This thread is dedicated only to the “sending” role. It waits for the user’s keyboard input (fgets) and sends (send) the message to the server.
Receiving Thread (receive function): Created with pthread_create(), this thread is dedicated only to the “receiving” role. It blocks on recv(), waiting for messages to arrive from the server.

By splitting the roles this way, the receive thread can display incoming messages from the server in real-time, even while the user is busy typing a new message in the main thread.

You can check out the code via the link(s) attached above!