dollar

Попробуйте так:

canvas.width = canvas.height * (canvas.clientWidth / canvas.clientHeight);

Лучше изучать не новый движок phaser, зная JS, а новый язык - C#.
Тогда движком автоматически станет Unity, который является гораздо лучшим выбором, если вы действительно хотите зарабатывать деньги.

К слову, освоение C# и Unity - это лишь малая часть того, что вам предстоит узнать про геймдев, если вы хотите делать и продавать игры в одиночку.

Если в одиночку, то лучше Unity.

Если в команде, то нужно освоить профессию геймдизайнера, а именно научиться делать понятную для всех документацию. Судя по вопросу, вы по этой части, а так есть и другие роли.

Unity - это тема. Без вариантов.

Но с зарплатами вы ошиблись. В геймдев идут не ради денег, а ради счастья и удовольствия от работы. Даже если вы будете учредителем, шансы заработать что-то ощутимое очень малы.

На 5 лет вперед вам тоже никто не скажет. В этой сфере всё быстро меняется. Пожалуй, Unity надолго укрепился и занял вершину славы. Ну и тенденция в мобилки. В остальном сложно сказать, что будет модно и востребовано. Кто бы мог подумать, что забагованный PUBG с кучей негативных отзывов зарабатывает миллиард долларов в год? Тем не менее, люди покупают.

Странный вопрос. Если вы хорошо знаете Unity и EU4, то как бы можете не спрашивать, а отвечать на подобные вопросы. Ладно, будем считать, что вы и правда хорошо в них разбираетесь.

• Unity имеет преимущество в том, что ниже порог входа. Вам это походу уже типа не нужно.
  
• Unity имеет больше всяких приятных штук монетизации и аналитики (хотя и ограничения есть). Вам это походу типа не нужно.
  
• UE4 имеет больше свободы, если вам нужно что-то очень-очень специфическое. Для всего остального в Unity есть готовые решения, за что его и выбирают (чтобы не писать велосипед).
  
• Внезапно в Unity вы можете подключить DLL, написанною, соответственно, на C/C++. Это может подкосить кроссплатформенность, но основные платформы должны остаться. Плюс крайний вариант сделать несколько версий.
  

Я бы поставил всё же на Unity. Хотя бы потому, что в UE4 может случиться затык, который съест время. В Unity шанс меньше, т.к. он рассчитан практически на детей (в том плане, что даже школьники могут быстро освоить, в отличие от EU4).

Сетевая часть - пожалуй, самая сложная часть в геймдеве (если это не браузерка, конечно).

Про интеграцию движков в существующие проекты я ещё не слышал. Обычно сначала выбирают движок, и на его базе строится проект, затем движок может допиливаться или не допиливаться под проект при необходимости. Так что, имхо, лучше развивайте дальше своё решение. Хотя если проект ещё маленький, то можно рассмотреть как бы интеграцию вашего проекта в libGDX, а не наоборот.

