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

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

באופן כללי, ישנם שני סוגים עיקריים של ארכיטקטורות רשת: peer-to-peer ולקוח-שרת. בארכיטקטורת peer-to-peer (p2p), נתונים מועברים בין כל זוג שחקנים מחוברים, בעוד שבארכיטקטורת שרת-לקוח, נתונים מועברים רק בין השחקנים לשרת.

למרות שארכיטקטורת peer-to-peer עדיין בשימוש במשחקים מסוימים, ארכיטקטורת שרת-לקוח היא הסטנדרט: היא קלה יותר ליישום, דורשת רוחב ערוץ קטן יותר ומקלה על ההגנה מפני רמאות. לכן, במדריך זה, נתמקד בארכיטקטורת שרת-לקוח.

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

ישנם שלושה מרכיבים עיקריים במערכות רשת משחקים:

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

חשוב מאוד להבין את תפקידו של כל חלק ואת הקשיים הקשורים בו.

פרוטוקול הובלה

השלב הראשון הוא בחירת פרוטוקול להעברת נתונים בין השרת ללקוחות. ישנם שני פרוטוקולי אינטרנט עבור זה: TCP и UDP. אבל אתה יכול ליצור פרוטוקול תחבורה משלך המבוסס על אחד מהם או להשתמש בספרייה שמשתמשת בהם.

השוואה בין TCP ו-UDP

גם TCP וגם UDP מבוססים על IP. IP מאפשר העברת חבילה ממקור למקלט, אך אינו מבטיח שהחבילה הנשלחת תגיע למקלט במוקדם או במאוחר, שהיא תגיע אליה לפחות פעם אחת ושרצף החבילות יגיע ב הסדר הנכון. יתר על כן, מנה יכולה להכיל רק גודל נתונים מוגבל, הניתן על ידי הערך MTU.

UDP הוא רק שכבה דקה על גבי ה-IP. לפיכך, יש לו אותן מגבלות. לעומת זאת, ל-TCP יש תכונות רבות. הוא מספק חיבור מסודר אמין בין שני צמתים עם בדיקת שגיאות. לכן, TCP נוח מאוד ומשמש בפרוטוקולים רבים אחרים, למשל, ב HTTP, fTP и SMTP. אבל לכל התכונות הללו יש מחיר: עיכוב.

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

אבל כפי שוודאי הבנתם, חביון במשחקים מרובי משתתפים חשוב מאוד, במיוחד בז'אנרים פעילים כמו FPS. זו הסיבה שמשחקים רבים משתמשים ב-UDP עם פרוטוקול משלו.

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

אז אם TCP מבאס, אז אנחנו הולכים לבנות פרוטוקול תחבורה משלנו המבוסס על UDP?

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

משחקים מצליחים רבים, כולל World of Warcraft, Minecraft ו-Terria, משתמשים ב-TCP. עם זאת, רוב ה-FPS משתמשים בפרוטוקולים מבוססי UDP משלהם, אז נדבר עליהם יותר בהמשך.

אם תבחר להשתמש ב-TCP, וודא שהוא מושבת האלגוריתם של נאגל, מכיוון שהוא מאחסן מנות לפני השליחה, מה שאומר שהוא מגביר את ההשהיה.

למידע נוסף על ההבדלים בין UDP ו-TCP בהקשר של משחקים מרובי משתתפים, עיין במאמר של גלן פידלר UDP לעומת TCP.

פרוטוקול קנייני

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

מאמר ראשון רשת למתכנתי משחקים 2008, קל יותר מהשנייה בניית פרוטוקול רשת משחק 2016. אני ממליץ לך להתחיל עם הישן יותר.

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

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

ספריות רשת

אם אתה צריך משהו יותר יעיל מ-TCP, אבל לא רוצה לטרוח ליישם פרוטוקול משלך ולהיכנס לפרטים רבים, אתה יכול להשתמש בספריית הרשת. יש הרבה מהם:

• יוג'ימבו גלן פידלר
• רקנט, שכבר לא נתמך, אלא המזלג שלו SLikeNet נראה פעיל.
• ENet היא ספרייה שנוצרה עבור FPS מרובי משתתפים קוביה
• GameNetworkingSockets על ידי Valve

לא ניסיתי את כולם, אבל אני מעדיף ENet כי זה קל לשימוש ואמין. בנוסף, יש לו תיעוד ברור ומדריך למתחילים.

מסקנת פרוטוקול תחבורה

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

הבחירה בין TCP, UDP והספרייה תלויה במספר גורמים. ראשית, מצרכי המשחק: האם הוא זקוק להשהיה נמוכה? שנית, מדרישות פרוטוקול האפליקציה: האם הוא צריך פרוטוקול אמין? כפי שנראה בחלק הבא, ניתן ליצור פרוטוקול אפליקציה שפרוטוקול לא אמין די מתאים לו. לבסוף, עליך לשקול גם את הניסיון של מפתח מנועי הרשת.

