Use case מהלך בודד בשח

[Gaus]

Use case מהלך בודד בשח

האלן חבר'ה! ראשית שלום לכולם, נחמד להיות פה איתכן, עברתי קצת על ההודעות ובהחלט עלו פה דברים מעניינים ומעשירים.. אני שוקד בימים אלו על משחק שח-מט, והחלטתי לעבוד במטדולוגיה איטרטיבית המבוססת על הXP. הuse Case הראשון שנבחר להתחיל ממנו את הdesign של המערכת הו מהלך בודד במשחק זא: מגיע תור שחקן, בוחר כלי, ומניע אותו למקום אחר. עד כאן ההקדמה... אשמח לקבל את הרעיונות שלך לתכנון צעד זה, הרכבת רשימת מהלכים לפי גורמים מעורבים וגורמים בעלי עניין במהלך זה, ותרשים המחלקות הנגזר ממנו. אם תהיה איענות, ונרכיב פה מודל , נתקדם לתרשים בדינאמי של הuse case.. חשבתי שיהיה נחמד לשתף את כל הפורום בתכנון של המשחק, זה יכול להיות משהו נחמד שיתהווה פה מעל דפי הפורום הזה מתחילתו ועד קיצו, ובסוף אני אפרסם את התוצאה הסופית של היצור אותו נקים.. אשמח לתגובות מרובות ככל הניתן, גאוס (לא המקורי)

 

[arn0n]

כמה רעיונות

המשחק סובב סביב מבנה נתונים עיקרי של "מצב הלוח". זהו פשוט תיאור של מיקום הכלים על לוח המשחק ברגע נתון. במהלך משחק הפעולה העיקרית היא מעבר בין מצבי לוח שונים. בנוסף, אם יש תמיכה במשחק כנגד המחשב, אז חישוב המהלכים ע"י המחשב יעשה שימוש ביצירת הרבה "מצבי לוח" תיאורטיים. 1. עשיית צעד מצריכה קבלת תיאור המהלך מהמשתמש - משבצת יציאת המהלך ומשבצת יעד המהלך. 2. לאחר קבלת המהלך מהמשתמש, יש לוודא שהצעד חוקי. חוקיות המהלך תלויה במחלקה שאליה משתייך הכלי, במיקום של הכלי, וגם (וזה קצת מסבך) בשאלה אם המהלך הזה יכול לגרום למט כנגד השחקן הנוכחי (אי אפשר להתאבד...). 3. אם הצעד חוקי, יש ליצור את מצב הלוח החדש, כולל הורדת כלים של היריב בהתאם לצורך. אז איזה מחלקות יש לנו? * מהלך - תיאור של מהלך תיאורטי. למשל המחרוזת " A2-B4 " מתארת מהלך (פרש) מ-A2 ל-B4 * לוח משחק , עם מתודות שמאפשרות: לסדר את הכלים על הלוח, לשאול אם מהלך כלשהו הוא חוקי, ביצוע מהלך (המתודה מחזירה לוח משחק חדש), וייצוג של לוח המשחק (טקסטואלי, לשם התחלה) * כלי שחמט, מחלקה אבסטרקטית עם מתודה שמקבלת תיאור צעד ועונה אם הוא חוקי עבור הכלי. * עבור כל סוג של כלי, יש מחלקה שמממשת את מתודת החוקיות הנ"ל. מה שכחתי?

 

[Gaus]

שכחת שחקן...

