Flash淘汰后，网页游戏的发展经历了一次大的转变。Flash曾经是网页游戏的主要技术之一，但由于其存在一些安全性和性能上的问题，以及HTML5、JavaScript等技术的发展，Adobe公司宣布停止Flash的开发和分发，这使得依赖Flash的网页游戏面临了挑战。

1. **转向HTML5和WebGL**: 许多网页游戏开始转向HTML5和WebGL等技术进行开发，这些技术直接在浏览器中运行，无需插件，性能和兼容性都得到了提升。WebGL提供了3D渲染能力，使得一些原本需要Flash的3D游戏得以实现。

2. **云游戏和微客户端**: 部分游戏采用云游戏的方式，用户无需在本地安装游戏，而是通过网络实时流式播放，降低了对硬件的要求。微客户端则是下载部分游戏资源，其余在云端运行，降低了对用户电脑性能的依赖。

3. **跨平台适应**: 随着移动设备的普及，更多的网页游戏开始优化移动端体验，开发响应式设计，适应不同设备的屏幕。

4. **轻量化小游戏**: 一些简单的休闲类网页游戏，如点击游戏、消除游戏等，由于其自身对硬件和网络的要求较低，依然能够在没有Flash的情况下持续发展。

5. **游戏平台和社区的转型**: 某些游戏平台开始转向原生应用或者转向其他技术平台，如Unity3D、Unreal Engine等，继续提供高质量的游戏。

总的来说，虽然Flash的退出对网页游戏市场有一定的影响，但技术的更新换代推动了行业的发展，让网页游戏有了新的生存方式和可能。

Flash死了，但你小时候玩过的游戏，还在试着活下去

而Flash 既可以方便的制作动画，又可以结合动画来写程序，同时格斗游戏需要精确编辑攻击判定和各种参数，这正好是 Flash 的强项。在还不太了解其他游戏引擎的梦旅人心里，它比纯粹的编程语言更适合制作游戏。

那个年份， Flash 还没有完全兴起。很长一段时间里，flash 创作者闪客们用 Flash 制作的大量歌曲 MV ，在家家户户的电视机上和大小城市的 KTV 里反复播放。简单低帧的动画，也是很多人对 Flash 的印象。

虽然Windows不再支持Flash炫舞手游盒子返场顺序表2022，但这款经典的Flash游戏焕发了第二春

flash淘汰后网页游戏

这样的设计使得整个游戏的“耐久度”相当可观。角色的武器和辅助装备有多个途径可以获得——刷关卡获得随机物品、商店直接金币购买、金币抽取。在本作中，武器和装备还有属性和词条的设定，这就让本作又有了“装备驱动型游戏”的味道——如果你是一个追求极品装备的玩家，玩这个游戏你可算是来对了。

前不久在Steam上架的《战火英雄》重制版倒是终于让我不用再担心开发团队只能“用爱发电”了，买断制的付费模式也正是最适合这款游戏调性的。《战火英雄》重制版依旧由原版开发团队Sky9 Games“掌勺”，因此保持了原汁原味。重制版不仅拥有比Flash原版更加出色的画面表现力，更重要的是，我终于能看明白它的剧情了——拥有完整故事情节和全程配音的动态过场动画，让剧情闯关的过程更加具有代入感。

曾经的Flash游戏，为一个时代落下了帷幕

时间退回至千禧年后，彼时互联网逐渐流行于普罗大众之间，但与那时各类网络热游、端游的网吧环境不同，受制于家庭电脑配置的参差不齐，部分玩家很难在自己的电脑上玩到心怡的游戏，尤其是对于一些刚刚接触电脑的低龄玩家而言，他们很需要一类替代蜘蛛纸牌、空心接龙等自带游戏的消遣方式。

如今看来，这些荒诞不经的剧情内容多带点抽象，简直比某些滥竽充数的“粪作”还主打一个糊弄人。但在这款游戏却给极小游戏视野的我，带来了极大的新鲜感，尽管其游戏制作有些粗糙，但真实场景与不错的游戏玩法，给玩家带来了相当不俗的代入感。

