关于count(id)查询慢的问题,请高手帮助解答
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于count(id)查询慢的问题,请高手帮助解答相关的知识,希望对你有一定的参考价值。
因为程序要做翻页,那么翻页前肯定要查询一下总的记录数
也就是说 要查询2次数据
第一次是 查询总记录数(把总记录数给分页类来分页)
第二次是 循环数据
那么问题来了, 因为我是要查询某个栏目的总记录数 而不是 某个表的总记录数
所以 count(id) 后面跟着where 的条件
4万条数据
经过测试 select count(id) as num from table 很快 170ms 左右就完成了
但是 增加了条件后 select count(id) as num from table where class = 1 or class in (1,2,3) 那么就需要3秒左右,非常慢
和in 没关系 单纯的 class = 1也不行 class 是 int类型
只有把where 删了 才非常快
条件是必须要加的 因为我是要查询某个栏目下面的总记录 所以需要where
我的php代码是这样
//获取总记录
$a = mysql_query("select count(id) as num from table where class = 1 or class in (1,2,3)");
$b = mysql_fetch_array($a);
//循环数据
$c = mysql_query("select * from table where class = 1 or class in (1,2,3)");
while($rs = mysql_fetch_array($c))
....
//翻页
$_page = new Page($b['num'],$listpage);
请高手帮帮我 应该怎么处理
如果不做总记录数 那么应该怎么翻页呢
还是不行,只有把where和后面的条件删掉 才很快. 是什么情况呢
追答这是必然的,因为where是筛选数据,这和单纯的查找不一样。举个例子吧,一口袋大米,现在我让你把它拿过来,应该很快吧,但是我如果说,把里面坏掉的大米挑出去之后再拿过来会消耗很长时间!
关于游戏制作,像侠盗猎车圣安地列斯,侠盗猎车IV这样的大型3D游戏是如何只作的?请编程高手解答
关于游戏制作,像侠盗猎车圣安地列斯,侠盗猎车IV这样的大型3D游戏是如何只作的?
C++语言 Java和VB语言编译还有游戏引擎 策划 美工 音效等等
看过一个视频 GTA4为了追求真实度 还派了组员出去拍外景 总之制作一款游戏很费时费力的
转的
日本游戏制作流程揭密
日本GAME制作方式
项目*理检讨
一、 现阶段问题点
(1) 组织架构
公司与项目应有不同之架构
(2) 各职务定位
各职务工作执掌与权责须划分更加清楚,特别是各部经理与总监。
(3) 项目经理与制作人的角色差异
须更进一步划分工作执掌与权责
(4) 项目*理
尚未进行,项目是否已算成立? 不清楚界定标准。
二、 附录 (参考资料)
(1) 何谓项目*理?
针对特定目标的一系列规划、组织、人事、领导与控制等活动,其目的在有效运用组织内人力、物力、财力等资源,以达成组织目标。
规划:为设定项目发展目标、制定政策、研拟策略及实施步骤,及如何达成该目标的基本过程。
设定目标:目标必须写下来。必须让所有参与者都能清楚明白它的意思。
研拟策略的要点:
1. 要把欲达到的结果,清楚地表达出来。
2. 这些结果要合理可行。设立一个难以达到的目标,会使参与的人望而却步。
3. 要把一系列的行动细节,详尽地陈述出来。
4. 必须指定负责人,使整个计划能因此而推动、进行。
5. 要*供合理的资源。
6. 计划的每一个阶段,均须有时间表。
7. 要设立工作表现的标准,以衡量所欲达到的成就。
组织:为了达成共同的目的,规定各个角色的职务,并依据一定的权限与责任的分配,决定各职务间相互的关系。
*理人必须知道自己究竟负责哪些活动,哪些人需对自己负责、自己又该对哪些人负责。此外,*理人还必须清楚整个公司的结构、自己在公司的位置、可以使用哪些沟通管道等。这些都必须以达成部门和公司的目标为主,并且定下所要完成的效果,最后再用文字陈述出来。
许多公司都把组织营建在员工身上,而不是先决定所要的结果,然后再寻找适当的人选来占据那些职位。通常,小公司并没有真正的组织架构,都是把现有人员分配去做所有的工作。不用多久,又会有另一批人被聘来分摊各部门的工作。一个简陋架构的公司,有时也能维持好几年的时间,但这样很难继续维持成长。
为了让企业成功,整个组织必须以「结果为导向」作为建筑架构的基础。公司的目标需明确且实际可行,整个*理工作也必须以达成公司的目标来进行。公司的架构完全依照所要达成的结果来设计–––每个职位是专为达成某个目的而设,然后再找寻最适当的人选来执行职务。
人事 甄选优秀人员于适当职位上,从事项目各项工作,并*训他们,以增进工作效率,提升人力素质。
领导:根据项目规划所制定的策略与工作进度,引导、影响与鼓舞成员完成任务的行为。
控制:将成本、进度、品质控制在预定的范围之内。
(2) 项目经理 (Project Manager)
「项目经理」为项目团队之主管,负责指派及领导工作人员进行项目工作,对上级主管或顾客负责项目成败,并解决项目内各项问题,实为项目之灵魂人物,亦可谓项目*理之重心与中心。
(3) *品经理 (Product Manager)
负责整个*品的处理过程,从研究调查、制造与*售。直到*品变成普通*产线的一部份时,「*品经理」仍须负责「维持」与「成长」的工作。
(4) 制作人 (Producer)
一个游戏的总指挥,从游戏制作到贩卖所有流程都是由游戏制作人负责。游戏制作人可以说是一款游戏的导演,他必须要掌控游戏发展的大方向。其工作范围包含监督开发工作、掌控游戏进度、重要事项决定、游戏预算控制。同时也是研发团队与公司之间的窗口,随时进行双方面的协调与*理,如何能够面对双方,并且妥善的将双方的讯息传达,也是游戏制作人最重要的工作之一。
(5) 执行制作人 (Executive Producer)
执行制作人与游戏的制作一起工作,其工作范围包含开发工作分配、执行制作的执行、相关工作的检查。身为执行制作人需要有较佳的沟通协调与*理的能力。虽然游戏制作人也同样有*理的职权,但游戏制作人并不能随时与游戏研发在一起,所以执行面由执行制作人来负责。
(6) 监制 (Director)
发包、工作分配、制作流程*理、游戏制作行程*理等实际制作发场的负责人。十分类似工地里的工头。
(7) 企划 (Planner)
撰写游戏的企划书。在这个部分里,游戏企划可以写出许许多多不同的方式或是系统,写的越多,游戏设计人员的选择机会也越多。而且企划在撰写企划或是新点子的时候,可以发挥充分的想象力,不需要考虑到硬件或是软件的执行能力,只要是想的到新点子都可以写在企划案里。当然企划案也不能远离原本企划会议中所讨论出来的大方向。
(8) 游戏设计师 (Game Designer)
将游戏企划所写作的企划书游戏化,也就是付诸实行。针对游戏企划所写的企划书中哪里不合理或是哪里需要加强的部分,加以删除或是修正,然后真正使之成为游戏中的一部份。根据游戏规模的大小,这个部份中又会细分为游戏系统设计、战斗系统设计、道具系统设计、格斗系统设计等诸多不同内容设计,每一项工作都会有专长该方面的游戏设计人员负责。
(9) 编剧 (Scenario Writer)
撰写游戏中所有的故事、剧情。有时候这个部分也会邀请非游戏业界的人来写剧本。比如说著名的小说家或是剧本作家。会邀请著名小说家撰写剧本的游戏大多是冒险游戏或是角色扮演。这类游戏的做法可以让游戏的故事内容更加吸引玩家,也可以说是游戏的卖点之一。将来在宣传方面也有很大的帮助。
(10) 角色设计师 (Character Designer)
设计创造游戏中所出现的所有角色。在日本游戏界中,这个部分也常常会邀请非游戏业界人员担任。比如说著名的漫画家、插画家就常常为游戏设计人物造型。这样的做法在日本游戏界中十分盛行,因为如果邀请到著名漫画家或是插画家为游戏设计人物,通常会使*售量提升。像鸟山明(七龙珠作者)为「勇者斗恶龙」系列设计人物、横山光辉的「三国志」系列、天野喜孝(日本著名插画家)为「太空*士」系列设计人物插画等等,都让游戏的知名度在发售前就已经提高很多。
(11) 2D插画师 (2D Illustrator)
设计背景或是平面角色。此外也细分成为只制作材质贴图(背景、物体表面的质感、表面贴图)的MAPPER和专门画位图的DOTER。
(12) 3D插画师 (3D Illustrator)
制作3D角色或是开头、过场、结束CG计算机动画。
(13) 日本游戏开发流程
草案制作
目前,拥有精英的游戏制作公司,绝对不是一开始就投入所有人力开始撰写程序而是先将游戏制成像「草案」(在日文中的说法称为「企划书」)这样的书面基础(b**e)。
草案其实是没有固定的格式(STYLE),少的时候有可能只是两三页A4大小的纸张,多的时候也有可能是包括参考资料而多达五十几页,草案的格式可以说是形形色色。依照游戏制作公司的习惯、企划人员的不同、甚至是游戏制作计画的不同,企划的书写格式也都不尽相同!此外,有些草案是透过许许多多次Brain Storming(集体创造性会议,公司企划人员或是其它有好创意的制作人员带着自己的新创意所参加的会议),经过不断的讨论与建议,而由多位企划制作人员所共同撰写出来的。
一般大家都会以为游戏的草案,是将企划者的创意很详细很详尽地书写在草案中,但是实际上却不是这个样子!草案实际上只要概略地叙述「这是个什么样的游戏」就可以了。也就是说,传达游戏的概略就是草案的使命。所以说草案其实不是为了游戏制作开发而产生的,草案的存在是为了让相关制作人员了解企划者所要传达的想法意念(Image)。也就是说,这样的草案是让经营者判断是否可以将这样的创意商品化、让业务贩售人员评估*售量、让其它制作人员加入不同的意见或是更好的想法,草案在专业的游戏制作公司里的主要目的便是如此。随着草案,有关游戏玩法的规则会被写在草案中,此外「什么好玩?哪里好玩?」也是草案中必须书写的基本条件!许多业余或是专业的企划人员,常常在草案中加入拢长壮大的故事剧本或是详细的角色资料设定。其实这些有关游戏的细部设定在草案中都是多余的。草案可说是说明游戏「好玩的地方」的最佳方式,因此如何将企划者所要表达的意念精简地集结起来就是件十分重要的事。当企划者将游戏中「好玩」的核心点明确地表达出来之后,接下来便是将「开发对应平台?」、「预定发行的时间?」、「适合什么样的年龄层?」、「游戏主要构成画面草图(Rough Contin**ty)」等资料加入,如果有必要的话可以再附上一些参考资料。具备这些东西之后,就算是完成一个草案!
决定草案、开始制作企划书
PS:事实上「企划书」在日本游戏制作业界的说法里是被称之为「仕样书」!翻译成中文为「规格书」。所以,日本所谓「企划书」如同我们所谓的「草案」、日本所谓「仕样书」如同我们所谓的「企划书」。
草案完成之后,接下来就是等待筛选的命运。不是所有的草案完成之后都可以被商品化,只有优秀的草案才可以走上实际制作→商品化→发售这样的过程。也就是说,事实上游戏软件的激烈竞争早在制作成商品摆在市场上贩卖之前就已经开始了。一般来说,只要是稍具规模的游戏制作公司都会随时拥有100份以上还未商品化的游戏制作草案。这些草案不仅仅都是来自公司内部开发部门企划人员的笔下,有许多也都是从公司外部募集而来的。由此可见,企划人员想让草案商品化的竞争情况实际上是十分激烈的。
当一份草案经过层层严格筛选而雀屏中选之后,游戏制作的流程也正式从草案阶段移到企划书(规格书)制作阶段。企划书是让企划(PLANNER)将自己的想法传达给程序设计(PROGRAMMER)、图形设计(GRAPHIC DESIGNER)...等制作小组成员的文件。企划书与草案不同,它不可以是只是「知道游戏的概略」。而是必须将游戏中所以大大小小的设定,十分具体地写到企划书当中。从游戏的开始画面到游戏结束画面、画面中任何一个角落的表现设定、分数的计算方式、角色的动作...等,游戏中会出现的任何事件任何事物,都必须在清清楚楚地写在游戏企划书中。所有与游戏制作相关的成员,都是以此份企划书为基础来执行制作工作,可见这份企划书的重要性(因此日本会将我们通称的「企划书」称之为「规格书」,也不是不无道理!)。打个比方来说,企划书就好比正在建筑房屋时所绘制的设计图一样。在撰写草案阶段的创意(Ide**)往往都是很模糊的想法或是个临时想到的,所以也就没有很仔细地思考到游戏的细部结构。而企划书则是将原本没有仔细思考的事物,仔仔细细地书写到文件上。所以撰写企划书的时候,便需要不断地收集资料,按部就班一步一步都不可马虎的执行。
企划书的撰写方式,也会依据游戏制作公司的不同、游戏内容的不同而有所变化。比如说以一个一个画面为单位的画面单位指导书或是以登场角色来区分的指导书。所以,事实上企划书的构成格式是很自由的,撰写人员可以依照自己习惯而别人又看的懂的方式来撰写。同样是说明角色的动作,企划书可以用「到达顶点之后暂停一下而后迅速落下」这样的文字叙述方式,也可以使用图画或是图解的方式来表示。甚至有时为了让程序设计人员可以更清楚了解,也会使用到计算公式或图表的方式来表示。所以,企划人员表达创意的方式可以是五花八门的。也就是说,企划书最主要的目的,是让制作成员了解自己需要做些什么,所以企划人员是不需要拘泥企划书中的章节、写法、体裁。最重要的事与开发团队成员的意见沟通。
企划书要传达的信息是相当多的,所以一份企划书页数有时也是相当惊人。特别是像剧本故事结构十分庞大,故事情节分歧*理十分不容易的RPG游戏,企划书的页数更是多的惊人。而如果真要要说明到底有「多少页」的话,还不如用「几公分厚」或是「几个纸箱」这样的单位还比较适当。在日本游戏界常常会听到这样一句话:「游戏才一开始制作,马上有一整面墙的柜子里全都是参考书籍以及企划书资料」。专业的游戏制作公司的草案是相当简洁,而企划书则是相当紧密有系统的。所以说,或许大家都不相信,但事实上游戏一开始制作的时候,其企划书已经是厚厚的一叠,甚至是装满一整个纸箱了。
与专业人员组成专业团队
到目前为止游戏的制作流程都是单一流程,而且游戏制作都是集中在以企划人员(PLANNER)为中心的少数制作人员身上。不过,当企划书即将完成之前,便要开始进行整个制作小组人员的整合。而且从这个时候开始,许许多多的工作是平行地同时进行。以下就为大家大略介绍一下流程。
一般来说,首先整合到执行计画中的是不使用计算机的工作人员。这里所谓的「不使用计算机」—— 是指公司外部的剧本作家或是角色设定的原作家等人。这些公司外部的原作者们其实在草案完成的同时,企划人员(PLANNER)便开始与他们不断沟通协调,并开始撰写剧本或是绘制人物造形的工作。为什么是这样的流程呢?那是因为纸上作业的工作是必须在程序设计工作开始之前就必须完成的。所以这些公司外部的原作者的工作都必须在其它工作人员前完成。
接下来是将程序设计人员(PROGRAMMER)整合到执行计画中。虽然说在企划书撰写的同时,企划人员(PLANNER)已经不断地与设计人员(PROGRAMMER)沟通协调游戏内容、表现方式等,但是设计人员(PROGRAMMER)真正忙碌是从这个时候开始。在初期,程序设计人员(PROGRAMMER)会是先撰写整个游戏系统的主要程序,比如说主角的动作、画面显示系统等。程序设计在游戏制作工作前期,就是建立游戏系统的基础。这样的工作如果以绘画的世界来比喻的话,就是准备绘画用纸、准备画具以及颜料、然后描绘出图画的轮廓。前期工作尽可能将细节的部分完全去除,而以游戏系统基本根基以及骨干程序为主。为什么是这样的是制作流程呢?事实上很多游戏在企划阶段会遇到有如「有办法将企划人员脑海里所企划的事物表现出来吗?」「自己所想的真的会好玩吗?」,为了证明这些疑虑,企划人员就可以藉由程序设计人员先期所制作出来实际会动作的画面来判断。这样的试作游戏在日本被称之为「PROTOTYPE」。这样的「PROTOTYPE」可以先期验证游戏是否真的好玩,如果验证结果是确定的,那整个游戏的制作便可以朝完整版的工作继续进行下去。
有时候依据情况的需要,程序设计人员不会先直接撰写游戏程序,而是先制作「工具(Tool)」、「编辑器(Editor)」等开发用的工具。这就好比在盖房子之前,先把锯子等工具做好是一样的意思。把工具、编辑器等程序都准备好,当游戏制作到后期时对于动作编辑、地图编辑等的工作便可以很有效率地进行。
图形设计人员(GRAPHIC DESIGNER)的工作几乎是与程序设计人员同时进行的。在日本游戏制作公司里,图形设计人员大多都是使用相同的CG专用开发计算机来制作游戏图像。所以所有图形设计人员的桌面上都是摆着相同CG专用开发计算机,那样的场面看起来是很壮观的。
虽说是制作映像的资料,不过游戏中的CG并不是只是一张大张的图画而已,而是分为很多不同的组件(Pa**)。比如说,角色人物的话就专门绘制角色人物,或是建筑物的话就专门绘制建筑物。这些各自负责自己所分配到部分的图形设计人员,最后就会将一开始就准备好的原画逐一制作组合成3DCG。
3DCG的制作,首先会先从制作以多边形(Polygon)组合起来的立体对象开始。在日本,像这样的立体图像制作工程被称之为「Modeling」,而从事这样工作的专业人员则被称之为「Modeler」。这些专业工作人员几乎都是使用3DCG专用的开发工具来完成「Modeling Data」,但是这样的Modeling Data只是一种拥有线条而没有颜色的图像,称之为「模型的线架构(Wire Frame)」。而接下来的工作是将颜色、材质、灯光等贴上,这样的工作称之为「贴图(Texture Mapping)」。接下来,这个有形状又有颜色的图像数据便要再被加入称之为「Animation Pattern」的动作资料,这样就成为会活动的3DCG。在目前的动画科技里,也加入了可以将人类的动作转换成计算机资料的「动态捕捉系统(Motion Capture)」以及可以将真实物体外型转换成计算机模型的「3D扫描系统(3D Scanner)」。
接下来是音乐制作的部分。相对于图形制作的团体工作,音乐制作是属于比较个人性质的工作。游戏音乐的作曲负责人在游戏草案完成的时候,便要开始配合游戏加入音乐的影像(Image)。这个时候并还没有开始作曲,而是仅止于思考整个音乐风格的走向,是要摇滚风格比较好呢?还是要古典风格比较好呢?这段时间可以说是音乐作曲家的摸索时期。企划书的完成,接下来便是将游戏画面体地呈现给作曲家,「到底用什么样的曲子比较好?」「曲子长度要制作几分几秒的比较好?」,这些问题在此时也渐渐明确化。所以大部分的作曲家都是在这个时期开始进行音乐旋律的制作。接下来,负责音乐的人员就要实际操作一个个已完成的游戏画面,依据游戏要表达的意念配上适当的音乐音效。
为什么游戏音乐要配合着一边操作画面来进行编曲呢?这是因为游戏的场面会依照玩家的意念与偶发的状况而有所不同,这是与电影、广告不同。比如说「GAME OVER」的曲子在何时连接什么样的曲子是最可以表示玩家的心情?玩家在什么样的场面之下最可以感到紧张的气氛?这些都是需要音乐创作人员实际去操作游戏、实际去感受游戏,然后再慢慢地调整出游戏音乐的曲调、曲子与曲子之间的连接,甚至是出现的时机、长度等。所以说制作游戏的音乐其实也是件十分辛苦的工作。
协调、协调、再协调
完整的企划书、完整的制作小组、完整的制作流程,但许许多多问题还是会伴随着整个游戏制作过程。而且随着各部门工作的进行,麻烦问题会越来越多,也越来越严重。
比如说常常遇到的就是与内存相关的问题。虽然说目前的游戏主机的内存已经比以前多了许多,但是毕竟还是有所限制。所以游戏制作计画一开始时,一般来说便会开始进行各部分内存大小的分配工作,如图形使用○○M、主程序使用○○M、音乐使用○○M。不过随着制作工作的进行,往往都会有超出原本内存容量设定的问题产生。原因有很多,比如企划书阶段时期计算错误、开发小组能力不足、某部门开发小组需要更大的内存容量来表现游戏效果…等。这个时候制作人(PRODUCER)或是监制(DIRECTER)便必须明确地的判断。是否还有其它多余的内存容量可以分配?是否削减哪个部分的内存容量?是否变更成其它规格?解决的方式虽然有很多种,不过与内存相关的麻烦问题是任何一组游戏制作小组都会遇到的烦恼!
接下来常见的便是不断循环的「可能」与「不可能」这样的问题。在游戏制作现场中,我们常常会听到「可能」与「不可能」这两句话。经大家讨论之后,企划人员将一个新的创意写入企划书中后,理论上就应该会是可行的。但是实际作业的时候,程序设计人员又常会出现「这种新创意是不可能做到」的遗憾。上述的事件对游戏制作现场的人员来说都是家常便饭,常常发生的状况。企划人员会说:「这是可以办到的吧!你一定要做出来!」,程序设计人员会说「不可能!我做不出来!」,两部门人员间的紧张火爆气氛也就时而发生。协调处理这样的问题(包括组员间相处人际关系)也都是制作人或是监制十分重要的工作。
除此此外,集合了这么多位工作人员的大型制作工作,人与人之间的沟通协调问题都是层出不穷。「应该可以再可爱一点」、「我要一种无形的感觉」、「运用比较有速度感的反应方式」……在游戏制作现场中,在开发小组的成员之间,像上述那样十分抽象的语言可说是随时都可以听到。因此,发言者的想法与听到话语的人的理解程度有微妙的差异,甚至是文不对题也都是时有所闻。在游戏开发过程中,光是要让所有制作小组成员制作出来的作品保持一定的风格就是一件相当费力的工作。
其实制作过程中遇到麻烦也不全都是不好的事,有时也会遇到让人觉得高兴的麻烦。比如说,游戏制作到一半的时候,突然有人说「如果这样做的话一定会更好玩!」。从企划书阶段之后经过几个月,也实际制作出会动的画面之后,上述的情况就常常会发生。不过是不是要采用预定以外的创意?如果采用了,那既定的工作时间又要从新排定,这对于整个制作小组就会是个大麻烦。当一个很好的新点子、新创意突然浮现脑海的同时,一大堆麻烦的工作调整问题也随之而来,这就是游戏制作工作。游戏制作工作到了后半段时期,有许多麻烦的问题也会随着分解到各个制作人员的身上,如何解决这些问题,也就相对成为每位工作人员工作的一部分。有游戏开发经验的人员采用负责人在面试的时候,常会说:「游戏制作人员必须要有很强的抗压力」。其理由为何,相信也就不需多作解释了。
各部分完成后进入测试工作
当开发人员最辛苦的时期结束的时候,也就是游戏各部分都完成的时候。完成的所有资料会全部集中到主程序设计人员的手上。图形资料、音乐资料、剧本等文字资料,再加上其它细部的的程序资料,都是在这个阶段完成整合。如果是角色扮演游戏、射击游戏、战略仿真游戏等,其游戏中角色的各种设定数值也都市在这个阶段中加入。这样也就完成游系的试玩版。
最初完成的试玩版,在日本一般称作「α版」,使用这个版本制作人员可以进行简单的Test Play。当然在试玩的过程中,如果有不正常的错误就会马上进行修正,此外也会开始进行游戏难易度调整。即使整个游戏制作过程经过十分严密配置,但是因为是各部门分工合作,所以还是会出现「看得到树却看不到森林」这样的缺失。像这样将树木一颗颗地修正,使其看起来像是一片森林,便是试玩版中必要的修正工作。
将「α版」中各部分所有的错误、不合理的地方加以修改之后,再一次将所有资料整合,这个试玩版便被称作「β版」。这个版本中的内容基本上与玩家将来在市面上买到的版本内容是一模一样的。不过由人类做出来的软件不会是十全十美没有任何错误的。这样的错误在程序设计人员间被称作「BUG」。因此接下来的工作便是找出这些躲在程序中的「BUG」,并加以修正去除。假设游戏中所有会出现的任何状况,从游戏讯息一个文字的小小错误到会导致游戏当机的重大错误,都必须一点一滴仔仔细细去找出隐藏其中的「BUG」。这样的工作也被称作「Debug」,一般会由开发小组所有组员或是公司外部的工读人员,甚至会动员到公司其它部门的工作人员。不论是多么辛苦所制作出来的游戏,只要游戏中出现任何一点小小的错误而导致当机,便成了没有用的「不良品」。虽然对开发人员而言,游戏制作流程到了Debug之前的阶段是算是可以松口气的时候,但是接下来的Debug工作却也是最后最重要的大工程。经过上述的过程之后,就到了游戏软件的最终版本「M**ter」,接下来就是等候压片量产。 参考技术A 我并不是编程高手,但我也会一点,也稍有了解
大型游戏是由大公司制作的,且公司中会分为很多部门,他们各有各的分工,比如,有专门管3D建模的,有专门管音效处理的,有专门管代码架构的,专门制作动画的,专门调试的,等等
至于编程所用的语言,因为游戏公司不公布源码,我们无从得知,但大部分游戏由c++写成,可能还会有很少量的汇编
很多人想自己写游戏,当然,理论上可行,但一个游戏可能会有成千上万条函数,其管理难度很大,所以说个人写游戏是很困难的,尤其像GTA这样的大作,必须要有很大的公司管理才可以 参考技术B 兄弟,这本来就是技术活。
就算是给钱也不一定有人回答的。
如果这里真的有好人回答你,请不要吝啬分数好不?
兄台问这问题莫非是要自己编游戏?还是奉劝您老算了吧。
可以很清楚的告知您老,这样的游戏不是靠普通的编程弄出来的。如果真的幸运的让你搞出来了,恐怕也要两年后的电脑才能供得起啊。。。对不?现在的游戏配置大体不是很高。GTA SA 这系列很完美,低配置,高游戏。
希望您老多多走动走动,不要再往这3D上打主意了。在这里小儿偶谢过了。。。 参考技术C 需要一个很大的系统,要明确分工,你要是想制作一个游戏,我看好你哦,现在的游戏要求低,等你制作好了,把网址告诉我,我也玩一玩 参考技术D 努力工作创造出来的! 第5个回答 2009-08-22 那是公司制作的,以你个人能力是不可能的,需要投资好几千万啊,你有吗?好了的话能赚很多钱的,难道你自己想制作吗?
以上是关于关于count(id)查询慢的问题,请高手帮助解答的主要内容,如果未能解决你的问题,请参考以下文章
刚学数据库,遇到一道关于数据库sql语句的题目,实在不会,请高手帮忙解答一下,谢谢!
有一存储过程,里面实现了增删改查,我如何在C/S界面中,事件中调用此存储过程,举例说明,求高手解答!