ראשית, תודה על העינות.. בגדול אתה עולה על הקו מחשבה שלי.. עלה איזה רעיון שלכל סוג כלי, תהיה מחלקת צעד-קטלוגי, אשר תייצג את כל הצעדים של אותו כלי, ומחלקה נוספת אשר תייצג צעד ספציפי חוקי של אותו כלי..מה אתם חושבים?.. כמו כן, ביצוג מצב הלוח שעליו אתה מדבר, איך היית מייצג זאת? באיזו צורה? יש לי מספר רעיונות.. אמכיוון שאני מתכוון לממש שחקו חכם ראוי שהיצוג לא יזלול זכרון.. ניסיתי לפתח מבנה ביט-וויזינג, שמקל בד"כ בחישוביות, אך לעיתים גם מסבך.. אם קיים איזה מבנה שנהוג להשתמש בו במצבים מהסוג הזה, וישנה תורה ברורה לגביו, אשמח להחשף אלין... כמובן שניתן לייצג זאת בצורה הפשוטה של מטריצה 8X8 עם מספרים שכל מספר מייצג את סוג הכלי, או רפרנס לכלי שיושב שם, אך אני לא בטוח שזו הדרך הנכונה... תמשיך ככה! תודה.

 

[arn0n]

Hold your horses!

לא שכחתי שחקן. ה-Use case שהצגת לא מצריך מחלקה של שחקן... לגבי קטלוג צעדים - רעיון נחמד, אבל לא ברור לי איפה נעשה שימוש בחלקה הזאת... לגבי מבנה הנתונים - בוא נתחיל מהדבר הכי פשוט שפועל - hashtable עם מפתח של המיקום (למשל A3) וערך שהוא רפרנס לאובייקט של כלי (מה שכן שכחתי, זה שצריך attribute של צבע הכלי). כמה דברים : 1. אם אתה רוצה לעשות זאת בשיטה איטרטיבית, אז תזכור לא לרוץ ולהמציא קודקס מחלקות ענקי... רק המינימום שצריך כדי שהמערכת תתפקד. 2 . אופטימיזציה עושים בסוף. לנחש מראש אם ואיפה יהיה צוואר הבקבוק זהו מאמץ מיותר. בסוף תגלה ש-95% מהמאמץ שהקעת באופטימיזציה נתן שיפור של 5% בביצועים. לכן, אפוטימיזציה מבצעים כשיש לך משהו שפועל נכון, ואתה יכול לקבל סטטיסטיקות מהימנות על ביצועי המערכת, כדי לדעת איפה למקד את מאמצי האופטימיזציה. אפילו במקרים בהם ברור שיש מקומות שידרשו אופטימיזציה, כדאי קודם לכתוב משהו פשוט שעובד, כדי שיהיה לך רפרנס להשוות אליו אח"כ, וכדי לעזור לך לגלות באגים.

 

[Gaus]

למה לא צריך שחקן?..

הרי את המהלך הבודד מבצע שחקן, והוא חלר פעיל מהuse cas.. הוא שמתחיל את הצעד.. אשמח לקבל הבהרתך בנודע... (אין כאן כוונה להתנצחות, אלא באמת לנסות לרדת לסוף דעתך) באופו כללי,אני מסכים איתך שצריך לבנות מודל מינימאלי ממנו מתחילים לרוץ, והפעיל את המערכת, ואיני חולק עליך כלל בכך שלא כדי לרתום את הסוסים לפני העגלה (אם כבר בסוסים עסקינן..) אך מאידך גיסא חכמנו ז"ל היו אומרים סוף מעשה במחשבה תחילה... לכן, מנסיוני, (בניתי בעבר מערכות יורסטיות מרובות עצים), כדאי לשים דגש על יעילות בעיקר כאשר, ואת זה שכחתי להזכיר, המערכת תיושם בג'אווה, שהינה שפה כבדה... שוב תודה.

 

[צונאמי]

כי הוא לא הכרחי כרגע.

לוח המשחק לא תלוי בשחקן. (אפשר לחכות עם זה לאח"כ כך ... ההפשטה המרכזית היא זו של לוח המשחק + כלי המשחק) אני הייתי מתחיל מה-USE CASE -> הזז כלי משחק. אז באיטרציה הראשונה אולי כדי לך לבנות את הלוח ובנוסף להגדיר ממשק עבור כלי משחק. ככה שבסוף האיטרציה הראשונה יהיה רק כלי משחק אחד (שייוצג ע"י עיגול למשל) ויהיה אפשר להזיז אותו לכל משבצת שאין בה כלי משחק אחר.

 

