我最近在看 《游戏引擎架构》 这本书，想做引擎是不是要先从普通的游戏逻辑功能开发开始做起再参与引擎？
之前是制作ios的app, 梦想参与游戏引擎开发，但是我是不是要先去做普通的游戏逻辑功能开发，从最初级开始做起，积累经验再找机会参与游戏引擎开发？ 但是我很担心做逻辑功能以后没机会接触到引擎底层了。 邀请的两位人都是我认为的引擎大牛，其中一位是本书译者
按时间排序
游戏引擎是游戏开发经验的体现。
顺其自然，建议先搞游戏，多多关注引擎，慢慢积累，有准备才有机会。。。另外，国内除了那几家谁还做引擎啊，在有的公司做引擎很无聊的，，，
“之前是制作ios的app, 梦想参与游戏引擎开发”——还是先空闲时间弄个游戏出来吧，游戏开发和应用开发差别还是不小的，弄出来再看看。milo那本书，是一个很好的大纲，不过里面有大量游戏开发的术语和经验，如果没有一定的游戏开发经验，这本书不大可能完全读懂“我很担心做逻辑功能以后没机会接触到引擎底层了。”——你的担心是很对的，因为这就是国内很多游戏公司的现实……，需要大把熟悉API愿意打磨产品细节的一线开发者，不需要能提升开发效率的技术人员，即使有这种职位需要也是让你烧以前的经验，或者直接就是弄胶水＋打杂……不过，从你的叙述中，我不觉得你打算这种公司入职，也不不缺工作资源……“邀请的两位人都是我认为的引擎大牛，其中一位是本书译者”——都到了这个程度了，也没必要在知乎上发问了，好队友是职业生涯最好的福利，能让你经验翻倍
最近也在刷milo大大翻译的这本《游戏引擎架构》，书里面有很多译者注是写的不错的略有扩展。这书可以先看着当科普，对引擎有个基本认识。最近写到一万多行，虽然重构了很多遍，但是感觉架构还是丑的不行....架构长得丑以后的开发会比较吃力。所以就先暂缓脚步看看书看看OGRE。其实还是要做过游戏才知道引擎需要什么，有了什么样的功能会促进开发效率。这也需要对自己的引擎的定位有一个认识。其实爱做什么做什么啊，怎么会做过游戏逻辑就不能碰底层呢？
可以试着不用游戏引擎写个3d游戏出来。
游戏开发需求是战略，引擎底层结构是战术。
对比下UE4和unity，前者自己做游戏，后者只做产品
感觉起步都是一条线上的，没啥冲突，只是最终的侧重点不同。想做好都有一堆概念需要了解。先把书看完，做个小样再说吧……
如果你加入的是一个较为成熟的引擎组，负责的是特定模块的开发，譬如做为一个图形工程师，那么未必，很多外围工作别人可能已经帮你做好了，只需要了解一下美术的需求即可；如果是想对完整的引擎进行把控，甚至于写出自己的引擎，成为引擎的架构师，那么对游戏的方方面面有所实践肯定是非常好的。说实在的，游戏开发有各种坑，有些你不踩是根本意识不到的。
加入我们公司，参与vise3d的开发
不一定，game引擎只是各個模組組合起來，如圖形引擎，物理引擎，腳本引擎，AI引擎，GUI框架等。引擎對專業性的要求很高，也需要深厚的C++功底。先要把C++學好了，因為底層的東西，基本都是用C++來開發的。然後選擇一個模組進行專研，大多數人選擇的是圖形引擎部分，但remember，這只是引擎中的一個模組。做普通的遊戲邏輯跟引擎開發差距還是很大的。做業務邏輯不需要懂底層的細節，大概知道即可。當然開發引擎也不一定需要懂得業務邏輯。
做过游戏，才知道需求， 有需求下再去做引擎做出来的引擎才能被别人乐于使用见过太多只写引擎不做游戏的人， 自己的引擎自己都不用来做游戏， 怎么能做好
已有帐号？
无法登录？
社交帐号登录GamePlay Programmer(游戏逻辑程序员)会不会渐渐消失?
这是我最近学习Unity3D的一个感受,那就是现在的游戏引擎实在是太好用了,各种组件都封装的非常好,包括脚本的编写也比较傻瓜化,有一种回到以前使用RPGMaker的感觉.包括状态机,行为树和AI都可以非常直观的去调用,实际上策划也可以独立完成一款不错游戏的构建了.那么,GamePlay Programmer会不会越来越少,或者与游戏策划合并成为同一种职位呢?
按投票排序
不会。至少目前虚幻这种端游主要用的引擎，非程序员无法驾驭。反倒是不会写代码的策划会逐渐消失。国内的游戏策划会更接近传统意义上的游戏设计师。update：楼上两位都是策划朋友回答，我作为程序回答一下。原文手机打的，没有表达清楚，重新表达下。gameplay程序员不会消失，但是跟toolset程序员的界限会越来越模糊。
国内有一定发展年限的PC端游戏公司，不仅限于网游，程序员大部分都是前后通吃，顺手还能winform写点工具出来。只是前几年页游发展太快，这几年手游又发展太快，出现了海量的要么是没学过图形的手游端程序，要么是只写过lua、python就招进来开始干活的所谓「逻辑程序员」。gameplay部分会越来越多由策划完成。
配表是策划想法落地的一种工具，连图也是，同理，写文档、画流程图都是。「策划需要写代码」，不是说真要策划吭哧吭哧硬编码写c或者c++。脚本一直都是想法落地的最重要的一种表达方式，没理由国外的分工更成熟的console工作室的designer会而国内的策划同行不会。
顺便，当gameplay程序员侧重点更偏向toolset和engine的时候，不少没写过脚本的策划一直说的「门外汉写乱脚本」的担忧基本不存在。碰巧看到一篇博客，引用如下：我们有许多制作流程的方式，最土鳖的方法是程序根据策划的需要不断开开心心地硬编码啊硬编码，我想时至今日除非毕业生否则不会有人再喜欢这么做了吧？稍微好一点的就是设计一个可以读取配置文件的系统，策划通过配置文件来自定义一些流程。这个是某英雄项目的做法，也是我过来后重点在推倒的东西。再往后，就是程序只写核心、只搭框架，要什么菜？自己通过脚本和工具往里面装。如果你在业内做过10年以上，你应该会回想起来这就是我们开发模式一直以来的变化。如果不能把策划调动起来，在这个游戏内容爆炸、游戏革新速度加快的时代，迟早会被淘汰。配表为什么不靠谱？为什么反感配表、配配置文件呢？这个方法一是太老旧了，二是它实际上并未能完成调动策划的使命。老旧就不用说了，02、03年刚开始学游戏开发的时候，这种配表的方法就是初级读本中也会收录的基本技能。未能完成调动策划的使命是怎么回事呢？但凡使用配表的工作组，往往只有两种对配表的组织方式：一种是程序提供核心流程后，“给，配吧”，交给策划。一种是策划想好自己的需求后，告诉程序，我要这样一个流程，然后这些地方开给我配置。从扩展性上来说：前者的问题是，做这个功能的程序实际上决定了整个系统的扩展能力。而后者的问题是，虽然表面看起来策划拥有对这个系统的控制权，但是实际上，做这个功能的程序实际上决定了整个系统的扩展能力。无论哪种情况下，策划由于并不是实际的实现者，因此再强势，其实也只是纸老虎。真正把控系统命脉的，仍然是制作这个系统的程序。如果这个程序是个没有扩展性思想的程序的话，策划需求的完成时间就会随着开发时间变得越来越高。如果这个程序是个有扩展性思想的程序的话，他一定会抛弃配表这种做法。从配表本身的特点来说：配表本身其实并不是为了解决流程概念的。它只是为了能让一些数据性的工作能交出去，不要占据程序宝贵的编程心力。用来描述已经既定的、简单的逻辑也是能够胜任的。比如，当条件A成立时做行为A，条件B成立时做行为B这种还是能够手到擒来的。问题在于，项目开发期，特别是端游，很多方案最终的样子跟最初的样子能够差得很远很远。我们的策划一开始也认为技能判伤害，最多只要做父子关系就行了。实际的结果呢？判伤害这块儿根据需求的变化已经调整了好几版了。如果我们程序是按照配表的方式做的话，单读表、分析表的地方都要改好几次。虽然这种工作对程序而言是小Case，但是同样也是没营养的工作，我相信就算是再喜欢写程序的，隔三岔五让你改个读表、改个流程，你也会心怀愤懑的。简而言之：配表无法自我进化。再怎么说，配表只是流程的附庸，先有了流程，才能决定配表是怎么个东西，如果流程在变，配表自然无法自我圆满。所以，拿配表来做流程的想法典型的就是土鳖想法——没有见过更好的方式，所以只能寄希望于他们唯一明白的方式——配表、配表、再配表。我认为，程序有责任告诉他们，你们有更好的方式来完成你们的目的。脚本是专业的流程工具人们设计语言和脚本，就是因为他们能够在我们和计算机之间建立起沟通的桥梁。人们因此可以让计算机去做我们想要他们做的事情。刚刚说的那个问题，脚本化之后根本就不是问题：之前的一次技能一次伤害判定不够了？脚本里这块儿之前是做了一次，你自己再加几次。哦，对了，相应的数据可以自己从配表里面读喔，不想读的直接写死在脚本里也行。后面，如果有需要的话，这里你改成读表就行。什么？你改了表结构？那脚本这里读表的地方你自己改一下就好啦。……除此之外还能完成很多你之前不敢想的东西：什么？Boss战的整个流程完全要跟角色技能不一样？没关系，为Boss这个技能单做一组脚本……中间还可以穿插场景交互喔~~过去程序钉死那就是死了，现在？自己发挥去吧。此外，脚本化后显而易见的我们获得了下面的优势：减少沟通成本，增加效率……程序的设计被倒逼框架化、模块化、单元化。……程序概念更清晰……更早地发现设计问题，更灵活地完成目标……引用自：
谢邀，我认为不会。理由如下：1，游戏引擎化开发是游戏工业化发展的表现，是进步，但并不一定所有商业游戏都要走引擎化这条道路。引擎可以越来越强大，但终究不是万能的，因为游戏的的表现形式无时无刻不在创新，但引擎一般是基于现有游戏表现形式开发出来的，它的泛用性会受到限制。2，掏钱买引擎，拿钱换的是时间，但技术门槛肯定还是要有。至少国内即便是大公司策划，你让他学U3D，他也得学相当一段时间。另，专职的游戏软件工程师（听好了是软件工程师，你们一不是程序员二不是码农，从来不是），真正的优势在于软工思想而非编码技术。说白了，你给一个文案策划讲什么叫高内聚低耦合他多长时间能听懂并应用在项目中呢……3，分工方面的东西我和
意见一致。从社会分工理论和CMMI（软件能力成熟度集成模型）的评判角度来说，分工的目的是为了提高生产效率。编码工程设计和编码本身的工作量即便用引擎也是相当大的，没有专业游戏软件工程师别想完成，完成了稳定性也达不到要求。所以为了生产效率这个人力肯定是不会省的。PS：你可以找一个策划，找男的对程序和游戏都感兴趣的，掰着手教他U3D，试试一年内他能出师不……题主这是「达克效应」认为U3D太简单了是个人都玩得来，其实真不是……
我经历过很多个手游项目，都是我做主策划并同时做逻辑程序，负责服务器、客户端的逻辑代码coding，我的目标就是让自己有一天不再coding，让其他策划直接coding就好，因此我当时就设计了几个努力方向：1，设计逻辑机制，让游戏设计规范化，让策划思路规范化。2，设计的dsl更自然语言化，让策划能像写文章一样自然地coding。但是能力有限，至今未能实现，也无心继续实现这块，因为去做别的事情了，当然我想说的是，好的程序员的努力方向就是让自己“失业”（基本不用做什么事情）。
我倒是希望啥都不懂的策划赶快消失。你也别赶什么工具潮流了。
最近下载了鹅厂的《天涯明月刀》画面超赞。但是game play做的惨不忍睹。各种动作衔接不好，寻路各种撞墙。所以在我看来国内非常之缺少优秀的gameplay程序员，相比之下优秀的图形学程序员还更多一些。
如果真的游戏逻辑程序员都不需要了，我就不干这一行了。
谢邀。一个事实来说明，unity3d当初开始流行的时候，圈内流行的是“这玩意简直就是美术就可以做游戏了，程序以后吃什么饭？”。结果是几年发展下来，程序开始转了不少到unity3d上来，美术依旧还是美术。大家还是一样的合作。不会预测，只说一个事实。
额，我想说，身为程序，我们的最终目标其实是让工具最简单易用，让baby们也能够通过简易的界面来使用复杂的系统。也许有一天，当全世界的程序平台接口都被统一和简化并且全面而又稳定的那一天，程序这种职业也许会真的消失。可以说程序猿们一直致力于做这种让自己失业的工作呢。所以程序猿是为了世界进步而做出悲壮努力的伟大一族。
我觉得不会，比如游戏引擎不会有点击npc然后弹开对话框这种东西的，如果有个引擎有这个功能，那么我用这个引擎去做fps游戏怎么办呢，当然你可以说这个引擎非常强大，连做打枪游戏的功能也有，那么我要去做个赛车游戏呢，或者简单点，做个连连看，俄罗斯方块呢？...策划们的需求是多变的，今天按钮点下去是弹这个窗，明天又改成弹那个窗了，后天或许又把这功能干掉了（当然弹什么窗这个功能可以丢给配置表，这里只是举个栗子），所以连高端的引擎工程师也搞不清楚策划们在想什么，以至于引擎解只提供了游戏开发的一些“共性”功能（几乎所有游戏都有的功能），比如把图形显示出来、模型导入进来给美术看效果，把游戏物件对象接口提供给程序员操作等这样的功能，不能解决游戏玩法和功能层的问题，因为功能层需求千变万化，比如美术画的图拖拖拽拽就能出来，不用管图形底层接口了，但至于这个图出来以后怎么办，会发生什么，怎么体现出策划的想法，还得靠逻辑程序员，没有哪个引擎能适应所有游戏，搞定所有功能。至于rpgmaker不用写代码就能搞定一个游戏，那用rpgmaker肯定做不出使命召唤，也做不出极品飞车，就算做个rpg游戏rpgmaker很多创新玩法都做不出，把rpgmaker做的东西搞成网游就很麻烦，别说再搞搞动态事件什么的了。
谢邀，我认为不会。我是不咋会写程序的策划,会点lua,也看过U3D的书。我觉得大概从2个角度来看问题吧1） 从独立游戏制作角度， 这是好事，代码门槛降低，更多想做独立游戏的人可以做，不过在独立游戏的制作里，这个本来就构不成什么实质性的问题，只是说U3D强化了这个概念。2） 从商业游戏角度，其实早年的策划大部分都是会写脚本，会架单服甚至对前后端的概念和具体工作方式非常了解，以现在的观点看现在的一小部分不合格的程序猿可能对于游戏架构的理解都不如那批人，可以随便找几家大公司看看现在当工作室老大的人，基本上都是半程序半策划的早年间圈内大神。我认为分工其实是进步，如果回到什么都做的年代，反而是一种退步，策划做游戏我真的认为不是堆砌逻辑和数值的过程。堆砌逻辑和数值只是表象，越做深了越发现经验+用户心理感受+打折促销（俗称运营思维）有很多东西要考虑和沉淀，说白了都是得学的。对于商业游戏公司来讲，要一个懂U3D 也懂玩法但是不懂心理&数值&系统的策划，和一个一行代码都不会写，但是非常了解人心理&数值&系统的策划，傻子都知道哪个好（当然现在很多公司要前者...这是因为便宜）分工导致专注，专注提升生产力，策划这行业我感觉还处在一招鲜吃遍天的家传武学时代，很多理论和知识只停留在口口相传上，与其专注于把自己变成一个蹩脚的程序员，还不如做好策划的本分，做精策划。专业的人做专业的事情，相信队友...
已有帐号？
无法登录？
社交帐号登录孩子还在玩游戏？不如学习编程做游戏！_华阳吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：19,857贴子：
孩子还在玩游戏？不如学习编程做游戏！收藏
2.1. 強化小孩逻辑思考力 写程序最重要的就是如何把大问题不断分割成小问题的过程，其中，小孩必须去思考如何把代码合理的安排在整个程序中，才能让程序流畅的处理输入、演算、直到输出，这对小孩对事物的逻辑分析能力会有极大的提升。 2. 培养小孩专注细心 出错，是每个写程序的人必经的事，不论大人小孩都没有例外。有时候只是少打了一个等号，或是在某一行的行尾少加了一个分号，就会造成程序大乱，更别说还有逻辑上分析问题时却忽略掉某种状况的陷阱。所以，在学习写程式除错的过程中，是绝对无法得过且过，能有效改正小孩马虎行事的毛病，避免当个差不多先生。 3.早日发现孩子的编程天赋，早发现早培养孩子非常善于吸收新知识，掌握新技术，让他们早早接触代码非常有必要。比尔盖茨、扎克伯格、乔布斯，他们都是从小学就开始编写程序了，从小就开始编程思想的培养和编程技术的积累，为他们后来成就大事业奠定了坚实基础。让您的孩子尝试一下编程，或许中国的比尔盖茨就诞生在你家。4.与其控制孩子玩游戏，不如鼓励孩子编游戏爱玩是每个孩子的天性。电子游戏也是软件，而且是具备很强逻辑性的软件。爱玩游戏的孩子通常也会是编程的高手。如果您的孩子因为沉迷于游戏而让你头疼，请您把他交给我们青冠青少年编程训练营吧。我们会通过编程的方法让他慢慢明白，游戏其实是程序员制作出来的软件。我们一定会将他们从玩游戏寻找快乐转化为编写游戏来寻找快乐。编程是实现寓教于乐的最好的课程。5.锻炼孩子的逻辑思维，培养孩子的科学素养其实，所谓的编程就是将人类的想法按照一定的编码规则，变成计算机可以识别的代码和语言，让计算机帮助我们实现数学运算、事物处理和信息查询等。今天我们在手机、Pad、计算机上使用的软件，诸如微信、游戏、支付宝，网上银行等，它们或简单或复杂，实际全部都是工程师编写出来的程序。计算机程序通常具备很强的逻辑性。完成一个编程就是在完成一个项目、一个任务。因此，编程可以锻炼孩的逻辑思维能力和创新能力，同时又可以锻炼其建立、完成和管理项目的能力。诚然，并不是每个孩子长大后都会成为程序员，但是，作为一个家长，如果你能引导孩子试着边玩游戏边学编程，交给他们学习途径和方法，是不是倍有成就感！正如麻省理工学院教授Mitchel Resnick所写的，学习代码也是认识科学的过程。地址：华阳益州大道南段益州国际广场708
联系人：程老师
联系电话：
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或游戏策划新人必学_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
<span class="g-ico g-ico-star g-ico-star-on" style="width:%">
<span class="g-ico g-ico-star g-ico-star-on" style="width:%">
<span class="g-ico g-ico-star g-ico-star-on" style="width:%">
游戏策划新人必学
上传于||文档简介
&&游&#8203;戏&#8203;策&#8203;划&#8203;新&#8203;人&#8203;必&#8203;学
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩3页未读，继续阅读
你可能喜欢}