rpg修改(atom)

在游戏的前期资源可以说是十分的匮乏，但是我们可以通过修改游戏的部分数据在前期就获得不错的道具，感兴趣的朋友快来看看这篇“NovaRain”分享的ATOM RPG 修改数据方法吧。

攻略推荐

核爆RPG末日余生图文攻略

修改数据方法

现在想修改玩家属性技能的话，可以用Cheat Engine表格，角色/技能指标的部份同样适用于队友。

在早期Beta时候ATOM的存盘是放在各个资料夹的分散档案(玩家资料、地图档等等)，玩家档案本身是文字档可以直接打开来修改属性和物品栏之类的，后来才改成现在一个存盘为一个打包档。

现在的存盘本身是gzip格式，只是副档名改成.as而已，用7-Zip解开会有一个同名但无副档名的档案，试着用文字编辑器打开该档案应该会是一团乱，用16进位编辑器会好一些，稍微看一下会发现这个档案其实是数个档案组合起来的，内容是玩家资料、地图档、地图迷雾、存盘缩图，搜寻还是找得到玩家资料，但要修改会很麻烦，因为这状况下你不能动到档案长度，一动到游戏就认不得它了，所以能做的修改极为有限，想修改叫出物品得用其他方式。

ATOM在进行游戏的时候会把现在资料放到存盘路径一个临时新增的"progress"资料夹内，这时的暂存盘就是各别分散的正常档案，能修改的只有不是现在所在的地图档，玩家资料和当前地图档改了没用，因为实际资料已经被加载内存，游戏在你离开一个地图时会把内存内的地图资料写到档案，重新进入时才会从档案读取。

以游戏一开场做为实际范例：

在一开始醒来过桥放完过场影片之后会到Otradnoye，直接转头跑到出口进入世界地图画面，这时切换回Windows找progress资料夹里面会有个Village_Ground_1_.dat档案，用文字编辑器(建议别用记事本)打开会是满满的物件资料。我想在村外废屋没上锁的柜子内塞些东西，所以搜寻柜子的原始资料(不确定之后改版他们会不会动到地图上的物件，至少1.05/1.06还是这资料)：

{"class":"Chest", "active":"true", "proto":"Metal_Shelf_1", "inventory":[ {"class":"Item", "count":"1", "proto":"Wastepaper"} ], "open":"true", "lockLevel":"0", "lockType":"Mechanical", "pin":"0", "name":"Metal_Shkaf_3", "transform":{"pos":[ "256.51", "0.01083292", "29.39307" ], "rot":[ "0", "0", "0" ], "scale":[ "1", "1", "1" ]}},

其中"inventory"后面接着的中括号之间的内容是该容器的内容物，就一捆废纸：

{"class":"Item", "count":"1", "proto":"Wastepaper"}

于是把上面那项目换成这一长串：

{"class":"Weapon", "count":"1", "proto":"AKS74U", "ammo":{"count":"30", "proto":"5_45mm_JHP"}}, {"class":"Ammo", "count":"120", "proto":"5_45mm_JHP"}, {"class":"Weapon", "count":"1", "proto":"Knife_War"}, {"class":"Consumable", "count":"10", "proto":"Biscuit"}, {"class":"Consumable", "count":"5", "proto":"StimFEN1"}, {"class":"Item", "count":"10000", "proto":"Money"}

实际物品是一把装满子弹的AKS-74U、120发5.45mm子弹、一把苏联战斗刀、10份口粮、5只治疗针、10000卢布的钱。存盘之后切换回游戏，重新进入Otradnoye跑去废屋就可以在柜子内找到这些东西了。

通常来说，当数据多、并发量大的时候，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他数据库)的压力，但不是使用Redis，就不用MySQL。

因为Redis的性能十分优越，可以支持每秒十几万此的读/写操作，并且它还支持持久化、集群部署、分布式、主从同步等，Redis在高并发的场景下数据的安全和一致性，所以它经常用于两个场景：

缓存

经常会被查询，但是不经常被修改或者删除的数据；比如数据字典，业务数据中的热点数据；这样不仅提升查询效率，还可以减少数据库的压力；

经常被查询，实时性要求不高数据，比如网站的最新列表、排行榜之类的数据，只需要定时统计一次，然后把统计结果放到Redis中提供查询（请不要使用select top 10 from xxxx）。

缓存可以方便数据共享，比如我先用电脑网页打开X东，选了两件商品放到购物车里面，再登录手机APP，也是可以看到购物车里面的商品的。