[צונאמי]

טוב שכחתי משהו נראה לי ../images/Emo3.gif

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

 

[Gaus]

אם הבנתי אותך נכוןץץ אז כן

מי שיתן ויעביר את ההוראות למהלך.

 

[צונאמי]

טוב אני רואה את זה קצת שונה

השחקן זה המשתמש עצמו (וכל הלוגיקה שם אני מקווה

) או בעתיד אם תחליט להוסיף שחקן ממוחשב. מה שאתה צריך זה ממשק שיאפשר לשחקן(המשתמש) לשחק. אין לי בכלל ניסיון ב-XP - קראתי קצת חומר באינטרנט בימים האחרונים. לדעתי בסוף האיטרציה הראשונה אתה צריך שיהיה: תצוגה של לוח שעליו מסודרים הכלים (כרגע רק עיגולים) ושתוכל לבחור כלי ולהזיז אותו לכל מקום אחר על הלוח. איטרציה שנייה: ליצור את הכלים עצמם + חוקיות הזזה. איטרציה שלישית: נראה כבר ....

 

[ייוניי]

../images/Emo45.gif מסכים

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

 

[צונאמי]

צעדים "קטנטנים" ?! ../images/Emo6.gif

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

 

[Gaus]

בסוף האיטרציה הראשונה מספיקה גם

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

 

[צונאמי]

הנה מה שיצא לי עד עכשיו

 

[צונאמי]

ועוד

 

[Gaus]

../images/Emo51.gif כל הכבוד, באמת יפה!

יש לך את פירוט הצעדים של הUC אשר מהם הוצאת את התרשימין הללו? אשמח לעיין בהם.. שוב תודה.

 

[צונאמי]

יש לי כמה תיקונים - אני אוציא במהלך

היום.

 

[צונאמי]

הנה התיקון.

ה-UC לפיו בניתי את העיצוב הזה הוא: 1. המערכת מחכה למהלך 2. השחקן בוחר משבצת על הלוח (מנסה לעשות PICKUP לכלי משחק) 1.1 אם אפשר להזיז את הכלי אז עבור ל-3 1.2 אם אי אפשר להזיז את הכלי חזור ל-1 (למשל את EMPTY אי אפשר להזיז לעולם) 3. השחקן בוחר את משבצת היעד לכלי. (כלי המשחק "ידרוס" כל כלי אחר שיושב שפ) 4. חזור ל-1. מה דעתכם ?

 

[ייוניי]

לא הייתי עושה מהלוח Singleton

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

 

[Gaus]

אומנם אתה צודק כח..

ברמת האפליקצייה כולה יתכן והלוח אינו Singletone אך ברמת UC בו אנו מתמקדים כרגע, הוא בהחלט כזה, וזו הכוונה שלו לדעתי, וזה בסדר מאחר ואנו צריכים לבנות STATRT-UP לUC ובה אנו פונים למחלקת הST , אם הוא רואה את הלוח כמחלקה הזו, אזי הוא צודק.. מה שכן יש לי בעייה איתה, זה האובר התייחסות לכל מיני מקרים חריגים.. בUC ראשון אנו לא צריכים להתתיחס למקרים חריגים אלא למהלך תקין אחד שמיצג, ואת החריגים אנו נשאיר ל Open issiue... כך נראה לי.. מכיוון שנדמה לי שצונאמי, שעשה עבודה באמת יפה, קמת נסחף לכיוון הישום, ז"א למבנה התיכנותי שלה, וזה נראה לי לא נכון, פירוט הצעדים צריך להיות יותר כללי, בלי לקבוע צורת תכנות... תקנו אותי אם אני טועה.. אורן.

 

[צונאמי]

מקרים חריגים ?

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