flash不是被杀死的，核心是安全性太差，这里说的安全性是指网页的flash支持插件。

如果想支持我，可以在Steam上购买Hapland Trilogy，或我在2020年后做的另一个游戏 Blackshift。我在foon.uk上也有一些基于浏览器的免费游戏。比较新的游戏是用JavaScript或WASM写的，而较旧的游戏（包括原版的Hapland）是AS2 Flash，由于有Ruffle支持，运行得还不错。后面的AS3的游戏无法运行了。

你很棒！有兴趣搞搞安卓的吗？最好安卓11以上的。

发布给最终用户的软件我会尽可能减少依赖，但我也不介意使用一些高品质的库。除了OpenGL和一些操作系统标准库之外，整个游戏系列采用了下面几个库：

flash还不错。就是现在沦为广告了

虽然我主要在Mac上开发游戏，但苹果的“公证”机制非常令人头疼。每当运行MacOS应用时，苹果都会检查开发者是否缴纳了年费。如果开发者没有付年费，MacOS就会强烈地暗示该应用是个病毒，并且拒绝启动。

请登录并关注博主以后才能展开

在反复推敲了几遍之后，我找到了一套还算不错的成就方案：完成每个游戏获得一个成就，完成每个副任务获得一个成就，然后几个重要的隐藏要素都有成就。正常玩家找不到的奇怪的隐藏要素没有设置成就，玩家只能获得发现的快感。

我觉得是大企业要他死的

我觉得Steam可能会为大型游戏工作室提供一个批量导入工具，但我没有这种工具，所以我分析了HTTP请求，保存下cookie然后自己写了一个导入工具。

我给每个游戏都添加了一个背景音乐，用的是我自己录制的一些音乐和现成的音效。有一次我去日本旅游，突发奇想去了某座山上的录音棚里录了一些东西。我在网上找了个音乐人帮我录了片头音乐，然后自己给片尾录了一些吉他和弦，还加了一些特效，免得让别人听出我的吉他水平很差。

Flash的界面很不错。按钮有边缘，图标是写实风格的，空间利用率也非常棒。使用旧的界面感觉就像是考古学家在探索被遗忘的罗马科技一样。失落的界面设计。

这款游戏本身的流程不算长，有三个任务，不过我还是想让人们再多玩几个小时。于是我给每个游戏增加了一个“副任务”——一个游戏的修改版本，其布局和谜题略有不同。制作这种副任务的工作量比制作新游戏小得多，但能达到不错的效果。

要实现保存和加载，只需要实现两个Zone，一个是活跃的Zone，另一个是“保存状态”的zone。要保存状态时，只需将活跃zone memcpy到保存状态zone中。加载状态时按照相反方向memcpy即可。

许多模拟器都有保存游戏状态的功能。按下“保存游戏状态”后，模拟器会将整个模拟游戏机的内存保存到文件中。这样，如果失败，只要按下“加载游戏状态”，就可以从保存的地方重新开始。

在制作这款游戏时，我想减小玩家的压力，所以想出了这个想法。整个游戏的流程很长，而且有许多很容易失败而不得不重来的地方。也许在2006年这不算什么，但现在我们都长大了，没有时间玩如此硬核的游戏。

现在，我有了一个很不错的C++版本的游戏，能在现代电脑上至少再稳定运行一二十年。不过我觉得还能再加一些额外的功能，所以除了重画许多图形、改进动画之外，我还做了下面这些改进。

首先，我尝试让导出器将帧数加倍。也就是说，将时间线上的每一帧导出成两帧。这样很容易就能获得48fps，但距离60fps还有一定距离，所以动画速度还是快了25%。最后的解决方案很朴实——我玩了一遍游戏，然后把动画过快的地方手动加上几帧。

我希望重制后能达到60fps，这意味着我需要对动画做一些处理，因为游戏的动画是按照24fps设计的。（Flash的动画工具只能在离散帧上创作，不能处理连续的时间。）

为了确保其他效果是正确的，我做了一个“颜色测试”图，其中包含了多种浓度的多个颜色，以及色相切换效果等，然后在游戏中显示，确保它在游戏中和Flash中显示效果一样。

