איקס עיגול בClojure – חלק ב׳ שרת

אחריי שבפוסט הקודם מימשתי את הלוגיקה של המשחק ולולאה קצרה שמבצעת משחק מלא, בפוסט הזה אני מסביר איך לחבר את הלוגיקה הזאת לשרת http כך שכל לקוח REST יוכל לשחק מול השרת.

הגדרת הAPI ומימוש של לקוח טיפש בNode.JS

את הAPI בחרתי לממש קודם כל בצד הלקוח מכיוון שככה יש לי דרך נוחה לבדוק את השרת מהרגע הראשון ומכיוון שככה אני חושב על הAPI מלמטה ומבין מה הצורך של הלקוח. הבחירה במימוש בjavaScript היא כהכנה לפוסט הבא בו אני מתעד לממש ממשק ווב קטן למשחק.

בחרתי לממש את הממשק בשלוש קריאות:

• התחלת משחק – יוצר אובייקט של משחק חדש בשרת ומחזיר חזרה מזהה של המשחק.
• קבלת עדכון – מחזיר חזרה את לוח המשחק, איזה שחקן משחק המשתמש, תור מי עכשיו ומי ניתח במשחק.
• ביצוע מהלך – קריאה ששולחת את המשבצת בה אנחנו רוצים לבצע מהלך ומחזירה האם המהלך התבצע או הסבר למה לא היה ניתן לבצע את המהלך (לדוגמא אם המשבצת כבר נתפסה או שזה לא התור של השחקן).

כעת על מנת לבדוק את הממשק באופן מלא, מימשתי אלגוריתם קטן שמשחק באופן הבא:

1. להתחיל משחק חדש.
2. לבקש עדכונים עד שמגיע התור של השחקן או שהמשחק נגמר, אם המשחק נגמר אז סיימנו. אחרת נמשיך לשלב הבא.
3. לנסות לבצע את כל המהלכים האפשריים לפי הסדר של המשבצות עד שמצליחים לבצע מהלך ונחזור לשלב הקודם.

בסיס הנתונים – שמירה על מצבי המשחק

מה זה atom?

כאשר אנחנו כותבים שרת אנחנו צריכים לממש דרך השומרת על המצב של המשחק בין הקריאות השונות (או שיש לנו משחק שמתבצע בקריאה אחת בלבד…). בשביל הפשטות, וכדי להתנסות בעדכון של משתנים בשפה, שכן בClojure יש מנגנון מעניין של שמירת משתנים (באופן גורף כל המשתנים הם immutable למעט atom) בחרתי לממש את בסיס הנתונים בזיכרון ה RAM. כמו כן כתבתי את הפונקציות באופן נפרד משאר השרת כך שיהיה ניתן בקלות לכתוב ממשק אחר שמשתמש באיזה בסיס נתונים אחר שארצה בעתיד.

בClojure יש דרך ממש מתוחכמת לעדכון של משתנים באמצעות atom אשר ניתן להדגים בקצרה באופן הבא:

כאן הגדרתי atom בשם x עם ערך התחלתי 0, לאחר מכן איפסתי אותו לערך 10, בשורה הבאה איפסתי אותו לאותו ערך בתוספת של 1. בשורה האחרונה השתמשתי בswap שהוא כבר פקודה מתוחכמת יותר שבמקום לקבל ערך היא מקבלת פונקציה אותה היא מריצה על הקלט ורק ובמידה ולאחר ההרצה הקלט המקורי הוא עדיין אותו הערך שיש ב atom אזי היא מעדכנת את הערך בתוצאה של הפונקציה – אחרת היא לוקחת את הערך החדש של ה atom (ששונה ע״י thread אחר) ואז היא מנסה שוב לעדכן אותו (ע״י הרצת הפונקציה על הקלט החדש) עד שהיא מצליחה לעדכן את המשתנה. ובכך אנחנו מקבלים מנגנון שהוא thread-safe לעדכון של משתנה. ניתן לראות זאת בדוגמא הבאה:

כאן הרצתי 10,000 threads שונים פעם אחת ע״י איפוס של הatom ופעם אחת ע״י החלפה, וניתן לראות באופן ברור שבשימוש בפונקצית האיפוש יש לנו התנגשויות בין thread שונים ואנחנו מגיעים לתוצאה לא אמינה. לעומת השימוש בהחלפה ע״י פונקציה שמוביל בכל פעם לתוצאה זהה ואמינה.

מימוש מבנה הנתונים

