[ Каскадный ] · Стандартный · Линейный РПГ текстовый файтинг, Закрытый бета тест

[Alexander87]

Пройдите по ссылке, нажмите кнопку Run
Вытяните экран мышкой снизу вверх и наслаждайтесь.

Игра на двоих.
1) Введите имена игроков.
2) Подберите класс, оружие и броню.
3) Выберете рандомные доп. характеристики.
4) Вступайте в бою друг с другом.



https://onlinegdb.com/Hy9iKBP27

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

Сообщение отредактировал Alexander87 - Среда, 31 октября 2018, 18:26

[Akell]

касательно кода. слишком он спутанный и непонятный. это плохо и лишние сложности.

предлагаю:
0) pep8
1) почитать про enum и вдобавок придумать там нормальные структуры данных, чтобы с ними было легко и приятно работать. а то у тебя всё через хардкоженные индексы в двумерных массивах.
2) т.к. тебе нужно обрабатывать ввод, то тебе нужны методы (функции или процедуры, как угодно эт называй) для обработки ввода и проверки его на ошибки. очень стоит вычленить это в отдельное что-то. например в модуль назвать это utils и туда пихать.
3) тоже самое что с п2, только касательно вывода информации.
4) очень много фактически одинаковых строк, прям 1 к 1. почитай про DRY (don't repeat yourself) и постарайся применять.
5) касательно общей архитектуры и структуры проекта и вообще. начинай думать и двигаться в направлении вычленения модулей, сущностей (классов/обьектов) и их аспектов/свойств и прочего, ищи что там у них есть общего и что можно вытащить в отдельные сущности. и переделай всё в направлении обьектно-ориентированного подхода. это позволит проще вносить изменения, улучшать, исправлять, тестировать код. просто сейчас у тебя всё в кашу смешано.
поясню о чем речь. в идеале как должно быть: ты хочешь добавить какую-то новую возможность. например в нового игребального персонажа или механику. и ты сам себя спрашиваешь, в скольких местах нужно переделывать? в идеале таких мест должно быть меньше чем пальцев на руке. (в самом недостижимом идеале - в 1одном месте)
у тебя просто сейчас очень сильно связанный код, с ним сложно работать и непродуктивно. от этого надо избавляться.
6) после того как появится куча модулей и прочего, можно приделать например юнит-тестики, и прочие тесты. это позволит иметь хоть какую-то уверенность в констистенстности вносимых изменений в код.
7) и замечинание про чрезмерное увлечение операторов ветвление (условным оператором). я понимаю что ты хочешь сделать, но вввидимо ввиду недостаточного опыта и навыков, ты используешь не те инструменты.
тебе бы очень подошло обьектно-ориентированное что-то.
тогда бы вместо перебирания вручную всех вариаций в if-else ты бы просто писал Player.takes_damage_from(Another_player) или Player.attacks(Another_player) и всё. Не нужно было бы для каждого отдельного вида бойца перебирать всё это через if. Вся конкретика происходящего была бы внутри бойца встроена уже. Сейчас фактически ты на себя взял всю ту низкоуровневую работу и те нюансы работы кода, которые бы не пришлось вручную делать при ООП. Т.е. ты вручную некие аналоги виртуальных фукнций к неким обьектам маппишь. Т.е. ты изобретаешь некое отдаленое подобие ООП с кучей лишних недостатков, вместо напрямую применения ООП. Что тебе мешает делать это явно? ты просто делаешь лишнюю рутинную работу, в которой легко наделать ошибок.
8) Не привязывайся к коду (в смысле симпатий), будь готов выкинуть его и переделать в любой момент.

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

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

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

если конкретика интересует, то например вот: 734-738

CODE

       player_inoy = warrior[(warrior.index(player))-1]
       if player_inoy[7][0]<player_inoy[7][2]:
           player_inoy[7][0]=player_inoy[7][0]+player_inoy[7][1]
           if player_inoy[7][0]>player_inoy[7][2]:
               player_inoy[7][0]=player_inoy[7][2]

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

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

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

таких аналогичных проблем ещё много в коде.

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

по итогам: код конечно не production ready, требуется значительная проработка архитектуры и структуры и дизайна проекта.

[Alexander87]

касательно кода. слишком он спутанный и непонятный. это плохо и лишние сложности.

