???要怎?估?一????虻?D量?

xiaoBig

举个例吧，，比如，一个WINDOWS界面需要的图量，
通用的：
1、界面框架，这个需要切的
2、关闭，最大最小化按钮，这几个按钮都有3态（正常，悬停，按下）
3、界面背景，这个是一张图进行缩放，一般都采用单色的，这样好处理，不会出现变形
4、主界面的确定取消按钮，也有3态
这样，除去滚动条选项卡文本框等等乱七八糟的东西，，一个WINDOWS窗口基本上就这么多吧，那就总共是1+3*3+1+2*3=17张，但是实际上17这个数字是没有意义的，在具体做的时候，，需要对每一张图的规格做出规定，格式需要看程序方面来定，一般情况下有缩放的会用PNG，无缩放的会用JPG，可能吧，具体的我也不知道了，毕竟偶不是图形程序员，嘿嘿，

暗夜公爵

不是…… 你找一个游戏把 图片包解开来看看 都有写啥图片……

天之虹

呵呵，还好了，也别把楼主吓得太呆

楼上说的图量真的是图量，还是不能和工作量划上等号的

以一个简单的弹出提示窗口——你要接受×××的组队邀请吗？确定 拒绝——来说，有三种做法：
1、做两张不带文字的图：一张是底框的界面，一张是可以点击的按钮（四态按钮这里先不说，先当作是一态），而后程序为其拼好加入文字；
2、做三张带文字的图：一张是底框的界面，两张是按钮
3、做一张带按钮带文字的图，由程序把该按钮部分做成可以点击的状态（较少公司这么做）

当然可以看出上面三种情况，图量是完全不同的，图量最大的那种当然表现效果最好（毕竟用系统的文字，样式太有限），图量最小的那种局限性十分大，第一种情况图量实际上是最少的——因为这些按钮和底框可以用在其他的弹出提示窗口上

回到正题，然而这对美术来说实际上还是做一张PSD图而已，作图的时间并没有减，无论是用哪种方案，而实际上不同的只是最后的输出的工作量。切图，实际上是把不同图层的部件分别保存输出出来，而并不真的如网页那样需要把图切成很多块，这是后话，这里就不提了

输出图片相比于界面制作，工作量其实少很多，所以方案带来的图量变化所带来的工作量变化，目前的阶段阁下就可以先不管了

至于图量的估算，愚认为可以从这些方面按以下顺序逐步估算：
界面数：大大小小的界面都列出来，界面以满屏或者满窗口算
功能数：每个界面要实现的功能，功能要细分，分到最小的单元，比方说血槽不是最小的单元，血槽还可以细分为槽和血，跳舞机各种弹出的分数、Perfect、Good、Bad等这些也是图量的一种
独立界面之外的配件数：道具就是这个分类中的一种了，图标也是一种，根据你的游戏好好想想有多少吧
模型贴图：如果是3D的，模型贴图也是容易忽略的一种图量，并且这种图量为数不少，你要256的还是512的贴图呢？什么？你还想用128甚至64的贴图？想想这些图量吧
其他：有些图量不是你能估算的——游戏程序的图标，制作用的示意图，凡此等等

最后，把这个总图量×1.5是可能不够的数值，×2是尚且勉强的数值，×3是大概适当的数值
为什么要这么×，呵呵，做着就知道了。

fengsan

首先明确以下内容
1。完整流程和是怎么样的？
     需要流程确定你的思路，根据流程作为分级和分支需求。
2。程序GUI是怎么样的？
     讨论明白GUI里的需求是什么样的。允许使用那些特殊效果，需要对图片采用哪种方法？
3。确定允许使用图片规格
     总图量大小控制在什么范围？图片格式怎么使用？图片资源是否打包和压缩？

当你知道以上问题以后   相信你就能够自己估算出一个游戏单单是在GUI方面的图量了。
至于全部游戏，除了多跟程序沟通，无法给与更多建议，毕竟是从程序采用方法和引擎支持密切挂钩