判断数据是否适合缓存到Redis中，可以从几个方面考虑：会经常查询么？命中率如何？写操作多么？数据大小？

我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。

缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。

高速读写

常见的就是计数器，比如一篇文章的阅读量，不可能每一次阅读就在数据库里面update一次。

高并发的场景很适合使用Redis，比如双11秒杀，库存一共就一千件，到了秒杀的时间，通常会在极为短暂的时间内，有数万级的请求达到服务器，如果使用数据库的话，很可能在这一瞬间造成数据库的崩溃，所以通常会使用Redis（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）。

这种高并发的场景，是当请求达到服务器的时候，直接在Redis上读写，请求不会访问到数据库；程序会在合适的时间，比如一千件库存都被秒杀，再将数据批量写到数据库中。

所以通常来说，在必要的时候引入Redis，可以减少MySQL（或其他）数据库的压力，两者不是替代的关系。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

Redis和MySQL的应用场景是不同的。

通常来说，没有说用Redis就不用MySQL的这种情况。

因为Redis是一种非关系型数据库（NoSQL），而MySQL是一种关系型数据库。

和Redis同类的数据库还有MongoDB和Memchache（其实并没有持久化数据）

那关系型数据库现在常用的一般有MySQL，SQL Server，Oracle。

1.存储方式

关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。

2.存储结构

关系型数据库对应的是结构化数据，数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。这一点对数据建模至关重要，虽然预定义结构带来了可靠性和稳定性，但是修改这些数据比较困难。而Nosql数据库基于动态结构，使用与非结构化数据。因为Nosql数据库是动态结构，可以很容易适应数据类型和结构的变化。

3.存储规范

关系型数据库的数据存储为了更高的规范性，把数据分割为最小的关系表以避免重复，获得精简的空间利用。虽然管理起来很清晰，但是单个操作设计到多张表的时候，数据管理就显得有点麻烦。而Nosql数据存储在平面数据集中，数据经常可能会重复。单个数据库很少被分隔开，而是存储成了一个整体，这样整块数据更加便于读写

4.存储扩展

这可能是两者之间最大的区别，关系型数据库是纵向扩展，也就是说想要提高处理能力，要使用速度更快的计算机。因为数据存储在关系表中，操作的性能瓶颈可能涉及到多个表，需要通过提升计算机性能来克服。虽然有很大的扩展空间，但是最终会达到纵向扩展的上限。而Nosql数据库是横向扩展的，它的存储天然就是分布式的，可以通过给资源池添加更多的普通数据库服务器来分担负载。

5.查询方式

关系型数据库通过结构化查询语言来操作数据库（就是我们通常说的SQL）。SQL支持数据库CURD操作的功能非常强大，是业界的标准用法。而Nosql查询以块为单元操作数据，使用的是非结构化查询语言（UnQl），它是没有标准的。关系型数据库表中主键的概念对应Nosql中存储文档的ID。关系型数据库使用预定义优化方式（比如索引）来加快查询操作，而Nosql更简单更精确的数据访问模式。

6.事务

关系型数据库遵循ACID规则（原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)），而Nosql数据库遵循BASE原则（基本可用（Basically Availble）、软/柔性事务（Soft-state ）、最终一致性（Eventual Consistency））。由于关系型数据库的数据强一致性，所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制，并且易于回滚事务。而Nosql数据库是在CAP（一致性、可用性、分区容忍度）中任选两项，因为基于节点的分布式系统中，很难全部满足，所以对事务的支持不是很好，虽然也可以使用事务，但是并不是Nosql的闪光点。

7.性能

关系型数据库为了维护数据的一致性付出了巨大的代价，读写性能比较差。在面对高并发读写性能非常差，面对海量数据的时候效率非常低。而Nosql存储的格式都是key-value类型的，并且存储在内存中，非常容易存储，而且对于数据的 一致性是 弱要求。Nosql无需sql的解析，提高了读写性能。

8.授权方式

大多数的关系型数据库都是付费的并且价格昂贵，成本较大（MySQL是开源的，所以应用的场景最多），而Nosql数据库通常都是开源的。

所以，在实际的应用环境中，我们一般会使用MySQL存储我们的业务过程中的数据，因为这些数据之间的关系比较复杂，我们常常会需要在查询一个表的数据时候，将其他关系表的数据查询出来，例如，查询某个用户的订单，那至少是需要用户表和订单表的数据。

