Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Алгоритми та структури даних, технології → Ігрова логіка плюс база данних.
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися
Така задача. Текстовий квест в котрім буде до 30 локацій. На котрі можна буде переходити в любий час. Чи правильно буде
Якщо кожен раз зберігати поточний стан локації. До бази данних. А коли гравець повторно повертається на локацію щоб скрипт зчитував з бази актуальний стан локації. Чи може є якийсь інший спосіб це організувати.
Це надто загальне питання. Загалом, гадаю, буде 3 типи інформації про локацію:
- незмінна інформація (якщо в локації є лавка з магічними речами, то вона там буде завжди);
- спільна інформація (якщо в грі передбачена взаємодія між гравцями);
- персональна інформація гравця (зламав вказівник - більше вказівника немає).
І так, очевидно, все має бути в базі і читатися, коли хтось зайде і запитає цю інформацію.
Питання було про бази даних. Це, звісно, чудово, що ви знаєте ці два розумні слова, але питання було не про них.
- незмінна інформація (якщо в локації є лавка з магічними речами, то вона там буде завжди);
Ліпше то занести в базу данних чи зберигти в txt? Хoчу зробити так щоб в коді взагалі не було жодного тексту.
Щоб можна було міняти текст нелізучи в код.
- спільна інформація (якщо в грі передбачена взаємодія між гравцями);
немій варіант.
- персональна інформація гравця (зламав вказівник - більше вказівника немає).
І так, очевидно, все має бути в базі і читатися, коли хтось зайде і запитає цю інформацію.
Ось це саме то. Є об'єкти(нпс) котрі переміщуються між локаціями. І на різних локаціях будуть мати різні описи
Наприклад :
На локації Шлюз після вибуху ми можем врятувати дівчинку.
Якщо ми її рятуєм то потім ми зустрічаєм на локації станція гідропоніки.
Якщо ні то більше її не зустрінемо.
Якщо ми вкрадем їжу з станції гідропоніки то дівчинка почне переміщатися до іншої локації в пошуках їжі. При тому що дівчинка має характеристики ситість, мораль, відчай і ще має в сумці кілька пердметів плюс, ще маємо діалоги знею котрі можуть змінюватись залежно від обставин.
сварлива каалка в своєму репертуарі
база даних є лише контейнер.такі питання взагалі не повинні вставати на цьому рівні. а от модель гри за якою треба писати сценарій, то є не зовсім трівіальна річ. розробіть модель і більшість питань відпаде сама.
дівчинка
ще один... і де поділися ті парубки моторні? відростили бороди і сидять по домівках? а навколо самі тьотки, нігери і геї?
ur_naz, вам попередження за порушення п.2.4 Правил.
pluszz, це все залежить від правил гри, які знаєте в кращому разі тільки ви, а загалом, я так розумію, не знає поки ніхто. Якщо у вас дійсно деталізація до такого рівня буде, то треба окремо таблицю локацій, таблицю зв'язків, таблицю персонажів і таблицю предметів, і то тільки в першому наближенні.
які образи чи погрози? яка нецензурна лексіка? ви про що?
pluszz, це все залежить від правил гри, які знаєте в кращому разі тільки ви, а загалом, я так розумію, не знає поки ніхто. Якщо у вас дійсно деталізація до такого рівня буде, то треба окремо таблицю локацій, таблицю зв'язків, таблицю персонажів і таблицю предметів, і то тільки в першому наближенні.
За основу беру такі правила https://replace.org.ua/misc.php?action= … download=1 трохи зміню ще не розумію як маю організувати деякі моенти. І можливо дещ зміню хоча наразі основу механіки беру без змін добавив лише сумку(інвентар)
Колись давно коли я перший раз дізнався про цю ігрову механіку, хотів запилити гру про голодомор 32-33х років. Але я просто неможу рука непіднімається на святе. Тим більше я знаю себе постійно роблю пунктуаційні та орфографічні помилки. Не уявляю можливим щоб у грі про голодомор була азіровка. Тому вирішив зробити гру на іншу тему.
таблиці зв`язків
Це буде таблиця в якій будуть можливі зв'язки з кожним з персонажів?
Посварилися Підозра Приязнь Дружба
_________________________________________________
Вася | 1 | 1 | 0 | 0
_________________________________________________
Віктор | 0 | 1 | 0 | 1
_________________________________________________
Картана | 0 | 0 | 0 | 0
Типу так може бути?
Персонажі:
ID_персонажа|iмя персонажа| ситість |Відчай| емоції |цикл набору ситості| сумка | id_поточної локації| історія персонажа
__________________________________________________________________________________________________________________________
1 | Вася | 40 | 0 | 1, 2, 3, 4, | 1 |10, 12 ,1| 2 | Син фермера з .....
Таблиця персонажів заповнюється скриптом колонка "емоції по id з талбиці емоцій" генерується функцією random.choice() беручи значення з таблиці емоцій обовязковою є лише пера емоція "Воля до житття". Ситість напочатку гри для кожного нпс може = від 30 до 40 як random ляже.
в сумці для кожного нпс будуть обов'якові предмети та один два рандомно вибрані.
Таблиця гравців
id | Телеграм id |персонаж| хід |досягнення
_________________________________________________
1 |XXXXXXXXXX| 2 | 40 | 1 , 2, 3, 4
Я то бачу так плюс таблиця локацій , таблиця змінних об'єктів типу( двері, камера спостереження, медична капсула тп з їх атуальним станом ), таблиця емоцій та таблиця предметів статичні в них нічого не змінюється просто зберігаються дані
Таблиця локацій вирішив не мудрити хай для ігрової логіки локація шлюз до вибуху і локація шлюз після вибуху будуть різними локаціями. А гравцям хай здається що то одне і теж.
Я не про то питав але дякую, це теж пригодиться.
Ні, я мав на увазі зв'язки між локаціями. Тобто, скажімо, з каюти можна потрапити в коридор і навпаки, але з з каюти можна (шестом) спуститися до загальної зали, але назад лише через коридор. Чи, наприклад, пробиття стіни може зробити новий прохід.
А ви вже про стосунки почали.
Замість "сумки" у предметів має позначатися, де вони знаходяться.
Ні, я мав на увазі зв'язки між локаціями. Тобто, скажімо, з каюти можна потрапити в коридор і навпаки, але з з каюти можна (шестом) спуститися до загальної зали, але назад лише через коридор. Чи, наприклад, пробиття стіни може зробити новий прохід.
А ви вже про стосунки почали.
Дякую. Упустив той момент.
Таблиця для кожної локації?
А як зберігають такі дані в офлайн іграх на пк в тадлицях чи там всьо хардкодять?
Замість "сумки" у предметів має позначатися, де вони знаходяться.
А якщо є кілька предметів на приклад аптечка в різних місцях тоді в таблиці треба робити аптечка 1, аптечка 2, аптечка 3,
koala написав:Ні, я мав на увазі зв'язки між локаціями. Тобто, скажімо, з каюти можна потрапити в коридор і навпаки, але з з каюти можна (шестом) спуститися до загальної зали, але назад лише через коридор. Чи, наприклад, пробиття стіни може зробити новий прохід.
А ви вже про стосунки почали.
Дякую. Упустив той момент.
Таблиця для кожної локації?
А як зберігають такі дані в офлайн іграх на пк в тадлицях чи там всьо хардкодять?
Можна зберігати графи. На мою думку це буде найправильніше .
Ні. Якщо у вас є багато однотипних об'єктів, то це одна таблиця.
Взагалі це все залежить від вимог - тут варто більшість даних тримати на диску і бути готовим відновлювати гру після довгих пауз, так що БД - саме воно; якщо ж дані треба діставати дуже швидко, то це класичні структури (ur_naz підкаже) або щось на тему модного дизайну, орієнтованого на дані (data-oriented design, DOD).
Ні. Якщо у вас є багато однотипних об'єктів, то це одна таблиця.
Взагалі це все залежить від вимог - тут варто більшість даних тримати на диску і бути готовим відновлювати гру після довгих пауз, так що БД - саме воно; якщо ж дані треба діставати дуже швидко, то це класичні структури (ur_naz підкаже) або щось на тему модного дизайну, орієнтованого на дані (data-oriented design, DOD).
Ну яке там швидко однокористувацька текстова гра секунда вправо секунда вліво ніхто не помітить.
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися
