Introductions & Devlog 1
Yo.
i’m Bryan and welcome to my little creative journal. i’m not completely sure what this little newsletter will turn into but for now it will be just a place to log my current creative endeavors and thoughts. i don’t have an elevator pitch for myself other than being an artist and serial interestist. my main concentration is drawing and graphic design, but i also love animation, photography, music, etc etc.
Right now i’m developing video games but a year from now i could move on to making rugs or something probably.
This year i made a vision board for the first time because having goals is cool. One of the bigger goals i have is to journal more. i know what i think, but sometimes i can’t really remember why i think what i think so i figured if i wrote everything down it’d help.
Also on the board is developing a game and releasing it physically. For the past 3 or so years i’ve been deep in the GB Studio mines creating games and doing my best to help others. GB Studio is an app that allows mortals like you and me make games that are actually playable on a real game boy without knowing asm.
i’ve called you here to witness the synergy of these two goals and opening of my third eye.
For now, this newsletter will be where i will put my thoughts on my progress developing video games and thoughts on my experience with the medium. Hopefully this will serve as a sort of guide for those working with the same tools and just be a little entertaining to everyone else. So what am i working on?
Lockon Powerserf (working title)
Lockon Powerserf will be a walk n gun action game. Its core mechanic is a lock-on targeting system that tracks a target after being hit. After lock on is engaged it can only be disengaged manually or when the target is destroyed. Currently i’m in the process of determining the full scope and building the game doc.
Originally i was working on expanding a game jam game i created two years ago called Trace God. The core mechanic was fun but i was having trouble coming up with interesting scenarios and struggling to find a way to rapidly iterate. Eventually it just felt like i was trying to force something that wasn’t ready so i put it on the backburner hoping i’d feel more motivated to find the x-factor later in the year. Didn’t really go that way so here we are.
These first installments will be a rundown of the different ideas and challenges in this new game and ways that i’ve gotten around them. Prepare for it to get a little technical but maybe that will inspire you to open up GB Studio or Godot or Bitsy and start creating your own story.
Inspiration
One night i was browsing the GB Studio Discord server when i saw saw some users experimenting with atan2 in order to successfully get a projectile move toward a target actor from any position in a shmup. This particular math function isn’t actually accessible through normal means in GB Studio so it was sort of a feat to witness. This eventually led to the feature being added to the standard Launch Projectile event in the GB Studio 4.0 beta. Later i was browsing twitter and stumbled upon Gold Guardian Gun Girl, an in-development, top-down mech shooter for NES.
The player has a targeting reticle in front of them and if it touches an enemy, the player’s projectiles lock on. Its a super short sequence but it got me rolling around the idea of auto targeting in GB Studio so i decided to try to prototype it.
Building the Prototype
The first challenge i ran into was the Launch Projectile event itself. The event can target an actor which is fine if its an enemy firing at the player, but for the player, there would have to be an event for every enemy in the game which is obviously a lot.
Distance-based auto-targeting was already off the table since it would be super resource intensive for the game boy CPU and wasn’t at all appealing to program.
But what if there was an actor i could always use as a target? i needed to tell the player which enemy was being targeted so why not use a reticle? All the reticle needed to do was jump to the position of the enemy.
This worked really well and was really kinda cool seeing it in action. Since you have to manually aim and hit the target first to lock on, it immediately adds some balance and skill to gameplay.
For static enemies this works just fine, but i still needed the reticle to track moving enemies. To do this i needed the reticle actor to continuously update its position to match whatever actor had just been targeted. I figured i could use the enemy actors’ unique actor IDs. This also isn’t readily accessible through basic methods in GB Studio so i had to resort to writing a little GBVM, the custom language GB Studio events are written in for the most part.
An actor’s id is usually its default name which is numbered based on the order it was created. The entire game has each actor numbered but for this method it seemed like actors had scene specific IDs which always started at 1 (0 always being the player).
For each enemy’s On Hit trigger, i added a variable named TargetActor and manually set the value based on what i thought the actor’s ID was based on its default name. I then needed to pass that value to a GBVM command to get that actor’s position. Those coordinates are then passed to the reticle actor.
With a lot of help i was able to get this done with a couple simple lines while learning about reserving spots on the stack. I still don’t fully understand it to be honest but it does make this bit of code a lot more portable.
The truncated logic is as follows:
On Hit (enemy actor)
$TargetActor = [actor ID]
On Update (reticle actor)
If $TargetActor > 0
; -- Reserve variable 4 on stack
.LOCAL_ACTOR = -4
VM_RESERVE 4
; -- Set the local actor struct id to target actor
VM_SET .LOCAL_ACTOR, VAR_TARGET_ACTOR
; -- Store the position of target actor in the local actor struct
VM_ACTOR_GET_POS .LOCAL_ACTOR
; -- Position Reticle
VM_SET_CONST .LOCAL_ACTOR, 1
VM_ACTOR_SET_POS .LOCAL_ACTOR
; -- Clear stack
VM_RESERVE -4
VM_IDLE
When shot, enemies also set a Targeting variable to true. This is used in a switch on the B button to determine whether to fire in the player's facing direction if false or at the reticle if true. The reticle's collision is disabled so all shots hit the enemy its covering. As i’m looking at this while writing i realize i could just have the B button look at $TargetActor just like the reticle actor’s On Update 😅
When not targeting, $TargetActor is set to 0. This is set either when pressing A or the target enemy is destroyed.
And with all that done we have a working prototype. Next time we’ll talk about the larger inspirations behind many of my decisions so far. I didn’t go into as much technical depth as i could have so let me know if there’s something you want to know more about!
Later 😎
🔥