There will be different opinions, people prefer different approaches. There isn't a right one. You understand the approaches correct.
My defenition for Game Engine will be: - Runtime library with different managers like you saying resources, memory, networking - Tools (Editor, converters, packaging tools, etc.)
On top of the engine you can write applications or games. In some engines these are called MODs but I don't like this definition.
A good way to think of data driver approach is to imagine your engine being the executable project (it doesn't have to be but just bear with me). Then you can write some extra library that loads dynamically like plugin and then you pass to it some configuration. It can be a big package of scripts, sounds, models, textures. It can be a small script or some fixed folder structure with assets. It doesn't matter what it is the important thing here is that it's swappable. This is your data that the engine works with.
A programming driven approach is when you have your final application/game being the executable. Then you can still use engine a core library of managers, you can use middleware. Different levels can be loaded from resources. But the scope of the game will be probably hardcoded in this application.
None of the above has to be the way I suggest. You can mix and match as much as you want from both approaches as long as it fits your needs. The data driven approach by default has to take more time to build a game with. But at the end you should have more reusable software. Also usually games are very design driven. Programmers we like to make everything to be logic, physically correct, etc. but usually it doesn't make fun game. Designers usually want to iterate, try different mechanics, tweak some properties, etc. That is a lot of extra work for a programmer if you are using programming approach.
You should weight the pros and cons depending of your needs and time budget.
Edit: Designers and programmers will be needed in any of the possible approaches. There might be a slight offset in work distribution as percentage, but it won't be a lot.
The biggest benefit of data driven engine is once it is up and running, which takes a tremendous effort, it will be faster and more reliable to work with it. It should be faster to make changes since no recompile is needed. Data bugs usually can be intercepted much better and avoid crashing or restarting the application.
Probably the biggest problem with data driven engine is that all the good things about it come to a price. Usually there is performance and memory footprint hit.
发布评论
评论（1）
会有不同的意见，人们喜欢不同的方法。没有一个合适的。您理解的方法是正确的。
我对游戏引擎的定义是：
- 运行时库，具有不同的管理器，例如您所说的资源、内存、网络
- 工具（编辑器、转换器、打包工具等）
在引擎之上，您可以编写应用程序或游戏。在某些引擎中，这些被称为 MOD，但我不喜欢这个定义。
考虑数据驱动程序方法的一个好方法是将您的引擎想象为可执行项目（它不一定是，但请耐心等待）。然后你可以编写一些额外的库，像插件一样动态加载，然后传递给它一些配置。它可以是一个脚本、声音、模型、纹理的大包。它可以是一个小脚本或一些带有资产的固定文件夹结构。什么并不重要，重要的是它是可交换的。这是引擎使用的数据。
编程驱动的方法是当您的最终应用程序/游戏是可执行文件时。然后你仍然可以使用引擎管理器的核心库，你可以使用中间件。可以从资源中加载不同的级别。但游戏的范围可能会在此应用程序中进行硬编码。
上述任何一种都不必是我建议的方式。您可以根据需要任意混合和匹配这两种方法，只要它符合您的需求即可。默认情况下，数据驱动方法需要花费更多时间来构建游戏。但最终你应该拥有更多可重用的软件。通常游戏也是由设计驱动的。程序员我们喜欢让一切都符合逻辑、物理上正确等等，但通常它不会制作出有趣的游戏。设计人员通常想要迭代、尝试不同的机制、调整一些属性等。如果您使用编程方法，这对于程序员来说是很多额外的工作。
您应该根据您的需求和时间预算权衡利弊。
编辑：
任何可能的方法都需要设计师和程序员。工作分配的百分比可能会略有偏差，但不会很大。
数据驱动引擎的最大好处是，一旦它启动并运行，这需要付出巨大的努力，使用它会更快、更可靠。由于不需要重新编译，因此进行更改应该更快。数据错误通常可以更好地拦截并避免应用程序崩溃或重新启动。
数据驱动引擎的最大问题可能是它的所有好处都是有代价的。通常会影响性能和内存占用。
There will be different opinions, people prefer different approaches. There isn't a right one. You understand the approaches correct.
My defenition for Game Engine will be:
- Runtime library with different managers like you saying resources, memory, networking
- Tools (Editor, converters, packaging tools, etc.)
On top of the engine you can write applications or games. In some engines these are called MODs but I don't like this definition.
A good way to think of data driver approach is to imagine your engine being the executable project (it doesn't have to be but just bear with me). Then you can write some extra library that loads dynamically like plugin and then you pass to it some configuration. It can be a big package of scripts, sounds, models, textures. It can be a small script or some fixed folder structure with assets. It doesn't matter what it is the important thing here is that it's swappable. This is your data that the engine works with.
A programming driven approach is when you have your final application/game being the executable. Then you can still use engine a core library of managers, you can use middleware. Different levels can be loaded from resources. But the scope of the game will be probably hardcoded in this application.
None of the above has to be the way I suggest. You can mix and match as much as you want from both approaches as long as it fits your needs. The data driven approach by default has to take more time to build a game with. But at the end you should have more reusable software. Also usually games are very design driven. Programmers we like to make everything to be logic, physically correct, etc. but usually it doesn't make fun game. Designers usually want to iterate, try different mechanics, tweak some properties, etc. That is a lot of extra work for a programmer if you are using programming approach.
You should weight the pros and cons depending of your needs and time budget.
Edit:
Designers and programmers will be needed in any of the possible approaches. There might be a slight offset in work distribution as percentage, but it won't be a lot.
The biggest benefit of data driven engine is once it is up and running, which takes a tremendous effort, it will be faster and more reliable to work with it. It should be faster to make changes since no recompile is needed. Data bugs usually can be intercepted much better and avoid crashing or restarting the application.
Probably the biggest problem with data driven engine is that all the good things about it come to a price. Usually there is performance and memory footprint hit.