- This topic has 2 תגובות, 3 משתתפים, and was last updated לפני 14 שנים, 7 חודשים by
.
-
תגובות
-
א) האם יש שינויים מהחוקים שהיו בשנים קודמות
ב) לפי מה שהבנתי בין השלבים יש 3 שעות כדי לשפר את התוכנה. איזה שינויים בתכלס אנשים עושים בין השלביםשלום ג'ואי,
אני יכול להבין למה אני בחדר מחשבים היחידי שפתוח ולא רואה אותך?
כדאי שנתאם בפעם הבאה…ברצוני להוסיף כמה שאלות:
ראיתי שעדכנתם את המדריך, האם עדכנתם גם את מנוע המשחק?מתי יהיה ניתן לקבלו?
יש הוספות חדשות שצריך לדעת עליהם?Regarding the changes people make:
People genrally try to improve their survivor, for instance implementing changes they thought of after they already sent the survivors, but before the competition itself. They can also now optimize certain parameters of their survivors against their opponents (since they now have access to them).
People can also use the smart bombs more wisely now, knowing what series of bytes to "lock on" to.
It is also recommended to scramble all of your parameters (such as wait times, number of bombs, movement speed, etc.) so that people won't be able to optimize themselves to you as well as you optimize yourself to them.
For instance, the main reason that UnderDog got third place last year was because he didn't change himself enough. He was on a tight competition for #1 place with XLII, but we (XLII) managed to use the smart bomb to lock on to a specific set of bytes his algorithm forced him to have. If he had used precautions (duplicated or encrypted code, like XLII) or changed himself enough, this would have failed. He died almost instantly on every fight we had together, and so on the final when we were together every time, he lost almost every time and got third place.
It is generally recommended to make your code impossible to read, so that your enemies can't adapt as well to your strategy – or find its flaws. This can be achieved by finding bugs in common debuggers so that anyone executing your code will get an error message (one version of Apocalypse did this with the cmd debugger, but we didn't implement this because our survivor was too big already). We actually did this using a more subtle trick (read the second post where I posted XLII). You can also encrypt it in a strange way so that debuggers have trouble – for instance, XLII code is split into two parts on the two survivors of the team such that one needs to xor both parts to get the code – which is troublesome to do with debuggers that aren't meant for simultaneous debugging, or with only a limited amount of time.
This is still breakable. The best you can do is simply make cracking your survivor not worth the effort.
- יש להתחבר למערכת על מנת להגיב.