今天重新整理了一下代码，在「百家乐」游戏中，处理玩家下注有2种考虑：
- 维护「筹码显示」，「下注金额」2个变量，下注之后给服务器发送消息，等待服务器返回成功，再更新数据和显示，这样做可以保证界面显示的筹码数和下注金额正确而且比较简单，但是会有延迟的感觉。
- 第二种做法是，维护「筹码显示」，「下注金额」，「等待验证的下注金额」3个变量。在下注之后客户端先行增加「筹码显示」和「等待验证的下注金额」，显示的下注金额总和为「下注金额」，「等待验证的下注金额」相加，实时更新了显示，等待服务器返回成功，「下注金额」增加该次下注额，「等待验证的下注金额」同时减少该次下注额，这2个数据之和相同，并不影响显示。
参看别家的百家乐游戏，仔细体验还是能发现它们是采取第一种做法的，以服务器返回为准。这种做法简单，但是效果上完全可以接受，那么在这里我们完全可以先采取第一种方法把功能做出来，后面迭代可以再优化体验。
就像我原来在《程序员》看过的一篇文章，在游戏领域的开发中，我更是体会深刻。对话如下：
《程序员》：设计软件系统时，你会采用哪些步骤？Nathan ：我认为，设计软件系统完全就是学习如何在行进中开发。我应用一种被我称之为“面向痛苦编程”（Suffering-Oriented Programming）的原则，使学习最大化，浪费最小化。关于这种方式的详细介绍我已写在博客上。其核心思想是，避免做出“通用”和“可扩展”的设计，除非你已透彻理解了问题域（Problem Domain）。相反，你应该直截了当地尽快打造出可用原型，继而通过迭代和改进学习问题域，当你对问题域的盘根错节有了清晰的理解后，再回过头来重新设计系统，使之具备通用和可扩展等特性。到最后一步才开始收紧代码，优化性能。归纳为三个步骤，就是“先使之可能，再使之漂亮，后使之快速。”