Zimaell, тогда выбираете надёжный алгоритм, придумываете длинный сложный пароль (ключ) - и шифруете. Тем же TrueCrypt или VeraCrypt можно. А так - куча программ.
А вообще почитайте для начала это, иначе данные в конце концов утекут, потому что вы исходите из предположений, которые могут оказаться не верны.
CityCat4, да я тоже помогаю, когда чел попал в затуп. Проблема в том, что в других случаях посыл в #опу (гугл) - это не ответ. И даже если намекнуть на отладку - это тоже плохой ответ с формальной точки зрения (потому что посыл). При этом нельзя жаловаться на вопрос, т.к. он как бы ничего особо не нарушает.
Ах, да, ещё есть вариант пожаловаться на вопрос, когда его автор так сильно проявляет свои чувства, нарушая существующие рамки, что наступает на мои свободы у вызывает у меня негативные чувства. Но это мы снова возвращаемся к тому, а какие же рамки.
Человек, конечно, личность, но на данном ресурсе он может проявлять её лишь в определённых рамках, подчиняясь правилам. Это же касается отвечающих. Мой вопрос касается именно этих рамок. Каковы они?
Я в курсе про то, что все мы люди, тут всё добровольно и пр. Речь не об этом. Предположим, мне встретился такой вопрос про ошибку в коде. Предположим, я решил, что точно хочу что-то ответить. Естественно, у меня хватает компетенции для ответа и даже есть много времени, то есть я 100% могу дать ответ. Тогда можно очень грубо прикинуть варианты, которые я вижу:
Рассказать автору, что есть такая штука, как отладка, и что ей можно заниматься самому, не дожидаясь ответа.
Просто сделать отладку и указать то место, где ошибка.
Каждый из этих вариантов имеет свои плюсы и минусы.
Первый вариант, возможно, откроет автору глаза на мир программирования. Это может оказаться наиболее полезный ответ. Но это также может, наоборот, спровоцировать конфликт, ну или автор просто посчитает ответ бесполезным.
Второй вариант может вылиться в долгую дискуссию, а что у вас здесь, а как вы запускаете, а поправьте здесь стиль, добавьте отступы, а то читать не удобно. В результате отвечающий потратит много времени на данного автора, хотя мог бы помочь ответами на другие вопросы. И когда проблема решена, радостный автор приходит на следующий день с новым кодом для отладки. Ведь в прошлый раз ему помогли.
Поймите, я же не против помощи людям. Я спрашиваю о лишь о том, что есть помощь в данном случае? И есть ли какой-то регламент, который рассказывает об этом?
Так я не предлагаю проверять реальность автора или его намерений. Мой вопрос вообще не об этом. Хотя, если очень захотеть, можно вывести некоторые моменты реальности автора или его намерений.
Очевидно (легко доказать), что отладкой заниматься проще самому разработчику, который пишет этот отлаживаемый код. Ведь у него уже есть доступ к кнопке, которая просто запустит программу. Даже если не использовать отладчик, а просто компилятор или интерпретатор - это уже всё упрощает. Отвечающему же нужно запустить тестовую среду, и максимально приблизить её к той, что у задающего вопрос.
Конечно, бывают простые примеры. Но в общем случае даже разница между версиями отладчиков или компиляторов вносит свои искажения.
Поэтому реальность автора и его намерений уже не так важна. И возникает новый вопрос, почему автор вопроса игнорирует собственные преимущества и эффективность. Путь даже это полноценный ИИ без модерации, его вопросы должны подчиняться человеческой логике, хотя бы создавать видимость. И лично у меня здесь всего два варианта ответа:
- либо автор вопроса про отладку не в курсе про отладку.
- либо автор вопроса про отладку в курсе, но хочет переложить работу на других.
В первом случае, мне кажется, автора нужно послать заниматься отладкой, а во втором случае - просто послать (проигнорировать вопрос).
Однако я спрашивал не об этом, а о том, как все эти моменты регулируются. Есть ли правила или негласные правила, которые применимы в таком случае. Даже про правила вежливости с учётом моих выкладок было бы интересно послушать. А уж как применять эти правила, я разберусь потом (в каждом конкретном случае).
О своих сомнениях я пишу в тексте выше, потому что и правда бывают случаи, когда вопрос, скажем так, нормальный, его автор и правда зашёл в тупик и сделал всё, чтобы упростить отладку отвечающим. Поэтому нельзя просто взять и тупо запретить вопросы про отладку. Собственно, я вообще ничего не предлагаю по этому поводу. Наоборот, я спрашиваю, что уже есть, и высказываю сомнения.
Любой технический вопрос можно удалять с формулировкой: "Если у тебя есть проблема, то ты либо не читал документацию, либо не хочешь думать". Тогда останутся лишь ведущие к дискуссии, которые тоже запрещены.
Не любой. Есть вопросы, которые остаются даже после прочтения документации и после некоторого периода размышлений. Но речь не о любых вопросах, а о вполне конкретном множестве вопросов, где автор просит найти ошибку в его коде. И фишка в том, что отладка - это базовый навык программиста. Даже программа по типу "hello world" - это проверка работы языка, то есть по сути отладка. А это значит, что автор вопроса не читал документацию вообще и не думал вообще. То есть потратил 0 усилий и 0 времени. И такой вопрос приобретает особый статус, отличный от "любого" технического вопроса.
На всякий случай, хочу прояснить пару моментов.
Переводить тему на более общую, более узкую, просто другую или приводить в примеры крайности - это по сути подмена тезиса (соломенное чучело), очень некрасивый приём. Надеюсь, вы им изобилуете не специально. Наверное, моя вина в том, что не достаточно структурировал вопрос, но экстраполировать - тоже не дело.
Мой вопрос касается не мотивации или человечности, а регулирования, то есть законов, норм, правил, традиций, касательно таких вот вопросов (про отладку). Например, правомерно ли послать автора заниматься отладкой самому, намекнув на такую возможность? Так-то я в курсе, что ответы добровольны. А насчёт мотивации я отталкиваюсь от того, что цель отвечающего - бескорыстно помочь, потратив своё время, получив что-то ментальное (баф к настроению, опыт и т.д.).
Вопрос состоит в том, как это регулируется. То есть, какие есть правила, или, может быть, их нет совсем. Или какие-то неписанные правила. Например, в таком-то случае это нарушение такое-то, а в другом случае это ок, и какие-то критерии.
Подвопрос состоит в том, что если не регулируется, то как лучше отвечать на такие вопросы, и стоит ли вообще. Как я уже объяснил в тексте описания вопроса, проблема в том, что лучший ответ (по-моему) для большинства подобных вопросов - это объяснить человеку про существование отладки, ну и предложить заняться ею. Но такой ответ многих не устраивает и воспринимается как вода или какой-то негатив без видимой пользы.
Максим Федоров, я пишу о том, что отладкой проще заниматься тому, кто непосредственно занимается разработкой. А в вопросах автор иногда вообще не знает такого слова, как "отладка". Вот мне и интересно, каков статус таких вопросов.
Но в любом случае, какой бы ни был баг (даже если он касается исполняющей среды или вообще самой ОС), автору вопроса, скорее всего, будет проще найти ошибку самому, потому что уникальные условия возникновения ошибки могут быть только у него.
Нужно лишь уметь в отладку. А это базовый навык программиста.
Удалаю свой ответ, так как автор вопроса походу вообще не понимает намёк про отладку и считает данный ресурс источником бесплатных программистов. Удачи ему.
А как узнать, какие ключи соответствуют друг другу? Какой критерий?
Например, _test соответствует чему? Он соответствует test2 или key2 из предыдущей строки?
Можно грубо разделить разработку игры на четыре части:
1) геймдизайн 2) программирование 3) арт 4) маркетинг.
Пропорции не равные и зависят от игры. Но при прочих равных можно грубо считать, что на каждую часть уходит 25% времени. Но бывает и так, что программирование - всего лишь 5-10% от всех усилий. А иногда вообще 0%, как в случае с настольными играми.
MOBEE_DIK, одним словом - за документацию. А так это самая нечеткая роль в геймдеве. Многие до сих пор спорят, чем же он на самом деле занимается.
Считается, что геймдизайнер должен придумывать интересные механики и уметь презентовать их команде, то есть объяснять, почему они клевые, и как именно их надо реализовать (вплоть до написания ТЗ). На практике гд берёт чужие идеи, в том числе членов команды.
Дальше, в зависимости от конкретной компании, могут быть свои нюансы. В какой-нибудь инди-команде он может быть душой проекта - находить язык с каждым и добиваться общего понимания, что именно делает команда. А в студии, где однотипные игры поставлены на поток, геймдизайнер уже практически не нужен.
Ну и есть различные направления - балансер, сценарист и т.д. Даже левел-дизайнер - тоже гд, хотя я бы отнёс частично к "художникам".
В принципе можно даже запихнуть картинку в
<noscript>, и параллельно инлайн-скриптом делать через канвас. Самый норм вариант, как мне кажется.