From ec2aa74d36670d74c153aa0022ab22e79502a061 Mon Sep 17 00:00:00 2001 From: David Luevano Alvarado Date: Tue, 2 May 2023 01:33:25 -0600 Subject: update to new version of pyssg --- live/blog/g/gogodot_jam3_devlog_1.html | 53 +++++++++++++++++----------------- 1 file changed, 26 insertions(+), 27 deletions(-) (limited to 'live/blog/g/gogodot_jam3_devlog_1.html') diff --git a/live/blog/g/gogodot_jam3_devlog_1.html b/live/blog/g/gogodot_jam3_devlog_1.html index 7f43ced..31060cb 100644 --- a/live/blog/g/gogodot_jam3_devlog_1.html +++ b/live/blog/g/gogodot_jam3_devlog_1.html @@ -3,27 +3,26 @@ " prefix="og: https://ogp.me/ns#"> - - + Creating my Go Godot Jam 3 entry using Godot 3.5 devlog 1 -- Luevano's Blog - - - + + + - - + + - + - + @@ -89,20 +88,20 @@

You can also find the jam entry here.

Similarly with the my FlappyBird clone, I plan to update this to a better state.

-

Initial setup

+

Initial setup

Again, similar to the FlappyBird clone I developed, I’m using the directory structure I wrote about on Godot project structure with slight modifications to test things out. Also using similar Project settings as those from the FlappyBird clone like the pixel art texture imports, keybindings, layers, etc..

I’ve also setup GifMaker, with slight modifications as the AssetLib doesn’t install it correctly and contains unnecessry stuff: moved necessary files to the res://addons directory, deleted test scenes and files in general, and copied the license to the res://docs directory. Setting this up was a bit annoying because the tutorial it’s bad (with all due respect). I might do a separate entry just to explain how to set it up, because I couldn’t find it anywhere other than by inspecting some of the code/scenes.I ended up not leaving this enabled in the game as it lagged the game out, but it’s an option I’ll end up researching more.

This time I’m also going to be using an Event bus singleton (which I’m going to just call Event) as managing signals was pretty annoying on my last project; as well as a Global singleton for essential stuff so I don’t have to do as many cross references between nodes/scenes.

-

Assets

+

Assets

This time I’ll be creating my own assets in Aseprite, wont be that good, but enough to prototype and get things going.

Other than that I used few key sprites from vryell: Controller & Keyboard Icons and a font from datagoblin: Monogram.

-

The snake

+

The snake

This is the most challenging part in my opinion as making all the body parts follow the head in a user defined path it’s kinda hard. I tried with like 4-5 options and the one I’m detailing here is the only one that worked as I wanted for me. This time the directory structure I’m using is the following:

FileSystem - Snake dir structure
FileSystem - Snake dir structure
-

Basic movement

+

Basic movement

The most basic thing is to move the head, this is what we have control of. Create a scene called Head.tscn and setup the basic KinematicBody2D with it’s own Sprite and CollisionShape2D (I used a small circle for the tip of the head), and set the Collision Layer/Mask accordingly, for now just layer = bit 1. And all we need to do, is keep moving the snake forwards and be able to rotate left or right. Created a new script called head.gd attached to the root (KinematicBody2D) and added:

extends KinematicBody2D
 
@@ -136,7 +135,7 @@ func _rotate_to(direction: int) -> void:
 Snake - Basic movement (left and right controls)
 
Snake - Basic movement (left and right controls)

 
-
Setting up path following

+
Setting up path following

 
To move other snake parts by following the snake head the only solution I found was to use the Path2D and PathFollow2D nodes. Path2D basically just handles the curve/path that PathFollow2D will use to move its child node; and I say “child node” in singular… as PathFollow2D can only handle one damn child, all the other ones will have weird transformations and/or rotations. So, the next thing to do is to setup a way to compute (and draw so we can validate) the snake’s path/curve.

 
Added the signal snake_path_new_point(coordinates) to the Event singleton and then add the following to head.gd:

 
var _time_elapsed: float = 0.0
@@ -173,7 +172,7 @@ func _on_Head_snake_path_new_point(coordinates: Vector2) -> void:
 Snake - Basic movement with path
 
