Какой язык программирования выбрать?
раскрыть ветку (76)
Согласен, к той же OpenGL можно подключиться с разных языков, да и движков хватает на разных языках.
раскрыть ветку (28)
раскрыть ветку (27)
раскрыть ветку (10)
раскрыть ветку (7)
Если бы вы хоть раз писали игру под андроид на джавке, а потом на шарпе, то, думаю с очень большой вероятностью вы бы на джавку уже не смотрели. Тут, конечно, есть нюанс - модули для взаимодействия на нативном уровне всеравно придется писать на джавке, так сказать необходимое зло.
раскрыть ветку (4)
раскрыть ветку (1)
Если писать на си, то игру можно будет без особых проблем запустить на большинстве мобильных платформ
А вот если встанет задача портировать игру на джаве на яблоки, то захочется убивать...
А вот если встанет задача портировать игру на джаве на яблоки, то захочется убивать...
Писал и на том и на другом. Java - libgdx и AndEngine, C# - Unity. Лично для меня Java > C# (для игр, конечно. Ну и для веба ещё.)
раскрыть ветку (1)
Ну например если ты знаешь C# и не хочешь учить Java только для того что бы написать апплет под адрон.
раскрыть ветку (10)
Ну ок, есть. Просто херовый пост.
Из поста какбы следует, что если хочешь написать игру под андроид, то ты должен выбрать c++, а написать игру для веба вообще не представляется возможности, поскольку множества "языков для веба" и "языков для игр" не пересекаются.
На мой взгляд, игры здесь вообще лишняя категория.
Из поста какбы следует, что если хочешь написать игру под андроид, то ты должен выбрать c++, а написать игру для веба вообще не представляется возможности, поскольку множества "языков для веба" и "языков для игр" не пересекаются.
На мой взгляд, игры здесь вообще лишняя категория.
раскрыть ветку (8)
раскрыть ветку (6)
Мне с 1С-м вполне норм живется))) Основное мое направление деятельности. Денюжку платят хорошую и ладно)))
раскрыть ветку (3)
Не подскажете, как можно писать на ведро НЕ под явой? Ибо что-то пробовал писать на плюсах -- как-то не пошло.
раскрыть ветку (3)
Игры очень прожорливы к ресурсам ПК\мобилок. С++ позволяет очень хорошо оптимизировать код. Ну и библиотеки само-собой
раскрыть ветку (17)
раскрыть ветку (15)
хм, взять 2д игру уровня клэш оф кланс, казалось бы, что тут такого - это же просто 2д (и да, ее можно отнести к казуальным), но вот ресурсов она жрет не меньше какого-нибудь асфальт 8, неожиданно, правда ?
Браузерки тоже прожорливы, к мощностям ЦПУ, так как умирающий флэш крайне кривая и громоздкая штука.
Браузерки тоже прожорливы, к мощностям ЦПУ, так как умирающий флэш крайне кривая и громоздкая штука.
раскрыть ветку (12)
Что-то не припомню браузерку, которая бы заставила мой не самый современный ЦПУ пыхтеть. Может мало играл.
Да и с казуалками на моих устройствах проблем не было. Они на плюсах все написаны, вы думаете?
Да и с казуалками на моих устройствах проблем не было. Они на плюсах все написаны, вы думаете?
раскрыть ветку (11)
Если я пишу игру под мобилу на С++ и у меня потери в 1МБ ОЗУ при смене сцен - это катострофа, я ищу утечку и чиню.
Когда писал на флеше - 15-20МБ потеря - а фигня, проблемы юзера с малым кол-вом оперативы.
Когда писал на флеше - 15-20МБ потеря - а фигня, проблемы юзера с малым кол-вом оперативы.
раскрыть ветку (9)
в любом языке потери - это не фигня, другое дело, что в плюсах разработчик обязан непреклонно следить за этим, что никоим образом положительно не сказывается на самой разрабоке.
раскрыть ветку (8)
Ну по крайней мере разработчик на ц++ может устрнаить потерю. И да, из-за этого им платят больше.
раскрыть ветку (7)
раскрыть ветку (6)
Я даже не знаю, что вам ответить. С чем не согласны, что не понравилось? Такой ответ выражает крайнее неуважение.
раскрыть ветку (5)
простите, если настолько задел. Вот смотрите: берем плюсы, тут разработчик должен следить за состоянием памяти и жизнью обьектов, не забывая освобождать память там, где это нужно (плюс заботиться о грамотной инициализации типов, которые по-умолчанию могут быть инициализированы мусором из памяти), следовательно, утечка памяти может произойти лишь по вине самого разработчика; теперь берем язык с CG - тут бремя заботы о жизни объектов лежит уже не на разработчике, а на сборщике мусора, что делает разработку несколько проще, но, все же, ошибки в алгоритмах могут и тут приводить к нежелательному продлению срока жизни объектов и проч., тут, как и в случае с плюсами, разработчик всегда может найти ошибку и исправить ее по возможности, т.е. ваше утверждение " по крайней мере разработчик на ц++ может устрнаить потерю" может говорить о том, что вы не знакомы достаточно хорошо с тем, как разные ЯП работают с памятью.
раскрыть ветку (4)
Проблема в том, что GC так же занимает ресурсы. Где-то видел график один, на котором была расписана активность процессов. Так вот GC занял 40% времени выполнения программы. При это все остальные процессы он просто останавливал. И в языка с GC можно "порекомендовать" сборщику обратить внимание на объект, но власти над памятью никакой нет. То что с такими языками разработка на много проще, я не спорю. И для опредленного класса задач этих языков достаточно, но не для всех.
раскрыть ветку (3)
как раз это еще один нюанс - слишком частый вызов сборщика так же может происходить по вине самого разработчика, тут уже все зависит от опыта. Власть над памятью на самом деле есть, так как есть возможность использовать небезопасный код, но в языках со сборщиком это уже весьма крайняя мера, сборщики, как правило, работают очень эффективно.
У нас в конторе есть несколько параллельных проектов - делаем игры, ммо для мобильных платформ, один проект на плюсах, другой - шарп, плюс нативные вещи на джава для андроид и на obj. C для iOS. Как показала практика, по удобству, скорости разработки, возможностям построения гибкой и надежной архитектуры, шарп вне конкуренции, достаточное быстродействие достигается с помощью грамотной оптимизации под каждую целевую платформу. Серверный код - шарп, для честности скажу, что так же есть места с использованием "небезопасного" кода на серверной стороне, так как все же не вышло дожать шарп до нужно уровня имеющимися на текущий момент способами, но все же, все работает весьма стабильно и эффективно.
У нас в конторе есть несколько параллельных проектов - делаем игры, ммо для мобильных платформ, один проект на плюсах, другой - шарп, плюс нативные вещи на джава для андроид и на obj. C для iOS. Как показала практика, по удобству, скорости разработки, возможностям построения гибкой и надежной архитектуры, шарп вне конкуренции, достаточное быстродействие достигается с помощью грамотной оптимизации под каждую целевую платформу. Серверный код - шарп, для честности скажу, что так же есть места с использованием "небезопасного" кода на серверной стороне, так как все же не вышло дожать шарп до нужно уровня имеющимися на текущий момент способами, но все же, все работает весьма стабильно и эффективно.
раскрыть ветку (2)
я говорю не о "пыхтеть" а о том, что игры прожорливы, несмотря на внешнюю простоту. А у вас и должно быть с ними проблем, это ведь андроид/айось выделяет под 2д игру 300мб озу, а не вы.
раскрыть ветку (3)
хм.. итспользую тут прогу для sqlite3. она написана на lua, позволяет встраивать код на lua. иногда интерфейс подтормаживает чутка, но со своей задачей справляется и все хорошо
раскрыть ветку (2)
Скорей всего имелось в виду разработка игры от А до Я
Так как плюсы заметно экономят ресурсы производительности, а большие игры их неплохо жрут, выбор логичен
Так как плюсы заметно экономят ресурсы производительности, а большие игры их неплохо жрут, выбор логичен
раскрыть ветку (5)
1c это не ЯП - это цпецифический, внутренний скриптовый язык узконаправленного программного обеспечения.
раскрыть ветку (2)
Потому что плюсы самый оптимальный вариант по произодительности/скорости написания игр. В среднем. Если речь идет о небольших проектах, то возможно лучше будет использовать Unity3D и C#
раскрыть ветку (1)
можно и ходить на руках) Но лучше делать на том, под что, то заточено, а не использовать золотой молоток.
раскрыть ветку (4)
очень оригинальный ответ. Думаю, что человек с опытом разработки игр под различные платформы такой ерунды не написал бы.
раскрыть ветку (3)
-_-
Тут дело не в играх, а в простоте разработки и сопровождения ПО и круге выполняемых задач. С++ хорош для быстродействующих систем. Но хороший архитектор рассмеется вам в лицо когда вы предложите реализовать на С++ что-то из систем электронного правительства (если в условии не стоит, что нужен только С++ и ничего больше), оперирующее с базами данных, ибо он будет нести дополнительную сложность разработки, сопровождения, тестирования и прочее. В этом плане лучше Java или C#.
Тут дело не в играх, а в простоте разработки и сопровождения ПО и круге выполняемых задач. С++ хорош для быстродействующих систем. Но хороший архитектор рассмеется вам в лицо когда вы предложите реализовать на С++ что-то из систем электронного правительства (если в условии не стоит, что нужен только С++ и ничего больше), оперирующее с базами данных, ибо он будет нести дополнительную сложность разработки, сопровождения, тестирования и прочее. В этом плане лучше Java или C#.
раскрыть ветку (2)
это же ваши слова - " Но лучше делать на том, под что, то заточено". Но с++ не заточен поди игры, как, собственно, и любой другой язык. На плюсах неплохо писать движок игры. Если же рассматривать клиентскую составляющую игры, то тут лучше выбирать ЯП на котором будет действительно удобно писать, так как красивая и гибкая архитектура это не про плюсы.
раскрыть ветку (1)
А больше процитировать не могли бы? Анти-паттерн https://ru.wikipedia.org/wiki/Золотой_молоток . Я говорил, что если нужно быстродействие пишите на С++ или ассемблере, нужна хорошая сетевая часть - java, хотите красивый интерфейс - питон и тд.
потому что с++ значительно быстрее любого другого языка. Но все зависит от того какую игру ты делаешь, если хочешь сделать какой-то Crysis то конечно с++ иначе твоя игра будет значительно больше требовать, если же какую-то казуалку, что-то простенькое в стиле Bastion или там hearthstone то можно даже питон заюзать, так как сильных требований к производительности от игры не нужно будет ждать.
раскрыть ветку (9)
раскрыть ветку (5)
раскрыть ветку (4)
раскрыть ветку (3)
я имею ввиду, что те кто садится делать сурьезную игру на с++, пилят и движок сами. Те кто берет готовые движки, в 90% имеют дело со скриптами
раскрыть ветку (2)
"сурьезные" игры делают не менее сурьезные конторы, у которых либо уже есть свой собственный двиг, либо они покупают лицуху на какой-нибудь ААА двиг, разработкой двигов с нуля уже не занимаются даже крупные игроки, так как экономически нецелесообразно и крайне трудозатратно.
раскрыть ветку (1)
Да я даже не спорю, это юмористическая картинка и я дал пояснение, что ваше упоминание про движок неуместно, так как здесь разбирают стереотипы. Да и фактически почти все движки написаны на С++, из чего можно сделать вывод что игры на этом движке так же написаны на С++.
Лолшто? Поясните ньюфагу, Крайзис вроде на крайенжи, а он в свою очередь на с++? И да, я понимаю что одно это движок, а другое это язык программирования
раскрыть ветку (2)
в движок закладывается поддержка ЯП, к примеру, взять анрил энджин - поддерживает лишь собственный плюсоподобный язык, извольте. Юнити - движок, который позволяет педалить игры на шарпе, плюсах и чем-то подобном джаваскрипт. В конечном итоге внутренний интерпретатор выдает код в том виде, в которм его понимает целевая платформа.
Если двиг написан на плюсах, это еще не означает, что игровую логику под него придется писать тоже на плюсах.
Если двиг написан на плюсах, это еще не означает, что игровую логику под него придется писать тоже на плюсах.
Языки программирования не одинаковы в своей скорости и требованиям к ресурсам, языка низкого уровня такие как c++ имеют лучше производительность за счет низкого оверхеда от специфики языка. Если так интересно то можете поискать всякие benchmark'и для разных типов задач. Все будет конечно зависить от задачи но в целом С будет в 2-3 раза быстрее той же Java и в десятки раз быстрее чем python. Даже если вы используете готовый движок(хотя это я не подразумевал когда писал коммент), вам все равно придется писать игровую логику, а возможно и допилить какой-то функционал который не реализует движок и тут то и будет разница в производительности.