查询某个商品的销售数据，那可能就会需要用户表，订单表，订单明细表，商品表等等。

而在这样的使用场景中，我们使用Redis来存储的话，也就是KeyValue形式存储的话，其实并不能满足我们的需要。

即使Redis的读取效率再高，我们也没法用。

例如商品的库存信息，我们虽然在MySQL中会有这样的字段，但是我们并不想MySQL的数据库被高频的读写，因为使用这样会导致我的商品表或者库存表IO非常高，从而影响整个体统的效率。

所以，对于这样的数据，且有没有什么复杂逻辑关系（就只是隶属于SKU）的数据，我们就可以放在Redis里面，下单直接在Redis中减掉库存，这样，我们的订单的并发能力就能够提高了。

个人觉得应该站出来更正一下，相反的数据量大，更不应该用redis。

为什么？

因为redis是内存型数据库啊，是放在内存里的。

设想一下，假如你的电脑100G的资料，都用redis来存储，那么你需要100G以上的内存！

使用场景

缓存

Redis最明显的用例之一是将其用作缓存。只是保存热数据，或者具有过期的cache。

例如facebook，使用Memcached来作为其会话缓存。

faceboo使用memcached来缓解数据库负，使用超过800台服务器为用户提供超过28 TB的内存。

队列

排行榜/计数

Pub 发布/ Sub订阅

总之，没有见过哪个大公司数据量大了，换掉mysql用redis的。

欢迎关注，解锁更多，同步进步！

题主你错了，不是用redis代替MySQL，而是引入redis来优化。

BAT里越来越多的项目组已经采用了redis+MySQL的架构来开发平台工具。

如题主所说，当数据多的时候，MySQL的查询效率会大打折扣。我们通常默认如果查询的字段包含索引的话，返回是毫秒级别的。但是在实际工作中，我曾经遇到过一张包含10个字段的表，1800万+条数据，当某种场景下，我们不得不根据一个未加索引的字段进行精确查询的时候，单条sql语句的执行时长有时能够达到2min以上，就更别提如果用like这种模糊查询的话，其效率将会多么低下。

我们最开始是希望能够通过增加索引的方式解决，但是面对千万级别的数据量，我们也不敢贸然加索引，因为一旦数据库hang住，期间的所有数据库写入请求都会被放到等待队列中，如果请求是通过http请求发过来的，很有可能导致服务发生分钟级别的超时不响应。

经过一番调研，最终敲定的解决方案是引入redis作为缓存。redis具有运行效率高，数据查询速度快，支持多种存储类型以及事务等优势，我们把经常读取，而不经常改动的数据放入redis中，服务器读取这类数据的时候时候，直接与redis通信，极大的缓解了MySQL的压力。

然而，我在上面也说了，是redis+MySQL结合的方式，而不是替代。原因就是redis虽然读写很快，但是不适合做数据持久层，主要原因是使用redis做数据落盘是要以效率作为代价的，即每隔制定的时间，redis就要去进行数据备份/落盘，这对于单线程的它来说，势必会因“分心”而影响效率，结果得不偿失。

以上就是我的浅见，欢迎各位在下方点赞，留言。

我是苏苏思量，来自BAT的java开发工程师，每天都会分享科技类见闻，欢迎关注我，与我共同进步。

楼主你好，首先纠正下，数据多并不是一定就用Redis，Redis归属于NoSQL数据库中，其特点拥有高性能读写数据速度，主要解决业务效率瓶颈。下面就详细说下Redis的相比MySQL优点。（关于Redis详细了解参见我近期文章：https://www.toutiao/i6543810796214813187/）

读写异常快

Redis非常快，每秒可执行大约10万次的读写速度。

丰富的数据类型

Redis支持丰富的数据类型，有二进制字符串、列表、集合、排序集和散列等等。这使得Redis很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。

原子性

Redis的所有操作都是原子操作，这确保如果两个客户端并发访问，Redis服务器能接收更新的值。

丰富实用工具

Redis是一个多实用工具，可用于多种用例，如：缓存，消息队列(发布/订阅)，通知，key值过期等等。

支持异机主从复制

Redis支持主从复制的配置，它可以实现主服务器的完全拷贝。

