Контакты

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (33)

Лучшие ответы пользователя

Все ответы (40)
  • Android: Qt vs Java. Что лучше использовать?

    @dplsoft
    Посмею оспорить ход рассуждений lorus ( Android: Qt vs Java. Что лучше использовать? ).
    Итог у нас почти один, но как в математике - когда ход рассуждений ошибочен - даже если ответ верен - то задача не решена. Возможно во много субъективно, но выскажусь, на правах личного мнения человека, который любит и писал и на Qt, и на Android с его "родным" Java тоже.
    На Qt для Android не писал, потому что на момент начала последнего проекта технология была сырая.

    И так: Не агитка за Qt но несколько слов в защиту Qt.

    Забегая вперед скажу: топикстартеру - если есть небольшой опыт разработки под Андроид, вы не работали ранее с Qt, и вам не важна переносимость исходного кода между всем и вся - продолжайте осваивать Android SDK ( Java ) .
    По крайней мере, сейчас.
    Хорошее знание хотя бы одного инструмента, лучше чем посредственное знание двух. ;)
    C Qt под Андроид потом разберетесь. Да и "пообкатаннее" оно будет.


    1. Qt - это всё-таки C++. Разрабатывать на нём существенно сложнее, чем на Java. То есть дольше и с большим количеством ошибок.

    Надо отличать "просто С++" и С++\Qt. В первую очередь, Qt - это фактически диалект языка С++. Например в объявлении Qt-класса появляются дополнительные секции signal и slots, а в процессе сборки существует фаза мета-компиляции, которая делает C++ код под вашу платформу. Не удивлюсь, если для андроида генерируется сместь Java и C++ кода которая потом скармливается Android NDK.

    Во вторых, Qt - это _самодостаточный_ фреймворк. Никаких STL или "чего-что-ещё что представляют себе в комплекте с C++" типичные сторонние разработчики.
    Многих проблем, которые приводят к сложности разработки "на простом C++" в "С++\Qt" просто нет "by design".

    Например в Qt заложен замечательный механизм предотвращения от выхватывания "null-poiunter" - "сигнал-слоты". Это в разы упрощает и делает надежнее работу как с GUI, так и с например, объектами, работающими в разных потоках. В Qt это все сделать разы проще, чем городить аналогичные стандартные механизмы на Java. Я не говорю в итоге оно будет эффективнее - тут надо выяснять и можно поспорить - но вот то, что в Qt многие вопросы работы с потоками и межпоточным взаимодействием продуманы лучше а механизмы удобнее - на мой вгляд это факт.
    (Хотя вот такого классного механизма аки runnable, в Qt нет. Но ждем 11-го стандарта С++.)

    В третьих - "С++\Qt" - это хорошо продуманный фреймворк едва-ли не с лучшим дизайном классов, продуманными методлами, единым стилем решения проблем.

    Как человек писавший на Qt 4.0-4.6 и сейчас закончивший первывый коммерческий проект для Android - могу выставить в сторону Java много минусов (в сравнении с Qt4/Qt5.) Просто потому, что Java - как в первую очередь коммерческая технология, был вынужден набирать нелогичности ради совместимости с предыдущими версиями - едва-ли не из первых версий Java. Посомтрите вопросы к сертификации - много вопросов, которые когда начинаешь разбирать "почему так" - уходят корнями в далекое темное прошлое развития Java. И в итоге - современная Java - это часто нелогичное, лоскутное одеяло, где в разных классах для решения одной и той-же задачи применяется если не разный подход и стиль, то как минимум разные имена методов. Ну вот зачем это?)))

    Да Java детально описан, и в технически прогнозируем - но его надо зубрить, тупо зубрить все исключения и проблемы наследования логики первых версий, и зубрить где используется put(), а где add()....
    ... а Qt-можно _понять_ и не зубрить, понять и только изредка заглядывать в документацию. И в итоге писать на нем - легче.

    К слову: дизайн классов гуглековских классов - хотя и очень-очень-оченьсвоеобразен и местами диковенен, но он, имхо, достаточно "строен" и в общей совокупности, не страдает такой уж сильной лоскутностью логики, какая имеется в стандартных классах Java. С какого-то момента ты понимаешь "как думали в гугле" и все становится несколько проще.

    Ещё к слову про миф "на Java писать проще чем на C++"(если сравнивается Java под DalvikVM и C++\Qt5):
    Не забывайте - DalvikVM - это вам не JavaVM.
    В DalvikVM вы легко отхватите "null-pointer-exception" если вы вдруг наивно думаете, что коли у вас есть в локальной переменной ссылка на фрагмент, активити или вью - то машина не уничтожит объект "когда ей вздумается", а у вас ваша переменная не об-null-ится.

    На понимание того, какие привычки десктопного написания и дизайна приложений нельзя переносить во фреймворки Android SDK и на перестройку собственного мышления - у вас уйдет несколько месяцев. А вы _начнете_ это понимать и отхватывать такие проблемы - как только начнете писать что-то бОольшее, чем набор разрозненных активити да пары фрагментов из учебных курсов.
    И в итоге - первый ваш серьезный проект на Андроиде - может влететь вам в хорошие переработки.
    Например, в том числе и потому что нет в Android SDK v17 жизненного цикла для класса Application. Нет механизмов для созранения состояния singleton-окружения и тд.и тп.

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

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

    2. Инструментарий разработки для C++ однозначно хуже такового для Java в силу, опять-таки, особенностей языка.

    Простите, но тоже малообоснованное утверждение. См пункт 1.

    Кроме того, отмечу:
    Qt-шный инструментарий позволяет вам получать одинаковое поведение на всех поддерживаемых платформах. Включая поведение GUI, Форм и одинаковую для всех систем архитектуру приложения. В идеале - с Qt - вы можете писать под Андроид так, как будто вы пишете под десктоп - не меняя архитектуру и структуру приложения.

    А когда вы пишете под Android на Java - вы всегда пишете кусок кода работающий в колнтексте DalvikVM и должны жить по предусмотренным данной машиной паттернам и сценариям, причем многие аспекты того "как это работает" - явно мало где прописаны. И если вдруг вы отсутпаете от стандартных шаблонов фреймворка Dalvik-машины - вы рискуете отгрести непонятные, трудно отловимые косяки, причем _вне_ вашего контроля, которые вы не можете корректно перехватить и обработать. Кто не знает - попробуйте уничтожить ViewGroup, id которого вы использовали как контейнер для размещения внутри него фрагмента. Как только вы делаете FragmentTransaction.commit() - вы ставите машине задачу, которую она будет выполнять "когда-то позже", вне вашего контроля, и не соизволит позволить вам корректно обработать исключение. Вплоть до возникновения ситуации, когда фрагмент пытается быть добавленным в Activity который уже отработал стандартные процедуры по Activity.finush(). Ладно бы оно выкинуло код ошибки куда, и тихо проигнорило - но это же Java - она выкинет исключение. А обернуть это дело в try...catch - вы не сможете - это не ваш кусок кода. Максимум что вы сможете - это "поймать перед смертью" Thread.UncaughtExceptionHandler. И все.
    (если я не прав - поправляйте меня, я же тоже не инженер гугля)

    3. Java - родная платформа для Android. Отсюда потенциальные проблемы с совместимостью у Qt.

    Вот зачем вы занимаетесь запугиванием?
    Android NDK (для разработки на С++) такой же родной как как и Android SDK (для разработки на Java).

    И с совместимостью у Qt с платформой Android проблем не больше, чем у любого другого приложения, которое использует вставки C++ кода и разработано с использованием стандартного Android NDK.

    --------------------------------------------
    Резюмируя: автору надо просто взвесить что зачем и как он собирается использовать.
    Если автору нужно одинаковое поведение на различных платформах - включая огрызочные поделия, Linux, разные Windows RT недопланшеты - то выбор ознозначен - курите Qt. Это возхитительнейший, ясный, хорошо продуманный и максимально логичный фреймворк, который не побоялись пересоздать с нуля ради устранения накопленных сложностей (вспоминайте переход с Qt3 на Qt4) Лично я приходил в восторг, когда работал с ним (2005-2009 гг)

    Но - в части Андроидного приклада : подозреваю, могут быть "технические риски" с использованием каких-либо особых "мобильных кусков" типа "работа со звонками, "работа с контактами", "работа с почтой" или "поставщиками контента", и пр.
    Я отошел от мира Qt когда Qt был 4.8 и я не искал там классы которые этим занимаются. Думаю что-то потомки троллей должны были создать в 5.2, но лучше проверить.
    В крайнем случае - может потребоваться стыковка с джава-объектами, и тут вам потребуется изучать Android NDK, и возможно даже писать немного оберточного кода на Java.

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

    Но в этом случае бутьте готовы к тому, что это не JavaVM, и сохранности ссылок _для_ряда_классов_ вам никто не обещает, а т.к. Java не предполагает наличия деструктора - вы _будете_ иметь определенные архитектурные сложности при построении сложных приложений.
    Например то, что в десктоп-приложении вы решили бы "простым" "синглтон-объектом" с простой функциональностью типа записал-прочитал из файла - тут вам _придется_ решать путем построения "поставщика контента" и т.п. - что значительно повышает "порог входа" для тех кто погруждается в разработку для Android.

    Но - надо отдать должное инженерам гугля - у них _были_ весомые основания поступать итак, и они максимально вас обезопасили от попадания в многие проблемы - если, конечно, вы используете фреймворк именно так, как это предполагается. И сделали многие механизмы достаточно элегантными, и приятными в использовании. Дизайн гуглековских классов мне в большей части нравится. В общем не забывайте понимать почему в примерах делается именно так как делается, а не иначе.
    Ответ написан
  • Переход с Angular на React. Тренд или нет?

    @dplsoft
    в следствии успехов маркетологов одного или другого лагеря.
    и смены моды.

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

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

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

    ну так вот: разница между 99% фреймворков джаваскрипта - это куча чепухи и рассказов про то как тут все клево, прогрессивно, моложежно. и практически ничего технически обоснованного. да, структуры разные, апи разный, но эта разница отражает как правило только вкусовщину их авторов и весьма редко имеет под собой хоть какую то техническую необходимость.

    потому что это МОДА.
    "не пытайтесь понять тараканов".

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

    они всего лишь пытаются увеличить круг потенциальных соискателей и привлекательность вакансии в глазах неразумных.

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

    ... ps: а jQuery при этом продолжает и продолжает выполнять 90% всей черной работы на 90% всех сайтов ;)
    Ответ написан
  • Разработчик недисциплинированно трекает время. Что делать?

    @dplsoft
    вы, если вы хороший менеджер, вы должны, наверное, понимать, что недоверие и чрезмерный контроль - становятся слишком накладными в плане трудозатрат. почитайте почему в китае работает практика "ту-ань-ши" кажется, когда в громадной компании всего 3 уроня управления - и у каждого менеджера по 40 замов, и почему этого нет в американо-европейской практике, где 1-2-3 зама - это "норма", и в итоге управленческий аппарат раздувается на множество слоев.

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

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

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

    вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
    почему вас не устраивает скажем 10% погрешность в этих значениях?

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

    и более того - это как раз и есть ваша работа как менеджера - следить за этим.
    если бы все люди сами все делали автоматически и честно - тот же фрилансер всегда сам правдиво, точно и по расписанию все заполнял - вы стали бы ненужной прослойкой.
    Ответ написан
  • На чем писать веб приложения с GUI как в desktop app?

    @dplsoft
    вставлю свои 5 копеек. сумбурно, не все совсем все по теме буду излагать (но там будет ответ на вопрос .. вроде как) но надо понимать область применимости того, что хочет тов. Евгений .

    Его желание "писать в веб так как десктоп" - мне очень даже понятно, и именно поэтому я фактически сделал свой фреймворк ( не на джаваскрипте, что вы, джава+вебсокеты, и совсем немного js). Но его область применения - тяжелый интерпрайз и интранет.

    т.е. писать приложения с веб-интерфейсом, используя подходы и концепции "как для дексктопа" - это иногда просто необходимо (сейчас веб интерфейс в браузере - это уже практически стандартное требование для корпоративных систем)... НО совсем нельзя, ни в каком случае нельзя так делать если вы собираетесь писать массовый веб-сайт "в паблик".

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

    и так. имхо, есть 2 направления, сложно совместимых идеологически друг с другом. ( 90% "веб разработчиков" скажут, что есть только одно... но и фиг с ними - они не знают, а я излагаю свое имхо-мнение системного архитектора, чей стаж в it зачастую больше, чем весь возраст упомянутых чуть ранее "веб разработчиков" ))).

    и так. "массовый веб" и "тяжелый интерпрайз" :

    1. массовый веб.

    тонны хомячков, тысячи примитивных запросов, простая логика (бизнес логика). на это заточено 120% современных веб-фреймворков, которые соревнуются между собой в синтакс-засахаренности, да функционально-фиче пригодности. микросервисы, stateless, rest-сервисы, json-туда-обратно - "... о как.. всем прияно...." и т.д. 90% последователей этих технологий не понимают даже основ проблем разработки больших систем на языках с динамической типизацией, готовы топить за самый модный в этом сезоне фреймворк, давить статистикой новых проектов на гихабе.... но да и фиг с ними, ... достаточно того, что те-же "хедлайнеры" - node.js - вдуплили эти проблемы и таки послали js подальше... тьфу - перешли на typeScript ( ибо статическая типизация - этт не закостенелость стариков, а вынужденная мера, совсем "не от хорошей жизни")... но тысячи хомячков любящих js ведь не могут ошибаться... и потому плодят мирриады js-фреймворков, каждый из которых применим в 2х случаях из 100. и отслеживают топ 10 попутярных в этом квартале языков программирования... ну ла ладно.

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

    примеры: вконтактик, форумы, и 99% всех веб сайтов.
    типичные технологии: php, одноглазый змей-питон, js, чудо руби, и все прочее и тд....

    ps: и да, я ни коем разе не хаю js. я его люблю. но крайне рисковано применять js в объеме большем чем скрипт на 2 страницы. первый же рефакторинг и переаботка кода поломает все нафиг. на определноом объеме кода вы попадете в ситуацию, когда попытка имправить баг будет вность еще больше багов и вы не сможете это остледить.
    то, во что сегодня превратили js и технологии на js - это страх и ужас, но да это моё имхо.


    2. интерпрайз интранет
    ...и различные АРМ с веб-интерфейсом в локальной сети и сложной бизнес логикой

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

    примеры: СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.

    вот тут как раз все наоборот. одна только попытка использовать stateless подход и тяжелый толстожЁпый js грозит вам переработками такого масштаба, что вам и не снилось. т.е. вы конечно построите первую версию и все у вас будет хорошо... до первого рефакторинга и отработки замечаний заказчика по новой версии регламента, которая была утверждена руководством месяц назад... (ну а вы начинали работу конечно полгода назад, и вот уже вроде как через месяц надо было бы сдаваться)... но внешние условия изменились, и у вас начинаются проблемы, вырисовывается громадный объем работ по рефакторингу. просто потому что крайне сложно сделать машину состояний и сложную логику диалога с веб-клиентом, в ситуации когда вы постоянно терятее состояние процесса на сервере... а вы попытались написать внутренний арм как будто это сайтик ...

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

    самое перспективное что я вижу - jsf/primefaces, но увы: он пригоден ровно пока у вас логика и интерфейс укладываются в формат демок на сайте производителя. поверьте мне - на реальном проекте - вы слишком быстро выйдете за границы применимости типовых компонент, вам начнет катастрофически не хватать их возможностей... и в этот момент начнется содом-и-гомора...

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

    в общем вот тут идеи десктопного приложения очень как пригодились бы, но готовых технологий нет.
    я вижу перспективу в использовании web-socket, но опять же, промышленных наработок и фреймворков нет.
    самое близкое что так умеет - c++/Qt но у них скорее трансляция в веб интерфейса с++ приложения. в 1С аналогично - у вас одинаковый интерфейс "управляемой формы" и в веб и на десктопе.

    у нас есть свои домашние заготовки, но, повторюсь, мы пока их не выпускаем на массовый рынок, предлагать не буду. погодите полгодика, и все будет.

    ---------
    в общем я к чему: хотите использовать десктоп в веб? пишите например на qt/c++. у них есть технология трансляции в веб приложения написанного на c++. опять же, на вебсокетах все работает). хотите писать тяжелые арм на джаве для интарнет-интерпрайз-систем - присоединяйтесь к нашему закрытому тестированию (за сим в личку) или ждите публичного анонса. для шарпов ничего не скажу, имхо шарпы только для Unity-гемдева и пригодны(имхо), а как интерпрайз-технология они так и не состоялись.

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

    потому - , уважаемый топик стартер - вы определитесь с тем что вы хотите делать, и поймите, готовы ли вы отказаться от идей десктопной разработки или вы согласны окунуться в нелюбимый многими мир "ынтерпрайза-мать-его". т.е.:

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

    или

    - "тяжелый интранетовский интерпрайз" ( несколько сотен пользователй максимум, сложная логика работы каждого АРМ, тяжелые запросы отрабаиываюшие по десятку минут, запутанные бизнес-сценарии рабрты гуи, фоновые процессы на сервере.... ) - многие десктопные концепции, когда гуи должен рассматриваться так, как будто он локальный - просто жизненно-необходимы. попытки строить эти системы по технологиям из области "массового веб" - ... скажем так ..."чреваты" и в 90% случаев пооучаются либо костыльно убогими, если вообще работают, либо неповоротливыми в разработке и рефакторинге. не смотря на это, готовых решений и концепций всё еще пока практически нет, каждый изъгаляется как может. рынок достаточно закрытый, относительно массового веб : 99% этих арм и ас работают в наглухо изолированных от интернеса сетях.
    Ответ написан
  • Как написать реал-тайм онлайн игру? Методология, паттерны, статьи?

    @dplsoft
    Сильно мне кажется, что вам в первую очредь надо понять/рассказатьНам что именно вы собираетесь писать, а уже потом - вам могут предлагать те или иные варинты решения.

    В зависимости от того, что вы будете делать - какая именно у вас будет "реалтаймовая серверная игра" - от этого будут зависить и те приемы или методы которые вам лучше всего подойдут.

    И что вы вкладываете в понятие "реалтаймовый"?
    вы понимаете, что если 2-х шахматистов ограничить регламентом - мол далайте ход раз в минуту и строго черезх минуту всегда - то это тоже будет _реалтаймовая игра_? "реалтаймовые шахматы с периодом 1 минута". Вас устроит такое?

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

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

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

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

    и потом уже выстраивайте из этого и того что вы знаете те или иные архитектурные механизмы и выбирайте паттерны.

    Вообще задача сильно глобальная - в том виде как задан вопрос.
    Может стоит попробовать начать с чего-то более простого? потому что если вы задаете вопрос про то "как открывать сокет" (технологический инструментарный вопрос) - но плохо представляете что делать если начнется "рассинхронизация" (это концепции логики работы распределнной системы сервер-клиенты) - то может стоит начать с чего-то попроще?

    например, сделать сервер для какой пошаговой игры?
    Ответ написан