最近几个月，我一直在开发我的第一款独立游戏《我的博客》，在游戏制作中也算是积累了一些经验与心得，所以，我打算制作一个Godot的中文版教程。

Godot 4 实用视频教程中文版


断断续续的仍在编写游戏中的逻辑代码，一直在缝缝补补中。

## 游戏数据

《我的博客》游戏中有着大量的游戏数据以及剧情任务数据，之前都是写的很随意，随意的把变量放到各个文件的角落，直到我开始考虑如何存档的时候，我才发现我根本无法把这些数据属性统一的保存和加载，这个时候我才想起来需要建立一个系统的游戏数据管理系统。

好吧，建立一个单例文件，然后逐一的把需要存档的变量都搬运过来，没办法，谁让开始写的太随意了，花了几个小时的搬运调试，基本上都固定到一个数据管理器里了。


## 游戏的进度

目前游戏的答题剧情主线任务已经基本确定，还有几个支线任务需要构思和编写，涉及到：服务器和数据安全引发的任务，博客联盟任务，和广告联盟的相关剧情，以及友情链接、留言评论等互动触发的支线任务。嗯还是需要花很多时间的。

## 一定要完成

年底，要加紧进度，最近还想写一些Godot有关的游戏制作教程，一方面B站也荒废了一段时间，999粉丝卡了一个星期了，想突破一下，另一方面也算是深入的学习Godot各方面的系统知识，传授分享更能加深学习的效果，以便更加熟练的操作Godot游戏引擎。


断断续续的仍在编写游戏中的逻辑代码，一直在缝缝补补中。

Godot游戏开发《我的博客》记录14-游戏的制作仍在继续


Godot4 学习资源教程推荐，都是自己收藏并学习过的，少走弯路加速你的游戏进度。


## 教程

Godot Engine 4.5 简体中文文档
https://docs.godotengine.org/zh-cn/4.x/



【精品熟肉】想在2024年做游戏？跟着Brackeys来学Godot引擎吧！
https://www.bilibili.com/video/BV17Z421J7uF

转载自YouTube的Brackeys频道：https://www.youtube.com/watch?v=LOhfqjmasi0

项目所需素材：https://brackeysgames.itch.io/brackeys-platformer-bundle


点评：入门Godot绝对不错的一个教程，简单实用，几乎囊括了入门的所有知识点。


做出你的第一个Godot 2D游戏！
https://merxon22.github.io/GodotArchive/zh/posts/beginner_2d/

点评：码客二十二，我就是看他的教程入门的Godot，简单，通俗易懂的全中文视频教程


一些Godot教程的总结
https://ai.feishu.cn/wiki/CQMPwbWtyikKgFkZSmycuWQNnJe?fromScene=spaceOverview

点评：很用心的笔记类型教程，适合看视频犯困的朋友。


游戏编程模式
https://gameprogrammingpatterns.com/contents.html

点评：深入游戏的高级编程之地，了解游戏编程模式



godot2D地图编辑教程：瓦片地图 平台 物理吊桥 脚本化生成
https://www.bilibili.com/video/BV1np3dzNEAw

点评：对于万片地图的应用讲解的很详细，UP主很有才华。

【中文语音】Godot4终极入门教程
https://www.bilibili.com/BV1pu4y1b7p6

点评：搬运油管的教程，质量不错，适合入门。


Godot 4 ARPG游戏教程
https://www.bilibili.com/BV1AJuozuEbq

点评：搬运油管的教程，质量不错，循序渐进，内容充实比较多。


【中文语音】在Godot4中创建一个有限状态机（FSM）

https://www.bilibili.com/BV1xy4y1c72y

## 资源

一些游戏素材资源音效下载站点：

https://kenney.nl/


https://opengameart.org/


https://itch.io/game-assets


https://pixlab24.com/



## 开源

这是一份不同开源视频游戏和商业视频游戏开源重制版的列表。

https://github.com/bobeff/open-source-games


Godot提供的一些案例

https://godotengine.org/asset-library/asset




Godot4 学习资源教程推荐，都是自己收藏并学习过的，少走弯路加速你的游戏进度。

Godot4 学习资源教程推荐


内容来自千问AI整理，感觉还不错，分享一下。
在 Godot 中，节点类提供了大量实用的内置方法。以下是常用的节点方法分类：

## 1. 节点管理方法

```gdscript
# 添加和移除节点
add_child(node)
remove_child(node)
queue_free()              # 安全删除节点
free()                    # 立即删除（不推荐）

# 节点查找
get_node(path)            # 根据路径获取节点
has_node(path)            # 检查节点是否存在
get_parent()              # 获取父节点
get_children()            # 获取所有子节点

# 节点遍历
get_child(index)
get_child_count()
find_child(name, recursive=true, owned=false)
```

## 2. 信号相关方法

```gdscript
# 连接和断开信号
connect("signal_name", callable)
disconnect("signal_name", callable)
is_connected("signal_name", callable)

# 自定义信号
signal my_signal(param1, param2)

# 发射信号
emit_signal("my_signal", param1, param2)
```

## 3. 节点生命周期方法

```gdscript
func _ready():            # 节点及其子节点都已添加到场景树
func _enter_tree():       # 节点进入场景树
func _exit_tree():        # 节点离开场景树
func _process(delta):     # 每帧调用（非物理）
func _physics_process(delta):  # 每物理帧调用
```

## 4. 场景树相关方法

```gdscript
# 场景树操作
get_tree()                # 获取场景树
get_viewport()            # 获取视口
is_inside_tree()          # 检查是否在场景树中
is_processing()           # 检查是否在处理
is_physics_processing()   # 检查是否在物理处理

# 场景切换
get_tree().change_scene_to_file("res://scene.tscn")
get_tree().change_scene_to_packed(packed_scene)
get_tree().reload_current_scene()
```

## 5. 变量和属性相关

```gdscript
# 属性设置
set("property_name", value)
get("property_name")
has_meta("meta_name")     # 检查元数据
set_meta("meta_name", value)
get_meta("meta_name")

# 变量检查
has_method("method_name")
call("method_name", args...)
```

## 6. 节点可见性和状态

```gdscript
# 可见性控制
show()
hide()
set_visible(bool)
is_visible_in_tree()      # 检查是否在场景中可见

# 处理控制
set_process(true/false)
set_physics_process(true/false)
set_process_input(true/false)
```

## 7. 输入处理方法

```gdscript
# 输入相关
func _input(event):       # 处理所有输入
func _gui_input(event):   # 处理GUI输入
func _unhandled_input(event):  # 处理未处理的输入

# 输入状态检查
Input.is_action_pressed("action_name")
Input.is_key_pressed(KEY_SPACE)
Input.get_mouse_position()
```

## 8. 节点坐标和变换

```gdscript
# 位置变换
global_position             # 全局位置
position                    # 本地位置
rotation                    # 旋转角度
scale                       # 缩放

# 坐标转换
to_global(local_position)
to_local(global_position)
global_transform            # 全局变换矩阵
transform                   # 本地变换矩阵
```

## 9. 2D/3D 特定方法

### 2D 节点
```gdscript
# 2D 变换
global_position
position
rotation
scale
rotation_degrees

# 2D 工具
look_at(target_position)
rotate(angle)
move_local_x(distance)
move_local_y(distance)
```