Или пишите с нуля - тогда сразу выбирайте Unity (переписывать с нуля, имея наработки, будет немного проще, а что касается C#, то лучше 1 день потерять, потом за 5 минут долететь). Сейчас новые игры пишут именно на Unity по многим причинам, в этом плане конкуренции практически нет.

Если нужен какой-то большой функционал, то можно посмотреть на отдельные библиотеки, из которых строятся игровые движки.

Физика представлена, соответственно, в виде Box2D, можете взять его. (Другие физические движки можете гуглить, обзор всех выходит за рамки вопроса).

Что касается сетевой части, вам придется принимать мучительные решения, как это реализовать наилучшим образом, чтобы игроки были довольны геймплеем в условиях ненулевого лага. Это целиком зависит от того, что у вас за игра и в чём фан.

GDScript похож на Python, поэтому можете учить сначала его. Кругозор у вас расширяющийся, амбиции большие, язык популярный, наверняка пригодится. А перейти с него на GDScript проще простого.

Документации не достаточно даже для того, чтобы стать программистом. А уж чтобы стать разработчиком игр, этого тем более не достаточно. При условии, что у вас соответствующий хороший бэкграунд, нужно минимум год потратить на профильное образование, после этого можно будет войти в геймдев на джунские позиции. Хотя если вы гений, можете попытать счастье в качестве инди-одиночки.

Дайте игроку самому решать, хочет ли он играть, и как именно. Для этого в конце показывайте что-то типа "Game Over" и переводите игрока на главное меню игры. У вас же есть главное меню в вашей игре? А там уже должен быть пункт "Начать заново".

В теории есть разные варианты.

1. Можно использовать кеш браузера. Особенно для статичных картинок и файлов, которые вы никогда не будете менять, и это точно. Об этом можно сообщить браузеру, и он поверит, и не будет загружать их повторно.
   
2. Можно использовать хранилище браузера (localStorage и IndexedDB). Правда, понадобится много заумного программирования.
   
3. Можно попросить пользователя установить расширение для браузера, которое, по сути, будет равносильно установке самой игры. То есть игра без него не запустится. Там много возможностей.
   
4. Собственно, почему расширение? Есть полноценные скачиваемые из стора веб-приложения, в том числе и игры. Хотя по сути то же самое.
   
5. Можно создать не веб приложение, а полноценное приложение для какой-то ОС (Windows, Android и т.п.), но со встроенным WebView, т.е. как бы со встроенным браузером.
   
6. Можно отказаться от браузерной игры. Серьезно, на сегодня это 3% мирового рынка игр, и доля продолжает падать. Оно вам надо там ловить что-то? Если ради интереса, то ради бога, а если ради прибыли, то лучше отказаться сейчас, чем потом.
   

Возможно, но вы должны понять, чем вы вообще хотите заниматься, и целенаправленно идти именно в этом направлении. Из вопроса это не понятно. Может быть, художником, или переводчиком, или юристом? Есть ли реальный опыт или только мечта?

Проще всего войти в геймдев джуном тестером. Но это ни разу не любой бомж с улицы. Еще можно попробовать себя джуном геймдизайнером. В обоих случаях нужен богатый игровой опыт и знание игр вообще. Но я уверен, что вы не знаете, что делают на этих должностях. Тестер - это не тот, кто целый день играет в игры. А геймдизайнер - не тот, кто придумывает клевые идеи и ему за это платят.

Еще можно попробовать себя в суппорте или каким-нибудь модератором на игровом форуме и т.д. Во всех случаях к вам будут какие-то требования. Нужен хоть какой-то релевантный вашему занятию бекграунд. Если этого нет, то пробиться в геймдев не получится.

К примеру, вы хотите быть у руля, т.е. вам нравится менеджмент. Возможен такой путь: сначала в тестеры, потом в лида отдела тестеров, потом в ПМы, потом в геймдизы или сразу в продюсеры. Выше продюсера уже никого нет, разве что спонсор. И тут вы вдруг понимаете, что продюсер - не самый главный, а всего лишь человек, у которого своя роль, свои обязанности и своя зона ответственности. Ошибка в том, что вы не знали, чего хотели, в итоге - разочарование.

Можете предтсавить, что геймдев - это бетонная стена. Пробиться головой через неё нельзя. Но можно купить перфоратор, это будет означать соответствующее образование, а в идеале - реальные достижения. Тогда вы сможете сделать отверстие и шагнуть на ту сторону стены. Инструменты возьмите с собой, там дальше будут другие стены.

Входных точек в геймдев существует много, но бетон - есть бетон. Это не масло и не хлеб. Глотать пыль не очень приятно. Хотите что-то попроще - идите в другую сферу.

Как исправить проблему

Исправление проблем в плохо работающей программе (игре) называется отладка. Процесс отладки - это поиск, т.е. последовательность проверок и экспериментов, в ходе которой копится информация, которая в итоге помогает догадаться, где и какая ошибка допущена.

Основной метод - это метод исключений. Примерно как в игре "Данетки" (или "Ситуации"), только применительно к приложению ("да" - работает, "нет" - не работает). Очевидно, что нужно правильно подбирать "вопросы", тогда и ответ быстро найдётся. Например, можно попробовать выполнить функцию удаления пули саму по себе без условий. Если она выполнится, то она точно работает, и можно исключить её из дальнейшего анализа. Если она не выполнится, то проблема в ней, и следует углубиться в неё, исключая всё остальное (пока что). Таким образом, одним лишь экспериментом (вопросом) проблема делится пополам, а точнее уменьшается вдвое. И так далее. За 10 таких вопросов-проверок вы уменьшите проблему в 1000 раз, а может уже и полностью локализуете её к тому времени.

Знаю, что ответ слишком общий, но он вам и правда подходит. Как тот ни бесполезно и нравоучительно звучит, но мой совет - учитесь отлаживать.

На данный момент вы задали 0 вопросов, включая этот. Почему ноль? Вопрос-то вы вроде как задали, но результат не описали. Вы сказали, что вам надо (чтобы враг и пуля удалялись), но не сказали, что на данный момент есть. Враг удаляется, а пуля - нет? Пуля удаляется, а враг - нет? Игра вообще не запускается из-за попытки сделать эту фичу? Пуля проходит насквозь? Пуля отскакивает, как от бетона, и падает на пол? Любая из этих подсказок была бы первым шагом и помогла бы уменьшить проблему в 2 или даже в 10 раз. Но вы эту подсказку не дали, так что проблема может заключаться, в чем угодно. В этом случае вам можно помочь либо телепатией (угадыванием), либо сделав вашу задачу с нуля, не беря в расчет ваши наработки.

Но даже если будет 1 подсказка, этого будет не достаточно. Как я сказал выше, нужно несколько подсказок. И где искать следующую, зависит от того, где вы нашли предыдущую. Так что вы и только вы можете этим заниматься. Через Тостер это будет в формате "попробуй так - сделал, вышло то-то - тогда проверь это - ок, выдало такое - значит, здесь исправь" и т.д.

Код в данном случае не очень помогает, и я уже сказал почему. Потому что проблема (которая не описана) может быть, где угодно, даже вне этого кода.

UPD:

Non-invocable member 'GameObject' cannot be used like a method.

Спасибо за добавление описания ошибок в текст вопроса. Теперь гораздо понятнее, что происходит (это аж 4 подсказки), но ответить однозначно всё равно нельзя. Потому что они вроде как очевидны, их описание говорит само за себя, но, тем не менее, вопрос всё ещё актуален. Это говорит о недостатке знаний в C# или в английском языке. Пройдусь кратко:

1. Trigger вы используете, но нигде не объявили. И компилятор жалуется, что не знает, что это такое. Возможно, вы хотите что-то проверить и вам по смыслу понятно, что это должно быть (какой-то "триггер"), но компилятор не знает английского, для него это лишь идентификатор какой-то сущности - переменной ли, функции ли, и так далее. Кроме того, даже человеческий программист зайдёт здесь в тупик, потому что не ясно, к чему относится ваше Trigger("Ammo"), равно как и Collision("Enemy"). Если у вас в игре много врагов и пуль, то что эта строчка может значить? Коллизию всех со всеми? Или что? Когда (если) вы глубже поймете язык C# и вообще ООП, то узнаете, что есть классы, объекты и их методы. И что методы обычно вызываются не сами по себе, а применительно к какому-то объекту, да хотя бы к текущему (но в текущему такого метода нет). Объяснять "в целом" можно долго, но я не смогу в ответ запихнуть учебник по C#.
   
2. Collision - здесь компилятор сообщает, что этот идентификатор ему знаком, но вы его используете не так, как задумано.
   
3. GameObject - аналогично предыдущему, это знакомо компилятору, но так нельзя, это не функция.
   
4. GameObjcet - а здесь компилятор говорит, как и в первом сообщении, что вы нигде не объявили этот идентификатор. Очевидно, что там просто опечатка. Это как раз тот пример, когда, занимаясь отладкой, вы должны догадаться об этом. Ведь, GameObject это вот прям основное слово в Unity, но компилятор его не знает? Что? Как так? И если исключить невозможное, то остается почти единственный вариант - опечатка. Вот так просто.
   

Без программирования сделать нормальную игру невозможно.

Даже blueprint'ы по сути являются, хоть и визуальным, но программированием. Там у вас будут названия переменных (свойств), их типы, включая числовые типы, собственно сами числа, операции над ними, логические операции, ветвления и т.д. Всё, как в программировании, только вместо 2+2 будет визуальная схема. В каком-то смысле текст программы даже проще писать и воспринимать, если привыкнуть (хотя к С++ придётся долго привыкать с нуля).

но самые простые игры безумно хочется поклепать :)

Оставьте Python для других задач, которые вы хотели решать с его помощью, а самые простые игры пишите на Unity.

Как говорится, лучше день потерять, потом за пять минут долететь (Unity). Либо можно продолжать всю жизнь ходить пешком (PyGame). Когда-нибудь придётся решиться, если так хочется делать простые игры. Но лучше рано, чем поздно.

Просто поймите, что языки создаются изначально для какой-то цели, поэтому хорошо подходит для неё и смежных областей, и плохо подходит для других, поэтому не применяется там. Нормальному программисту, даже начинающему, нет особой проблемы изучить синтаксис нового языка. Сложности начинаются, когда этот язык начинает применяться для несвойственных ему задач. Возможно, когда-то давным давно PyGame был хорошим началом и подавал светлые надежды на развитие в будущем. Но по состоянию на сегодня (2019) Unity бьёт все остальные движки почти по всем фронтам, в том числе по удобству и простоте обучения. А ведь это именно то, что вам нужно, не так ли? Быстро делать простые игры - это как раз про Unity.