предлагаю:
0) pep8
1) почитать про enum и вдобавок придумать там нормальные структуры данных, чтобы с ними было легко и приятно работать. а то у тебя всё через хардкоженные индексы в двумерных массивах.
2) т.к. тебе нужно обрабатывать ввод, то тебе нужны методы (функции или процедуры, как угодно эт называй) для обработки ввода и проверки его на ошибки. очень стоит вычленить это в отдельное что-то. например в модуль назвать это utils и туда пихать.
3) тоже самое что с п2, только касательно вывода информации.
4) очень много фактически одинаковых строк, прям 1 к 1. почитай про DRY (don't repeat yourself) и постарайся применять.
5) касательно общей архитектуры и структуры проекта и вообще. начинай думать и двигаться в направлении вычленения модулей, сущностей (классов/обьектов) и их аспектов/свойств и прочего, ищи что там у них есть общего и что можно вытащить в отдельные сущности. и переделай всё в направлении обьектно-ориентированного подхода. это позволит проще вносить изменения, улучшать, исправлять, тестировать код. просто сейчас у тебя всё в кашу смешано.
поясню о чем речь. в идеале как должно быть: ты хочешь добавить какую-то новую возможность. например в нового игребального персонажа или механику. и ты сам себя спрашиваешь, в скольких местах нужно переделывать? в идеале таких мест должно быть меньше чем пальцев на руке. (в самом недостижимом идеале - в 1одном месте)
у тебя просто сейчас очень сильно связанный код, с ним сложно работать и непродуктивно. от этого надо избавляться.
6) после того как появится куча модулей и прочего, можно приделать например юнит-тестики, и прочие тесты. это позволит иметь хоть какую-то уверенность в констистенстности вносимых изменений в код.
7) и замечинание про чрезмерное увлечение операторов ветвление (условным оператором). я понимаю что ты хочешь сделать, но вввидимо ввиду недостаточного опыта и навыков, ты используешь не те инструменты.
тебе бы очень подошло обьектно-ориентированное что-то.
тогда бы вместо перебирания вручную всех вариаций в if-else ты бы просто писал Player.takes_damage_from(Another_player) или Player.attacks(Another_player) и всё. Не нужно было бы для каждого отдельного вида бойца перебирать всё это через if. Вся конкретика происходящего была бы внутри бойца встроена уже. Сейчас фактически ты на себя взял всю ту низкоуровневую работу и те нюансы работы кода, которые бы не пришлось вручную делать при ООП. Т.е. ты вручную некие аналоги виртуальных фукнций к неким обьектам маппишь. Т.е. ты изобретаешь некое отдаленое подобие ООП с кучей лишних недостатков, вместо напрямую применения ООП. Что тебе мешает делать это явно? ты просто делаешь лишнюю рутинную работу, в которой легко наделать ошибок.
8) Не привязывайся к коду (в смысле симпатий), будь готов выкинуть его и переделать в любой момент.

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

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

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

если конкретика интересует, то например вот: 734-738

CODE

       player_inoy = warrior[(warrior.index(player))-1]
       if player_inoy[7][0]<player_inoy[7][2]:
           player_inoy[7][0]=player_inoy[7][0]+player_inoy[7][1]
           if player_inoy[7][0]>player_inoy[7][2]:
               player_inoy[7][0]=player_inoy[7][2]

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

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

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

таких аналогичных проблем ещё много в коде.

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

по итогам: код конечно не production ready, требуется значительная проработка архитектуры и структуры и дизайна проекта.

Спасибо большое!!! Вы указали куда двигаться и что для этого использовать. Вы мне очень помогли. Буду искать и учить новые методы реализации. Вы верно подметили что я использовал самые базовые неэффективные способы для реализации задуманного. Буду учить ООП и новые библиотеки что могут мне помочь в упращении кода. Завтра разберусь подробно в Вашей оценке и начну изучать неведомые мне вещи, что были Вами описаны.

[Akell]

Спасибо большое!!! Вы указали куда двигаться и что для этого использовать. Вы мне очень помогли. Буду искать и учить новые методы реализации. Вы верно подметили что я использовал самые базовые неэффективные способы для реализации задуманного. Буду учить ООП и новые библиотеки что могут мне помочь в упращении кода. Завтра разберусь подробно в Вашей оценке и начну изучать неведомые мне вещи, что были Вами описаны.

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

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

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

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

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

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

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

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

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

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

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

арсенал расширять так или иначе придется.

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



Сообщение отредактировал Akell - Четверг, 01 ноября 2018, 03:04