### 3D 节点
```gdscript
# 3D 变换
global_transform
transform
rotation
scale
translation

# 3D 工具
look_at(target, up=Vector3.UP)
rotate_x(angle), rotate_y(angle), rotate_z(angle)
```

## 10. 调试和工具方法

```gdscript
# 调试输出
print("message")
push_error("error message")
push_warning("warning message")

# 断点调试
assert(condition, "error message")
```

## 11. 资源和文件操作

```gdscript
# 资源加载
preload("res://path.tscn")     # 编译时加载
load("res://path.tscn")        # 运行时加载

# 场景实例化
var scene_instance = PackedScene.new()
scene_instance.instantiate()
```

## 12. 计时器和延迟调用

```gdscript
# 延迟调用
call_deferred("method_name", args...)
await get_tree().create_timer(1.0).timeout  # 等待1秒

# 计时器节点
var timer = Timer.new()
timer.timeout.connect(callback)
add_child(timer)
timer.start(duration)
```

## 13. 组和标签方法

```gdscript
# 节点组操作
add_to_group("group_name")
remove_from_group("group_name")
is_in_group("group_name")

# 遍历组内节点
for node in get_tree().get_nodes_in_group("enemies"):
    node.take_damage(10)
```

## 14. 常用的全局方法

```gdscript
# 随机数
randf()                    # 0.0 到 1.0 的随机浮点数
randi()                    # 随机整数
rand_range(min, max)       # 指定范围的随机数

# 数学函数
lerp(from, to, weight)     # 线性插值
clamp(value, min, max)     # 限制值范围
stepify(value, step)       # 步进化值

# 字符串和转换
str(variable)              # 转换为字符串
int(string)                # 转换为整数
float(string)              # 转换为浮点数
```

## 15. 实用的组合方法

```gdscript
# 等待节点
await node.ready            # 等待节点就绪
await node.tree_exited      # 等待节点离开场景树

# 安全的节点操作
if has_node("path"):
    var node = get_node("path")
    # 安全操作

# 批量操作
for child in get_children():
    if child is Node2D:
        child.visible = false
```

这些方法是 Godot 开发中最常用的节点操作方法，掌握它们可以大大提高开发效率。根据具体需求选择合适的方法，可以让代码更加简洁和高效。


在 Godot 中，节点类提供了大量实用的内置方法。以下是常用的节点方法分类，内容来自千问AI整理，感觉还不错，分享一下。

 Godot4中节点类常用的内置方法

## 为什么要使用状态机？

在游戏开发中，角色的行为（如站立、行走、跳跃、攻击）通常需要复杂的逻辑来控制。如果不使用状态机，代码会充斥着大量的 if/else 或 match 语句，导致代码难以阅读、维护和扩展，这就是所谓的“意大利面条式代码”。例如下边的代码：

    # constants.gd (假设我们有一个全局脚本或内部枚举来定义状态)
    enum PlayerState {
        IDLE,
        MOVE,
        JUMP,
        ATTACK
    }

    # Player.gd 脚本 (所有逻辑集中于此)
    extends CharacterBody2D

    # 运动和重力常量...
    const SPEED = 300.0
    const JUMP_VELOCITY = -500.0
    var gravity = ProjectSettings.get_setting("physics/2d/default_gravity")

    # 追踪当前状态的核心变量
    var current_state: int = PlayerState.IDLE
    # 追踪攻击是否完成
    var is_attack_finished: bool = true
    # 追踪动画播放器
    @onready var animated_sprite = $AnimatedSprite2D 

    func _physics_process(delta):
        # 1. 应用重力 (这部分是通用的，但需要注意JUMP状态下的特殊处理)
        if not is_on_floor():
            velocity.y += gravity * delta

        # 2. 处理攻击完成后的状态清理 (相当于 Attack.gd 的 _exit 逻辑)
        if current_state == PlayerState.ATTACK and is_attack_finished:
            # 攻击完成后，根据是否还在移动来决定回到 IDLE 还是 MOVE
            var input_direction = Input.get_axis("move_left", "move_right")
            if input_direction != 0:
                current_state = PlayerState.MOVE
                # 播放动画 "Move" (重复的动画逻辑)
            else:
                current_state = PlayerState.IDLE
                # 播放动画 "Idle" (重复的动画逻辑)
            is_attack_finished = false # 重置，避免频繁切换 (这里逻辑可能更复杂)
            
        # --- 主状态判断逻辑 (巨大的 if/else 块) ---
        
        # === IDLE 状态逻辑 (对应 Idle.gd) ===
        if current_state == PlayerState.IDLE:
            # 动画播放逻辑 (相当于 _enter)
            animated_sprite.play("Idle")
            
            # 检查转换条件
            if Input.is_action_just_pressed("attack"):
                current_state = PlayerState.ATTACK
                # 转换后的 _enter 逻辑
                animated_sprite.play("Attack")
                is_attack_finished = false
                
            elif Input.is_action_just_pressed("jump") and is_on_floor():
                current_state = PlayerState.JUMP
                # 转换后的 _enter 逻辑
                animated_sprite.play("Jump")
                velocity.y = JUMP_VELOCITY
                
            elif Input.get_axis("move_left", "move_right") != 0:
                current_state = PlayerState.MOVE
                # 转换后的 _enter 逻辑
                animated_sprite.play("Move")

        # === MOVE 状态逻辑 (对应 Move.gd) ===
        elif current_state == PlayerState.MOVE:
            # 动画播放逻辑 (相当于 _enter)
            animated_sprite.play("Move")
            
            # 1. 移动处理 (_physics_update)
            var direction = Input.get_axis("move_left", "move_right")
            velocity.x = direction * SPEED
            
            # 2. 检查转换条件
            if Input.is_action_just_pressed("attack"):
                current_state = PlayerState.ATTACK
                animated_sprite.play("Attack")
                is_attack_finished = false
                
            elif Input.is_action_just_pressed("jump") and is_on_floor():
                current_state = PlayerState.JUMP
                animated_sprite.play("Jump")
                velocity.y = JUMP_VELOCITY
                
            elif direction == 0:
                current_state = PlayerState.IDLE
                # 转换后的 _enter 逻辑 (可以省略动画播放，因为 IDLE 状态会处理)

        # === JUMP 状态逻辑 (对应 Jump.gd) ===
        elif current_state == PlayerState.JUMP:
            # JUMP 状态下的移动处理
            var direction = Input.get_axis("move_left", "move_right")
            velocity.x = direction * SPEED * 0.7 # 跳跃时速度减慢
            
            # 检查转换条件 (落地)
            if is_on_floor():
                var input_direction = Input.get_axis("move_left", "move_right")
                if input_direction != 0:
                    current_state = PlayerState.MOVE
                else:
                    current_state = PlayerState.IDLE
                # JUMP 状态的 _exit 逻辑被省略了，因为它和新状态的 _enter 混合在了一起
                
            # 检查转换条件 (空中攻击)
            if Input.is_action_just_pressed("attack"):
                current_state = PlayerState.ATTACK
                # ... (重复的 Attack 转换逻辑)

        # === ATTACK 状态逻辑 (对应 Attack.gd) ===
        elif current_state == PlayerState.ATTACK:
            # ATTACK 状态下不能接收移动或跳跃输入
            velocity.x = 0
            
            # 攻击动画的自动完成逻辑 (需要一个信号或计时器来设置 is_attack_finished = true)
            # 假设这里有一个处理攻击动画进度的逻辑
            pass # 等待 is_attack_finished 变为 true

        # 3. 最终移动
        move_and_slide()

