Metal Gear Solid - הנושא הרשמי

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

שחקתי כבר מעל לשעה בmg2 והוא באמת מרגיש כמו קפיצה של דור. אשכרה mgs1 עם גרפיקת pixel art. הכל עלה שם דרגה בצורה קצונית, השליטה, היכולות, הגיימפליי, הגרפיקה וגם העלילה התנפחה כך שב10 הראשונות יש יותר דיאלוג מאשר בכל mg המקורי. זה ממש מרגיש כמו מטאל גיר, ממש.

בשבוע האחרון עלו הרבה previews של MGS:GZ של שאר הכתבים שהוזמנו אז ל NASU ושיחקו/סיימו את המשחק (עד אז ל GI היתה בלעדיות על הסיקור) ודבר אחד שעליו היתה הסכמה, בין אם הכתב לא אהב את הקונספט והרגיש שמדובר בדמו בלי באמת בשר ועלילה מבולבלת (תלונה שחזרה הרבה, גם כתבים שסיימו את PW אמרו שהרגישו קצת אבודים בסיפור) ובין אם הוא עף על המשחק וחשב שהוא מציע תמורה מעולה למחיר וכו' זה שהגיימפליי אדיר, יצירתי, פתוח ובאופן כללי משפט שחזר לא מעט- "הכי טוב בסדרה", תמיד MGS הציעה חופש יחסי באיך לגשת לסיטואציה אבל מה שיהיה ב 5 זו רמה אחרת לגמרי, חובה לצפות בסרטון הזה כדי לראות עד כמה הגיימפליי פתוח ואיך המשחקיות הקלאסית של MGS התפתחה:

http://www.youtube.com/watch?v=e8q8-KrIssA
כל כך מגניב וזה עוד בבסיס צבאי בגודל מטר ביחס למשחק המלא, MGS5 הולך להיות ענק.

youtube

נראה פשוט מעולה, אני שמח שהמשחק נראה כל כך טוב בלי לחשוף בכלל עלילה.

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

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

ד.א עוד דבר מגניב שאפשר לעשות זה לעלף 2 חיילי אויב, להעלות אותם על הג'יפ, ולזרוק אותם ביחד איתו מהצוק 😃

והמשחק כבר יצא מוקדם בטעות באיחוד האמירויות (גם טיטאנפול) בגרסאות ה PS3,X1 וה 360.
https://pbs.twimg.com/media/BiNGIWpCMAEStF-.jpg
https://pbs.twimg.com/media/BiM6VjMCEAAwwEL.jpg
גרסת הפס4 עוד לא יצאה שם אבל בעיקרון עוד מעט כבר יעלו המון גיימפליי ותוכל לראות את כל הסיפור אם אתה רוצה, כולה שעה וחצי המשימה העלילתית, פחות מלראות סרט 😃

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

זה באמת יהיה הזוי מאוד, אפילו בשבילך.

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

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

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

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

רק שאלה, אין לי מושג על העלילה של MGS אבל הבנתי שground zeros זה לא ממש משחק מלא אלא הקדמה לאחד שיארוך הרבה זמן ובאמת ימשיך עלילה שנקרא - Phantom pain.

ואם כן מתי phantom pain יוצא בכלל? הוא באמת משחק "מלא"? ומה בעצם תפקידו של GROUND ZEROS

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

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

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

לא. כשמפתחים משחק קודם כל אתה תפתח אותה בסביבת פיתוח נוחה של Visual studio או כל IDE אחר על מחשב ועל מערכת הפעלה ווינדוס, במקביל כל מה שלא לוגי לחלוטין ותלוי מערכת הפעלה וAPI ספציפי בשל אילוצי ספריות שסוני בטח נותנת למפתחים אתה תיצור שכבת Infrastructure שתפותח עם שתי גרסאות, אחת לפיסי בה אתה תפתח מעל Direct x ואחת שתפותח על עיוור או על IDE של סוני ותרוץ על הפלייסטישן. ככה לפחות עובדים במערכות Embeded קשה לי להאמין שדברים יהיו שונים בעולם פיתוח המשחקים. כל תוכנה שנוצרת בעולם קודם כל תפותח על פיסי שרץ תחתיו ווינדוס כי שם נוח לכתוב, קל לדבג ואפשר לעשות Unit testing דיי בקלות, ואת הקצוות אתה תמיד תשלים בצד השני. יכל להיות שהגרסה שתפותח על פיסי לא תעמוד בביצועים, אבל מבחינה לוגית היא תהיה זהה וכך גם 99% מהקוד.

