汤锴 11:33:01
如果镜头是追尾的，在旋转时，可能会碰到墙，
有几种做法：
1 保持镜头在墙背后，并把这面墙消隐
2 保持镜头在墙背后，并把这面墙以半透明方式描画
3 从玩家到镜头方向引一条矢量，计算该矢量与墙壁的交点，把摄像机位置设置到这个交点，也就是摄像机被拉近了。
黄泉道用了第3种方法。
但黄泉道有一条摄像机规则：摄像机到玩家的距离不能小于最小值。
可是当玩家非常贴近墙壁时，距离很可能小于这个值，此时我们把摄像机沿墙壁向该矢量的Y分量方向滑动，以维持摄像机规则不被破坏。
水晶羽 11:35:34
对我就是用这个方法的

也就是说我的游戏是在一个迷宫走动 但是第一 视角

下面是以前的一些记录，打个包发在这里。

关键词：新影舞者项目

内容：对旧影舞者项目进行修改，增删游戏内容，改变故事背景，并使用最新的S3D引擎实现。过程中参考以前的策划案和游戏代码。

核心：与场景互动，动作+解谜

如何突出核心？
增加场景地形元素的丰富性（但并不是越多越好，要各有特色），并因此增加主角动作的丰富性。设计主角动作使其合理且流畅，有一两处创新最佳。
动作的难度控制在合理的范围内。
设计更优秀的谜题，不但要平衡难度及合理性，而且与关卡甚至游戏故事的联系要更紧密。
更多隐藏要素的关卡（其实也未必真的很隐蔽，主要是给玩家带来惊喜，并给他一种原来这个游戏设计如此细致的感觉），适当精确的关卡设计（如影舞者MockUp中经典的爬到贴墙，向外爬3步再转身跳

接了个做网游外挂的外包.这方面没有经验,不过应该不太难吧?
大家祝我早日搞定吧!

显血,显蓝,显经验
自动喝血,喝蓝实现了

说下心得:
1 打开进程空间:
没什么好说的,我也是抄的别人的代码,一下就搞定了
// 找进程
if( !m_bFoundGame ) {
 m_hGameWnd = FindWindow( NULL, "某游戏" );
 if( m_hGameWnd ) {
  DWORD PID;
  GetWindowThreadProcessId( m_hGameWnd->m_hWnd, &PID );
  m_hProcess = OpenP

基本信息：
3D-RPG游戏，1人，通关后可以进入噩梦难度。
以后可以考虑追加网络功能。

优势：
暗黑式的框架设计可以保证游戏的接受度至不会差，风险较小，并且是世界性的口味。
由于是RPG游戏，所以弱化了动作系统，这对于手机来说显然是一个优势。
简单易上手，但具备相一定的游戏内涵。各种各样的战斗技能组合，任务系统，装备掉落带来很大的随机性；生活技能修炼和附魔带来了追求最强的乐趣，即使玩家通关一遍，也很想继续游戏下去。
对于手机来说是大作级别，如果开发把握得当，最终产品可以带来震撼的效果。

劣势：
需要对黄泉道做游戏系统上的修改，这部分修改不会涉及引擎底层，但时间成本仍然需要仔细计算。
美术资源量很大，UI工作量也大。
相对ACT游戏，更需要设计良好的剧

注：当年写的，现在看来有许多谬误

写几个非常有用的要点：

0 杜绝浮点运算
因为ARM CPU一般不具备FPU协处理器，需要软件方式模拟，经常需要数千个时钟周期才能完成浮点数的加减计算，所以必须使用定点数。
这个大家都知道，但是要提一下的是，如果能够为定点数提供封装，然后作为内置类型使用，以后一定会方便很多。
再有一个就是精度问题，软件渲染中会为定点数精度的问题头疼的地方会有很多。最好能在不同的场合使用不同小数位精度。一般来说，16:16与8:24是最常用的选择。


1 内存读写绝对是最浪费时间的操作
大多数手机都使用一条16位BUS来获取指令和数据。由于所有指令都是32位的，BUS速度就应当是CPU速度的两倍，才能满足需要。但实际上BUS速度要比CPU慢，速度比在1:2到1:4

当年的PS2项目SMB的开发小结，现在看来感触颇多，发出来缅怀一下那种奋斗的精神。

<一> 描画：
1.关于贴图ID：
最初用到的每张新的贴图，都会在TextureManager中生成新的实例。但是，假设模型A和模型B都用到贴图A，那么贴图A实际上只需要一份实例，否则就会带来内存的极大浪费，以及VRAM的大量无用upload。
为了鉴定这些物理上其实相同的贴图，我们对每张贴图都附加了一个全局唯一的ID，然后用这个ID来判断需要生成的每张贴图，如果该贴图ID已经存在，则直接返回已存在贴图的引用。
通过这个技术，我们把贴图upload时间缩短了70%以上。

2.关于VRAM管理
贴图在VRAM中以BLOCK为最小单位存放，但是存放顺序却不是连续的，所以需要对齐数据。