قواعد لیگ شبیه سازی امداد و نجات
(بر مبنای 2006)
محیط سخت افزاری و نرم افزاری
A. کامپیوتر های مسابقه:
ما مسابقه ای در 4 مرحله داریم. پس چهار دست بازی در هر دوره بر گزار خواهد شد و 5 کامپیوتر در یک دوره استفاده میشود.
یکی برای هسته
یکی برای نمایش دهنده
3 تا برای عامل ها
B. مشخصات کامپیوتر هسته:
Intel® Pentium® 4 Processor 3.40 GHz with HT Technology,
1GB DDR-DIMM.
C. مشخصات کامپیوتر عاملها:
Intel® Pentium® 4 Processor 2.80 GHz, 1Gbyte
DDR-DIMM.
D. محیط شبیه سازی:
SUSE Linux 10.0 (32bit) with GCC 4.0 and
J2SDK-1.5.
E. بسته نرم افزاری شبیه سازی:
سرور 0.49.9 اینم آدرسش
http://sourceforge.net/projects/roborescue/
i- هسته وظیفه دارد بسازد در هر دوره شبیه سازی id های تصادفی. این معنی میدهد که شماره شناسایی ساخته شده برای هر دوره شبیه سازی برای یک ساختمان متفاوت از قبلی است.
ii- ویژگی گرد شدن نسبت hp/damage نیز اضافه شده است. این گرد شدن مقدار نست سلامت به آسیب (hp/damage) به عاملها فرستاده میشود برای حد اقل 1000 یا 10 تقریب.
F. شبیه سازی آتش:
i- شناسایی میزان سوخت در ساختمان ها تا حدی تصادفی شده است.
ii- باید : یک خصیصه جدید به نام دما temperature برای نشان دادن دما یک ساختمان در حال سوختن میتواند فرستاده شود با عاملی که در شعاع 10 متری از مرکز ان ساختمان قرار دارد.
ارزش حس حدود 50 تا تقریب میخورد.
- نقشه ها:
5 نقشه استفاده میشود که از طرف tc ها یا همون Technical Committee کمیته ناظر تعیین میشود.
i- مرکز شهر فلیگنو
ii- شهر کوبه ژاپن Kobe (1/10 , 1/4)
iii- Virtual City شهر مجازی
iv- یکی یا بیشتر ، نقشه هایی که یکهو از طرف کمیته داوران به نمایش در می آورند.
H. پیام ها:
a- شرایط ارتباطات:
پیام ها استفاده میشود با عاملهای نجات دهنده برای ارتباطات بین یک تیم که باید تحت شرایط زیر اجرا شود.
در هر دوره :
· برای یک عامل تنها 4 پیام ارسال و 4 پیام در یافت
· برای مراکز دو برابر عاملها ارسال و دو برابر عاملها در یافت پیام .مثال: 10 آتش نشان داریم ، پس مرکز آتش نشانی میتواند در هر دوره 20 پیام ارسال و 20 پیام دریافت کند.
b- نوع:
هر پیام باید شامل سه بخش (selfID, senderID, data part) id فرستنده ، id گیرنده و بخش اطلاعات باشد.
c- حجم پیام ها:
حجم بخش اطلاعات پیام نباید بیش از 256 بایت باشد. و فرستنده و گیرنده باید یک عدد از نوع اینتیجر 32 بیت باشد.
d- فرایند خواندن پیام:
فرایند استاندارد خواندن پیام توسط عامل:
I- نگهداری تمام پیام ها در دو ایستگاه (بافر) ، بافر 1(برای مشخصات فرستنده و مشخصات گیرنده) و بافر 2 (برای نگه داری اطلاعات)
II- انتخاب 4 پیام استفاده شده در بافر 1
III- خواندن اطلاعات متناظر با بافر 2
مثال: Agent.java از تیم YapAPI
66 KaHear hear = (KaHear) data;
67 RealObject sender = world.get(hear.senderId);
68 if (sender!= self()
69 && m_numHearing ++ < hearingLimit())
70 hear (sender, hear.message);
i- KA_HEAR_TELL and KA_HEAR_SAY دو روندی هستنند که به تازگی به پروتکل شبیه سازی امداد و نجات اضافه شده است.
KA HEARاز سال 2003 استفاده شد
KA_HEAR_TELL KA_HEARپیام را به kernel با دستور AK_TELL میفرستد
KA_HEAR_SAY : KA_HEAR پیام را به kernel با دستور AK_SAY میفرستد .
هسته میفرستد 2 بسته زیر را وقتی که دریافت میکند فرمان ارتباط را
(AK_TELL or AK_SAY)
· زمانی که هسته یک دستور ارتباطی AK_TELL (فرمان ارتباط) را دریاقت میکند ، سپس دو بسته ، KA_HEAR KA_HEAR_TELL ، (which have the same message body
· زمانی که هسته یک دستور ارتباطی AK_SAY را دریافت می کند ، سپس هسته دو بسته KA_HEAR و KA_HEAR_SAY را میفرستد.
ii- افراد تنها ار آخرین KA_HEAR می توانند اسفاده کنند.افراد بنا به قواعد 2003 میتواند بدون تغیری اجرا شود ، چون که هسته دو بسته ذکر شده در بالا را میفرستد. افراد میتواند یکی یا هر دوی KA_HEAR اصلی و در این نظریه KA_HEAR , KA_HEAR_TELL و KA_HEAR_SAY .
افراد می توانند انتخاب کنند دستور ها را برای دریافت یک پیام ارتباطی.
تعداد پیام ها ی فرستاده شده و دریافت شده تغیری نمی کند. عامل ها باید یک
پیام را تنها از یک KA_HEAR , KA_HEAR_TELL و KA_HEAR_SAY برای این که این سه دستور دارای چند بخش هستنند.
I – تعداد:
تعداد عاملها و نقاط خاصی از آتش گرفتگی در gisini.txt در جدول زیر وجود دارد.