יש לי שני טיפים:

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

בסוף חלק זה, אני ממליץ לך לקרוא מבוא לתכנות משחקים מרובי משתתפים בריאן הוק, המכסה רבים מהנושאים שנדונו כאן.

פרוטוקול יישום

כעת, כשנוכל להחליף נתונים בין לקוחות לשרת, עלינו להחליט אילו נתונים להעביר ובאיזה פורמט.

הסכימה הקלאסית היא שלקוחות שולחים קלט או פעולות לשרת, והשרת שולח את מצב המשחק הנוכחי ללקוחות.

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

סדרה

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

הרעיון מייד עולה בראש להשתמש בפורמט הניתן לקריאה אנושית, כגון JSON או XML. אבל זה יהיה לגמרי לא יעיל ויתפוס את רוב הערוץ לחינם.

במקום זאת, מומלץ להשתמש בפורמט הבינארי, שהוא הרבה יותר קומפקטי. כלומר, החבילות יכילו רק כמה בתים. כאן עלינו לקחת בחשבון את הבעיה סדר בתים, אשר עשוי להיות שונה במחשבים שונים.

כדי לעשות סדרה של נתונים, אתה יכול להשתמש בספריה, לדוגמה:

• FlatBuffers גוגל
• Cap'n Proto סופת חול
• דגני שיין גרנט ורנדולף וורהיז

רק תוודא שהספרייה יוצרת ארכיונים ניידים ודואגת להן.

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

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

דחיסה

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

מעט אריזה

הטכניקה הראשונה היא אריזת סיביות. זה מורכב משימוש בדיוק במספר הביטים הדרוש לתיאור הערך הרצוי. לדוגמה, אם יש לך enum שיכול לכלול 16 ערכים שונים, אז במקום בייט שלם (8 סיביות), אתה יכול להשתמש רק ב-4 סיביות.

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

אריזת סיביות עובדת טוב במיוחד עם דיסקרטיזציה, שזה יהיה הנושא של הסעיף הבא.

דְגִימָה

דְגִימָה היא טכניקת דחיסה הפסדית המשתמשת רק בתת-קבוצה של ערכים אפשריים כדי לקודד ערך. הדרך הקלה ביותר ליישם דיסקרטיזציה היא על ידי עיגול מספרי נקודה צפה.

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

אלגוריתמי דחיסה

הטכניקה הבאה תהיה אלגוריתמי דחיסה ללא הפסדים.

להלן, לדעתי, שלושת האלגוריתמים המעניינים ביותר שאתה צריך לדעת:

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

דחיסת דלתא

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

הוא שימש לראשונה במנוע הרשת Quake3. להלן שני מאמרים המסבירים כיצד להשתמש בו:

• מודל הרשת Quake3 בריאן הוק
• סקירת קוד מקור Quake 3: מודל רשת פביאן סנגלרס [תרגום מאמרים על Habré, ראה סעיף "מודל רשת"]

גלן פידלר השתמש בו גם בחלק השני של המאמר שלו. דחיסת תמונת מצב.

Шифрование

בנוסף, ייתכן שיהיה עליך להצפין את העברת המידע בין לקוחות לשרת. יש לכך מספר סיבות:

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

אני ממליץ בחום להשתמש בספרייה בשביל זה. אני מציע להשתמש ליבסודיום, כי זה פשוט במיוחד ויש לו מדריכים מעולים. מעניין במיוחד ההדרכה בנושא החלפת מפתחות, המאפשר ליצור מפתחות חדשים בכל חיבור חדש.

פרוטוקול יישום: מסקנה

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

לוגיקה של יישומים

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

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

ישנן מספר טכניקות למתן את ההשפעה של בעיה זו, ואני אכסה אותן בסעיף הבא.

טכניקות החלקת עיכוב

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

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

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

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

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

יש גם שני מאמרים בוויקי של Valve, מקור לרשת מרובה משתתפים и שיטות פיצוי חביון בתכנון ואופטימיזציה של פרוטוקול לקוח/שרת במשחק התמודדות עם פיצויי איחור.

מניעת רמאות

ישנן שתי טכניקות עיקריות למניעת רמאות.

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

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

הגיון יישום: מסקנה

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

משאבים מועילים אחרים

אם אתה רוצה לחקור משאבים אחרים של מודל רשת, אתה יכול למצוא אותם כאן:

• הבלוג של גלן פידלר - שווה לקרוא את כל הבלוג שלו, יש בו הרבה מאמרים מצוינים. כאן כל המאמרים על טכנולוגיות רשת נאספים.
• רשת משחק מדהים מאת M. Fatih MAR היא רשימה מקיפה של מאמרים וסרטונים על מנועי רשת משחקי וידאו.
• В wiki subreddit r/gamedev יש גם הרבה קישורים שימושיים.

מקור: www.habr.com