北京时间 7 月 29 日消息，去年，微软推出 Windows 8 操作系统，它至今未能动摇到游戏世界。微软的朋友&&移动社交休闲游戏商 Arkadium 认为，它知道如何修复问题：更好的分析。
　　最近，Arkadium CEO 肯尼&罗森布拉特(Kenny Rosenblatt)指出，Windows 8 平板和手机的覆盖面还比不上苹果 iOS 和 Google Android，如果开发者认为自己可以获得 iOS 平台的其它支持，比如有企业帮助他们获得用户、帮他们作分析，那么他们就会更倾向于为 iOS 平台制作程序；自己做这些事成本太高，小游戏制作室无法承担。
　　最终，Arkadium 决定自己开发一个专有游戏分析平台，如果外部开发者想让自己的游戏进入，Arkadium 是抱有鼓励态度的。过去 13 年，Arkadium 的主要产品是游戏，当中许多游戏是&贴牌&的，代表大型媒体品牌制作，它们不想自己设立游戏工作室。
　　2011 年开始，微软就与 Arkadium 合作，让它为 Windows 8 设备预先装载新版老游戏。
　　尽管 Arkadium CEO 暗示微软 Windows 8 平台缺乏支持，实际上 Windows 8 已经有自己的专属平台，它来自 MarkedUp。微软也提供在线资源，帮助开发者了解程序内的运营状态。
　　还有 Annie 程序，它为 Windows Store 程序排名，还为 iPhone、iPad、Google Play、亚马逊、Mac 程序排名。
　　对于 Windows 8 游戏，许多开发者的态度是&观望&，罗森布拉特同意此看法，他说大多开发者的确如此。不过罗森布拉特也强调，APP 越少，对年轻点的开发者机会就更多。
<span class="burynum" id="bury_num_
上一篇：( 09:32) 下一篇：( 10:16)您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
基于Symbian平台的俄罗斯方块游戏的设计与开发.doc49页
本文档一共被下载：
次 ,您可免费全文在线阅读后下载本文档
文档加载中...广告还剩秒
需要金币：150 &&
你可能关注的文档：
··········
··········
本科生毕业论文（设计）
目 基于Symbian平台的俄罗斯方块
游戏的实现
学生姓名 XXX
指导教师 XXX
院 信息科学与工程学院
专业班级 计算机科学与技术XX班摘 要
Symbian 操作系统是当前智能手机中最有号召力的一个操作系统。由于它是完全开放的系统，任何厂商都可以在Symbian系统上开发自己的软件，所以当它变得更加强大，应用更加广泛的时候，对智能手机软件的需求也就会增长。基于Symbian OS的智能手机是开放的，用户可以任意下载、安装、卸载由第三方软件开发者（或者用户自己）开发的应用软件,而不需要厂商的同意。S60是最受欢迎的低端智能手机的Symbian用户界面。而手机终端性能的提高，必将带动手机游戏的发展。因此本课题设计实现了Symbian系统下的俄罗斯方块游戏。
此文中的俄罗斯方块游戏是在手机上运行的，手机程序的开发和PC程序的开发有很大的不同，但是在设计思想上却是大同小异，都遵循软件工程的一般原理。本课题在设计中从俄罗斯方块的功能需求入手，结合软件工程的思想，严格按照软件工程的开发步骤，完整的实现了俄罗斯方块游戏。由于受手机平台资源少的限制，本游戏在算法的设计上有其独到之处，对方块的操作都是通过移位运算来实现，节省了资源，提高了游戏的运行效率。游戏的最终运行结果令人满意,开发非常成功。
Symbian操作系统，智能手机，S60，俄罗斯方块游戏
Symbian OS is a full-featured mobile operating system that resides in most of today’s smart phones. Because it is completely open, anyone can manufacturer in the Symbian system and develop its own software, so the demand for smart phone software is growing as these devices become more powerful and more widely used. While Symbian OS-based sm
正在加载中，请稍后...请大家推荐优秀的游戏开发平台！
[问题点数：20分，结帖人sjm100]
请大家推荐优秀的游戏开发平台！
[问题点数：20分，结帖人sjm100]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关帖子推荐：
本帖子已过去太久远了，不再提供回复功能。开发Windows Mobile应用需避免的常见错误
发布时间： 17:42:08
作者：Alex Gusev
错误并不总是不祥之事。犯错是自然的学习方法。但是，这种“学习”在开发循环中可能要付出极高的“学费”。这点在手机应用开发方面尤为突出，应用程序员需要对付许多电脑软件开发者早已忘却的问题。
许多错误会给手机开发者带来严重的伤害。在这篇文章中，我将列举某些最为普遍的问题。
mistakes()
手机开发者必须记住的一件最重要的事情是，Windows CE操作系统与桌面操作系统并不相同。它们有某些共有的功能，但是两个系统所对应的开发方法存在很大的差异。这些差异来源于不同形式的要素、可用资源、API支持等。无论你使用的是C++、Visual Basic、Java还是C#，如果相同的代码可以在PC和PDA（游戏邦注：即个人掌上电脑）上以相同的方式运行，那么你就算是相当幸运的。因而，如果你考虑将现有的桌面应用移植到WinCE上或者考虑开发新的应用，应当记住手机操作系统和电脑操作系统并不相同。
操作系统、设备和框架
除了知晓手机操作系统不同于电脑操作系统之外，你还应当注意到，目前存在不同的手机操作系统以及不同的设备和架构。你需要针对目标设备类型和操作系统制定合适的计划。
比如，如果你以使用Windows Mobile的设备为目标开发出某个应用，那么该应用可能就无法在使用CE.NET的PDA上良好地运行。这种支持缺陷可能会让你所考虑的目标设备减少一半。同样，如果你的产品使用了某款设备中的某个特别功能，那么也可能存在无法支持该应用的设备。这时候你应该考虑，以特定的设备为目标是否是正确决策。当然，如果你是设备产商，自然无需考虑这个问题！但是，对于应用开发者来说，你最好让整个项目的类代码可在几乎所有的设备和平台上运行。
各种框架、程序库和技术的使用也是个问题。比如，Pocket PC SDK包含MFC库，但是Smartphone SDK却没有。基于这种情况，如果你想要兼顾两种设备，就需要有两套方案。所以，在做决定时要格外谨慎！
以上是战略的相关问题，现在我们开始讨论手机应用的结构。目前有两种截然不同的方法：为保持应用稳定，是选择只制作一个可执行文件还是选择将应用分割成一个主要可执行文件和数个DLL呢？
两种结构都各有利弊。我见过许多使用COM对象和大量DLL的项目，这些项目都非常复杂。我必须声明的是，这种方法在Windows Mobile平台上的运行表现并不好。因而，单个可执行文件和少数几个DLL是理想的选择。对桌面系统而言，这种方法显然也是很棒的，但是桌面系统提供了更完善的资源。对Windows CE而言，应用表现会显著弱化。
Windows CE上的DLL中还存在的问题是，如果你存储资源（游戏邦注：比如设置应用支持多种语言），可能导致很严重的问题，因为应用可能在运行期间转变资源处理方式。这使得应用的表现极具不可预测性。现在有许多方法可以避免在应用中使用大量DLL。比如，在将应用投放国际市场时，你可以在可执行文件中“翻译”资源，而不是将它们设置成独立的DLL。网络上有许多描述类似技术的方法可供参考。
你如何配置应用对避免开发失误来说也很重要。手机应用的配置同样也有许多不同的方法，因而我们没必要深入探讨某些具体的错误。但是，有两个可能产生的配置问题应当考虑，那就是注册表的使用和代码的再用性。
大型桌面系统使用注册表的方法就像是用数据库来存储数百个参数。对于Windows Mobile应用来说，这种方法无效，原因很简单：手机设备时常需要更新固件。一旦进行固件更新，很可能注册表中的所有数据也被重置，从而丢失。不管怎样，维持此类配置存储简直是个噩梦，因而可以通过购买Pocket Controller等额外的工具来实现目标。
如果你的应用需要大量的参数，那么就要考虑用合适的方法来存储，比如XML和二进制文件等方法。
代码的重复使用无疑是开发中最棒的事情。这也是我们创建程序库和框架等内容的原因，这可以帮助我们更好更快地开发应用。
你必须谨慎地使用此类程序库。比如，如果在手机设备上使用不当的话，MFC框架可能产生许多问题。毫无疑问，如果你能够利用它的话自然可以带来很大的帮助，但是，某些类运用到手机上时，其效能要远远小于桌面版本。CSocket和WinInet等正属于这个范畴。而且，某些可通过API实现的功能性在手机上无法实现。程序员不可使用那些无效的类。微软已经决定在Windows CE的最新版MFC中终止某些类。比如，WinInet类就会被终止。如果你不幸在项目中使用了这些类，那么你就需要从新编写（游戏邦注：此处内容以2006年为叙述背景）。GUI类崩溃是出现相对较少的情况，但是我认为应当将此视为意外而不是普遍问题。
I/O、内存和堆栈
最后，我们要探讨的是可能导致手机应用出现错误的编程问题。
首先，从表现和设备资源的角度来谈论I/O操作。对于桌面系统来说，正常的接受是以模块为单位来读取而不是字节。对于手机应用来说，情况并没有如此简单。如果数据存储在闪存卡（游戏邦注：如SD和CF等）中，那么访问时间就会非常长。假设数据存储在展平文件中，不使用二进制或文本文件（游戏邦注：比如XML）。如果你能够瞬间读取内存然后按照需要加工处理，那么确实很不错。但是，在需要处理大量数据的情况下，这几乎是不可能的。在这种情况下，你必须配给分布在各处的组块。各版本操作系统的内存配给战略可能存在差异，这是件很麻烦的事情。你可以在Pocket PC 2002版、2003版和Windows Mobile 2003 SE上进行测试。在Pocket PC 2002上，你可以享受到大组块配给，但是在随后的版本中，较小组块的配给更快。在Windows CE 5.0中，情况再次发生改变，因而不再有RAM。存储卡依然存在，但是正如你所看到的那样，需要重新选择最佳的方法来实现最好的I/O表现。
并非所有的PDA都搭载着资源或者有大量可用的资源。这会直接影响到应用可用的栈大小。许多手机应用使用基于对话的结构，因为它很简单。为众人所知的是，对栈进行大型配给是不可行的，因为你默认的栈大小只有64KB。当你在栈上创建多个对话且同时打开时，能够呈现的直观效果较少。显然，边界上平衡的关键对话数量只有3到4个。如果你的程序尝试使用更多，栈溢出已经是最好的结果了。通常情况下，这会导致应用某些部分崩溃。
最后要阐述的编程错误是异常情况处理中的问题。Windows CE的早期版本并没有广泛支持异常情况处理。现在，情况大有不同，该系统已支持一般的C/C++处理。异常情况处理对手机应用来说特别重要，因为手机平台的运行环境友好度不如桌面系统。正确地运用异常情况处理会使你的产品更加健全，但是不要滥用这种功能，否则会影响到应用表现。
游戏邦注：原文发表于日，所涉事件及数据以当时为准。（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
Big Mistakes To Avoid in Windows Mobile Development
Alex Gusev
Mistakes are not always a bad thing. Making mistakes is a natural way to learn. However, the cost of such &#8216;learning&#8217; in the development cycle can be pretty high. This is especially true for mobile applications, where a programmer battles against so many issues that desktop developers can&#8217;t even remember any more.
There are a number of things that are most harmful for mobile developers to do. I present several of the most common troubles worth reviewing in this article. I start with strategic issues.
Different Platforms are Different
The very first and probably most important fact mobile developers must remember is that Windows CE operating system is by far not like its big brother the desktop operating system. They have common features and share common philosophy, but there is a big difference in development approaches used for each. This is due to different form factors, resources that are available, supported APIs and so forth. Regardless of whether you use C++, Visual Basic, Java or C#, you will be lucky if the same code will run on both the desktop and on a PDA in the same way. Thus if you&#8217;re considering the porting of your existing desktop application to WinCE or considering the development of new applications, remember that the mobile operating system is not the same as a desktop operating system.
Operating Systems, Devices and Frameworks
In addition to knowing that mobile operating systems are different from desktop operating systems, you should also note that there are different mobile operating systems as well as different devices and frameworks. You need to properly plan for the device types and operating system you would like to target.
For example, if you have developed an application for devices using Windows Mobile, then your application might not run good on PDAs with CE.NET inside. This lack of support could cut your target devices in half. Similarly, if your product uses specific features of a specific device, then there may be devices that can&#8217;t support your application as well. For this reason, you should ask yourself if targeting specific device features is a right decision. Of course, if you are device vendor, such problems are out of scope! For application developer, however, generic code you produce as better for the whole project, i.e. you application will be able to run almost everywhere.
Another issue from the same family is the use of various frameworks, libraries and technologies. For example, the Pocket PC SDK contains MFC library but the Smartphone SDK does not. As such, if you want to target both Pocket PC Devices and Smartphone devices, then you need to think twice. Another example can be seen with ADO CE. In addition to many differences with desktop version, Microsoft has decided to discontinue its support in Windows Mobile 5.x. So be double careful there!
Application Structure
That is enough regarding issues with strategy, now consider the structure of a mobile application. There are at least two polar approaches: to make an application solid &#8212; do you always have the one and only executable or do you divide your application into a main executable and number of DLLs?
Both structures have well-known pros and cons. I&#8217;ve seen many projects (very complicated and fat enough to be honest), which used COM objects and huge number of DLLs. I have to state here that such approach doesn&#8217;t work well on Windows Mobile platform. One executable and few DLLs are ideal though. This is obviously true for desktop systems as well, but there you are in much more comfortable situation with resources. In case of Windows CE application performance will be reduced dramatically.
Another issue with DLLs on Windows CE is that if you store resources, (e.g. to support multiple languages in your application), it may cause significant problems because the application may switch resource handles at runtime. The resulting behavior may be quite unpredictable. Eugene Tilman and I have spent a number of sleepless nights trying to detect why a big application sporadically crashes on a device but works like a charm in desktop emulation. There are different methods for avoiding the need for many DLLs. For example, when implementing internationalization, you might &#8216;translate&#8217; resources within the executable rather than keep them in a separate DLL. There are a number of references on the web describing similar techniques.
Application Configuration
How you configured your application is also important for avoiding mistakes. Again, there are many different ways to configure a mobile application, so we will not dig into specific mistakes. Rather, there are two possible configurations issues you should consider: Registry use and code reusability.
There are big desktop systems which use the Registry in much the same way as a database in that it is used to store hundreds (if not thousands) of parameters. For Windows Mobile application such tricks just won&#8217;t work due for a very simple reason: mobile devices suffer from hard resets from time to time. If a hard reset occurs, you have a good chance that all data in the registry will be reset as well and thus lost. Regardless, maintenance of such configuration storage can be a real nightmare, although it can be done by purchasing additional tools such as Pocket Controller.
If your application needs a lot of parameters then consider suitable method to store them &#8212; a method such as XML, binary files or something else.
One of the best things in development is code reusability. That&#8217;s why we all create libraries, frameworks and so forth. This helps us to develop faster, better, &#8230; (you can continue as much as you want to).
You have to be careful using such libraries. For example, the MFC framework can cause you problems when used incorrectly on mobile devices. No doubts, it helps a lot wher however, there many classes that are implemented for mobile usage with much less efficiency than in desktop version. This includes classes like CSocket and the WinInet stuff. Additionally, some functionality available through the API are unavailable for mobile usage. But this is not the worst trouble. Such problematic parts of the library are obviously subject to improve. Programmers simply do not use ineffective classes. Hence, Microsoft has decided to discontinue some of them in newest MFC version for Windows CE. For example, the WinInet classes are being discontinued. If you&#8217;ve the bad luck to have used them in your projects, then you will have to rewrite them. In rarer cases, some GUI classes may be dropped, but I believe it should be treated as an accident rather than common case.
I/O, Memory, Stack & Co.
Finally, there are programming issues that can be the cause of mistakes in mobile applications.
I/O operations are the very first point to talk about from a performance and device resources point of view. For desktop systems the normal receipt is simple: read by blocks rather than by bytes. For mobile applications it is not as straightforward. If data is stored on a flash card (SD, CF etc.), then access time may be painfully long. Suppose that data is kept in a flat files with no matter binary or text (like XML). It is a good thing if you can read it all in one shot to memory and then process as needed. In the case of huge amounts of data, however, this is simply impossible. In those cases, you have to allocate chunks here and there. It is a really bad thing that memory allocation strategies may vary from one version of an OS to next one. You can easily test on a Pocket PC
and Windows Mobile 2003 SE. On Pocket PC 2002 you benefit from big allocations, but on later versions smaller chunks are allocated faster. With Windows CE 5.0 the situation changed once again, because there is no RAM anymore. Storage Cards are still there, but as you see, it might be a particular magic to choose the best method to reach the best I/O performance.
Not all PDAs are loaded with resources or have lots of resources available. This fact hits you first of all with the stack size that is available for applications. Many mobile applications uses Dialog-based architecture because it is simple. It is well-known that big allocations on the stack, e.g. BYTE arr[65536], are inapplicable because you have by default only a 64KB for stack. Less intuitive effects can occurs when you have a number of dialogs created on the stack and open simultaneously. It appears that critical number is balancing on the boundary of 3 to 4 dialogs only. If your program tries to pop up more, a Stack Overflow exception will be the best thing you can get. Usually it just crashes at some arbitrary place.
The last but not the least thing regarding programming mistakes is in exception handling. Earlier versions of Windows CE did not support exception handling extensively. Now the situation is quite different. Normal C/C++ handling is allowed, TRY and CATCH macros may be forgotten. Exception handling is extremely important for mobile applications, because an environment is less friendly than the desktop. Applying exception handling in the correct way will make your product much more robust, but don&#8217;t be too excited with it, otherwise you can loose the performance.
In Conclusion&#8230;
You&#8217;ve now seen many of the biggest mistakes! I hope reviewing them will help you to avoid them and thus lead to better decisions in your own mobile applications. With mobile technology growing so rapidly, doing mobile development is getting better with every new operating system release. So who knows, maybe soon mobile programming will become as regular as desktop development. ()
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1