《游戏之旅》的原文摘录

  • 实际工作中,我们总能碰到一些问题,现成的函数库往往得不到最佳解,需要自己动手一行行地实现。多年的编程经历让我明白了一个道理:绝大多数情况下,没有解决不了的问题,只有因为平时缺少练习而惧怕问题的复杂度,畏惧的心理让我们选择避让,采取并不那么好的方案去解决问题。最后,还可以找到一个合适的理由,比如一切以稳定或一切以工期为重,以此获得心灵的安慰。 世界少有天才的程序员,更多的是勤奋的程序员。只要不停地编码编码再编码,同时在每次编码后有一些思考,编程的水平自然就会提高。如果你有和我同样的经历:被关在机房中编写那些竞赛的习题,不做完不准吃饭,那么,一定会赞同我的观点。我的编程基本功就是那样被训练出来的。 兴趣是程序员一直做下去的源动力,尤其是游戏程序员。他们可以让计算机变成娱乐自己的玩具。虽然只有少部分学习编程的人最终以编写游戏为职业,但大多数人最初都有自己写过小游戏自娱。我自己当年也是这样的。 (查看原文)
    亚里士多偷 4赞 2014-09-13 10:29:29
    —— 引自第41页
  • 我甚至一度怀疑,许多玩家在脑力劳动疲惫了一天后,潜意识里欢迎这些机械操作,从体力上的重复劳动来换取脑力的休息。 (查看原文)
    狂气之瞳改 2011-10-24 18:37:46
    —— 引自第347页
  • 编程的基本功,光靠理解是无法随手写出正确、清晰的代码的。 (查看原文)
    赵亮亮亮亮亮亮 2013-04-06 10:37:01
    —— 引自第14页
  • 他们把过多的时间花在了学习时髦的开发工具、新的语言、各种API上;又有一些人,虽然脱离了这些浮华,十分专注的去啃C++、设计模式这类书,但是,却很少有人重视基本算法的实作,这方面的实际经验太少了。 (查看原文)
    赵亮亮亮亮亮亮 2013-04-06 10:38:41
    —— 引自第41页
  • 虽然我还不知道最后应该怎么编程,但是这个世界上没有知识是学不会的,不是吗?如果一开始学不会,就可以把问题细化分解,然后学习更基本的知识,最后,所有的问题都能变得和 1+1=2 一样简单,我需要的只是时间。 (查看原文)
    亚里士多偷 2014-09-13 09:56:19
    —— 引自第12页
  • 刚开始,我还带着一点点自负,可是没多久就认识了自己的不足。 第一堂课上,我被老师叫到了讲台。让我当着所有同学的面写出一个二分查找的程序。按道理说,这是个非常容易的问题,可是我居然写写改改,在黑板上磨蹭了半天才留下个坑坑巴巴的程序。这告诉我一件事情:编程的基本功,光靠理解是无法随手写出正确、清晰的代码的。 编程,同样讲究孰能生巧。 (查看原文)
    亚里士多偷 2014-09-13 10:01:12
    —— 引自第14页
  • 受限于计算机硬件的空间限制和游戏的实时性要求,并不是所有普适性的现成的程序库可以供我们直接调用的。一个不能熟练运用各种基本算法和数据结构的程序员不可能成为优秀的游戏程序员。只有把这些基本问题烂熟于心的人才可以在面对新问题时,做到游刃有余。据我个人之所见,大多数不太优秀的游戏程序,多出于程序员的编程经验不足,对相对复杂的算法或数据结构把握不够,或出于对复杂事物的恐惧心理而逃避所致。 (查看原文)
    亚里士多偷 2014-09-13 10:07:33
    —— 引自第15页
  • 这些朋友,大多是一些在校大学生,期望通过互联网以一种无需思考和学习的途径去完成作业。对于此,通常我只能无可奈何地回信:掌握算法,对于已实现的程序,应该是通过阅读来理解它,然后必须亲手重新实现出来,而不是复制过来编译运行。只想看看最后的结果,对于学习毫无意义。 (查看原文)
    亚里士多偷 2014-09-13 10:12:39
    —— 引自第25页
  • 其实,这些智能算法,本质上并不复杂,都只是提供一个思路而已。举凡大自然中存在的事物,刨根问底,又哪点是构造在复杂的原理之上的呢?耐下性子,加上一些扎实的编程功底,几个小时就能把它们一一实现。充斥着网络的,求XX算法源码帖子的作者难道不该为自己写不出几百行代码而汗颜吗? 自己动手实现一下,真正了解这些方法,慢慢地就可以真正运用它们到实际中去。我们程序员平时脑力总是集中在怎么描述问题,以适应某种特定的算法,那么了解更多的算法会让我们更快地解决棘手的问题。 (查看原文)
    亚里士多偷 2014-09-13 10:17:27
    —— 引自第35页
  • 实际工作中,我们总能碰到一些问题,现成的函数库往往得不到最佳解,需要自己动手一行行地实现。多年的编程经历让我明白了一个道理:绝大多数情况下,没有解决不了的问题,只有因为平时缺少练习而惧怕问题的复杂度,畏惧的心理让我们选择避让,采取并不那么好的方案去解决问题。最后,还可以找到一个合适的理由,比如一切以稳定或一切以工期为重,以此获得心灵的安慰。 世界少有天オ的程序员,更多的是勤奋的程序员。只要不停地编码编码再编码,同时在每次编码后有一些思考,编程的水平自然就会提高。如果你有和我同样的经历:被关在机房中编写那些竞赛的习题,不做完不准吃饭,那么,一定会赞同我的观点。我的编程基本功就是那样被训练出来的。 兴趣是程序员一直做下去的源动力,尤其是游戏程序员。他们可以让计算机变成娱乐自己的玩具。虽然只有少部分学习编程的人最终以编写游戏为职业,但大多数人最初都自己写过小游戏自娱。我自己当年也是这样的。 (查看原文)
    手艺人 2021-06-11 14:42:34
  • 有限状态机广泛地被用于游贼程序中,多用来解决类似上面的问题。有许多人可能会想到使用多线程来控制游戏中的角色,但是,多线程还是有不小的开销的,而且存在复杂的同步问题。不过,我也曾经尝试过自己实现一个轻量的用户级协作式线程,由用户自己主动控制线程的切換来减轻同步的复杂度;用简单的跳转语句以及少量的环境保存来缓解0S级线程的切换开销。 这在我参与研发的一个商业网络游戏《梦幻西游》的客户端中得到大量的使用,效果不错。另外,在GDC2004上我听了个演讲,介绍了种基于行为描述的语言( A Behavior Language,ABL)来解决上述问题,关于ABL可以在 egl。 g atech。edu找到。 当时的条件所限,我们无法通过互联网交流,查询资料,请教前辈,但即使在今天,我依然提倡碰到棘手的问题,先不要急于上 Google搜索,或者在IM软件上找人问,自已的思考是最好的解决问题的钥匙。每个问题都会有无数的解决方法,每次独立解决一个问题,都是一次开拓思维的机会。 (查看原文)
    手艺人 2021-06-11 15:47:40
  • 比如,用一个for循环去复制一块内存,就永远比 memcpy要慢因为 memcpy是编写CRT库的人手工写出的为CPU特别优化的汇编代码(另一个原因是大多编译器会特殊处理 memcpy这个函数)。 (查看原文)
    手艺人 2021-06-11 15:49:23
  • 关于数据块的复制 C的标准库中提供了一对函数: memcpy和 remove。通常我们会使用前者(后一个是改良版本,会判断源数据区和目的区域是否有重叠,然后根据具体情况选择复制的次序)。不少初学者在刚刚接触汇编优化时,都兴奋地想用自己学会的新知识CPU的新指令重新写一个自己的 memcpy版本改进速度。 可惜的是,大多数情况下,除了满足一下编码欲,这是一件毫无意义的事情。实际上,C语言中,在复制小于64K的数据时,我们几乎不可能写出一个比标准库提供的 memcpy还要快的函数。 这是因为,现代编译器为一些核心函数做了编译器级别内嵌处理的版本(不同于简单的 inline), memcpy这样的函数实质上被看做一种关键字在处理,而不是一个简单的函数调用。本身,对数据复制这种并不复杂的操作,优化的余地就不大,而对于小数据块,用户定义的函数,会把许多的处理消耗在函数调用上。 (查看原文)
    手艺人 2021-06-11 16:03:39
    —— 引自第207页
  • 以我个人的经历,总结出一条不被很多人接受,但自己却十分受用的准则:尽可能地使用结构最简单的工具来完成任务,直到这个工具不合适。 能用纯C写的程序不用C++,能用C的原生数组的情况下不用st:: vector。能用std:: vector的情况不用std::map,能自己写的代码不用第三方库。但是,请不要误解这条原则。首先,世界上没有绝对的原则,如果它们存在,我们就可以按手册来编写完美的程序了。完美的程序不存在,绝对的原则也同样不存在。 其次,我不主张重写C++的标准库,重写MFC或者任何已经存在的广为大众所使用的代码;也不主张去用C去实现面向对象的设计方法,或是拿宏去取代模板这些回到历史中去的事情。C++的每一个特性都有它们存在的理由,大多数程序员都没有达到非议标准的技术层次,提出上面的准则需要运用者把握其中的度。这个度就是使用工具的人对工具本身的了解程度。 (查看原文)
    手艺人 2021-06-11 16:29:04
    —— 引自第251页
  • 我再也不堪忍受看到绘图过程的低反应速度,放弃了最开始苦苦寻觅支持更高颜色数和更高分辨率的 BGI 驱动的想法,直接抛弃了 BGI。 (查看原文)
    breaker 2018-09-05 15:40:10
    —— 引自第1页
  • 标准的显示模式是 VGA 640 x 480 16 色,由于效率和 16 位内存地址空间等的限制,这种模式被设计得相当奇怪。标准 VGA 是一个 8bit 设备,显存有明显的等待状态,为了直接操作它需要和诸多寄存器打交道,如索引寄存器、数据寄存器、位屏蔽寄存器、位平面等。 标准的 VGA 是一个 8bit 或 16bit 设备,其编程接口工作于 16bit 模式下。在 32bit 操作系统一统天下的时候,已经极少使用 VGA 编程了。 VGA 通常把显示内存映射到 16bit 模式下地址 A000:0000 到 B000:0000 的 64K 空间下,而 VGA 标准的配置有 256K 显存。这使得大部分 VGA 模式并非平坦地对应于内存地址空间,控制起来需要操作 VGA 的若干读写端口,编程相对麻烦。唯有 320 x 200 256 色标准模式,是在内存地址空间上与显存逐字节对应的,也为最多的游戏开发人使用。而更专业的开发人员会依赖自己的技术,发挥 VGA 的性能到极限,那就是 Mode-X。 VESA 标准在 DOS 时代的末期被广泛地使用,它给程序员提供的接口被称作 VBE (VESA BIOS Extension)。即使是一些很古老的显卡也在 BIOS 中固化了 VBE 1.2 的接口。如果没有,通常也能找到一个可以额外加载的 TSR 内存驻留程序来提供相关的服务,这些就是显卡驱动程序的前身。 使用 VBE,就可以轻易地突破原来 VGA 可以管理的显存的上限,使用更高的分辨率。VBE 1.2 最高可以提供高达 1280 x 1024 真彩色 (16.8M) 的支持。在 1990s 中期发布的 VBE 2.0 更提供了 32bit 保护模式下的接口,使用户不必在 16bit 实模式下,使用那可怜的 64K 地址窗口来访问几百 K 甚至上 M 的显存。 DOS 下的老玩... (查看原文)
    breaker 2018-09-05 15:40:10
    —— 引自第1页
  • 在熟悉了 VBE API 后,我动手写一些有趣的程序、一些小游戏。但是没动手多久就发现行动过于草率了,即使 VBE 的接口再容易使用,还是和最终需要干的事情,如画一条线,贴一个图有所距离。如果将这些代码和游戏逻辑处理的代码混杂在一起,只会使程序变得更混乱。而且这部分代码非常具有共性,几乎每要写一个小游戏,都需要用到。多写几个程序就能总结出哪些代码是共通的,提取出来放在一起,做成一个函数库,就成了一个最原始的游戏图形引擎的雏形了。 (查看原文)
    breaker 2018-09-05 15:40:10
    —— 引自第1页
  • 实际工作中,我们总能碰到一些问题,现成的函数库往往得不到最佳解,需要自己动手一行行地实现。多年的编程经历让我明白了一个道理:绝大多数情况下,没有解决不了的问题,只有因为平时缺少练习而惧怕问题的复杂度,畏惧的心理让我们选择避让,采取并不那么好的方案去解决问题。最后,还可以找到一个合适的理由,比如一切以稳定或一切以工期为重,以此获得心灵的安慰。 (查看原文)
    手艺人 2023-06-22 18:03:43
    —— 引自第41页
  • 1984年,刚刚进入小学的我见到了生命中的第一台电脑。我的父母都是一家国有大钢铁厂的小职工,拿着每月百多块的工资。或许是一家之主的父亲更年轻求学的时候学过一些计算机编程的知识,居然拿出了一家多年全部的积蓄,花了六百多元人民币买下了一台港产的家用电脑Laser-310(如图1-8所示)。在此之前,家中唯一的电器就是一台九寸黑白电视了。 (查看原文)
    细胞膜 2024-04-10 09:36:58
  • 因为我在编程方面有那么一点点天赋,在湖北省的编程比赛中,以初中生的身份参加高中组比赛取得了还算不错的成绩,所以在初二那年的暑假,参加了省里的集训队。 武汉的夏天是非常炎热的,整个夏天,每天我都要坐进蒸笼一般的公共汽车,去离家相当远的武汉测绘大学上计算机课。课堂上使用的是本科生用的数据结构的教材。在大学的教室里,老师给我重新整理了头脑中条理不清的链表、树、图这些概念。刚开始,我还带着一点点自负,可是没多久就认识了自己的不足。 第一堂课上,我被老师叫到了讲台。让我当着所有同学的面写出一个二分查找的程序。按道理说,这是个非常容易的问题,可是我居然写写改改,在黑板上磨蹭了半天才留下个坑坑巴巴的程序。这告诉我一件事情:编程的基本功,光靠理解是无法随手写出正确、清晰的代码的。 编程,同样讲究熟能生巧。 (查看原文)
    细胞膜 2024-04-10 09:36:58
<前页 1 2 后页>