Comments 21
Я бы на вашем месте избавился от структур и сделал классы, а так же переписал все существующие классы используя ООП. Так же можете почитать про паттерн «Наблюдатель(Observer)».
Хорошая идея! Вы не первый кто мне пишет об этом, но на момент написание этой статьи мне казались структуры самым оптимальным вариантом, я заменю их на классы (в ближайшее время). Спасибо за критику и совет!)
На момент создания клиента я думала сделать сервер с моделью «Приоритет сервера» т.е. клиенты отправляют нажатые клавиши на сервер, он их обрабатывает и создаёт сообщения для всех клиентов. Поэтому я и выбрала структуры (т.к. я не представляю другого представления танчиков в расте).
Вы можете отправлять на сервер текущее положение объекта и возвращать с сервера положение других объектов. Так же сделать выстрелы. Так же, не знаю насколько это рационально, но я бы использовал JSON для передачи данных.
Если хотите, можем пообщаться в вконтакте
Если хотите, можем пообщаться в вконтакте
Сервер на Rust, там нет классического ООП с наследованием.
Общий комментарий — а всегда ли надо делать "классическое" ООП?
Если требуется просто динамический полиморфизм — хватает одноуровневой иерархии "интерфейс/трейт-реализация". Это ещё не ООП.
Ну а если требуется сложная многоуровневая иерархия… я бы подумал как свести к одноуровневому случаю. Пока не видел ни разу, чтобы многоуровневые иерархии были реально удобны.
Не сразу осилил навигацию по репозиторию. А почему бы не сделать версии не бранчами, а тэгами? Ну и на гитхабе есть удобная вкладка «releases» :)
Хорошо, спасибо большое за совет )
Я ещё только изучаю гитхаб, поэтому не додумалась до этого )
Я ещё только изучаю гитхаб, поэтому не додумалась до этого )
Да вам верно сказали. Версии в ветках это совсем не правильно с точки зрения любого репозитория.
Обычно правило такое: одна ветка (branch) = один новый функицонал или исправление бага. После создания рабочего функционала и правки бага ветка сливается в master (default) и закрывается.
Версионирование грамотнее делать в тегах, не зря там существует закладка «releases».
Обычно правило такое: одна ветка (branch) = один новый функицонал или исправление бага. После создания рабочего функционала и правки бага ветка сливается в master (default) и закрывается.
Версионирование грамотнее делать в тегах, не зря там существует закладка «releases».
Вот так обычно выглядит работа с ветками — storage1.static.itmages.com/i/18/0111/h_1515652644_4953807_3b6ebf2243.png
Здесь пример bitbucket но общая суть как и в гитхабе.
Здесь пример bitbucket но общая суть как и в гитхабе.
Притча для автора koito_tyan. Жил-был Нотч, он умел писать на C++, но свой Minecraft написал на Java. Почему, спрашивали его люди, тормозить же будет. «Мне на Java лучше думается». С тех пор у всех Minecraft тормозит, а Нотчу по-прежнему лучше думается. В 2014 году Microsoft купила его игру вместе с компанией за $2.5 млрд. Тут и сказочке конец. Пишите на том, на чем вам «лучше думается».
Еще — хорошо когда есть рабочая демка, то что может запустить каждый без компилятора и бубна. Пускай там будет не весь задуманный функционал, но хоть что-то уже дышит. Это ставит автора в более выгодное положение при разборе исходных текстов — применённые решения может быть и не совсем оптимальны, но они заведомо работают.
Еще — хорошо когда есть рабочая демка, то что может запустить каждый без компилятора и бубна. Пускай там будет не весь задуманный функционал, но хоть что-то уже дышит. Это ставит автора в более выгодное положение при разборе исходных текстов — применённые решения может быть и не совсем оптимальны, но они заведомо работают.
Да, поэтому я и пишу сервер на том, на чём мне легче думать, а игру на том, что мне легче понимать )
koito_tyan, а тебя кое-кто обогнал — geektimes.ru/post/297529
Там двое ребят, сервер Java/клиент JS, браузерка, демка вполне работает — http://selim.co/snowbox/
Надо их догнать и перегнать! (они выдохлись)
Там двое ребят, сервер Java/клиент JS, браузерка, демка вполне работает — http://selim.co/snowbox/
Надо их догнать и перегнать! (они выдохлись)
Сам недавно начал изучать Rust, очень интересно посмотреть на опыт других изучающих. Я пока не могу комментировать код от себя, потому что сам еще плохо разбираюсь в языке, но у меня есть пара предложений автору, что можно было бы сделать лучше.
1) Уберите из репозитория на гитхабе все, что не относится к исходникам и документации (exe и obj файлы, build-папки, и т.п.) и почитайте про .gitignore
2) Добавьте, пожалуйста, комментариев к коду сервера. Во многих местах просто непонятно, что происходит и почему сделано именно так, а не иначе.
В целом, статьи читать интересно, хоть и сумбурно. Меня мотивирует :)
1) Уберите из репозитория на гитхабе все, что не относится к исходникам и документации (exe и obj файлы, build-папки, и т.п.) и почитайте про .gitignore
2) Добавьте, пожалуйста, комментариев к коду сервера. Во многих местах просто непонятно, что происходит и почему сделано именно так, а не иначе.
В целом, статьи читать интересно, хоть и сумбурно. Меня мотивирует :)
Хотелось бы узнать мнение автора по вопросу выбора яп для написания клиента и сервера.
В индустрии принято писать клиенты на компилируемых языках (С++, Rust?), а сервера же, для MMO, например, на языках вроде C# и Java.
У Вас же всё наоборот.
Также, интересует вопрос обоснованности использования такого огромного количества потоков. Так как больше потоков != лучше или быстрее. Проводились ли измерения быстродействия того же сервера при однопоточном режиме работы или хотя бы при сокращении потоков до 2-3?
В индустрии принято писать клиенты на компилируемых языках (С++, Rust?), а сервера же, для MMO, например, на языках вроде C# и Java.
У Вас же всё наоборот.
Также, интересует вопрос обоснованности использования такого огромного количества потоков. Так как больше потоков != лучше или быстрее. Проводились ли измерения быстродействия того же сервера при однопоточном режиме работы или хотя бы при сокращении потоков до 2-3?
Сейчас (в связи с конкурсами) мне трудно написать новую статью, но уверяю вас что количество потоков снизилось.
Сервер активно дописывается до новой версии, возможно в будущем мне придётся переписать его снова/пересмотреть использование некоторых переменных.
Про языки… Rust -> отличный быстрый язык, который не подвержен резким падениям из-за не пойми чего (не пустые слова, на C# падали консольные приложения без явной ошибки в коде). Тем более Rust я понимаю гораздо лучше чем C#.
Это всё есть небольшой эксперимент, который скоро завершится классным проектом (сейчас есть небольшая команда помогающая написать какой-никакой GUI, надеюсь что сможем :) )
Да, и поэтому пришлось выбрать эту модель (вот сам сервер файл запуска сервера).
При однопоточном режиме сервер очень медленный, при 2-3 потока, быстрее но не так как надо. В следующей статье я опишу почему получилось именно так, спасибо за заинтересованность этой темой ))
Сервер активно дописывается до новой версии, возможно в будущем мне придётся переписать его снова/пересмотреть использование некоторых переменных.
Про языки… Rust -> отличный быстрый язык, который не подвержен резким падениям из-за не пойми чего (не пустые слова, на C# падали консольные приложения без явной ошибки в коде). Тем более Rust я понимаю гораздо лучше чем C#.
Это всё есть небольшой эксперимент, который скоро завершится классным проектом (сейчас есть небольшая команда помогающая написать какой-никакой GUI, надеюсь что сможем :) )
Проводились ли измерения быстродействия того же сервера при однопоточном режиме работы или хотя бы при сокращении потоков до 2-3?
Да, и поэтому пришлось выбрать эту модель (вот сам сервер файл запуска сервера).
При однопоточном режиме сервер очень медленный, при 2-3 потока, быстрее но не так как надо. В следующей статье я опишу почему получилось именно так, спасибо за заинтересованность этой темой ))
Sign up to leave a comment.
Танчики в консоли, статья третья: «Сервер и клиент»