Так это, Новый Год на носу, все телепаты в отпуске. Ты бы хоть main.xml файл выложил, а то не благодарное это дело угадывать чего там у тебя в нем не правильно и какой такой токен в нем invalid.
А вообще он же указывает на проблему в 8 строчке, пробовал смотреть, может там криминальное что?
Сообщение отредактировал Daeloce - Пятница, 25 Декабря 2015, 13:32
скорость движения стремится к нулю о-о-очень долго - это слишком критично
То ли я не понял что вы написали, то ли вы что-то не то сделали. Падение скорости будет только на последнем перед waypoint'ом шаге, и только на один этот шаг(шаг это тик по времени).
ЦитатаQValidator ()
а к количеству допустимых шагов между клетками
Тоже не ясно. Вам надо привязываться именно ко времени, потому что если между тиками прошло 400 мс, то вам и надо пройти на 400 мс. Деланьем вместо 1 шага на 400 мс 40 шагов на 10мс вы лишь избежите промахивание мимо цели и правильно отработаете передвижение.
Ну вообще-то цену принято называть до того как взял заказ, а не после. Я считаю стандартно, беру стоимость своего часа работы, и умножаю на оценочное время требуемое на реализацию проекта(с учетом всех рисков естественно). В вашем случае нужно сделать так же, а потом уже корректировать цену исходя из возможностей заказчика. Но на будущее лучше все же оговаривать цену до начала работ.
Добавлено (25 декабря 2015, 07:24) ---------------------------------------------
ЦитатаOpenGOO ()
Так считают, если работают за ЗП.
С чего это? Это нормальный способ расчета и для разовых контрактных заказов.
Минус такого решения, при приближении к waypoint'у будет происходить замедление, т.к. последний шаг всегда утыкается в точку маршрута, не зависимо от скорости и прошедшего времени. Если это критично, и существенное падение скорости перед этими точками не допустимо, можно сделать так. Выбираешь временной шаг который тебе удобен, например 10 мс, и все прошедшее между вызовами время делишь на кусочки по 10 мс, и для каждого временного отрезка делаешь смещения объекта, т.е. грубо говоря если тебе надо сдвинуться на 100 мс, ты двигаешься 10 раз по 10 мс, таким образом какой бы лаг по времени не был, ты каждый раз движешь удобными для тебя отрезками времени.
Алгоритмов существует множество, от аналитических до различных имитаций реальных физических систем(например когда ребра графа заменяются растяжимыми упругими стержнями и ищется равновесное состояние). Почитайте например тут: http://mmc2.nsu.ru/default....pl=I206 здесь имеется несколько алгоритмов, выбирайте какой понравится.
Сообщение отредактировал Daeloce - Четверг, 24 Декабря 2015, 17:37
Опыта разработки именно игр не было, это первая. Имеется приличный опыт программирования(это моя основная профессия и заработок уже 7 лет ).
Графика это пока что одна из основных проблем, ибо из меня художник как из свиньи балерина, а у жены опыта пиксель арта нету, хотя сама она художник. Пока ориентируюсь на пиксельную спрайтовую графику, что-то на подобии этого: http://i1005.photobucket.com/albums/af180/loldsohard/MAP-3.png Но точно буду определяться как только реализую основную часть функционала(ориентировочно первая неделя января).
Добавлено (22 декабря 2015, 22:03) --------------------------------------------- Alfe,
Экономическая стратегия с непрямым управлением, в которой вы управляете небольшим поселением в условиях глубокого севера.
Сообщение отредактировал Daeloce - Вторник, 22 Декабря 2015, 22:18
Как бы там HPC. А это скорее вообще не ++, а Си. С классами потому что мне так немного удобнее. Но HPC это как раз то немногочисленное исключение(а я указывал что оно есть), но процент которого крайне мал в общей массе софта на плюсах. Кроме этого же, вся моя продуктовая разработка на С++, уже чистое ООП.
ЦитатаGudleifr ()
Надоели. Простите за хамство, но, в отличие от Вас, понимаю. Разница между нашими пониманиями:
Картинок я вам тоже могу много прислать, вот только ваши претензии к STL в том что она "прячет" данные от пользователя, говорит о фундаментальном не понимании принципов ООП(для которого "прятанье" данные является одним из основополагающих аспектов).
ЦитатаGudleifr ()
Таблица расстановки, если только в STL не налажали. Но не суть,
Это как раз мой второй предложенный вариант. Соответственно прошу примеры проектов/книги авторов, которые бы доказывали ваше утверждение.
ЦитатаGudleifr ()
Еще надцать лет попишете (как сейчас) код, к которому нельзя по очевидным причинам прицепить ООП,
Спасибо, но я пишу на ++ код, к которому не то что можно прицепить ООП, но который с использованием только этого самого ООП и написан.
ЦитатаGudleifr ()
И какой процент этого покрывает STL?
Ну например бинарные деревья, это map. НО. Этого и не должно быть в STL, ибо область применения подобных алгоритмов крайне специфична, и либо они берутся из соответствующих HPC библиотек, либо пишутся самим программистом. Но даже в случае самостоятельного написания данных контейнеров, в нормальном С++ проекте, вам не позволят работать с голыми массивами, вы должны будете их обернуть в свой собственный my_very_hpc_vector, который будет инкапсулировать голый массив и скрывать его от пользователя вашего вектора.
ЦитатаGudleifr ()
Так что, STL просто "защищает" пользователя от данных вместо того, чтобы получить к ним доступ в нужной для него форме.
Естественно. Это и есть ООП. И снова я возвращаюсь к вопросу, вы вообще в курсе что такое ООП?
Выше Вы допускали выход за пределы STL и Qt только в виде исключения.
Не выход за их пределы, а использование сущностей со схожим функционалом вместо них. Т.е. использование динамического массива вместо vector'а действительно должно быть очень существенно обосновано. Как из этого вы вынесли "не-ОО" стиль, я по прежнему не понял.
ЦитатаGudleifr ()
Пожалуй, самая дебильная библиотека работы с графикой.
Вообще-то одна из лучших библиотек, как графических так и общего назначения(те же контейнеры в ней на много удобнее чем STL'ные). Вы на ней что-то сложное писали, чтобы так утверждать? Я писал, и пишу. И много.
ЦитатаGudleifr ()
но насколько "вглубь" библиотеки распространяется эта ОО?
С каждой вашей фразой, мне все больше кажется, что вы понятия не имеете, что такое ООП... Но разу уж спросили, то "глубоко", до самых низов, т.е. до вызовов системных функций.
ЦитатаGudleifr ()
Вы уверены
Уверен. Я не однократно правил их исходники и слал им патчи.
ЦитатаGudleifr ()
был перенесен на "быдлокод" - STL.
То что STL - "быдлокод" это пока что ваше голословное утверждение. STL это как раз то самое ООП которое вы так тут обличаете. И автор языка(как и все выдающиеся программисты, что Александреску, что Макконел, что десятки других) использует с++ только с ООП парадигмой.
ЦитатаGudleifr ()
У меня - более 30. И я не только видел, но и ломал код перечисленных компаний. Замнем.
Какое отношение "ломание" кода имеет к нашему разговору? Или вы его "ломали" получая исходники? Я видел исходники продуктов этих компаний. И там сплошной ООП. И да, у вас 30 лет коммерческой разработки на ++? Если нет, то опять же какое это имеет отношение к нашему разговору? Хоть 30, хоть 60 лет коммерческой разработки например на Си, ни на грамм не добавят вам опыта и видения проектов на С++.
Давайте обозначим тему разговора. Если вы мне хотите доказать что С++ ущербный язык, что Си/Smalltalk/D/Ada/...(подставить нужный язык) лучше и нужно использовать их, то я предлагаю закончить эту дискуссию, она не имеет смысла. Если же вы хотите меня убедить, что правильное использование С++ это использование его в "не-ОО" стиле, и в таком виде он на много удобнее/красивее/лаконичнее/т.п., то чтобы мы как-то перешли в конструктивное русло, приведите мне пример С++ приложения(более или менее коммерческого, школьные поделки меня мало интересуют), написанного в "не-ОО" стиле. Пометка, изначально С++ приложения, потому что есть ряд софта(например gcc) который лишь недавно стал формально ++ софтом, что естественно не может являться образцом стиля разработки на С++. Вместо примера софта, вы можете привести книги авторов, уровня Макконела или Александреску, которые бы утверждали что "не-ОО" стиль написания С++ программ - верный. Наконец, если же вы пытаетесь донести до меня исключительно ваше мнение, то опять же давайте перейдем в конструктивную область, и обсудим преимущества и недостатки обоих подходов, а то все это выливается в пустое припирание.
ы сами написали, что читабельность C выше "не-ОО C++" и что применение ООП допускается только в виде исключения ("должна быть доказана его необходимость").
Вы не верно прочитали, что я написал, перечитайте. Мой посыл: читабельность С выше чем "не-ОО С++", поэтому НЕ использование ООП допускается только в виде исключения. По умолчанию код на С++ должен быть ООП.
ЦитатаGudleifr ()
Ни разу не видел такого (окромя учебников). Всегда одно и то же (как у Вас): сплошные отмазки по поводу неспецифичности задачи и практической необходимости делать "через массивы".
Прежде чем такое утверждать, нужно хотя бы уточнить, проекты какого уровня вы вообще видели на ++. Возьмите например Qt, открытая С++ библиотека, и посмотрите как она написана. Не видел почти ни одной серьезной программы на ++ в которой использовались бы голые динамические массивы. Даже в случаях когда существующие контейнеры не годятся по той или иной причине, пишутся свои контейнеры, которые скрывают эти самые голые динамические массивы(надеюсь не надо объяснять, что в конечном итоге, STL'ные контейнеры это тоже обертки над динамическими массивами? ). Если что у меня 7 летний опыт комерческой разработки на ++, я видел код таких компаний как Sony Ericsson, Samsung и Motorola.
ЦитатаGudleifr ()
Страуструп и Парнас были жуткими идеалистами.
Вы уже Страуструпа похоронили, или почему он "был жутким идеалистом"? От ++ он не отказывался, продолжает их развивать и вроде как заявлений о "правильном не-ОО стиле написания программ" я от него не слышал.
Вот только это никакого отношения к С++ не имеет. Это чистый Си.
ЦитатаGudleifr ()
Только один: C++ ничего не стоит как язык.
Что-то я не уловил перехода от сказанного мной к такому выводу.
ЦитатаGudleifr ()
И правильный способ его использования: не-ОО код, вызывающий ОО-библиотеки ("быдлокодерский", в отличие от "классического" - честное ООП; и "чтоб было" - замена ненужных struct на ненужные class).
Нет, это неправильный способ. Правильный способ написания С++ программ, это ООП. Если вам не нужен ООП, вам не нужен С++(не всегда так, я сам например в HPC программах смешиваю плюсы и си, но это исключение, а не правило). Весь коммерческий и серьезный плюсовый код пишется в ООП стиле. Ну а ваши заявления о "правильном способе" расскажите Страуструпу и Александреску!
найти в программах "нечитабельную лапшу" из умных указателей обычно не труднее, чем из сырых.
Естественно, говно-код он есть везде, я нечитабельную лапшу даже на шарпе с джавой видел, а там её породить надо умудриться я вам скажу. Вот только нужно смотреть не количество кривых программ, а наоборот. И читабельных программ на С++ где используются char*'ы с malloc'ами не существует(точнее как, существуют естественно, вот только эти программы обычно без модификаций компилируются чисто сишным компилятором :)). Поэтому во всех руководствах/учебниках и в любой нормальной команде разработчиков есть простое как 3 рубля правило: если ты пишешь на С++, то ты обязан использовать STL(или аналогичные библиотеки в случае их использования, например Qt). И каждое написание собственного вектора, использование динамического массива или указателя на чар должно быть четко обосновано, с точки зрения невозможности использования готовых вариантов из стандартной библиотеки.
Зачем нужен С, если есть ASM? Зачем нужен ASM, если можно в машинных кодах писать? Зачем компьютер использовать, если можно все в ручную на бумаге посчитать? Зачем...
По теме.
Зависит от задачи. На работе, где в основном пишу HPC вещи, плюсы в использую в режиме "Си с классами", ибо там голые массивы, да еще и руками выровненные под кэш и т.п. суровая необходимость, так что в ООП не развернешься. При разработке же обычных приложений(десктопный и серверный софт) на плюсах, за применения сишных конструкций и подходов в любой нормальной конторе бьют по рукам, так что там только ООП в максимально чистом виде.
Конечно, и в C++ можно иметь дело с "просто строкой", но почему-то это (работа с "просто данными") первое, от чего отучаются C++-программисты.
Если под "простой строкой" вы понимаете char*, то я вам скажу почему "это первое, от чего отучаются C++-программисты". Потому что за использование указателей на чары вместо string нужно не то что бить по рукам, а лишать права подходить к компьютеру ближе чем на пару метров. Потому что после таких вот советов, плюсовый код превращается даже не в Си с классами, а в нечитабильную лапшу из смеси malloc, new, free, delete, char*, string и прочего. Практически не существует случаев, при которой нужно использовать сырые указатели вместо string'а(вызов сишных библиотек не в счет).
Сообщение отредактировал Daeloce - Вторник, 22 Декабря 2015, 12:18
Рабочее название: Davvi Gavpot("Северный город" - с северносаамского) Жанр: Экономическая стратегия непрямого управления. Пространство: 2d. Вид: Стандартный для стратегий вид сверху. Описание: Вы мэр/управляющий/глава небольшого северного поселения. Вас только что выбрали, чтобы вы организовали жизнь людей в вашей деревеньке. Люди которые живут в ней не дураки, они сами способны найти себе еду в лесу или собрать дров. Но окружающий мир суров, вы живете в глубоких северных землях, кругом снег, лед и глубоко отрицательные температуры, и чтобы пережить суровые зимы вам нужно организоваться и от индивидуального типа ведения хозяйства перейти к централизованному. Сможете ли вы улучшить жизнь ваших людей, наладить добычу основных ресурсов и убедить всех следовать вашим советам? Переживете ли вы суровые зимы, температура при которых опускается далеко ниже нуля, а бураны и метели делают даже короткую вылазку в лес суровым испытанием? Или может своим неумелым руководством вы лишь разрушите, и так шаткую, экосистему и станете ответственным за гибель десятка людей? Поглядим... Особенности вашей игры: Попытка объединить экономическую стратегию, со всеми присущими особенностями: большим количеством различных связанных ресурсов и зданий, наукой и сложными потребностями, с непрямым управлением - когда вы лишь можете обозначить что строить или добывать вашим людям, а уж сделают ли они это, будет зависеть от множества факторов. Какие есть похожие игры? Смесь RimWorld и Anno Для какой платформы? Windows и Linux Какой движок\конструктор собираетесь использовать? SFML и C++
Дневник разработки:
15 декабря:Создан скелет движка игры. 16 декабря:Реализована основа для игровой карты и генератора территорий. Реализованы алгоритмы поиска путей. 17 декабря:Реализована основа для юнитов и игровых объектов. Реализованы механизмы их взаимодействия друг с другом. 18 декабря:Рефакторинг и оптимизация кода. 19-20 декабря:Реализована основа для различных item'ов(ресурсы, инструменты и пр.), сделан инвентарь для юнитов, возможность применять item'ы к объектам и добычу ресурсов. Добавлена основа для ИИ, в качестве примера реализован ИИ дровосека, и сделана демка с дровосеками добывающими лес. 21-22 декабря:Реализован механизм зданий. К зданиям можно приписывать работников, каждому из которых назначается профессия по которой он начинает работать(например люди приписанные к хижине дровосека становятся дровосеками и начинают рубить деревья). Сами здания нужны для 2х целей, добыча ресурсов и комбинация ресурсов для получения новых. При этом каждое здание может назначать несколько разных целей юнитам(например дровосек может как рубить дрова при наличии топора, так и собирать хворост при его отсутствии, что ему делать определяется настройками здания, которое в будущем будут задаваться через пользовательский интерфейс Проведен рефакторинг и оптимизация кода. 23-24 декабря:Реализован механизм пользовательских менюшек для зданий. Реализовано на примере хижины дровосека, в которой теперь можно назначать работника из доступных юнитов. У юнитов реализован механизм выбора тайла в зависимости от направления действия/движения. Нарисован тайл поселенца.
Ближайшие планы:
* Подготовка технологической демки и запись видеоролика с ней. * Реализация характеристик юнитов влияющих на различные их параметры(количество и вес переносимых item'ов, жизни и т.п.) * Реализация механизма влияния окружающей среды на юнитов.
P.S. Скрины выложу на этой неделе, нужно подобрать или нарисовать тайлы, а то пока что по карте разноцветные квадраты бегают
Сообщение отредактировал Daeloce - Пятница, 25 Декабря 2015, 00:09
).