Что должно быть в 2D игровом механизме? [закрытый]

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

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

• Компонент для их генерации (с помощью алгоритма заливки).
• Обязательно включите все основные алгоритмы поиска пути / планирования (A * / Dijkstra / и т. д.) для прохождения этих графиков.

Подводным итогом этого является то, что вам придется определить, что такое «карта» для движка, что может ограничить пользователей движка ,

Связанные вещи:

• Триггеры, основанные на местоположении (игрок входит в невидимый круг, и что-то происходит - кат-сцена, начало засады и т. Д.). Я бы сказал, предоставить базовый класс для триггера и реализовать некоторые базовые классы, чтобы показать, как это делается (например, подхват оружия и т. Д.)
• Некоторые игровые движки реализуют сетевое взаимодействие (хотя это своего рода часть «xna stuff»)

Простое обнаружение несовершенных пикселей. НЕ ФАРСЕР Физика. Простые процедуры рисования, такие как Drawline, Drawcircle и т. Д.

Инструмент повторения плитки. То, что позволяет пользователю добавлять / создавать плитку и манипулировать краями для получения гладкого повторяющегося узора.

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

• Фреймворк анимации, чтобы вы могли сказать: возьмите этот спрайт, переместите его в этом направлении, следуя по этому пути, используя эту скорость, ускорение и тому подобное
• Базовая система GUI. Не надо реализовывать целую Windows, но основные вещи, такие как указатель, кнопка и т.д. - держите это базовым
• Отладочный компонент для отображения FPS, количества спрайтов и т.д.

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

Это зависит от игры, но часто требуется еще одна вещь - хорошая сетевая среда.

Многие современные игры, В том числе 2D-игры, похоже, есть какая-то форма сетевого взаимодействия.

3D Acceleration должен быть в 2D-движке.

Использование 3D-оборудования, которое есть у большинства людей в наши дни, - лучший способ получить потрясающую производительность для ваших 2D-игр ...

Пара идей:

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

Я думаю, что вы выполнили общие требования 2D-движка. Единственное, чего мне не хватало бы в этом списке, было бы:

• Библиотека GUI

Также для упрощения процессов разработки:

• Механизм сценариев (LUA, C # Script, ...)
• Динамически обновляемые ресурсы ( см. Запись в блоге Ника Грейвлина )

Вы можете также добавить еще один слой поверх существующего материала XNA:

• Совершенно голая реализация сети / лобби
• Более абстрактная обработка нескольких контроллеров (DropIn / DropOut во время игровых сессий, например, см. Resident Evil 5 Coop) - возможно, на основе событий

Наконец, вы можете добавить несколько шейдеров «ready2use». Может быть, получить вдохновение от прекращенного FaceWound (от разработчика "Garry's Mod").

Гм. Этот список является "внутренним" списком. Сделать отличный движок - значит сделать отличный «внешний» список. Посмотрите на UE3 например - он здесь из-за отличных инструментов. Вам нужны инструменты для создания мира, для создания оптимальных пакетов ресурсов (это тоже должно быть во внутреннем списке ;-)), для спецификации объектов столкновения и т. Д. Кроме того, чтобы добавить к ответ Organiccat , вам нужно определиться с техническим уровнем. Вы можете использовать простые спрайты или использовать необычные эффекты (поэтому нужны шейдеры, а для этого вам нужна инфраструктура)

Да, вы можете. У меня есть. Но стоит ли это того?

Если вы делаете это для развлечения, оно того стоит.

Если вы делаете это для настоящего, пригодного для использования Mac, оно того не стоит.

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

Я сделал это просто для удовольствия, но в итоге я потратил на Hackintosh больше, чем если бы я только купил Mac Mini. Конечно, мой компьютер в 4 раза быстрее, но это не то же самое, что настоящий Mac. На Mac все просто работает ... это действительно приятно. Но на моем Хакинтоше ничто не работает без непосредственного вмешательства с моей стороны ... не очень приятно.

Я всегда планировал использовать этот компьютер для разработки Windows, так что это не было тратой, но в противном случае это было бы ОГРОМНОЙ тратой. [одна тысяча сто восемьдесят семь] Я просто делаю вещи, и вы, вероятно, втайне ненавидите их.

Я сделал это просто для удовольствия, но в итоге я потратил на Hackintosh больше, чем если бы я купил Mac Mini. Конечно, мой компьютер в 4 раза быстрее, но это не то же самое, что настоящий Mac. На Mac все просто работает ... это действительно приятно. Но на моем Хакинтоше ничто не работает без непосредственного вмешательства с моей стороны ... не очень приятно.

Я всегда планировал использовать этот компьютер для разработки Windows, так что это не было тратой, но в противном случае это было бы ОГРОМНОЙ тратой. [одна тысяча сто восемьдесят семь] Я просто делаю вещи, и вы, вероятно, втайне ненавидите их.

Я сделал это просто для удовольствия, но в итоге я потратил на Hackintosh больше, чем если бы я купил Mac Mini. Конечно, мой компьютер в 4 раза быстрее, но это не то же самое, что настоящий Mac. На Mac все просто работает ... это действительно приятно. Но на моем Хакинтоше ничто не работает без непосредственного вмешательства с моей стороны ... не очень приятно.

Я всегда планировал использовать этот компьютер для разработки Windows, так что это не было тратой, но в противном случае это было бы ОГРОМНОЙ тратой. [одна тысяча сто восемьдесят семь]

You're approaching it in an upside-down manner.

What should be in your engine is the following:

All the code that turned out to be common between your first and your second game.

First, write a game. Don't write an engine, because, as you have found out, you don't know what it should contain, or how it should be designed. Write a game instead.

Once you have that game, write another game. Then, when you have done that, examine the second game's code. How much of it was reused from the first game?

Anything that was reused should then be refactored out into a separate project. That project is now your game engine.

This doesn't mean that you shouldn't plan, or shouldn't try to write nice code. But make sure you're working towards something concrete, something where you can tell a good implementation from a bad one. A good implementation of a game, is one that works, is fun, and doesn't crash. Write your code to achieve those things first.

A good implementation of an engine? That's trickier. What's a good implementation of a renderer? Of an AI framework? Of a particle system? Ultimately, the only way to determine whether you have a good engine is by seeing how well it works in an actual game. So if you don't have a game, you have no way to evaluate your engine. And if you have no way to evaluate your engine, you have no way of judging whether any of the code you're writing is actually useful.