但最后我没有采用任何一种方法，我接受了半透明效果在Flash和游戏中不同这一事实，然后不断调整图形直到在游戏中的效果满意。透明物体在Flash中永远不会和实际效果一致，但幸好透明物体不是太多，所以不是太大的问题。

我只想到了两个方法来解决这个问题：1) 设置两个阿尔法通道，一个保存覆盖值，一个用于感知混合值；2) 在栅格化图形时不加抗锯齿，而是将图形绘制在一个非常大的帧缓冲区中，然后利用过滤算法将其缩小。

现在，经过抗锯齿栅格化后的图形使用的是阿尔法混合模式，而Flash导出的阿尔法透明度、渐变和颜色变换使用的是另一种混合模式。但是渲染流水线中只有一个阿尔法通道。那么，渲染器应该怎样解释阿尔法值呢？如果按照感知混合的方式解释，那么半透明的物体是正确的，但抗锯齿边缘和其他效果就是错误的。如果按照覆盖值来解释，那么结果正相反。总会有一些是错误的！

在不透明的黑色像素上绘制一个半覆盖的白色像素，其结果不应该是50%的灰色。光的原理并非如此，向量图的栅格化也不是这样工作的。（没有背景色，栅格化过程做不到“该像素的颜色应该位于前景色和背景色之间的 x%”。）

在对向量图进行光栅化时，你需要产生抗锯齿的输出，此时光栅化程序会产生一些阿尔法值，叫做“覆盖值”，意思是，如果某个像素在向量图中被盖住了一半，那么该像素的alpha值就是0.5。

经过一番测试后，我发现Flash的阿尔法混合和颜色变换不是在线性空间内进行，而是在感知空间内进行的。从数学角度而言这样做是否正确还有待商榷，但我能理解为什么，因为许多绘画程序都是这样做的，它们希望能按照人们期待的方式工作，而不会考虑那些不懂商业的数学家的想法。但我还是要说，这样做是错误的！这样会导致抗锯齿等功能出现问题。

唯一的难题是让场景本身适应额外的宽度，这需要重新绘制许多图形并重新排列，以适应新的长宽比。尽管有一点痛苦，但最后还是搞定了。

所以，我在每个游戏上画了两个矩形，一个是16:9，一个是16:10。然后游戏会根据屏幕分辨率计算矩形大小，然后用计算出的矩形作为相机的视图边界。只要所有重要的游戏元素都在这两个矩形的相交部分，且相交部分的边界不会超出场景边缘，就没问题。

现在最常见的长宽比是16:9，一些笔记本上也有16:10的长宽比。我希望游戏能在这两种长宽比上正常运行，不会出现黑条，也不会拉伸图像。唯一的做法就是将原图切掉一部分，或加上一部分。

有过将旧媒体文件转成新格式经验的人对此应该不陌生。原来的游戏在浏览器上运行，根本没有考虑到全屏运行，所以长宽比是随意选取的。每个游戏都不一样，但大致都在3:2左右。

所以，虽然底层依然是一大堆字符串查找，但这一层类型安全能够防止在错误的对象上调用错误的方法，避免了一大堆在动态类型语言中由于输入错误而导致的烦人的bug。

BigCrateLabel *label() { return (BigCrateLabel *)getChild("label"); }

BigCrateLid *lid() { return (BigCrateLid *)getChild("lid"); }

我想说明的最后一点是，最后生成的脚本是静态类型的，这一点很好，因为ActionScript本身并没有类型。而导出程序生成的游戏对象大致如下：

将所有的帧脚本转换成C++之后，就可以在编译时将其提取出来，变成每个符号的Node子类中的方法。同时还会生成一个负责分发的方法，负责在正确的时机调用这些方法。这个分发方法大致如下：

这款游戏几乎所有的逻辑都是用ActionScript编写的附着在时间线上的帧脚本。这些要怎么导出？我不想在游戏中包含ActionScript解释器。