以上为开发者青睐Redis的主要几个可取之处。但是，请注意实际生产环境中企业都是结合Redis和MySQL的特定进行不同应用场景的取舍。如缓存——热数据、计数器、消息队列（与ActiveMQ，RocketMQ等工具类似）、位操作（大数据处理）、分布式锁与单线程机制、最新列表（如新闻列表页面最新的新闻列表）以及排行榜等等可以看见Redis大显身手的场景。可是对于严谨的数据准确度和复杂的关系型应用MySQL等关系型数据库依然不可替。

更多技术了解，关注小伍

web应用中一般采用MySQL+Redis的方式，web应用每次先访问Redis，如果没有找到数据，才去访问MySQL。

本质区别

1、mysql：数据放在磁盘 redis：数据放在内存。

2、redis适合放一些频繁使用，比较热的数据，因为是放在内存中，读写速度都非常快，一般会应用在下面一些场景。排行榜、计数器、消息队列推送、好友关注、粉丝。

首先要知道mysql存储在磁盘里，redis存储在内存里，redis既可以用来做持久存储，也可以做缓存，而目前大多数公司的存储都是mysql + redis，mysql作为主存储，redis作为辅助存储被用作缓存，加快访问读取的速度，提高性能。

使用场景区别

1、mysql支持sql查询，可以实现一些关联的查询以及统计；

2、redis对内存要求比较高，在有限的条件下不能把所有数据都放在redis；

3、mysql偏向于存数据，redis偏向于快速取数据，但redis查询复杂的表关系时不如mysql，所以可以把热门的数据放redis，mysql存基本数据。

mysql的运行机制

mysql作为持久化存储的关系型数据库，相对薄弱的地方在于每次请求访问数据库时，都存在着I/O操作，如果反复频繁的访问数据库。第一：会在反复链接数据库上花费大量时间，从而导致运行效率过慢；第二：反复地访问数据库也会导致数据库的负载过高，那么此时缓存的概念就衍生了出来。

Redis持久化

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

如有不同观点，欢迎发表评论。如果喜欢我的回答，欢迎“点赞、分享”。

数据量多少绝对不是选择redis和mysql的准则，因为无论是mysql和redis都可以集群扩展，约束它们的只是硬件(即你有没有那么多钱搭建上千个组成的集群)，我个人觉得数据读取的快慢可能是选择的标准之一，另外工作中往往是两者同是使用，因为mysql存储在硬盘，做持久化存储，而redis存储在内存中做缓存提升效率。

Redis和MySQL的应用场景是不同的。

通常来说，没有说用Redis就不用MySQL的这种情况。

因为Redis是一种非关系型数据库（NoSQL），而MySQL是一种关系型数据库。

和Redis同类的数据库还有MongoDB和Memchache（其实并没有持久化数据）

那关系型数据库现在常用的一般有MySQL，SQL Server，Oracle。

我们先来了解一下关系型数据库和非关系型数据库的区别吧。

存储方式

关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构；

关系型数据库为了维护数据的一致性付出了巨大的代价，读写性能比较差。在面对高并发读写性能非常差，面对海量数据的时候效率非常低。而Nosql存储的格式都是key-value类型的，并且存储在内存中，非常容易存储，而且对于数据的 一致性是 弱要求。Nosql无需sql的解析，提高了读写性能；

所以，在实际的应用环境中，我们一般会使用MySQL存储我们的业务过程中的数据，因为这些数据之间的关系比较复杂，我们常常会需要在查询一个表的数据时候，将其他关系表的数据查询出来，例如，查询某个用户的订单，那至少是需要用户表和订单表的数据。

查询某个商品的销售数据，那可能就会需要用户表，订单表，订单明细表，商品表等等。

而在这样的使用场景中，我们使用Redis来存储的话，也就是KeyValue形式存储的话，其实并不能满足我们的需要。

即使Redis的读取效率再高，我们也没法用。

但，对于某些没有关联少，且需要高频率读写，我们使用Redis就能够很好的提高整个体统的并发能力。

例如商品的库存信息，我们虽然在MySQL中会有这样的字段，但是我们并不想MySQL的数据库被高频的读写，因为使用这样会导致我的商品表或者库存表IO非常高，从而影响整个体统的效率。

所以，对于这样的数据，且有没有什么复杂逻辑关系（就只是隶属于SKU）的数据，我们就可以放在Redis里面，下单直接在Redis中减掉库存，这样，我们的订单的并发能力就能够提高了。

redis是放在内存的~！

没有说不可以，就怕公司架构师、领导、高管有偏见，怕丢数据、不安全，其实技术牛的公司，完全可以不用MySQL

如今，找到一个 好的开源代码编辑器并不难，随便选择一个就可以了。