有限状态机（FSM）提供了一种优雅的解决方案。它将角色的每一个行为定义为一个状态（State），并清晰地定义了状态之间的转换（Transition）规则。本教程将基于 godotfsmtest 项目的代码结构，向您展示如何在 Godot 4.4 中实现一个结构清晰、基于类的 FSM。

## 项目结构

![项目结构](https://www.suiyan.cc/assets/images/2025/QQ20251114-110111.png)

前期准备：Godot4.4 以上的版本，熟悉 GDScript的基本语法、类、类的继承和信号量（Signal）的使用，熟悉场景中的角色添加以及动画的添加，如果这些内容有不熟悉的，查看下边的代码可能会有些迷糊。

状态机的含义简单来说就控制动画来展示是角色所处的状态，例如空闲、行走、跳跃和攻击等。场景中的`AnimatedSprite2D`定义了角色的状态动画。

![角色的状态动画](https://www.suiyan.cc/assets/images/2025/QQ20251114-111006.png)

## 状态机类 State

创建State基类，后续的状态都会继承这个State，通过状态机和信号量来管理当前的状态，例如状态之间的切换。

代码如下：

    # State.gd
    class_name State 
    extends Node

    # 信号：用于通知状态机进行状态转换
    signal transitioned(state_name, new_state_name)

    # 对拥有这个状态机的角色的引用（例如：Player）
    var actor: CharacterBody2D
    var anim_sprite: AnimatedSprite2D

    # 1. 状态被进入时调用
    func enter() -> void:
        pass

    # 2. 状态被退出时调用
    func exit() -> void:
        pass

    # 3. 在 _process (每帧) 中调用
    func update(delta: float) -> void:
        pass

    # 4. 在 _physics_process (物理帧) 中调用
    func physics_update(delta: float) -> void:
        pass



### 状态机类

 State : 状态机基类 

### 方法

![方法](https://www.suiyan.cc/assets/images/2025/QQ20251116-104744.png)

### 信号

![信号](https://www.suiyan.cc/assets/images/2025/QQ20251116-104744.png)

## 状态机管理器

状态机管理器负责管理当前状态、存储所有状态，以及处理状态间的转换。代码如下：

    # StateMachine.gd
    class_name StateMachine extends Node

    # 导出变量：允许在编辑器中设置初始状态
    @export var initial_state_name: State
    var states: Dictionary = {}
    @onready var current_state: State = null
    @export var actor: CharacterBody2D # 引用拥有者
    @export var anim_sprite: AnimatedSprite2D #引用动画

    func _ready() -> void:
        # 收集所有子节点（即所有具体状态）
        for child in get_children():
            if child is State:
                var state = child as State
                child.anim_sprite = self.anim_sprite
                # 将状态添加到字典中，键为节点名
                states[state.name] = state
                state.actor = actor # 传递角色引用
                state.transitioned.connect(on_state_transition)

        # 检查并进入初始状态
        if initial_state_name:
            change_state(initial_state_name)
        else:
            printerr("Error: Initial state not set or not found.")

    # 转换状态的核心函数
    func change_state(new_state: State) -> void:
        # 1. 退出旧状态
        if current_state:
            current_state.exit()  
        # 2. 设置新状态
        current_state = new_state
        # 3. 进入新状态
        current_state.enter()

    # 信号处理函数
    func on_state_transition(state_name: String, new_state_name: String) -> void:
        # 确保是当前状态发出的转换请求
        if current_state and current_state.name == state_name:
            change_state(states[new_state_name])

    func _process(delta: float) -> void:
        if current_state:
            current_state.update(delta)

    func _physics_process(delta: float) -> void:
        if current_state:
            current_state.physics_update(delta)


## 在角色中集成状态机管理器

    # Player.gd (附加到 CharacterBody2D 节点)

    class_name Player 
    extends CharacterBody2D

    # 引用状态机节点
    @onready var state_machine: StateMachine = $StateMachine
    @onready var anim_sprite: AnimatedSprite2D = $AnimatedSprite2D
    func _ready() -> void:
        # 将自身的引用传递给状态机，以便状态可以控制角色
        state_machine.actor = self
        state_machine._ready() # 确保状态机初始化
        
    # 注意：现在 _physics_process 由状态机和当前状态来管理，
    # Player 脚本本身不再直接处理复杂的运动逻辑。
    func _physics_process(delta: float) -> void:
        state_machine._physics_process(delta)

    func _process(delta: float) -> void:
        state_machine._process(delta)


绑定状态机管理器，以及动画节点等相关的节点。


## 创建具体的状态

Idle 角色的空闲状态，

    # Idle.gd (附加到 Idle 节点, 继承 State.gd)

    class_name Idle 
    extends State

    #新增：定义跳跃速度常量
    const JUMP_VELOCITY = -450.0 # 负值表示向上运动
    # Godot 4 默认重力加速度（方便计算）
    var gravity = ProjectSettings.get_setting("physics/2d/default_gravity")

    func enter() -> void:
        # 在进入空闲状态时，确保移动速度为0
        actor.velocity.x = 0
        # 播放 Idle 动画 (假设 actor 有一个 AnimationPlayer 节点)
        anim_sprite.play("idle")

    func physics_update(delta: float) -> void:
        var direction = Input.get_axis("move_left", "move_right")
        # 1. 如果有移动输入，转换到 Move 状态
        if direction != 0:
            transitioned.emit(name, "Move")
            return
            
        # 2. 如果有跳跃输入，转换到 Jump 状态
        if Input.is_action_just_pressed("jump"):
            
            # ⚠️ 关键修正：在转换之前，赋予角色向上的速度
            actor.velocity.y = JUMP_VELOCITY 
            
            transitioned.emit(name, "Jump")
            return
        # 3. 攻击
        if Input.is_action_just_pressed("attack"):
            transitioned.emit(name,"Attack")
            return  
        # 3. 在 Idle 状态下保持重力和移动
        # 仅施加重力（如果角色站在一个活动的平台上，或者检测到不再贴地）
        if not actor.is_on_floor():
            # 这里应该转换到 Fall 状态，但如果只是施加重力，确保使用正确的重力值
            actor.velocity.y += gravity * delta # 使用常量 gravity 更准确
            # 注意：如果角色还在 Idle 状态且 velocity.y > 0，它应该转换到 Fall 状态  
        actor.move_and_slide()

enter()函数中触发当前状态的相关的动画、声音等。

在转态进行时进行判断，transitioned.emit(name, "Jump")发出信号进行状态的切换。

## 总结

通过 FSM，我们成功地将复杂的角色逻辑解耦：

Player.gd 只需要知道它有一个状态机。
StateMachine.gd 负责切换状态。
Idle.gd, Move.gd 等状态脚本只负责各自状态下的具体行为和转换检查。

完整的案例代码仓库：

[案例代码仓库 github](https://github.com/bosichong/godotfsmtest)


[案例代码仓库 国内镜像gitee](https://gitee.com/J_Sky/godotfsmtest)

在游戏开发中，角色的行为（如站立、行走、跳跃、攻击）通常需要复杂的逻辑来控制。如果不使用状态机，代码会充斥着大量的 if/else 或 match 语句，导致代码难以阅读、维护和扩展，这就是所谓的“意大利面条式代码”。有限状态机（FSM）提供了一种优雅的解决方案。它将角色的每一个行为定义为一个状态（...

在 Godot 4.4 中构建灵活的有限状态机 (FSM)


关于游戏的剧本编写，在看过了《游戏剧本怎么写》这本书之后有了一定的启发，虽然之前没接触过剧本的编写，但是一些主线任务的编写也算是有了一些剧情的大概，当务之急是游戏整体进度的推进和完成度。

## 开始游戏

对于游戏的启动，有一个启动画面，我利用现有的素材拼凑了一个logo，哈哈哈，自我感觉还是不错，先将就着用，有了好的想法，我在更换，效果如下：

![游戏启动画面](https://www.suiyan.cc/assets/images/2025/启动画面.png)

进阶这就是一些简单的剧情和过场动画，之后就会进入到主场景了，万事开头难，总觉得游戏的开始这段很重要，生怕玩家打开了之后就关闭了，所以，我尽力做的还一些吧。

## 剧情的推进

之后就是剧情以及游戏进度的推进了。昨晚追了一下网飞的剧集《弥留之国的爱丽丝》，怎么呢说呢，我愿称之为日版的《鱿鱼游戏》。看完第一季，我就在思考一个问题，对于目前我制作的这款游戏，我现在站在什么位置了？忽然觉得自己即是玩家又是游戏的设计者，这明显很矛盾，因为这样我很难把握这个游戏的设计初衷，我觉得我还得更多的站在游戏设计者的角度去考虑这个游戏的设计。
后续的剧情，虽然在脑海里有了一定的构思，但是明显感觉很乱，毕竟，我没有经历过太多的博客撰写与维护的经历，以我个人对近20年的独立博客的理解，完全不够撑起这个游戏的故事情节，所以，我需要一些更多的有关独立博客运营、发展中遇到的典型事件，这需要去独立博客中挖掘了，AI能提供一些大纲，但是如果游戏中存在一些情节和剧情，如果不够真实，玩家就无法代入剧情，也就是很假的感觉吧。就像是我模拟以为很棒的博主，他的博客访问量达到了很高，可以说几乎利用独立博客的流量实现了财富自由，但是我本身并没有经历过，我只能靠自己瞎编，就像一个穷人无法理解有钱人的生活一样。

## 感触

第一次写游戏，一个比较大一点的独立游戏，感受了很多独立游戏开发者的心酸与苦痛，感受到了那种煎熬和折磨。以前总以为，不就是做个游戏吗，大脑里构思一下，就以为完成了游戏的全部。或许只有经历过的人才知道，独立游戏制作者的在开发过程中的复杂感受吧，质疑、怀疑、矛盾、失望、沮丧、自卑、无助、感觉所有人间的负面情绪都要遭一遍才算完整的独立游戏制作过程。希望每个独立游戏开发者都能坚持到最后，不放弃，加油！


关于游戏的剧本编写，在看过了《游戏剧本怎么写》这本书之后有了一定的启发，虽然之前没接触过剧本的编写，但是一些主线任务的编写也算是有了一些剧情的大概，当务之急是游戏整体进度的推进和完成度。

Godot游戏开发《我的博客》记录13-完成了游戏的启动与过场


上个星期，重写了游戏中的技能升级的方法，改用自己编写的任务系统来触发技能升级，优化了代码和任务的触发，虽然花了些时间，但也是很值得的，但是同时也陷入了整个游戏的剧本编写的深坑。


## 何时应该优化代码？

对于复杂的系统编写，我们不可能最开始的时候就会使用最优化的代码编写，有的时候我们一路if else + 循环遍历写到最后，感觉还是很不错的，不管什么优雅和设计模式，那个时候我们只要实现自己的想法。随着代码量的逐渐增多，有些代码的不断重复使用，遍历已经变得模糊难以理解的时候，这个时候就可以考虑开始优化代码了，不然，继续写下去，无法理解代码的含义，大量重复代码堆积如山，会对后期的编写带来极大的困难。

优化代码，封装代码，采用适合的设计模式，此时就应该考虑这些了，并不见得非得要优化的十分优雅追求极限，适可为止就好，不要钻牛角尖，一切为了最终的实现即可，性能优化对于小型的项目来说基本没什么需要做的，我觉得大多数人自己写的项目对于现代的计算机都是不必在乎性能的。

## 剧本怎么写？

卡在剧情上有一段时间了，所以一遍优化代码一边在想如何编写这个游戏的剧本，后来，发现自己根本没有这方面的经验，索性在微信读书中搜索了一些相关书籍，这里推荐一本小日子的书《游戏剧本怎么写》，目前看了两天，已经看了大半了，对于剧本的编写有了一些眉目，脑海里也有了一些想法。

书中介绍了剧本的编写的要点，例如书中提到剧本编写的核心要点：序破急（类似中文：起承转合），其含义就是说，一个好的故事或是剧本需要有三个部分：序是开端，破是高潮之前的部分，急是高潮和结局。继续研读，了解到剧本的几个要素：主主角、世界，以及剧本的结构等专业知识以及相互之间的关系。

原来以为游戏的剧本会在做游戏的时候信手捏来，以为可以游刃有余，结果实际写起来是连滚带爬啊！哈哈哈。


## 专注先写出游戏的剧本

其实游戏做到现在，我发现我只做出了游戏的世界，以及这个博客世界中一个博主运营博客的模拟，但是要想让这个游戏的内容变得丰满，还需要很多的事件与情节来把整个剧情丰富起来。所以当务之急是先把剧本搞起，虽然没搞过，但是看看书也学到了一些几本知识和技巧，照猫画虎吧。


上个星期，重写了游戏中的技能升级的方法，改用自己编写的任务系统来触发技能升级，优化了代码和任务的触发，虽然花了些时间，但也是很值得的，但是同时也陷入了整个游戏的剧本编写的深坑。

Godot游戏开发《我的博客》记录12-游戏剧本怎么写？


![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mybloggame1018_02.jpg)

![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mybloggame1018.jpg)


这几天搭建好了里程碑成就系统，然后就开始着手编写相应的成就任务了，粗略的算了下，大约会有百十个左右的成就任务。


## 博客的里程碑

根据目前现有的游戏情节以及游戏中的各种属性，可以编写很多成就里程碑。想想现实中的博客，我们每次达成一些成就的时候，也会小小的兴奋一下。

每个博客都会经历一些相同的经历，每个博客也会自己独立的经历，有些轻飘飘的随风而去，有些则记忆如新刻骨铭心。

这些年，我仍记得那年使用Django写的博客有漏洞，整个服务器的磁盘被写满了黄赌的广告，竟然过了好长时间才发现。也清楚的记得博客程序重构编写的艰辛，或许在AI时代，人们再也无法体会那种没有辅助的编写代码的折磨了。

## 主线

这几天一直在脑海里不停地构思游戏的主线剧情，但是没什么太多的新意，感觉普通人的博客就是一个平平淡淡的小河，静静的流向互联网的大海，根本没有啥波澜。
或许普通人的一生也不过如此，但是，每个人总有自己高光的时刻，或许只是时间太短，匆匆而过。

一条曲折令人振奋的剧情确实不好创作，嗯，毕竟文学创作不是我的强项，或许我会借助AI，但是AI有时也差强人意。

## 期望

每次记录之后，我都要为自己加油打气，生怕自己某天放弃了这个游戏的制作，目前来说这个游戏的进度已经过半，我暂时还没有放弃的意愿，当然，我希望自己也不会有这种想法，加油！自己。

这几天搭建好了里程碑成就系统，然后就开始着手编写相应的成就任务了，粗略的算了下，大约会有百十个左右的成就任务。

Godot游戏开发《我的博客》记录11-里程碑与成就任务的持续开发


随着代码编写的推进，终于进入到了任务和事件的编写，感觉绕了一大圈又回到了起点。我想起了我创建这个游戏的初衷：

>这是一个名字暂定为「我的博客」模拟养成游戏，游戏的画面风格暂定为2D主场景，游戏的大体内容：玩家是一个博主，在2000年的时候你会创建一个自己的独立博客，通过不断地学习和持续的输出，持之以恒的维护与运营，终于若干年后在博客届混出个名堂，通过流量换得了收入与名誉，并且在运营的过程中会遇到很多突发事件，这些突发事件会给你带来一些意想不到的结果。随着游戏不断地推进，你会通过学习新的技能来提高自己的创作能力，通过社交、seo、优化美化博客等手段来提高网站的知名度和访问量，解锁不同的成就。直到游戏运营到2025年游戏结束，整个游戏会因为你不同的运营方式和学习方式产生不同结果和获得不同成就，给足玩家满满充实的游戏快感。

[Godot游戏开发《我的博客》记录01](https://www.suiyan.cc/blog/20250724005122)

## 如何开始

这几天我一直在思考，这个游戏如何开始，已经有了几个游戏开场的构思，但是都不够「完美」，或许这世界上本身就不存在完美，我们初创的博客完美吗？我们一路走来，不断的完善维护以及升级我们的博客，改变我们的博客也在不断的改变着我们的自己。有时候我在想，当年我刚刚搭建博客的时候就是一个小白而已，我的想法就是想有一个网址，能链接到我的博客，我写的东西能被全世界所看到。

## 独立博客的历史

关于独立博客的发展历史大多都和互联网捆绑，我AI了一下，整理了一些相关年份的大事件，但是，总感觉还是不够很多，而且有些大事并没有提及，互联网对于个人独立博客的记载少之又少，也许我只能多多的浏览那些老博客，或许能有些收获。

我希望随着游戏中时间的推进，玩家能感受到身处那些历史年份中创作博客的体验，想法很好，实现起来还是需要挑挑拣拣，每个人对每个时代的感受不一样，三观也是重要的情感因素，一个能符合大众玩家胃口的游戏时间线和与之对应的事件就显得尤为重要了。

我一直在整理这些博客相关的重大事件，不如说是在回忆那些年走过的路。

## 关于代码的重构

之前编写这个游戏的框架事，写的比较随意，根本没有想那么多，就是一通写，if else + 遍历搞定了，25年时间博客运营的模拟，但是当我开始编写任务事件的时候，我发现，好多的任务操作是重复的，我不可能每个任务写一堆方法函数，所以，最近又花了一个国庆的时间（大约每天一小时），写了一个基于事件驱动的任务系统，这样我就可以根绝事件的发生的基本规律配合配置文件来编写相关的剧情任务了，虽然编写任务系统花了些时间，但是也是为了方便日后编写大量的任务节省开支吧。

## 或许你可以帮助我

如果你有幸浏览这个帖子，并且到了这个位置，能回答几个简单的问题吗？算是帮助我写完这个游戏。

请回答：

1. 你为什么创建了你的博客？
2. 在运营打理博客的这些年里，有哪些让你难忘的事情？
3. 对于未来，你的博客还会运行下去吗？ta的意义有事什么？

感谢各位！

随着代码编写的推进，终于进入到了任务和事件的编写，感觉绕了一大圈又回到了起点。我想起了我创建这个游戏的初衷。

Godot游戏开发《我的博客》记录10-关于游戏的主线任务的思考：独立博客的终极意义


这几天终于把游戏内主要的几个场景UI以及功能的代码都写完了，目前来说，游戏可以运行直到结束，除了没有剧情和任务外，一个博客的日常操作基本模拟的差不多了。


当前游戏的简单预览动态截图：

![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mybloggame.gif)


## 复盘

《我的博客》是一个模拟个人独立博客运营的小游戏，游戏通过一个独立博主在2000-2025年，利用25年的时间摸爬滚打的在博客这个江湖中混成了一个响当当的大佬，赚的荣誉与票子。

以下是回忆，也是为了之后的主线剧情和随机任务的创作做准备。

当前游戏主要属性：

1. 博主相关属性：等级段位，相关技能包括：写作、技术、文学、编程、绘画等，这些以数值来展示，金钱属性。
2. 博客属性:访问量统计，rss订阅，文章收藏数，广告联盟的收入，博客联盟相关，主机域名相关，投资理财.
3. 事件线：2000-2025的时间线。

后续会围绕着这些属性来进行主线和支线、随机事件的触发，会加入一个金字塔类型的成就系统。

## 难点

目前来说，对与主线的任务我没有一个具体的构思，虽然有些想法，但不够具体没有细节，还需要在仔细的打磨一下，这里就是我们大家都在思考而且每天都在做的事情，我们搞独立博客为了什么？

或许，我会把这些内容投喂给AI，可以获得一些参考，但是我更洗完自己多思考，使这个游戏有个好的开端和结局。


## 未来的进度

游戏中的主线、随机事件以及成就系统，这三个完成之后，游戏中的所有代码的编写基本上就完成了，我当然希望越快越好，好在现在有AI加持，一些繁琐的代码编写可以交给AI来处理，还有就是在组件的使用以及BUG处理上,使用AI的使用节约很多时间。

我当然期待着寒假不会跳票，把这个游戏发布出来。佛祖保佑。

这几天终于把游戏内主要的几个场景UI以及功能的代码都写完了，目前来说，游戏可以运行直到结束，除了没有剧情和任务外，一个博客的日常操作基本模拟的差不多了。

Godot游戏开发《我的博客》记录09-完成了游戏中所有重要的场景模拟代码


几天前，突然收到了一封来自博客文章评论的邮件提示，内容是：「这个有些期待啊，什么时候好啊？到时候我也想玩一下」，来自网友xpp9的评论。
这是开发这款游戏以来第一位有意愿想玩它的玩家。因为虽然我在博客里记录了游戏制作的过程，但是游戏的具体内容我并没有发布，能有人期待也算是超出了我的意料。

![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/Snipaste_2025-09-20_08-35-20.jpg)


## 精简——不忘初心

在游戏设计开发的最初，我并没有想加入金融系统，后来考虑到可玩性以及游戏中货币的消费需求，我开始考虑加入金融系统。但是，当时我考虑添加的时机是在又完成后的第一个版本添加。
这几天不知道怎么想的非常想提前添加，但是，如果现在几添加金融系统会大大影响开发的进度，会添加相关的很多内容。所以，我添加了游戏中的银行的简单功能之后考虑，暂停金融相关的内容开发，继续回到游戏的主要内容设计与开发中。
我需要进度，需要一个完整的游戏展现出来，所以不忘初心，按着初期的计划才是最重要的。

## 唯手熟尔

使用Godot4编写游戏，有一段时间了，最开始的时候，照着官方的教程案例写，都不能真正的理解代码含义，后来，一直写一直学，最近终于算是入门了Godot的游戏开发了。至少能理解Godot游戏开发中的一些基本概念，比如节点、信号、槽函数、场景、资源等。
而且配合着AI编写代码，也算是有些速度了。大模型不但帮我编写代码，还帮我解决了很多问题。尤其是一些复杂的UI界面的设计与实现，大模型都能很好的结合数据帮我编写代码。

## 后续

继续还有一些游戏内容的代码编写，但是游戏主代码的编写已经进入了后半段了，我会继续努力保持进度，尽快完成游戏的开发，完成后续的场景绘制等UI的设计与实现。

几天前，突然收到了一封来自博客文章评论的邮件提示，内容是：「这个有些期待啊，什么时候好啊？到时候我也想玩一下」，来自网友xpp9的评论。 这是开发这款游戏以来第一位有意愿想玩它的玩家。因为虽然我在博客里记录了游戏制作的过程，但是游戏的具体内容我并没有发布，能有人期待也算是超出了我的意料。

Godot游戏开发《我的博客》记录08-第一个有意愿想玩这款游戏的玩家


断断续续的写了10天的代码，终于完成了游戏中博客联盟的模拟，博客联盟的编写暂时告一段落，愿望是美好的，现实是残酷的，复盘一下最近的游戏开发进度，规划一下未来的游戏开发方向。


## 博客江湖

游戏中的联盟我暂时起名为《博客江湖》，联盟的功能我剪了又剪，为了推进游戏开发的进度，不得已挥舞大刀砍掉了很多的想法，目前只保留了博客的排行（根据博客的等级段位），以及博客的捐赠排行和记录。效果如下：

![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mg_2025-09-10_08-01-05.jpg)

![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mg_2025-09-10_08-01-22.jpg)

![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mg_2025-09-10_08-01-37.jpg)

后续可以添加一些联盟相关的游戏事件，我觉得运营博客的或多或少的都会接触一些博客聚合的联盟类型网站，虽然联盟带来的流量很少，但是质量还是不错的，在资源困乏、流量稀疏的年代，苍蝇腿也是肉啊。

## 后续的开发计划

鼓捣好了游戏中的联盟之后，后续开发计划如下：

1. 投资理财：包括银行的活期和定期存储。彩票：类似双色球、大乐透等。股票交易系统：包括模拟20-30值股票。
2. 消费购买: 赚到钱了就得消费，目前消费项目：1国内外旅游，升级到工作室，雇佣技术人员，购买学习资料，服装，升级电脑。
3. 服务器运维：运营博客的服务器主机宽带域名以及安全防护等，这个是花销，也是收入，访问量很高的时候，会有合作。
4. 成就系统：这个算是游戏中的事件啊。
5. 场景的深入美化：绘制所有场景中的细节和动画。
6. 游戏中的声音：包括游戏中的背景音乐，以及玩家的操作音效。
7. 游戏的宣传动画：包括游戏的启动动画，以及游戏中的一些事件的宣传动画。

暂时就是这些，还有就是游戏的存档和读取。

由于是开源免费的游戏，暂时没有考虑到发布平台，所以游戏的发布相对会简单些。现在最大的希望就是寒假的时候能够把游戏做完，发布出来。

断断续续的写了10天的代码，终于完成了游戏中博客联盟的模拟，博客联盟的编写暂时告一段落，愿望是美好的，现实是残酷的，复盘一下最近的游戏开发进度，规划一下未来的游戏开发方向。

Godot游戏开发《我的博客》记录07-复盘与展望


着手开始构建游戏中的博客联盟功能，这让我想起很多当下的博客联盟，目前我比较关注的博客联盟有：十年之约，BlogFinder，博友圈以及记忆中比较认可的就是已经关门大吉的积薪。

## 现实中的博客联盟

如今的博客联盟也算是不少了，常见的中文博客联盟应该10家之多，不知名的算起来几十家联盟也是有可能的。当然，他们的质量也是参差不齐的，几乎没有什么公平可言。首先，从联盟的推荐文章来看，大多都是一些站长的喜好或是关系户的文章，普通的用户文章被推荐的可能性是比较低的。推荐规则不透明，也没有什么机制来确保推荐的文章质量。

当然个人博客本身就是主观的延伸，联盟的管理也是人，优点是没有大数据搀合在其中，不然推荐的都是自己喜好了。联盟的特点也是各有所长，侧重点不同，有的联盟更注重推荐文章的质量，有的联盟更注重推荐文章的数量，有的就是rss的列表而已。虽然不赞同原积薪站长的某些言论，但是他的博客联盟文章推荐方式以及内容的侧重点还是抓的不从，据说是AI+人工干预。

## 游戏中的博客联盟

好吧，回到游戏中我对博客联盟的构思。目前的想法是，在游戏中构建两或三个博客联盟，模拟100个博客的数据，每周更新博客联盟的数据。模拟每周文章推荐，推荐10篇文章在联盟首页展示，对应的就是给游戏中玩家的博客带来额外的流量。除了模拟文章推荐，还有博客的流量排行榜，综合分数排行榜以及段位排行榜，我会三选一，目前比较倾向段位排行，实行起来比较简单。博客的段位是根据玩家的等级对应出来的10个段位，博客运行时间越长，流量以及属性点越高段位也越高。

100个博客的数可能比较多，明天试试先模拟，反正只有文章的标题，数据不会太大。随着玩家博客等级段位的不断提升，最终玩家会登顶排行榜第一名，获得流量以及知名度的额外加成。对于文章的推荐，我考虑了一个赞助博客联盟的小动作把，以捐助联盟的名义“贿赂”联盟的管理人员，进而获得更多的文章推荐机会，游戏后半部分，玩家还可以大额捐助联盟对联盟进行收购，已达到对自己博客流量的强有力的推荐。

## 流量密码

游戏中有很多获得流量的方式，除了提升自身的技能以外，还可以花钱购买流量，当然，具体玩家如何购买流量，这个我还没有细想，方式也是很多的，毕竟是游戏，不高的夸张一点，玩起来也就没有意思了。

## 主线情节

目前主线任务就是完成25年的博客运营，其中并没有安排什么故事情节，我觉得有必要安排一些情节，但是，博主千千万，每个人都有自己的故事，一时间还真的没想到什么有代表性的故事。不过先完成博客联盟的功能，当游戏中的世界逐渐完善之后，我觉得自然会有一些新的电子。




着手开始构建游戏中的博客联盟功能，这让我想起很多当下的博客联盟，目前我比较关注的博客联盟有：十年之约，BlogFinder，博友圈以及记忆中比较认可的就是已经关门大吉的积薪。

Godot游戏开发《我的博客》记录06-游戏中的博客联盟


经过这个暑假的忙碌，终于基本上完成了游戏的主线代码，也就是模拟博客博主的自身属性的提升，以及发布博文后一些访问量数据的变化，同事模拟了广告联盟的收入，另外测试性的添加了二个随机事件，总之一切还算顺利。

## 游戏进度
游戏的进度目前基本完成了，后续主要是根据游戏中博客的访问量数据以及博主的属性数据来触发一些事件，以及属性值来达成的一些成就，目前还有一个博客联盟的功能还在构思中，一方面这是游戏中的一个虚拟竞技的场景，通过访问量以及博主自身的属性值来与虚拟的其他博主进行比较，以彰显玩家的博客价值。另外还需要加入一个资产理财，这个打算在后续的一个版本中添加，类似银行的储蓄、理财、股票交易、彩票等，这也是游戏中玩家通过博客的运营后获得金钱的理财消费的出口，进而引出财经博主的相关资料片。

## 未来

预计下个月也就是九月份，完成所有的目前预订的游戏功能代码以及游戏玩法体验的测试，然后进入场景的绘制阶段，把画面的一些细节搞出来，最后找些声音添加上，有信心在年底发布第一个测试版。

## 一些感触

独立游戏开发，确实很难，难在于坚持下去，有的时候会因为一些技术上的或是绘图上的问题产生负面的想法，但是只要用心去做，去思考，终究会找到解决的方法，另外就是要注意控制游戏的内容，不要无限制的添加新的想法，这会造成游戏的完成度下降，导致各种成本的增加，超出预算，进而产生放弃的想法。

踏踏实实，一步一个脚印，把功能拆开，一个一个的去实现，就会离最终的完成越来越近。加油，共勉。


经过这个暑假的忙碌，终于基本上完成了游戏的主线代码，也就是模拟博客博主的自身属性的提升，以及发布博文后一些访问量数据的变化，同事模拟了广告联盟的收入，另外测试性的添加了二个随机事件，总之一切还算顺利。

Godot游戏开发《我的博客》记录05-游戏的主线任务代码基本完成


看了一下时间，上次还在纠结场景绘制风格的时间，这一转眼都过去了半个月了，好在，我的游戏主场景基本确定了，人物角色的设计也基本确定了，下图就是游戏的第一次预览图，先复盘一下最近的杂乱的思绪把。


![游戏主场景预览](https://www.suiyan.cc/assets/images/2025/mybloggame.jpg)

目前的场景都是静态，后续会加入动态效果，以及一些互动。

## 关于游戏画风的各中尝试

这阵子一直在尝试游戏的画风，最开始的时候选择了像素风格，后来换成3D风格采用blender建模，但是感觉3d风格在颜色、材质和动画方面的控制碍于技术原因十分有限，而且风格极难把握，最终还是放弃了，选择了2D风格，但是具体的画风还需要筛选，而且自己的绘画技术是业余的，有很多的想法，但是碍于技术和手是无法实现的，最终有绕回去了像素风格，一来感觉像素风格的控制方式更接近编码，绘制起来也很简单，最终还是选择了像素风，且不会在改变了。

肯定会有人说，为什么不适用AI来绘制场景和人物，目前来说，AI绘制不可控还是主要原因，但是使用AI来进行快速的原型设计还是不错的，先用AI大体绘制出你的所想，然后自己在临摹打磨，这样也可以节省很多时间，但是直接使用AI来制作游戏中的角色和场景，这个我还没试过，即便可以，也需要花费很多的时间来研究，最终你也会发现AI并不能实现你的想法。

## 知乎推荐了一些Godot或独立游戏开发的文章

策划、编码、美术、推广等等，一个游戏包含了很多的方面，每个环节都需要人来负责，但是独立开发者就只能靠自己了，没有团队的支持，进度自然会很慢。做游戏也好，写代码也好，都需要很多时间，有的时候，我们必须搞定一键事情的优先度，还有就是果断，不要过度的尝试，不停的尝试会浪费掉很多时间，但是有的时候，我们必须要尝试，才能知道什么才是最好的。知乎推荐了一些独立游戏开发者的经验之谈，偶尔也会看看，受益匪浅。

游戏开发也好还是其他的行业初期，你都会觉得这是一个困难的事情，也会为一些技术方面的问题头疼，随着你对该行业技术的了解不断的加深，技术都会变成体力劳动，那个时候你会有了更多的更深层次的感触，恭喜你，你已经在该行业中有很大的进步了，当你脱离技术开始讨论这个行业的时候，你会发现，你已经觉醒，或者说你已经发现了一些什么。

## 道阻且长

独立游戏开发也好，其他行业的创业也好，都会需要一个漫长的过程，当然，有的人运气好，最终会有一个好的结果，或是花费很短的时间，但那都是别让人，大多数人都是普通人，莫说成功，只要能坚持下去，我觉得都是好样的！加油！共勉！




看了一下时间，上次还在纠结场景绘制风格的时间，这一转眼都过去了半个月了，好在，我的游戏主场景基本确定了，人物角色的设计也基本确定了，下图就是游戏的第一次预览图，先复盘一下最近的杂乱的思绪把。

Godot游戏开发《我的博客》记录04-终于完成了主场景的绘制


只要有空余的时间我就在思考游戏的场景的绘制风格的选择，最开始的时候选择了像素风格，后来换成3D风格采用blender建模，但是感觉3d风格在颜色、材质和动画方面的控制碍于技术原因十分有限，而且风格极难把握，最终还是放弃了，选择了2D风格，但是具体的画风还需要筛选。

## 关于游戏中的事件

在游戏中，对于一个博主来说，遇到一些随机事件应该是很寻常的，当然大千世界形形色色的人和事在游戏中不可能全部都会遇到，但是还是要模拟一些常见的随机事件。
目前的随机事件触发后都会影响到博客的访问量增减，当然也会有随机事件触发影响到人物或是博客的属性。适当的随机事件会增加游戏的趣味性，也会增加游戏的难度。
我会考虑游戏的复杂度，来适当的添加游戏的随机事件，避免掉入无止境的事件陷阱，导致游戏的进度永远无法完成。

## 一些随感

当事件系统的代码写的差不多之后，还要开启成就系统，当玩家完成一些任务，比如写了100篇博客，或者写了1000篇博客，就可以解锁一些新的成就。当然成就触发的条件很多的，基本所有属性的数据都可以触发，所以，游戏的属性和数据越多，可触发的成就任务就可以设计的越多，但是，这似乎有会掉进「功能需求爆炸」的陷阱，应当警惕。

当一切代码妥当后，开始详细的绘制场景，过程动画等，后期添加音效以及背景音乐等，工程还是很复杂的，路虽远，行则将至！


只要有空余的时间我就在思考游戏的场景的绘制风格的选择，最开始的时候选择了像素风格，后来换成3D风格采用blender建模，但是感觉3d风格在颜色、材质和动画方面的控制碍于技术原因十分有限，而且风格极难把握，最终还是放弃了，选择了2D风格，但是具体的画风还需要筛选。

Godot游戏开发《我的博客》记录03-关于游戏的场景绘制风格的选择


今天一看时间，都是八月份了，上次我记录游戏开发的时候还是7月末，简单的说下游戏开发的进度和一些细节吧。

## 烦人的伏天

今年东北的伏天有些提早了，还没入伏就热的不要不要的，上个星期开车发现空调不热，好家伙，妥妥的温水煮青蛙啊，不到最热的时候竟然没有感受出来空调不出冷风！简答的排查了一下，确定了压缩机和制冷的功能没有问题，那么就可能是冷暖风门的问题了，还好车还在三包期间，就送去让四儿子给查查修修，结果，排查两天，等件两天，维修两天，一个小小的风门更换要一个星期......不过最终的结果还是不错的，又可以凉快的开车了。


## 游戏的进度

琐事依然不断，之前一直在设计并编写游戏中关于博客访问量的模拟，其中有两个模拟的大头，一个是博客的rss订阅一个是博客文章的收藏，顺带创建了一个详细的统计类。
关于rss和博客文章收藏的模拟，虽然还是很初级的，但是也考虑了很多因素进去，但是目前影响这二个数量的因素还是访问量。游戏中rss和收藏是根据访问量来增加的，反过来，也会因为rss和文章的收藏量给博客带来一些流量，简单的模拟了rss和文章收藏的增长和减少，是指跟接近现实中的流量增长和衰减。


## 关于AI辅助编程

可能有些朋友会觉得，直接使用AI辅助编程会更好，我也是一直在用啊，但是你想让Ai直接帮你写出符合你的构思的完整的游戏代码，这个可挺难的。我目前就是拆分功能，劲量把需求拆分到具体的方法，而并不是让AI直接修改代码，不然，别说帮你生成代码了，不把你的代码改出毛病就不错了。

## 总结

接着整个八月都会继续更新一些游戏的事件，目前来说，游戏中博客访问量的自然增长基本上都完成了，需要增加一些新的事件来增加游戏的趣味性。并且需要达成一些成就。


今天一看时间，都是八月份了，上次我记录游戏开发的时候还是7月末，简单的说下游戏开发的进度和一些细节吧。

Godot游戏开发《我的博客》记录02-缓慢的进度


游戏开发已经有段时日了，我决定在我的博客记录这个游戏开发过程，一方面是督促自己抓紧开发游戏的各个环节，记录游戏开发的过程和学习使用Godot开发游戏的经验，另一方面也是希望能够吸引到对这个游戏感兴趣的玩家，当然如果能够有高手指点一下更好啦。

## 游戏构思

断断续续的开发已经过去4个月了，这是一个名字暂定为「我的博客」模拟养成游戏，游戏的画面风格暂定为3D主场景，游戏的大体内容：玩家是一个博主，在2000年的时候你会创建一个自己的独立博客，通过不断地学习和持续的输出，持之以恒的维护与运营，终于若干年后在博客届混出个名堂，通过流量换得了收入与名誉，并且在运营的过程中会遇到很多突发事件，这些突发事件会给你带来一些意想不到的结果。随着游戏不断地推进，你会通过学习新的技能来提高自己的创作能力，通过社交、seo、优化美化博客等手段来提高网站的知名度和访问量，解锁不同的成就。直到游戏运营到2025年游戏结束，整个游戏会因为你不同的运营方式和学习方式产生不同结果和获得不同成就，给足玩家满满充实的游戏快感。

目前来说，游戏的构思还是和当初一样，至于细节，一直是一遍做一边在丰富中。本想着留一个游戏场景了，但是预览了一下游戏，发现场景中的很多元素都还没有画出来，算了，太简陋了，先不贴了。

## 开发记录

当前的游戏开发进度：

游戏内的时间线已经确定，一些博客的日常，包括发表博文的常见类型，以及博客的维护都有了基本的框架，已经实现。目前正在做游戏中的一些事件，例如：每年的12月和1月份会触发【年度总结】这个任务，玩家可以发布一篇【年度总结】的博文，来总结自己这一年的博客运营情况，以及自己的学习情况。当然游戏内的事件还是很多的，基于时间和属性触发的任务会很多。

## 一些细节的构思

游戏内实现了广告联盟的基础功能，例如加入联盟的审核，加入后广告类型的选择，根据玩家选择了不同的广告投放类型，进而影响到博客访问量和收入。
实现了玩家的技能属性对于发表不同博客产生的访问量的影响，还有就是RSS订阅文章收藏以及文章分享给博文带来的额外的访问量。

后续还有几个主要的玩法，博客联盟、理财（储蓄，基金、股票）触发财经博主的技能，这个玩法我还是挺期待的，当通过博客赚到钱后，进行理财投资，迅速提高自己的收入，实现财富自由。

## 激励自己

游戏内容还是挺多的，但是万事都需要一步一步的实现，每一个玩法的背后都是一堆代码的编写，当然完成代码的编写只是最初的一步，后续还需要不断地完善和优化界面和游戏元素，添加声音和背景音乐，啊，想想都够麻烦。慢慢来吧，希望早日完成这个游戏开发。




游戏开发已经有段时日了，我决定在我的博客记录这个游戏开发过程，一方面是督促自己抓紧开发游戏的各个环节，记录游戏开发的过程和学习使用Godot开发游戏的经验，另一方面也是希望能够吸引到对这个游戏感兴趣的玩家，当然如果能够有高手指点一下更好啦。

Godot游戏开发《我的博客》记录01


最近一直在构思一些游戏的中的细节，有的时候想了几天都没有具体实现的方式，不过，大部分游戏的场景最终都还是找到了具体实现的方法。这期间，我的思绪不断地回到这个游戏构思的初期，那个抽象出来的理想中的游戏世界。

## 抽象与具体

随着游戏制作的深入，无论是游戏的设计、构思，还是编码与美术，都从最初的抽象模糊的世界开始变得具体了。之前可能想的太简单了，总以为一个游戏在脑海里过了一遍，把代码写好，把图片做好就可以了，完全没有想到随着游戏制作的深入，这一切都变的更加具体了。如果游戏制作实在画画，那么初期就是打型构图，中期就是细化结构，后期就是完善细节。  我并没有想到，一个游戏的细节会有那么多，每个细节都需要具体的实现方式。

## 理想与现实

或许人类在做什么之前，都会有一个理想的目标，例如先赚他一个小目标（一个亿），这是一个抽象的理想，当我们开始为了实现这个小目标的时候，一切抽象都得变得具体，我们需要具体的实现方式。例如：我要打工，赚它一个亿，但是我要怎么做？这个时候就是从理想回到现实。

## 面对现实

赚一个亿，比我要做完这个游戏难的很多，但是有些就实现了，有些人就没实现，甚至连一些更小的理想都没实现。



最近一直在构思一些游戏的中的细节，有的时候想了几天都没有具体实现的方式，不过，大部分游戏的场景最终都还是找到了具体实现的方法。这期间，我的思绪不断地回到这个游戏构思的初期，那个抽象出来的理想中的游戏世界。

抽象的理想和具体的现实


一晃俩月过去了，我的游戏开发进度真是惨不忍睹，从信心满满的开始，到折磨的崩溃，再到开始怀疑人生。从做好一个游戏到把这个游戏做完，这真是一个自我折磨的过程。

## 信心满满的开始

之前，我确实低估了制作一个游戏的「成本」，技术，时间，绘画，当各种不同的技术多维度的叠加到一起的时候，才会逐步的发现制作一个游戏的成本是多么的高。之前也写过一些博客，记录了一些想法，当我开始着手把这些想法实现到游戏中的时候，我才发现自己很多的技术空白，绘画能力的限制，甚至游戏的逻辑有的时候都无法理清了。

## 事无巨细的游戏细节

我以为想好的游戏的构思就可以了，但是我开始制作这个游戏的时候，我发现整个游戏的世界，都需要我来制作和维护。这真是一个巨大的坑。

我已经不是开始的时候了，我现在满脑子都是一个想法：如何把这个游戏做完。




一晃俩月过去了，我的游戏开发进度真是惨不忍睹，从信心满满的开始，到折磨的崩溃，再到开始怀疑人生。从做好一个游戏到把这个游戏做完，这真是一个自我折磨的过程。

标签: godot