פיתוח מרקטפלייס NFT בתוך המשחק מקצה לקצה

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

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

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

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

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

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

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

מה נותן מרקטפלייס בתוך המשחק וליוצרים שלו

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

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

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

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

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

דרכים לארגון מסחר: השוואת אפשרויות

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

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

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

שלבי הטמעה: מביקורת כלכלה ועד השקה

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

1. ביקורת כלכלת המשחק. מפרקים את המלאי: מה ובאיזו תדירות מחלקים לשחקנים, מה כבר נסחר מחוץ למשחק, ואילו פריטים בכלל הגיוני להעלות לבלוקצ'יין. בתוצאה — רשימת נכסים והערכת עומס על הפלטפורמה.
2. סכימת זכויות על פריט. קובעים מה נשמר בבלוקצ'יין ומה נשאר בבסיס הנתונים של המשחק, איך הפריט עובר לקונה ומה קורה בעת חסימת חשבון. בלי הסכימה הזו כל סכסוך בעלות נפתר ידנית.
3. לוגיקת העסקה. מתארים הצבת לוט, קיבוע מחיר, תמלוגים ליוצר הפריט, ביטול ומכירה חוזרת. בנפרד — תרחישים שבהם קונה ומוכר פועלים בו-זמנית.
4. הרכבת חוזים ושירותים. מממשים חוזים ואת החיבור לשרת המשחק: מטא-נתונים, נדירות, היסטוריית בעלות, תור פעולות בעומס שיא.
5. בדיקה בסביבת בדיקות. מריצים תרחישים על עותק של נתונים אמיתיים: כפילויות, העברה חוזרת, עסקאות תקועות, גלגול לאחור. בודקים איך הלוגיקה מתנהגת כשהשחקנים בסדר גודל גדול מהרגיל.
6. השקת הפלטפורמה. פותחים למעגל מוגבל של שחקנים, משווים מדדים בפועל לתחזית, ואז מסירים הגבלות. אחרי התייצבות מעבירים לצוות את הקונפיגורציות, הסכימות והנוהל למצבי מחלוקת.

מערך האספקה: חוזים, סכימות, נהלים

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

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

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

מקרה בוחן: פלטפורמה בתוך המשחק ומדדי הפרויקט

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

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

מה שינינו

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

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

מדדים לפני ואחרי

• שיעור העסקאות בתוך המשחק: 38% → 87% — פלטפורמות חיצוניות הפסיקו להיות הערוץ המרכזי.
• הנפקת פריט חדש: שלושה-ארבעה שבועות → כארבע שעות לאצווה — תבנית קולקציה, חתימה המונית, פרסום בוויטרינה.
• פניות על פריטים שאבדו: כשלוש מאות בחודש → בודדות, כי היסטוריית הבעלות נשלפת מהיומן והפריט מוחזר בלי טיפול ידני.

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

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

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

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

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

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

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

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

חוזים של הענף העדכני בתקן פורסים ברשת תואמת כמו Polygon. את המעבר עושים בגלים של 5–10% מהשחקנים עם התאמת בקרה אחרי כל גל — פערים נסגרים לפני פתיחת המסחר.

שאלות טכניות נפוצות לפני תחילת העבודות

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

מה מגן על הקונה ברגע העסקה?

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

מה יקרה אם שירות חיצוני ייכשל?

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

האם אפשר לשנות את כללי התמלוגים אחרי ההנפקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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