Snake - Basic movement with path

 
-
Define body parts for the snake

+
Define body parts for the snake

 
At this point the only thing to do is to add the corresponding next body parts and tail of the snake. To do so, we need a PathFollow2D to use the live-generating Path2D, the only caveat is that we need one of these per body part/tail (this took me hours to figure out, thanks documentation).

 
Create a new scene called Body.tscn with a PathFollow2D as its root and an Area2D as its child, then just add the necessary Sprite and CollisionShap2D for the Area2D, I’m using layer = bit 2 for its collision. Create a new script called generic_segment.gd with the following code:

 
extends PathFollow2D
@@ -185,7 +184,7 @@ func _physics_process(delta: float) -> void:
     offset += Global.SNAKE_SPEED * delta
 

 
And this can be attached to the Body‘s root node (PathFollow2D), no extra setup needed. Repeat the same steps for creating the Tail.tscn scene and when attaching the generic_segment.gd script just configure the Type parameter to tail in the GUI (by selecting the node with the script attached and editing in the Inspector).

-
Adding body parts

+
Adding body parts

 
Now it’s just a matter of handling when to add new body parts in the snake.gd script. For now I’ve only setup for adding body parts to fulfill the initial length of the snake (this doesn’t include the head or tail). The extra code needed is the following:

 
export(PackedScene) var BODY_SEGMENT_NP: PackedScene
 export(PackedScene) var TAIL_SEGMENT_NP: PackedScene
@@ -269,13 +268,13 @@ func _add_segment_to_queue() -> void:
     _snake.propagate_call("set_process_input", [on_off])
 

 
Which will stop the snake node and all children.

-
Fix on body segments following head

+
Fix on body segments following head

 
After a while of testing and developing, I noticed that sometimes the head “detaches” from the body when a lot of rotations happen (moving the snake left or right), because of how imprecise the Curve2D is. To do this I just send a signal (snake_rotated) whenever the snake rotates and make a small correction (in generic_segment.gd):

 
func _on_snake_rotated() -> void:
     offset -= 0.75 * Global.SNAKE_SPEED * pow(get_physics_process_delta_time(), 2)
 

 
This is completely random, I tweaked it manually after a lot of iterations.

-
The food

+
The food

 
For now I just decided to setup a simple system to see everything works fine. The idea is to make some kind of generic food node/scene and a “food manager” to spawn them, for now in totally random locations. For this I added the following signals: food_placing_new_food(type), food_placed_new_food(type) and food_eaten(type).

 
First thing is creating the Food.tscn which is just an Area2D with its necessary children with an attached script called food.gd. The script is really simple:

 
class_name Food # needed to access Type enum outside of the script, this registers this script as a node
@@ -323,7 +322,7 @@ func _on_body_entered(body: Node) -> void:
 Snake - Food basic interaction
 
Snake - Food basic interaction

 
-
Za warudo! (The world)

+
Za warudo! (The world)

 
It just happend that I saw a video to create random maps by using a method called random walks, this video was made by NAD LABS: Nuclear Throne Like Map Generation In Godot. It’s a pretty simple but powerful script, he provided the source code from which I based my random walker, just tweaked a few things and added others. Some of the maps than can be generated with this method (already aded some random sprites):

 

 World map generator - Random map 1
@@ -351,7 +350,7 @@ func get_centered_world_position(location: Vector2) -> Vector2:
 

 
Where get_cells_around is just a function that gets the safe cells around the origin. And this get_valid_map_coords just returns used cells minus the safe cells, to place food. get_centered_world_position is so we can center the food in the tiles.

 
Some signals I used for the world gen: world_gen_walker_started(id), world_gen_walker_finished(id), world_gen_walker_died(id) and world_gen_spawn_walker_unit(location).

-
Food placement

+
Food placement

 
The last food algorithm doesn’t check anything related to the world, and thus the food could spawn in the walls and outside the map.

 
First thing is I generalized the food into a single script and added basic food and special food which inherit from base food. The most important stuff for the base food is to be able to set all necessary properties at first:

 
func update_texture() -> void:
@@ -401,9 +400,9 @@ func _ready():
     return [world_generator.get_centered_world_position(location), location]
 

 
