21这是网上找的代码。稍作修改即可使用。这里只显示倒计时。您也可以改为显示资源的增加。用C语言操作mysql数据库。1//TODO:在此处添加您的控件通知处理程序代码2boolbRes=m_dbConn.Connect("databaseipaddress",3306,"username","password","databasename");3if(!bRes)4{5AfxMessageBox("连接失败");6返回；7}89stringstrSql="select*fromcitylimit1";//该段用于所有显示或取值类型。中间的sql语句可以自己构造。10结果集*rs=m_dbConn.ExecuteQuery(strSql);11while(rs->Next())12{13stringstr=rs->GetString("username");14AfxMessageBox(str.c_str());15}16/*17strSql="updatecitysetmoney=money+100whereCity_ID='xxx'";//所有的增删改查都用到这一段，中间的SQL语句可以自己构造。1819bRes=m_dbConn.ExecuteUpdate(strSql);20if(!bRes)21{22AfxMessageBox("ExecuteUpdatefail");23}24*/25m_dbConn.Close();2627定时器的主要功能。28voidCBeiLiDlg::Go()29{30while(true)31{32//AfxMessageBox("go");3334Sleep(5*1000);//毫秒。定时器刷新时间。35}36}当然可以。这里的C代码不能直接使用。只是其中的一部分。新的方法是通过php定时器类来负责前台，时间到后调用ajax完成执行。后台定时执行php定时器类的特殊处理函数，处理前台断线，前台没有正常执行的情况。如果我们的新游戏能在今年年底正常上线。我可以把这个类公开，这不是技术性的，而是巧妙的。地图，城市，基本都有。接下来是城市中的建筑物。上面说的资源增加，其实从建设上来说更准确。然而，建筑物的分类和价值将复杂得多。这是规划考虑的问题。在建筑方面，我们只谈一个前台的建筑效果。当然，这种影响是可有可无的。可以直接给一个类似新闻列表的展示，加上倒计时。显示的效果是，点击build之后。在不刷新页面的情况下加载动画图片。并在时间到时自动转换为其他图片。118顺带一提。如果要考虑多浏览器兼容性，那就用prototype.js吧。如果只需要ff和ie。那就用jqury.js或者自己写试试吧。因为120kprototype.js已经不小了。在后台部分，将时间到时添加资源的代码更改为时间到，添加或更新建筑物。就是增加N张表。.新方法是增加事件子类。构建基本表：输出、类型、图片等。建筑明细表：属于哪个城市，可以在城市表中进行关联。不同的关联方式会对程序产生很大的影响。各种关联方式都可以，但是关联方式一旦确定，最好不要更改。现在也有建筑物。使用类似的计时方法，兼职、征兵等都可以实现。战斗、兵种参数：兵种、数量、攻击、防御等。战斗临时表：谁的兵，打谁，出发时间，战斗时间，战斗结果。这里的几句话很简单。实际的表会稍微复杂一些。在网页游戏中，战斗过程有两种，一种是给出双方的参数，时间到了，根据公式计算结果。一种是半实时或实时战斗，就是那种一边喝药一边战斗，一边使用技能一边战斗的类型。第一个过程。点击派兵。此时士兵的参数、出发时间、到达时间都记录在战斗临时表中。在定时器中处理战斗的部分，判断是否到了开始战斗的时间。开战时，获取被攻击方棋子的参数。然后通过几个公式计算结果。处理结果，比如有多少士兵被杀，战场上掉了多少钱，谁拿下了城市。很多判断和updata。（这里的定时器处理和获取资源的定时器处理很相似。）最后将结果发送给双方。（还涉及到短信系统。）第二个过程。点攻击。立即处理数据。击中npc很容易做到。在玩家之间的战斗中，被攻击的玩家也可以被视为npc。两个或更多人实时战斗。需要使用ajax。目前技术上和理论上都没有问题。我还没有真正编写代码，所以很难说。现在，技术上已经确定，可以很好的实现。一个非常简单的公式，可以在两个战斗中使用：intval(sqrt($User_B_AP)-sqrt($User_A_DP));根号下的攻击-根号下的防御=伤害。到具体写的时候，公式肯定会复杂很多，这个头疼的就交给策划吧。战斗的具体参数其实是程序没有考虑的。程序只需要考虑从数据表A中获取数据，存储到临时表B中，然后当时间到了（通过定时器实现），从数据表C中获取数据，通过公式计算，最后临时表B被删除或另存为备份。这里的思路其实就是定时器类。数据是什么？求一个计划。有几张桌子？求一个计划。战斗公式？求一个计划。有了地图、城市、建筑、士兵、战斗之后，道具的出现是必不可少的。为什么？一个城市能做什么？生资源，生钱，生兵。士兵怎么办？可以抢资源，可以抢钱。资源和金钱有什么用？购买道具。你买道具干什么？更好的抢资源抢钱。（同时抢夺资源和金钱时，会消耗资源）这是一个很简单的循环。它只是形成一个圆圈，虽然这个圆圈很小。有的计划想得很好，就是绕不开圈子，所以没有任何意义。首先，需要一个props的基表。自动ID、道具类型、道具属性、描述。在道具的处理上，可以在玩家表中增加更多的字段，道具跟随玩家。您还可以单独创建一个详细的道具表。以类似背包的方式实施。背包的存放方式有两种，一种是存放在数组中，另一种是存放在横表中。都很麻烦。但是，从道具的流通和交易来考虑。使用背包方式是值得的。下一个功能。店铺。拍卖。基本上，它与一般的网站应用程序非常相似。只不过产品变成了游戏中的道具而已。货币为游戏货币。3.总结上面的小例子，思路基本完美，没问题。只给出了一小部分程序代码，这一小部分才真正能够看懂。程序的其他部分应该没有问题。网页游戏最重要的是数据流量和可玩性的循环。现在我们来谈谈：程序的健壮性和数据流的清晰度。以上功能，如果真的做出来了，玩起来还不够。就是不好玩，做起来也没有意义。然而，仅仅做到这一点，依然是一件困难的事情。游戏中涉及的东西太多了。即使是很简单的游戏，即使网页游戏看起来很简单，其实也很简单；很难做到。没有页游开发经验的人策划页游或者开发页游。会觉得很简单。实际上只有几个主要功能。思维上也容易打圈。实际情况是，一个很简单的函数，需要绕一圈的时候；需要交互的时候。这个功能不再简单，而是复杂，相当复杂。这是你对设计模式还不太了解的时候，如果你精通设计模式，那么功能就简单了。尤其是你想做一个有足够可玩性、可以营销的产品，哪怕一开始的想法很简单，功能也很简单。但是当你真正计划的时候，当你真正编程的时候。你需要处理大量的数据和值，你需要处理大量的交互。这时候，原本简单的事情变得复杂了。虽然从程序上看，技术含量不高。更准确的说，是繁琐，非常繁琐。一个好的方案就是把数据表列出来，把数据趋势列清楚，摆在你面前。这样的计划并不多。当然，他可能没有被列的很准确，但是程序员可以更准确的理解他的意思。