3D数学基础图形和游戏开发(暂时不更)
前言 提到三维视频或游戏制作,可能很多人脑海中想到的就是3Dmax,Maya,Unity,UE之类的软件,但是,如果要学习和利用好这些软件 ,仍然需要掌握一定的基础知识; 不间断持续更新….
游戏开发设计模式1 策略模式
第一章 策略模式 在本章将会说到利用其它开发人员的经验和智慧,遭遇过的问题,怎么解决问题的方式进行实例演示。我们会看到设计模式的用途和优点和一些关键的OO设计原则。 模拟鸭子 游戏中会出现各种鸭子,一边游泳戏水,一边呱呱叫。UML图如下 现在我们得让鸭子能飞起来 我们只需要在Duck类中加上Fly()方法,然后所有的鸭子都会继承Fly(). 出现问题 但是现在遇到一个可怕的问题! 假如需求里面有橡皮鸭子,木头鸭子,是不可能会飞的,但是又继承了Duck基类。 基类加上新的行为,会使得某些并不适合该行为的子类也具有该行动。所以说当我们涉及到维护或者复用目的而使用继承,结局并不完美。 像我们一般写程序或者设计不严谨的情况下,我们首先想的是橡皮鸭子类利用继承关系把Fly()方法覆盖掉,就好像上图覆盖Quack()的做法一样。 假如需求里面要求再加一个木头鸭,不会飞,也不会叫,是不是继承的子类又是什么都不做? ...
游戏开发设计模式2 观察者模式
第二章 观察者模式 在本章将会说到利用其它开发人员的经验和智慧,遭遇过的问题,怎么解决问题的方式进行实例演示。我们会看到设计模式的用途和优点和一些关键的OO设计原则。 气象观测站需求 甲方公司有接口可以检测到目前的天气状况,希望我们能够开发一个程序,有三个面板,分别显示 温度,湿度,气压 状况,当接口发生变化获取到最新的天气状况数据时,三种面板必须实时更新。 而且,这是一个可以扩展的气象站 气象监测应用的概况 此系统中的三个部分是气象站(获取实际气象数据的物理装置),WeatherData对象(追踪来自气象站的数据,并更新布告板)和布告板(显示目前天气状况给用户看)。 weatherData对象知道如何跟物理气象站联系,以取得更新的数据。WeatherData对象会随即更新三个面板的显示:目前状况(温度,湿度,气压)气象统计和天气预报。 如果我们选择接受这个项目,我们的工作就是建立一个应用,利用Weather对象取得数据,并更新三个面板:目前状况,气象统计和天气预报。 接下来让我们看一下甲方给我们的检测天气接口数据代码: ...
游戏开发设计模式3 装饰者模式
第三章 装饰者模式 在本章将会说到喜欢爱用继承的同学一个全新的设计方式。我们即将再度探讨典型的继承滥用问题。你将在本章学到如何使用对象组合的方式,做到在运行时去装饰类。为什么呢?一旦你熟悉了装饰的技巧,你将能够在不修改任何底层代码的情况下, 给你的(或别人的)对象赋子新的职责。(话不多说 直接开喷) 前期项目举例说明 有一个商店 因为生意火爆,准备修改他们的销售订单系统,他们原先的类设计是这样的 当我们购买咖啡时,也可以要求在里面加入各种调料,例如在里面加 牛奶,巧克力,奶泡等调料,商店会根据加入不同调料来收取不同的费用,所以订单系统必须考虑到调料这一部分。 首先我们看一下依照上面的类设计会怎么样 每个cost()方法将计算出咖啡加上订单上各种调料的价钱。饮料加几个就会类就会多的爆炸, 每个价格都需要单独在类里面进行计算,繁琐无比 违反设计原则 很明显,商店自己给自己挖了一个维护巨坑。想一想如果牛奶价格上涨,怎么办,新增加了一个焦糖风味怎么办?维护起来工作量爆炸。 以上类设计违反了我们之前说的两个设计原则。 ...
游戏开发设计模式4 工厂模式
第四章 工厂模式 接下来讲松耦合的面向对象设计,除了使用new操作符之外,还有更多制造对象的方法。你将了解到实例化这个活动不应该总是公开地进行,也会认识到初始化经常造成“耦合”问题。你将了解工厂模式如何从复杂的依赖中帮你脱困。。。(话不多说 直接开喷) 思考New 已经过了三个章节,我们来一起思考new的问题。我们不应该针对实现编程,但是当我每次使用new时,不正是在针对实现编程吗? 当看到“new”,就会想到“具体’ 是的,当使用“new”时,你的确是在实例化一个具体类,所以用的确实是实现,而不是接口。这是一个好问题,你已经知道了代码绑着具体类会导致代码更脆弱,更缺乏弹性。 当有一群相关的具体类时,通常会写出这样的代码: 这里有一些要实例化的具体类,究竟实例化哪个类,要在运行时由一些条件来决定。 当看到这样的代码,一旦有变化或扩展,就必须重新打开这段代码进行检查和修改。通常这样修改过的代码将造成部分系统更难维护和更新,而且也更容易犯错。 但是,总是要创建对象吧!而c#只提供一个new关键词创建对象,不是吗?还能有些什么? ...
游戏开发设计模式5 单件(例)模式
第五章 单件(例)模式 这一站 是单件模式(Singleton Pattern) 用来创建独一无二的,只能有一个实例的对象的入场券。 单件模式的类图可以说是所有模式的类图中最简单的,事实上,它的类图上只有一个类!尽管从类设计的视角来说它很简单,但是实现上还是会遇到相当多的波折。 所以,系好安全带,出发了! 独一无二 问:什么!整章的内容就是如何实例化“一个对象“吗? 答:这可是“唯一”的对象呀! 问:这有什么用处? 答:有一些对象其实我们只需要一个,比方说:线程池(threadpool)、缓存(cache)、对话框、处理偏好设置和注册表(registry)的对象、日志对象。 事实上类对象只能有一个实例,如果制造出多个实例,就会导致许多问题产生,例如:程序的行为异常、资用过量,或者是不一致的结果。 问:好吧!或许的确有一些类应该只存在一个实例,但这需要花整个章节的篇幅来说明吗?难道能靠程序员之间的约定或是利用全局变量做到? ...
游戏开发设计模式6 命令模式(更新中)
第六章 命令模式 在本章,我们将把封装带到一个全新的境界:把方法调用(method invocation)封装起来。 没错,通过封装方法调用,我们可以把运算块包装成形。所以调用此运算的对象不需要关心事情是如何进行的,只要知道如何使用包装成形的方法来完成它就可以。 通过封装方法调用,也可以做一些很聪明的事情,例如记录日志,或者重复使用这些封装来实现撤销(undo) 举例说明 最近鸡哥气象站向我展示并简单介绍了新扩张的气象站。我必须说,我对于该软件架构的印象非常深刻,所以想邀请你为我们设计一个家电自动化遥控器的API。 附上一个创新控制器的原型以供你研究。这个遥控器具有七个可编程的插槽(每个都可以指定到一个不同的家电装置),每个插槽都有对应的开关按钮。这个遥控器还具备一个整体的撤销按钮。 我也在资料里面附带一个案例类,这些类是由多家厂商开发出来的,用来控制家电自动化装置,例如电灯、风扇、热水器、音响设备和其他类似的可控制装置。 ...