הסיכוי היחיד שאין גרסאת פיסי היא שסוני פיתחה IDE כל כך טוב שיאפשר למפתחים לדבג בשיא הנוחות של הפיסי בצורת Remote ותיתן תמיכה לכל בקשה של המפתחים. מאחר ויוצא לי בעבודה היומיומית שלי לעבוד מול חברות קצת יותר רציניות מסוני כמו TI לדוגמא עם הרבה יותר משאבים מסוני ועדיין עובדים בצורה הראשונה אני יכל רק לנחש שגם אם קיים IDE הוא לא מתקרב לVS או Eclipse על גרסותיה. גם כשפיתחתי מערכת שרצה על Vxworks בעבודה הקודמת שהגיעה עם אחלה גרסה של Eclipse ועם תמיכה נהדרת שעלתה לחברה שלי מאות אלפי דולרים של Wind river עדיין העדפתי לפתח את הגרסה הראשית על הפיסי על ווינדוס ולעשות שינויים בשכבה התחתונה שרק קראה לבקשות מול מערכת ההפעלה.

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

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

Drkeo - גם לGZ קוראים MGS V כלומר 5 אז זה לא עושה אותו חלק מphantom pain? ואם אני ארצה להתחיל לשחק בMGS אבל להתחיל מ Phantom pain, אני אצליח להביו משהו מהעלילה או שכדאי לי לגנוז את הרעיון.

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

תודה על ההסברים, Death יכלת כבר לכתבו בסינית וזה היה נשמע אותו הדבר פחות או יותר 😃

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

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

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

כשמפתחים מוצר לחומרה כל שהיא צריך מספר דברים:
1) מהדר שיתרגם את השפה שכתבת לשפה שהמעבד של אותה חומרה כדי שהמעבד יבין, לדוגמא המעבד בפס3 היה צריך מהדר יחודי לו כי הוא לא השתמש באותה שפת אסמבלי כמו מעבדי אינטל. מעבדי אינטל משתמשים כיום בשפה שבסיסה מהמעבד 8086 בגלל זה אתה שומע את השם X86 הרבה. בנוסף לכך עם השנים אינטל הרחיבה את שפת המעבד שלה עם תוספות גרפיות כגון MMX ועוד.
2) כמפתח אתה תרצה שיהיה לך נוח לבדוק את הקוד שכתבת, כלומר להריץ אותו ולראות את השתנות הזיכרון במחשב ומה קורה מבחינה לוגית והאם הדבר מתרחש כמו שכתבת עם הInput הנתון. כשמפתחים בסביבה של ווינדוס אתה מרוויח שני דברים - אתה מדבג את הקוד שלך על המחשב שלך שהוא בדרך כלל מחשב אינטל לא חלש (כפול ליבה ומעלה), כמו כן הדבר לא צריך להתבצע בצורה של התקשרות החוצה. נכון ראית לא פעם מפתחים יושבים עם קונסולות של פס3 על השולחן? למה זה? כי הם מחברים את הקונסולה למחשב ומשתמשים בIDE כל שהוא כדי להתחבר לאותה קונסולה מרחוק ולבצע Debug מרחוק. למה זה מסורבל יותר? בגלל שמדובר למעשה על המחשב עליו אתה כותב שמדבר עם הקונסולה יש למעשה Server וClient בכל צד שמדברים אחד עם השני על בסיס תיקשורת כל שהיא, נגיד טורית או לחילופין Ethernet (כמו רשת ביתית), הדבר מאט את כל תהליך הבדיקה. אם אתה כמתכנת תצטרך לשבת מול מחשב ועל כל פקודת התקדמות שתלחץ במקלדת תצטרך להמתין מספר שניות או אפילו מעבר לכך כדי שהפקודה תגיע לPS3, המעבד יעשה את הפקודה והתוצאה תחזור אליך אתה תשתגע. כי אתה מקדם אלפי שורות ביום. בפיסי זה קורה מיידית. מעבר לכך, לפעמים הDebuger ששייך לחומרה איזוטרית (והמעבד של הפס3 היא חומרה איזוטרית מאחר והיא לא היתה נפוצה בעולם) אתה דיי שבוי במספר מאוד מצומצם של כלים שפותחו על ידי סוני או IBM שלא תמיד זהים באיכותם לאילו שזמינים מצד מייקרוסופט לדוגמא ש-90% מהעולם משתמשים בהם ועברו הרבה יותר כברת דרך בפיתוח.
צד נוסף הוא ספריות נוספות, אם לדוגמא אתה רוצה לבדוק את הקוד שלך עם עוד ספריות שפותחו על ידי מתכנתים אחרים והופצו באינטרנט כשאתה עובד מעל מערכת הפעלה שרק פותחה לפס3 לדוגמא אתה יכל לנחש שהקוד שאותם חברה כתבו לא יעבוד כי תמיד יש פנייה כזאת או אחרת כשאתה כותב קוד למערכת ההפעלה שמדברות עם ממשק משלהן שנבדל בינן לבין עצמן. כך לדוגמא אם יש ספרייה שמאפשרת לעשות עוד בדיקות של גוגל לא בהכרח היא תתמוך במערכת הפעלה שפותחה על ידי סוני כי זה לא מעניין את גוגל ואין שוק לדבר.
3) כשכותבים קוד רוב רובו הוא פעולות לוגיות ורק הקצוות שלו הן פנייה למערכת הפעלה או חומרה יעודית. אין שום בעייה בתכנון נכון של תוכנה לבדל את רוב הקוד שיהיה משותף לשתי פלטפורמות (מחשב ופלייסטישן) וככה אתה רק צריך לשנות את קצוות ואתה נהנה למעשה מיכולת פיתוח מאוד נוחה של כל הקוד. עכשיו גם אין שום בעייה כדי שיהיה לך מוצר שירוץ על פיסי בצורה רגילה לפתח את הקצוות הלא משותפים בצורה חורנית ולא יעילה באמצעות Direct X לדוגמא.
4) אל תשכח שמשחק היא מערכת מורכבת עם אלפי מצבים שונים ומשונים, לרוב כדי להגיע למצב מסויים למפתח לא יהיה כוח לדבג עד אותה נקודה בשל איטיות ההקשרות עם הפלייסטישן והדבר גורם למצב שמפתחים מדפיסים מצבים על המסך ומנסים לפענח אם מה שנכתב למסך זהה למה שהם התכוונו. הדבר גורר למעשה להתארכות תהליך הפיתוח, אתה מנסה להגיע למצב, הוא לא התרחש, אתה מרסט את הפלייסטישן וחוזר חלילה.

