
Happy new year everyone! Hope you had a great break. CoderDojo will restart Saturday 10th of January.
Looking forward to seeing you and building new awesomeness in 2026!
We have come to the end of the CoderDojo year 2025.
We look forward to seeing you tomorrow Saturday 6th Dec 2025 at CoderDojo Athenry for our last session before we break for Christmas, also known as our Pizza Party.
You can leave your laptops and tablets at home, but please bring drinks for your own children, as different families have different preferences. We will serve pizza, chips and chicken nuggets. We ask you to consider making a small donation to help cover our costs. Cash preferred but Kieran will also accept Revolut.
Christmas jumpers are encouraged!
Following our winter break, we will return on the 10th Jan 2026.
Hello Witches, Wizards, Mummies and Vampires!
CoderDojo takes a Halloween holiday. There will be no CoderDojo on Saturday 18th of October and Saturday 25th of October.
If you want to refer to the schedule, you can find it here:
You can even add the schedule to your own Google Calendar by scrolling down the schedule page and clicking the small “+” icon.
Happy Halloween
Hi folks, here are some notes for Week 3. We completed our lighthouse and sculpted an island.

We’re kicking off the 2025-2026 year with an introductory session on Saturday 20th Sept 2025 at 12pm in Clarin College, Athenry.
Come along if this is your first time attending CoderDojo Athenry, if you’re wondering which group to join, or you just have some questions. Those who have been at CoderDojo Athenry before need not attend.
We will resume with our first normal session from 12pm-2pm on Saturday 27th 2025, again at Clarin College. Our full schedule can be found here.
Regretfully we have to cancel tomorrow’s Creator’s session as neither Kieran nor Mike are available.
If ninjas from Creators would still like to come along, they are welcome to sit in with Bodgers for the day.
Looking forward to seeing you again on the 29th March 2025.
This week we:
Moving Enemy from Area2D to AnimatableBody2D
It was necessary to move the enemy from an Area2D based node to a physics body of some sort. AnimatableBody2D is intended for physics bodies that are moved with animation or code.
To change the type of the Enemy node, we right-clicked on it and choose “Change Type”. We then searched for AnimatableBody2D.
Moving code from Mover.gd to Enemy.gd
We added new script directly to the Enemy’s root node, called Enemy.gd. We copied all the code from Mover.gd with the exception of the line “extends Area2D” at the very top and pasted it into Enemy,gd overwriting everything except the very first line, “extends AnimatableBody2D”.
We copied the variables from Mover in the inspector, and assigned the same values to the variables in Enemy.
Testing we found that this worked a bit, bit there was weird effects. It was moving the player too, for example. We recalled that Mover.gd was designed to move the parent of the node it was attached to. For Enemy, that is the scene root, and not what we want. We removed the variable storing the parent and all reference to it, setting our own position instead,
Additionally, we noted that the node called Mover, with a Mover.gd script attached, was still part of the Enemy node tree. It would also be moving our enemy, which we didn’t want. We deleted this node from the tree.
Now when we tested, we found that the the enemy was more-or-less behaving as before, excepting that it was wiggling about. Disabling “Sync to Physics” in the inspector resolved that.
Improving the Code so that Enemy Behaves as a Physics Object
Since AnimatableBody2D is a physics object, we could improve how we were moving it.
With physics objects, we don’t normally set the position explicitly, we set a suggested position, or a suggested velocity and let the physics engine then influence the actual outcome.
To move towards that change, we added a new function _physics_process() and moved the last line of _process() into it, changing position (explicit) to global_position (suggested). We also changed position to global_position in the bounds checking code. The last line in _physics_process() is a call to move_and_collide() which is passing control to the physics engine, once we’ve made our suggestion on position:
func _process(delta: float) -> void:
wander_change_dir_time -= delta
if (wander_change_dir_time < 0):
pick_random_direction()
set_wander_change_dir_time()
func _physics_process(delta: float) -> void:
global_position += direction.normalized() * speed * delta
move_and_collide(direction)
What we then noted, was that the AnimatableBody2D respects collisions with other physics bodies, so the bounds checking that we had previously in Mover.gd was no longer necessary to prevent the enemy moving out of bounds, so we removed exported variable bounds and the function check_pos_for_bounds().
Even though the Enemy was constrained to stay within the play area by the walls around the edge, there was no way yet for it to automatically reverse direction on hitting a wall (or other physics body). We added the following code to _process_physics() to achieve this:
func _physics_process(delta: float) -> void:
global_position += direction.normalized() * speed * delta
var collision = move_and_collide(direction)
if (collision):
var collision_pos = collision.get_position()
if (direction.x < 0 && collision_pos.x < global_position.x):
direction.x = 1
if (direction.x > 0 && collision_pos.x > global_position.x):
direction.x = -1
if (direction.y < 0 && collision_pos.y < global_position.y):
direction.y = 1
if (direction.y > 0 && collision_pos.y > global_position.y):
direction.y = -1
Creating Collision Layers
Objects that can collide with other objects have layers and layer masks:
Imagine these scenarios:
We established these layer:
We moved our player, enemy and boundary walls into their appropriate layers and set their layer masks. The player (ship) is in layer 1 and it’s mask is set to 2, 3, 4.
New Code for Body-on-Body Contact
In ship.gd we could now add code to detect body-on-body contact:
func _physics_process(delta: float) -> void:
var mouse_pos : Vector2 = get_viewport().get_mouse_position()
var ship_to_mouse : Vector2 = mouse_pos - position
var distance : float = ship_to_mouse.length()
if (distance > DEADZONE):
velocity = ship_to_mouse * speed_by_distance
else:
velocity = Vector2.ZERO
move_and_slide()
for i in get_slide_collision_count():
var collision = get_slide_collision(i)
var collision_obj = collision.get_collider() as CollisionObject2D
if (collision_obj && \
collision_obj.get_collision_layer_value(2) == false):
%GameManager.inform_body_entered(self)
After move_and_slide() above, we can check for collisions. We need to take any collisions that are not with objects in layer 2 (the boundary layer) and inform the name manager that we’ve hit something we shouldn’t.
Adding Sound when we Shoot
We went to freesound.org to look for suitable sound effects for our Ship when it shoots. Note that the site requires an account before it allows downloading.
We then added a new AudioStreamPlayer2D under Ship and called it ShootSound. Dragging it into the top of the Ship.gd script and pressing CTRL before releasing the mouse button provided this reference:
@onready var shoot_sound: AudioStreamPlayer2D = $ShootSound
In _process() after we’ve created the missile, we just have to insert this line to get the sound to play:
shoot_sound.play()
Getting the Code
All our code for this year is available on our GitHub.