游戏使用的Flash特性（如颜色变换、遮罩等）都是现成的，尽管我实现的遮罩并不支持任意形状的遮罩，而只是矩形裁切而已，然后我将所有图形都编辑成了矩形，这样所有遮罩都用矩形就可以了。

导出程序的其余部分就没什么意思了，只不过是遍历整个树，然后转换变换矩阵、颜色效果等数据。最后再进一步转换游戏程序本身。我选择C++编写导出程序的原因只是我熟悉C++而已。

我可以选择让导出程序将字节码写到一个文件中，同时将文本代码写到另一个文件中，但我并没有这样做，而是选择了汇编器，因为（1）我已经有汇编器了；（2）不需要再调试汇编器；（3）汇编器支持标签。

这里，我想出的一个方法是将数据导出成汇编代码，而不是二进制文件。当然汇编代码并不是CPU指令，只是数据而已。这样调试可以更容易一些，因为我可以翻阅汇编文件，查看生成的内容，而不需要通过二进制编辑器来查看每个字节。

于是我计算了每个图形的XML的哈希值，仅在哈希值发生变化的时候进行构建。即使是这样，有时也会出问题，因为Flash有时候会重新排列XML标签，即使图像没有任何变化。但同样，这样做已经足够好了。

光栅化非常慢，所以为了保证构建时间不会太长，我需要跳过没有变化的部分。Flash使用的压缩后的XML文件中有一个字段表示最终变更时间，但Flash似乎并未正确使用该字段，所以无法依靠它。

在渲染好PNG之后，导出程序将这些PNG图像拼成一张精灵图。方法很简单，只是将所有图像按照尺寸排序，然后逐行排列在一起而已。这远远不是最佳方案电视盒子吃鸡游戏推荐，但已经足够好了。

选择CoreGraphics让我颇为犹豫了一番。我选择它主要是因为我在Mac上开发，而Mac恰好提供了这个库，我又不想麻烦使用其他的依赖。但这个选择导致只能在Mac上进行栅格化，即使是构建Windows版也不得不这样做。如果可以重来一次，我会选择一个跨平台的库。

即使我没有具体的规格，对其进行栅格化也并不困难。向量图的贝赛尔曲线模型从PostScript诞生以来就没有变过。所有API的工作方式也和当年一样。经过一番尝试后，我弄清楚了 ! 和 [ 等符号的意义，于是写了一个程序来解析这些形状定义，并利用Mac的CoreGraphics将其渲染成PNG图像。

Flash的向量图保存在XML文件中。你也许会说，XML并不适合保存图形数据，但毕竟这是Macromedia的产品设计师决定的。

我决定进行离线栅格化，然后将栅格化后的文件打包到游戏中。在运行时进行栅格化应该很有意思，而且能保持小体积的可执行文件，但我不想在游戏中加入额外的处理。我希望尽可能多地让代码在我自己的机器上运行，这样可以保证它们不出问题。

Flash中的图形都是向量图。虽然 Flash 支持位图，但本身是为向量图设计的。因此Flash动画在当年的拨号连接上都能快速加载。这款游戏的所有图形都是向量图。

幸运的是，.fla文件只不过是XML而已。我需要解析该文件，将相关的数据导出到一个自定义的格式中，然后编写播放器来读取、描绘场景、处理输入，然后运行动画。我还需要处理ActionScript。

下面，我简要介绍一下这款游戏的构建。所有精灵以树形结构组织。在 Flash 中，动画精灵可以在某些帧上添加代码，当播放到该帧时就会运行这段代码。这款游戏使用了许多这种代码。游戏角色的行走路线只不过是时间线很长的动画而已，角色上经常会有帧动作，比如当到达门口时，如果门是关着的，就把门打开，或者当遇到地雷时，如果地雷还没有爆炸，就引爆。

最后我放弃了，部分原因是 AIR 有很多 bug，而且很难用，但主要原因是我不想用一个奇怪的 Adobe 软件作为最终解决方案，我希望能完全用我自己的技术来代替。考虑到以后可能会移植到 Linux，我不想受 Adobe 的限制。

专题： 单机游戏反三国   单机游戏战三国   大三国单机游戏