如何对复杂数据建模
我必须创建一个模型来存储多个平台上游戏的游戏控制。我很难找到正确的方法。
- 不同系统上的控制器按钮有所不同(Wii、Xbox 360、PS3 都有自己特定的控制器按钮。)
- 有些游戏实际上是几个游戏打包为一个;有些游戏实际上是多个游戏打包在一起的。这意味着一个产品可以根据所玩的游戏有多个控件。
- 许多游戏的游戏控制会根据您的游戏内活动(驾驶/行走/飞行等)而变化。
- 仅存储按钮功能是不够的,因为大多数游戏都有几个需要组合按钮的特殊动作。
您将如何解决这个问题?老实说,我不知道从哪里开始!
更新:非常感谢大家的深思熟虑且非常有帮助的意见。我还没有选择和回答,因为最终决定这个功能不值得付出努力。再次非常感谢。
I have to create a model that stores gameplay controls for games on several platforms. I am having trouble finding the right approach.
- Controller buttons are different on different systems (Wii, Xbox 360, PS3 have their own specific controller buttons.)
- Some games are actually several games packaged as one; this means a single product can have several controls depending on the game being played.
- Gameplay controls for many games change depending on your in-game activity (driving/walking/flying, etc...)
- It's not sufficient to just store button functions since most games have several special moves that require a combination of buttons.
How would you approach this problem? Honestly, I don't know where to start!
Update: Many thanks to everyone for your thoughtful, and very helpful input. I am yet to choose and answer because, in the end, it was decided that this feature is not worth the effort. Many thanks again.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
一些控制器共享共同的布局,但具有不同的面,即 360 和 PS3(X 是 A,三角形是 Y 等)。有了额外的外围设备,如战斗杆、飞行杆、吉他等,它们也只是映射到控制台期望的不同面孔。由于按钮通常在任何控制器成型之前就已定义,因此您也可以这样做。
每个映射并不都适用于每个控制器,因此它可能并不理想 - 考虑到现代控制台控制器,它应该没问题。如果添加 Intellivision 控制器和键盘/鼠标,事情可能会开始变得奇怪。
注意:我不知道这些全身运动控制的事情是如何在内部处理的,如果你必须处理它们,祝你好运。
LFOOT_HOKEYPOKEY
之类的。注2:说真的,不要在那里使用 char(8) 。详细说明,但保持足够笼统,以适用于通用控制器风格而不是品牌。
现在每个控制器品牌的按钮及其名称(假设有一个“控制器”表):
现在,按下一个按钮(或多个按钮,或一个序列)代表游戏的操作。这没有考虑上下文(原始问题的 2 和 3),例如游戏模式或备用按钮配置,但 Josh Smeaton 和 Littlegreen 已经涵盖了这一点。
这定义了每个单独游戏的动作,这不是很有效。您可以通过添加游戏“类型”的通用层来显着压缩内容。许多特定类型/视角的游戏都有通用的控件,而且只会变得越来越常见(控制台 FPS 添加预定义的 Halo 和 CoD 风格的按钮配置,因为玩家知道它们,等等)。因此,如果您可以为每种类型定义一组常见操作,并仅根据需要使用它来覆盖/扩展这些默认值,那么您可能能够获得更清晰的解决方案。
首先,定义每个操作:
最后,定义与每个操作相关的按钮按下操作。 “序数”字段用于组合序列,例如格斗游戏组合 - 单个动作是第 0 个序数,序列从 1 开始计数,只是为了使它们易于区分。它不考虑时间,因此您可能需要一个“无”按钮作为一些更复杂的组合游戏的休息(Soul Calibre 等)。
(免责声明:我为我工作过的游戏工作室创建了一个类似的数据库。不完全相同,但足够相似,以至于我故意遗漏了很多内容。抱歉!希望这足以启动一些想法,而且这是一个有趣的问题。)
Some controllers share common layouts but with different faces, i.e. 360 and PS3 (X is A, triangle is Y, etc). With extra peripherals like fight sticks, flight sticks, guitars, etc - they're just different faces mapping to the console's expectations as well. Since the buttons are usually defined before any controller is even molded, you can do the same.
Each mapping won't all apply to every controller, so it may not be ideal - considering modern console controllers, it should be fine. If you add in Intellivision controllers and keyboard/mouse, things might start to get weird.
Note: I have no clue how those full-body motion control things are handled internally, good luck if you ever have to deal with them.
LFOOT_HOKEYPOKEY
or something.Note 2: Seriously, don't use a char(8) there. Get detailed, but keep it general enough to apply to a generic controller style and not brand.
Now the buttons per each brand of controller, with their name (assumes a "controllers" table):
Now, for the actions a button press (or multiple buttons, or a sequence) represents to a game. This doesn't account for the context (2 & 3 of the original question), e.g. game mode or alternate button configurations, but Josh Smeaton and littlegreen already covered that.
This defines actions per each individual game, which isn't very efficient. You might be able to condense things significantly by adding a generic layer of game "types." Many games within a certain genre/perspective have common controls, and it's only becoming more common (console FPSes adding predefined Halo and CoD-style button configurations since players know them, and such). So, if you can define a set of common actions per each genre and use this only to override/extend those defaults as needed, you might be able to pull off a much cleaner solution.
First, define each action:
And finally, define the button presses associated with each action. The "ordinal" field is for combo sequences, like fighting game combos - single actions are 0th ordinal and sequences count up from 1, just to make them easy to differentiate. It doesn't account for timing, so you might need a "nothing" button as a rest for some of the more complex combo games (Soul Caliber et al).
(Disclaimer: I created a similar database for a game studio I worked at. Not quite the same, but similar enough that I'm kind of intentionally leaving a lot out. Sorry! Hopefully that's enough to kickstart some ideas though, and it's a fun problem.)
对于初学者,您可以尝试一下(编辑:第二次尝试):
例如:
You can try this for starters (EDIT: second try):
For example:
我会尝试一下:)
I'll give this a whirl :)
这个怎么样:
How about this:
使用上述结构的示例:
控制台:PS3
游戏:MAG
...
当前游戏状态:
背景:驾驶
允许的操作:方向(向前、向左等)、刹车、冒烟
允许的组合:每个操作的每个组合的列表
当按下一系列按钮时,例如:L1 + DirectionRight,在允许的组合中查找该组合,找到相关的操作,并执行该操作。
An example of using the above structure:
Console: PS3
Game: MAG
...
Current Game State:
Context: Driving
Allowed Actions: Directionals (forward, left etc), Brake, Smoke
Allowed Combinations: List of each combination for each action
When a series of buttons are pressed, eg: L1 + DirectionRight, look up that combination in allowed combinations, find the relevant action, and execute that action.
我只简单思考一下,但我认为你可以使用这样的东西(我懒得添加 ER“叉子”,但顶部表格引用底部表格):
。
您可以选择将按钮链接到控制台
I only give it a short thought but I think you can use something like this (I was to lazy to add ER 'forks' but top table references bottom table(s)):
.
optionally you could link button to console
我会尝试一下:)
1)您需要一个系统表
2)您需要一个包表(对父级的引用可为空)、一个包含游戏的表和一个用于将游戏链接到的表包。这确保了游戏可以是不同包的一部分。不过,它不允许不同的软件包具有同一游戏的不同“特殊版本”。但这不是一个要求:)
3) 我不确定这是否与 2) 相同,如果不是:一个引用游戏的表格,如果:参见 2)
4) 你需要一个表格对于引用游戏部分的动作(“序列”),那么您需要一个用于键组合的表,并引用序列。最后,您需要一个特定键的表,以及对组合的引用。
我认为这将涵盖它,尽管我对操纵杆、鼠标等有一些担忧。您可能希望将“键”表分成几个表,以避免该表中的许多列,但这是您必须做出的决定,具体取决于关于您计划如何访问数据库等。
I'll give it a try :)
1) You'll need a table for systems
2) You'll need a table for packages (with a nullable reference to a parent), a table with games and a table to link games with packages. This ensures that a game can be part of different packages. It's not allowing different packages to have different "specialversions" of the same game, though. But that wasn't a requirement :)
3) I'm not sure if this is the same as 2), if not: a table with a reference to a game, if: see 2)
4) You'll need a table for an action ("sequence") with a reference to a gamepart, then you'll need a table for a key-combination, with a reference to the sequence. Finally, you'll need a table for a particular key, with a reference to a combination.
I think this will cover it, though I have som concerns regarding joysticks, mouse etc. You might want to split the "key"-table into several tables to avoid to many columns in that table, but that's a decision you have to take depending on how you are planning to access your database etc.