Шукати в цьому блозі

тестові ключі для ADMOB-ГУГЛ

  Важливо включити тестові ключі реклами під час розробки, щоб ви могли натискати на рекламу, не псуючи статистику для рекламодавців Google. Якщо ви натиснете рекламу, не в тестовому режимі , ви ризикуєте що гугл забанить ваш акаунт.

*** перевірте актуальність кодів на https://developers.google.com/admob/android/test-ads

smart_banner,
Banner 
ca-app-pub-3940256099942544/6300978111
Interstitial-міжсторінкова ca-app-pub-3940256099942544/1033173712
Interstitial Videoca-app-pub-3940256099942544/8691691433
Rewarded Videoca-app-pub-3940256099942544/5224354917
Native Advancedca-app-pub-3940256099942544/2247696110
Native Advanced Videoca-app-pub-3940256099942544/1044960115

 


--require plugin
require "ads"

--initialize admob
admob = Ads.new("admob")
admob:setKey("admob-key")
admob:enableTesting() --тестовий режим
--show admob
admob:showAd("smart_banner","ca-app-pub-3940256099942544/6300978111")  --тестовий банер
 
 
admob:addEventListener(Event.AD_FAILED, function(e)
 print("admob AD_FAILED", e.error)
end)

Методи зменшення мережевих затримок в динамічних онлайн-іграх

   Розглянемо підхід створення онлайн-ігор, p використанням ігрового сервера . Сервера подібного типу мають достатню потужність, а також стабільне з'єднання і високу пропускну здатність, що дозволяє звести до мінімуму затримку між гравцями і сервером.

   Сервер отримує дані від клієнтів, перевіряє і використовує їх для обчислення нового стану ігрового світу, після чого відправляє результати обчислень всім гравцям. В даному підході ймовірність появи нечесних гравців практично зведена до нуля, адже будь-які підозрілі дії, що відбуваються гравцями, будуть блоковані з боку сервера.

   Реалізація описаної вище архітектури спілкування клієнтів і сервера призводить до затримки між діями гравців і сервером. Наприклад, гравець натискає на кнопку пересування персонажа вправо, однак герой відчуває невелику затримку перед тим, як починає рухатися. Причиною виникнення даної затримки є необхідність клієнта у відправці даних про своє введенні на сервер. Після отримання нової інформації сервер починає її обробку та розраховує новий стан ігрового світу. Як тільки розрахунки зроблені, сервер повинен відправити результат назад клієнту. Подібні ситуації роблять гру недостатньо чутливою для гравця, а в гіршому випадку - непридатною до проходження. У світі ігрової індустрії і проектування багатокористувацьких онлайн-ігор розробники створили універсальний алгоритм клієнтських передбачень, який допомагає зробити гру максимально чутливою.

   Більшість часу ігровий сервер обробляє достовірні запити( без читерства гравців). Це означає, що більшість вхідних даних про введення з ігрових пристроїв клієнтів, швидше за все, будуть істинними, і оновлення стану ігрового світу завершиться максимально передбачувано. З цього припущення випливає те, що клієнт може передбачити новий стан ігрового світу самостійно, не чекаючи відповіді від сервера, причому, в більшості випадків його передбачення виявляться правильними. Таким чином, замість того, щоб просто відправляти дані про введення і очікувати, поки новий стан ігрового світу почне відображатися на екрані, клієнт може відправити введення і негайно почати рендеринг результатів цього введення, грунтуючись на власних розрахунках.
   При такій реалізації обміну даних між клієнтом і сервером виходить уникнути затримки між введенням і відображенням результатів цього введення, і гра буде здаватися для гравця більш чутливою.

   Для більшості онлайн-ігор використання алгоритму клієнтських передбачень є достатнім для комфортної гри. Однак, для специфічного жанру «онлайн-шутер», головною ігровою механікою якого є стрілянина гравців один в одного, є проблема затримки між пострілом на клієнтській стороні і обробкою цього пострілу на сервері. Усунення даної проблеми можливе за допомогою алгоритму компенсації затримки, який в ігровій індустрії називається «лаг-компенсація».

  Розглянемо підхід до реалізації алгоритму компенсації затримки «Favor the shooter» (англ. «Сприяти стрілку»). Під цим підходом мається на увазі наступне: якщо гравець побачив будь-яку ціль на своєму екрані, направив на неї приціл і зробив постріл, який ігровий клієнт зареєстрував, як «попадання», в цьому випадку даний постріл з імовірністю 90% повинен бути зарахований і на стороні сервера.
У корені даної техніки лежить алгоритм компенсації затримки, який дозволяє серверу перевіряти інформацію про постріли, передану гравцем