微软的 VS Code和 GitHub 的Atom是两个最流行的、功能丰富的、类似于 IDE 的代码编辑器，都拥有庞大的用户群和粉丝。

VS Code 和 Atom 现在都属于微软，因为 Atom 的原开发者 GitHub 现在属于微软。这两个都有一个有吸引力的、现代的 UI，有一个漂亮的原生黑暗主题。两个编辑器都使用 Electron作为用户界面。

相似的地方很多，这就是为什么你很容易在它们中间选择时感到迷惑。

如果你不能下定决心，想在 VS Code 和 Atom 之间进行一番比较和选择，这篇文章应该可以帮助你。

VS Code

VS Code是开源的现代编辑器之一。它的用户群爆炸性地增长，因为它具有类似 IDE 的功能，但仍然保持相对较轻的资源占用。

VS Code 是由微软制作的，可用于 Linux、macOS 和 Windows。微软于 2015 年 11 月 18 日在 GitHub上根据 MIT 许可发布了 VS Code 的大部分源代码。

VS Code 的开发者对 Electron 进行了一些奇妙的优化，使其尽可能的轻量级和高效。由于 Electron 应用程序可以在大多数操作系统上运行，Linux、macOS 和 Windows 的用户都可以从这些优化中受益。

在 Linux 上安装 VS Code也相当简单。事实上，它在许多发行版的软件中心都有。

为什么你应该选择 VS Code？ 那些从一开始就想获得接近 IDE 的功能，而又不想摆弄他们的代码编辑器的人，[通常] 会选择 VS Code 。即使是基于 Electron，VS Code 与其他 Electron 应用（如 GitHub 的 Atom）相比，开销也非常小。更多开箱即用的功能，如微软的 IntelliSense 自动补完、Git 集成、Markdown 支持等等。插件可以只用来增加功能、主题和支持新的语言；而这种插件约束确保编辑器的核心在增加新插件后仍保持熟悉。

由微软分发的二进制版本仍然是专有的免费软件。VSCodium建立在 VS Code 的公开源代码之上。然而，关于 VSCodium 的讨论超出了本文的范围，如果你想获得 VS Code 提供的功能，而又没有任何专有元素的话，可以考虑将其作为 VS Code 的一个可行的替代品。

Atom

GitHub 的 Atom是另一个自由开源的代码编辑器，可用于 Linux、macOS 和 Windows。Atom 是一个使用 JavaScript 通过 Electron 制作的桌面应用程序，用于轻松开发软件包。

Atom 的源代码是根据 MIT 许可发布 在 GitHub 上的。由于 Atom 是 GitHub 的产品，因此它嵌入了 Git Control。

Atom 被称为“可魔改的hackable 21 世纪文本编辑器”，因为它可以使用 HTML、CSS 和 JS 完全定制。

像 VS Code 一样，你可以轻松地在其他平台和 Linux 上安装 Atom。

选择 Atom 的理由 Atom 是那些想要一个基础的编辑器，并希望在其上进行开发的人的首选，因为 Atom 的可魔改性质。内置了 Git 和完整的 GitHub 集成；考虑到它是由 GitHub 开发的，这并不令人惊讶。从应用程序中非常容易搜索、安装和升级 Atom 的插件。可用的 Atom 插件是非常可扩展的，甚至可以完全改变编辑器的功能，并最终创造出几乎一个新的编辑器；它确实是“可魔改”的。Atom 的二进制版本和它的源代码是完全开源的（不像 VS Code 的二进制版本包含专有部分+遥测）。你可以 把 Atom 从一个代码编辑器变成 IDE，有更智能的上下文自动完成、代码导航功能、文档格式化等。

总结

Atom 和 VS Code 都是建立在 Electron 之上的。但是微软在 VS Code 上做了更多的优化，使其尽可能的轻量化。

在这一点上，VS Code 就像 Ubuntu，几乎所有的东西都开箱即用。而 Atom 就像 Arch，精简，而极易魔改（可扩展）。

Atom 和 VS Code 在技术上都隶属于微软，最终它们会殊途同归。因此，最好是使用你的社区（网页开发/软件开发）所倾向的编辑器，并铺平前进的道路。也许你最终会选择 Vim！

via: https://itsfoss/visual-studio-code-vs-atom/

作者：Pratham Patel选题：lujun9972译者：wxy校对：wxy

本文由 LCTT原创编译，Linux中国荣誉推出