זה פחות או יותר מה שהתכוונתי.

החידוש שייחצנו לגבי הפלייסטשין 4 והX86 הוא שעכשיו מתכנת יכל לפתוח Visual studio של מייקרוסופט ושמגיע עם מהדר של X86 בצורה של ברירת מחדל, לכתוב איזה קוד שירצה בצורה לוגית ולהריץ את אותו קוד על הפלייסטשין ללא בעיה. בעבר הייתה צריך לבנות משהו שנקרא Tool chain, כלומר - שרשרת תרגום חדשה ובעצם להכניס מהדר חדש לסביבת הIDE שלך, תהליך שלפעמים הוא לא נוח ומסורבל בפעם הראשונה. כל הסימנים מצביעים לך שמפתחים רוצים לפתח בסביבה שנוח להם לפתח בלי הרבה התעסקויות בגלל זה סוני הלכה לקראתם. זה לא שהפריע למתכנת בעבר לאיזה שפה מכונה השפה שהוא כתב תורגמה אלא כמה נוח לו לעבוד מהמחשב במשרד.

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

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

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

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

זה remote debugging כשהמכונה המרוחקת מחוברת ישירות למחשב שלך. זה לא אמור להיות איטי בכלל. אפילו remote debugging על מכונות מרוחקות באותו LAN זה לא בעיה. יש לאג של כמה עשרות מילישניות בודדות.

ומפתחים טובים לא משתמשים הרבה בדיבאגר בכל אופן. משתמשים בטסטים אוטומטיים (unit/integration tests) ולוגים בשביל להבין איפה הבעיות, אם יש.

אגב, keo, גם אם אתה מפתח web אתה יכול לדבג כמעט הכל.

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

משתמשים בהכל. כשאתה מריץ וקיבלת תקלה בטסט של ריגרסיה אתה תרצה כן להפעיל עם Debugger כדי לגלות ספציפית מה הוביל לבעייה. טסט Unit test מחייב אותך לעבוד עם Debugger מאחר ואתה כותב אותו ברמת פונקציה, עד שתגיע לנכונות שלו אתה תעבוד עם Debugger. לעבוד עם הדפסות בלבד הוא תהליך ארוך שלא יוביל אותך תמיד לבעיה. כשמתחברים מרחוק יש לא פעם דיליי מאוד גדול, מעבר לכך יש גם לא פעם טעויות מצד הדיבאגר, מאבד את מיקום הProgram counter, לא נותן גישה לזיכרון כמו שצריך ואפילו הData base של הIntellesense נעשה Corrupt לא פעם. גם Breakpoints לא תמיד נתפסים.

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