Уявімо ігрову ситуацію, в якій два гравці знаходяться на певних позиціях. Один з гравців робить постріл по ворогу. Припустимо, що стрілок перебуває на позиції (10, 10), а ворог розташований навпроти нього і має позицію (15, 15). Гравець робить постріл, результатом якого є промінь, побудований від точки ігрового світу (10, 10) до точки, де розташований ворог (15, 15). Алгоритм клієнтських передбачень, який розглядався раніше, з упевненістю
може сказати, що ворог уражений і відображає як результат анімацію попадання снаряда по супернику. Паралельно з пострілом на сервер клієнт відправляє інформацію про те, звідки цей постріл був зроблений. Сервер симулює процес цього пострілу, знаючи позицію стрілка і цілі, і відправляє результат (в даному прикладі потрапляння в ворога) не лише клієнту, який зробив постріл, а також і ворогу, по якому стріляли. Стрілок, отримуючи відповідь від сервера, лише підтверджує власне клієнтське передбачення, а ворог в цей же час отримує пошкодження на 10 одиниць здоров'я. В даному прикладі постріл завершився вдало, і затримка в з'єднанні між гравцями і сервером ніяк не вплинула на його результати.

Ускладнимо даний приклад, додавши умову, що на момент пострілу обидва гравці пересуваються в одному напрямку. В даному випадку затримка в з'єднанні зіграє зі стрільцем злий жарт, в той час як для ворога вона виявиться  «захистом». Припустимо, що гравці пересуваються лише вправо по осі X і постійно відправляють серверу інформацію про введення з своїх ігрових пристроїв. Як і в попередньому прикладі, стрілок здійснює постріл з позиції (10, 10) по цілі, яка, на його думку, в поточний момент часу має координати (15, 15). Алгоритм клієнтських передбачень, в черговий раз, реєструє точне попадання по рухомій цілі, однак суперник не отримує ніякої шкоди.
Дана проблема пов'язана з тим, що гравці отримують події з сервера, які відбувалися в минулому. Це означає, що в той момент, коли гравцеві, що робив постріл, прийшла нова позиція свого суперника (15, 15),на сервері ця інформація стала вже неактуальною. У той
Час, як дані про постріл з позиції (10, 10) в точку (15,15) були доставлені ​​на сервер, ворог вже перебував на новій позиції (16, 15), тому симуляція пострілу завершилася невдало. Проблема синхронізації подібного роду ще більше посилюється при більших затримках в з'єднанні між клієнтами і сервером.

         Ключем до виправлення даної проблеми є алгоритм компенсації затримки. Суть алгоритму полягає в тому, щоб надати серверу можливість запам'ятовувати позиції гравців, в яких вони були в минулому.
          Збереження позицій базується на затримці в з'єднанні між клієнтом і сервером: тобто, якщо затримка становить 50 мілісекунд, тоді сервер запам'ятовує всі позиції гравця, в яких він перебував 50 мілісекунд назад. Чим більше затримка в з'єднанні між клієнтом і сервером, тим довше сервер зберігає інформацію про переміщення цього клієнта. Тепер, коли клієнт здійснює постріл, він додатково відправляє свою позицію, з якої цей постріл був здійснений, щоб
Інформація про переміщення стрілка на сервері стала актуальною. Також стрілок відправляє інформацію з якого гравцеві він зробив постріл і завершився цей постріл попаданням, грунтуючись на результатах клієнтського передбачення. Сервер, отримавши дані про постріл, знаходить гравця, який є метою і фактично відмотує час назад, перевіряючи, чи дійсно знаходився цей гравець в точці, в якій по ньому потрапив стрілок.
Якщо інформація про потрапляння підтверджується, сервер відправляє стрілку і ворогу, відповідні повідомлення з підтвердженням попадання. В даному випадку, можна вважати, що затримка в з'єднанні практично зведена до нуля, і гравці зможуть потрапляти один в одного, навіть якщо вони грають з різних кінців світу.
       Таким чином, реалізація алгоритму клієнтських передбачень дозволяє усунути затримку між діями з ігрових пристроїв гравців і відображенням результатів цих дій. Використання алгоритму компенсації затримки в іграх жанру «онлайн-шутер» дозволяє гравцям отримувати максимально чутливе керування грою в перестрілках, в незалежності від того, наскільки далеко від них розташований ігровий сервер і яку затримку в з'єднанні вони мають..


Лайфхаки фотошоп

Генерувати палітру кольорів із  зообораження:


зоображення\режим\індексовані кольори   -- вказати кількістьо кольорів

зоображення\режим\тамлиця кольорів -зберегти палітру