Other than that, there are some differences between placing normal and special food (specially the signal they send, and if an extra “special points” property is set). Some of the signals that I used that might be important: food_placing_new_food(type), food_placed_new_food(type, location) and food_eaten(type, location).

-
Stats clas and loading/saving data

+
Stats clas and loading/saving data

 
I got the idea of saving the current stats (points, max body segments, etc.) in a separate Stats class for easier load/save data. This option I went with didn’t work as I would liked it to work, as it was a pain in the ass to setup and each time a new property is added you have to manually setup the load/save helper functions… so not the best option. This option I used was json but saving a Node directly could work better or using resources (saving tres files).

-
Stats class

+
Stats class

 
The Stats “class” is just a script that extends from Node called stats.gd. It needs to define the class_name as Stats. The main content:

 
# main
 var points: int = 0
@@ -466,7 +465,7 @@ func set_stats(stats: Dictionary) -> void:
         trait_jump = stats["trait_jump"]
 

 
And this is not scalable at all, but I had to do this at the end of the jam so no way of optimizing and/or doing it correctly, sadly.

-
Load/save data

+
Load/save data

 
The load/save function is pretty standard. It’s a singleton/autoload called SavedData with a script that extends from Node called save_data.gd:

 
const DATA_PATH: String = "user://data.save"
 
@@ -510,7 +509,7 @@ func _handle_new_file() -> void:
         file.close()
 

 
It uses json as the file format, but I might end up changing this in the future to something else more reliable and easier to use (Stats class related issues).

-
Scoring

+
Scoring

 
For this I created a scoring mechanisms and just called it ScoreManager (score_manager.gd) which just basically listens to food_eaten signal and adds points accordingly to the current Stats object loaded. The main function is:

 
func _on_food_eaten(properties: Dictionary) -> void:
     var is_special: bool = properties["special"]
@@ -579,7 +578,7 @@ func _get_max_stats() -> Stats:
 

 
Then this sends a signal display_stats to activate UI elements that shows the progression.

 
Naturally, the saved Stats are loaded whenever needed. For example, for the Snake, we load the stats and setup any value needed from there (like a flag to know if any ability is enabled), and since we’re saving the new Stats at the end, then on restart we load the updated one.

-
Snake redesigned with the state machine pattern

+
Snake redesigned with the state machine pattern

 
I redesigned the snake code (the head, actually) to use the state machine pattern by following this guide which is definitely a great guide, straight to the point and easy to implement.

 
Other than what is shown in the guide, I implemented some important functions in the state_machine.gd script itself, to be used by each of the states as needed:

 
func rotate_on_input() -> void:
@@ -653,7 +652,7 @@ func physics_process(delta: float) -> void:
 

 
Where the important parts happen in the enter and exit functions. We need to change the Global.SNAKE_SPEED with the Global.SNAKE_DASH_SPEED on startand start the timer for how long should the dash last. And on the exit we reset the Global.SNAKE_SPEED back to normal. There is probably a better way of updating the Global.SNAKE_SPEED but this works just fine.

 
For the other ones is the same. Only difference with the jump_state.gd is that the collision from head to body is disabled, and no rotation is allowed (by not calling the rotate_on_input function).

-
Other minor stuff

+
Other minor stuff

 
Not as important but worth mentioning:

 
    
 
  • Added restartability function.
    • 
@@ -667,7 +666,7 @@ func physics_process(delta: float) -> void:
 
  • Refactored the nodes to make it work with change_scene_to, and added a main menu.
    • 
 
  • Added GUI for dead screen, showing the progress.
    • 
 

-
Final notes

+
Final notes

 
I actually didn’t finish this game (as how I visualized it), but I got it in a playable state which is good. My big learning during this jam is the time management that it requires to plan and design a game. I lost a lot of time trying to implement some mechanics because I was facing many issues, because of my lack of practice (which was expected) as well as trying to blog and create the necessary sprites myself. Next time I should just get an asset pack and do something with it, as well as keeping the scope of my game shorter.

 
For exporting and everything else, I went with what I did for my FlappyBird Godot clone

 
-- 
cgit v1.2.3-70-g09d2