הפונקציות הדרושות ממבנה הנתונים הינם:

1. שמירה של נתוני המשחק על פי מזהה.
2. החזרת המידע של המשחק.
3. מחיקה של משחק.
4. עדכון של שדה במידע המשחק (על פי שם שדה וערך חדש).
5. הרצת פונקציה על כל משחק פעיל.

בחרתי לממש את זה ע״י מפה של מפות – כך שיש לנו מפה שמחזיקה את המידע של המשחק ואנחנו מזהים את המשחק לפי מזהה ייחודי. ובתוך המזהה אנחנו מחזיקים מפה שלבסיס הנתונים אין שום ידיעה לאיברים שיש במפה (ע״מ לשמור על הפרדה משאר חלקי השרת).

כאשר גם כאן שווה לשים לב שבכל שינוי אנחנו מחליפים את המפה הראשית במפה חדשה בא אנחנו משנים משהו אחד במפה (מוחקים/ מוסיפים/ מעדכנים ערך).

והיה כשרת המשרת – מימוש הקריאות בצד השרת

את השרת עצמו בניתי בעזרת ring תוך שימוש בjson-middleware כדאי לאפשר לי קבלה ושליחה של הודעות בjson. מוזמנים לקרוא כאן הסבר על איך ליצור שרת פשוט. וכעת נעבור לקריאות עצמם בשרת:

יצירת משחק חדש

כאן בעצם אני מכניס משחק חדש לבסיס הנתונים, כאשר בעזרת הלוגיקה של המשחק מקבלים את הלוח הראשוני והסימן של השחקן (50% איקס ו50% עיגול כאשר איקס תמיד ראשון) וכמו כן מסמנים את זמן ההתחלה לטובת מחיקה של משחקים מבסיס המידע לאחר זמן מוגדר.

שימו לב לדרך בה נוצר המזהה הרנדומלי של המשחק ע״י קריאה לפונקציית java (שכן Clojure רץ על JVM).

קבלת עדכון על מצב המשחק

כאן מקבלים את האובייקט של המשחק מבסיס הנתונים, ובעזרת הלוגיקה בודקים של מי התור והאם יש כבר מנצח (או תיקו) במשחק.

השחקן מבצע מהלך

כאן מימשתי קריאת POST שמקבלת את מזהה המשחק והמשבצת בא השחקן מעוניין לבצע את התור. ואז מתבצעות הבדיקות הבאות:

1. האם זה לא התור של השחקן?
2. האם המשחק נגמר?
3. האם המשבצת הזאת תפוסה?

במידה והתשובה לכל אחת מהשאלות הקודמות היא כן אז מחזירים שגיאה, אחרת מבצעים את התור בעזרת הלוגיקה, שומרים את התוצאה ומחזירים למשתמש הודעה של הצלחה.

לולאת המשחק – Deep-Blue

כעת כל מה שנותר לממש זה את לולאת המשחק של השחקן השני (המחשב) אותה נממש באופן הבא:

כאשר הפונקציה הראשונה זו הפונקציה שנקראת עבור כל משחק, אנחנו בודקים האם צריך למחוק את המשחק (כדי לפנות את הזיכרון ממשחקים שנגמרו) אחרת אנחנו בודקים האם זה לא תור השחקן והמשחק לא נגמר ואז המחשב מבצע מהלך רנדומלי על הלוח.

future – זה דרך פשוטה להריץ thread חדש ובמידת הצורך ניתן לחכות עד שמתקבלת תוצאה מהפונקציה.

סוף דבר

לאחר שסיימנו הרצה של הקליינט הטיפש שכתבנו בהתחלה תיתן לנו:

מה הייתי עושה שונה?

1. לשם הפשטות בחרתי לשמור את לוח המשחק כלוח אך בדיעבד על פי הפילוסופיה של Clojure היה יותר הגיוני לשמור מערך המכיל את כל הצעדים שבוצעו על הלוח, כך שכל צעד לא גורם לשינוי אלא רק להוספה (כמו בסיס-נתונים של בלוקצ׳יין), זה יכול להיות נחמד לשדרג במימוש עתידי.
2. להוסיף הפרדה ברורה יותר בין הריצה של המשחק לבין הקוד של השרת, שכן בסופו של דבר שרת REST זה רק דרך אחת להריץ משחק.

את הקוד המלא ניתן לראות כאן.

בפוסט הבא אני מתעד להתנסות בSvelte לממש קליינט web פשוט שמאפשר לשחק במשחק.