itch.io

Devlog Final, 8/5

The Deadline looms above us all, and I dare say it is finished. Though, I wish there was more I could have done.

I started out thinking "I should keep the scope of the project manageable", and I still had to cut it back at least 3 times. The game is rather simple as it is, and if I may say, probably barely a game. But I have never done something like this before. There were moments of sheer joy when I figured out how to do something and it just worked, first try!

I am grateful to have done this jam. I hope to do more in the future, but I might need a break for a week or two. I think I will continue to update Space Runners from time to time, as I seek to explore and build up my knowledge and skill base. 

Thank you all again for your support and kindness!

https://nerkson.itch.io/space-runners-mgj

One last Devlog, out!

Devlog 13, 8/4

Due to a medical emergency, I was only able to get some work done. Thankfully, the work done was pivotal to calling this a done product! I now have a functional title screen and the game loops nicely. I could probably submit it now and say its done! But I wanna do more.

Tomorrow, I think I will work on getting some hand drawn art done for the game, and maybe see if I can make one more enemy type and then a boss type enemy. Package it all together and see what happens. 

Devlog out!

Devlog 12, 8/3

Today was spent working on the systems for defining the ability for a homing missile. Since I have an understanding of movement on Enemy scripts to the player, I should have most of the script already done. Only one problem with that though - the enemy always knows where the player is! This is because I defined player movement in the Globals script as a Vector2. Its trivial to create movement to the player, and even enemy homing shots, because the players direction is so precisely known.

It is significantly harder to do this for the enemies.

Enemies aren't defined in the global variable and... wait, why can't I do that? Why not just import the enemy TSCN into the globals script as a variable and reference it as enemy_pos.vector2? Well, it doesn't work. A globals script cannot call itself, it seems. I'm instancing the enemies in the first level script but this script has no way to be referenced outside of its script. I have a master level scene and script set up to transfer the most basic stuff to each level - this includes the player itself, the UI, and some basic nodes for enemy and projectile cleanup. I just realized though, since all my enemies always spawn in the Enemies blank node, I could use a signal to check when things enter the tree/node ...

Devlog out!

It's not too terrible hard for a 2D game! Setting up a good Globals script really helps.

Devlog 11, 8/2

Today, a lot was done!

Thanks to the help of selfless people on both the Godot and Game Jam Discord, I was able to figure out a solution to my enemy shooting problem. I was hoping to not have to just copy and paste code everywhere, but for now it seems to be working just fine. Spawned in enemies shoot!

And, thats not all. They also now move!

And can blow up the player too, if you stand still taking screenshots for your devlog. I have GIFs of it all, but making them viewable on a 3MB upload is... not easy.

Their movement is also a bit trickier too, something I also figured out on my own. The enemies will only turn and fire at the player if the player is inside their flagged zone that checks for the player. I simply just tied movement stopping to the player entering the zone, and resuming if the player exits it. With this code, I can now also create a melee enemy that will just constantly seek the player to harm them! More fragile perhaps, but much faster too.

I gave them a red projectile with no enemy collision so they stopped killing each other as well. As far as Im concerned, this is the bare minimum. This is now a game. If worse comes to worse, I can package this together and say I made the worlds easiest shooting game.
I really need to look into adding some rudimentary sound as well, and maybe a background music track. Also, custom graphics for the ship, background space, enemies, and laser. I just need a super productive Friday and I think I can knock a lot of this out. 

I'm starting to feel hopeful again! Thanks to everyone who has helped me so far. I hope I am making you all proud.

Devlog out!

Devlog 10, 8/1

Already August! This year has flown by. Today, some progress was made, but other progress was not made in the same sense. I coded in some flags to help with the spawning.

Every time an enemy is spawned in with the spawning script, 10 is reduced from spawnamount, and that once it is less than or equal to 0, stop spawning. Which means with a spawnamount of 30, only 3 enemies spawn in.

Everytime an enemy's queue_free is called, 10 is reduced from the WinCondition. So, after 3 enemies are killed, the game unpauses a timer that waits 3 seconds then switches the scene to the victory scene. I felt rather clever writing this on my own, as I have largely been dependent on google searches and tutorial videos.

Unfortunately, my largest problem still seems to exist: The enemies that are spawned in do not fire their guns. I have a feeling it is because the main tutorial I followed tied shooting logic to the enemies being avaiable at scene _ready, and not enemies that are spawned in after the fact. Which means I need to find a way to refactor the code to my needs.

Which I do not know how to do. Everything about the above script simply doesn't work for spawned enemies. I'm almost certain I need a func _process(delta): to set the flags of the spawned in enemies, but creating that code with the above does nothing. I am feeling so lost.

If I cannot solve this, then my game is dead in the water effectively. I will have to reduce the scope from 50+ enemies, to just five enemies per level. Which kind of makes the game significantly less... fun. Still technically a game, I guess.

It has been a tiring day at work, and my brain was already sore before trying to debug this. I am feeling exhausted. Sleep time.

Devlog out!

Devlog 9, 7/31

Progress was made, but more questions have been raised.

One of the core systems left to make this an immensely more interactive game is to set spawn locations for enemies to spawn in at. Instead of manually placing dozens of spawns, each tied to their own individual timers, I can simply make a system that spawns enemies endlessly (though eventually, a loop will be created to stop enemy spawns.)

This code makes the magic happen. I'm quite proud of it too, since its code that I thought up almost entirely myself (I had to get a helpful reminder about the global position part from the Godot Discord!)

Here;'s the test scene in action:

Nothing fancy, just four specific markers. When the code is active...

They do spawn right on top of each other. In the actual game they'll move towards the player, which should make this less of an issue I hope?

When applied to the actual scene...

IF you've seen some of my previous devlogs, you may have noticed something. The enemies turn to look at me when they detect the player in their player range, but they aren't firing their gun.

I'm honestly not sure why. It must be something thats part of their spawn conditions, that its not linking to something... but what? I genuinely don't know. IF you know, feel free to poke me.

Some thoughts on whats next:

• With this done, I can work on the shooting part later. I want to try to get the movement part taken care of tomorrow.
• Something else I'd like to do - probably set some booleans for the movement so that if the player is within the shoot range, to stop movement. Then, if the player leaves it, re-engage movement. So they aren't all rushing into melee. This would mean I could create a melee enemy much easier too! Could give it some wierd properties. 
• Another thing I want to look into is homing projectiles - once I figure out movement, surely figuring out that shouldn't be too much farther away? This would let me create the third enemy, a weaker but homing enemy. I'd also like to replace the players grenade with the homing projectile as well, and set enemy kills to refund part of a meter that builds up, that then fires a small volley of homing projectiles.
• Working out health pickups from enemy kills shouldn't be hard as well, the main tutorial I followed had a section on ammo spawns from broken crates that should apply here. 
• Finally, a boss character. But what can the boss do? How do I make it boss like with very simple understanding of programming? Much to think about. Worst comes to worst, I can just make level 3 a super intense level of enemy spawns.

Devlog out!

Devlog 8, 7/30

A lot of core systems got done today!

I managed to finish 12 hours of tutorials for this project, and the game is starting to finally take shape. 

I added in a system that gives enemies and players invulnerable frames, so they dont die quite as fast. Scene Transitions are fairly simple in Godot, so a quick "You win" screen transition is possible! A bit ugly, but ugly gets games made. 

I also coded in HP and damage values, so that now the player can gain and lose HP. If the player hits 0 HP....

Dirty, ugly, simple. 

Getting the animation to play *before* the Queue_free and making queue_free wait until the animation was done was a bit tricky at first, but I realized that in Godot, the animation player can have timelines of functions. Just put the queue_free in a custom function and shove it at the 2 second mark of the animation, and voila! 

This is starting to shape up. I feel that with these accomplishments this weekend, the last 6 days are going to be frantic, but doable. This is my final list of what I want done, at the *bare minimum*. 

• Enemies move and follow the player. Ideally, they only move to stay within a specific range. Shouldn't be too hard to do? 
• Code a few more enemies. A melee enemy that rushes the player and explodes, and maybe an enemy that fires homing shots. 
• Speaking of, I want to change the players grenade to be a button that fires a small volley of auto homing shots. 
• Add health and ammo pickups from fallen enemies. The tutorial I am following has these pickups available from items... I should be able to repurpose the destroyed enemies for this as well. 
• Code in a mini boss that fires enemies that home in to the player, and a final boss that is either just a tougher version of the mini boss, or a boss with multiple stages.
• Add in enemy spawns and make a system that configures the enemies to spawn in.

I've decided to re-adjust the scope of the game from 6 levels to 3. Meaning that the first level is just basics against waves, second is against waves and then a mini boss, and then third is against waves, then boss. Its a bit dissapointing, but will allow me to quickly get this out by Sunday. Its finally starting to take shape!

Devlog out!

Enemies can be tricky! Keep at it friend, and always feel free to post if you need help.

Devlog 7, 7/29

No Devlog for 7/28! We had some rough storms and it was best I take the day off for safety.

Progress is slow, but it is surely starting to come together. Some of the things I've done yesterday and today are:

• Set up functional UI that is responsive. The UI will now properly increment and adjust to real time statistics.
• Create Item Pickups that recharge the grenade and health of the player! As above, they also properly increment the UI so the player can see that they work. They also change color using modulate depending on if they can be used or not.
• Created my first enemy that can fire lasers at the player!

Its a very basic UI, but it gets the job done. I still have a counter for player ammo - a hold over from the original design where the main gun had an ammo resource. I feel its best if its just infinite, and the grenade does all the heavy lifting. 

Apologies for the small gif, but it should show that there is indeed an enemy (and if you see a red dot, thats a pick up!). The enemy has a hitbox range thats very adjustable, and will probably need to be adjusted eventually. Right now, projectiles are queue_free after two seconds, so I need to make sure that the enemy doesn't fire beyond that range (or the player can outrange the enemies for that matter..)

Right now, the enemy doesn't have a real health bar, but I feel that I'm starting to understand the logic of coding a bit better. To me, it seems like I need to set some variables in global that dictates enemy health, much like how it currently dictates the player HP. Then assign a value to the laser that says it -= that variable by x amount, and then if the globals.enemy_hp is == 0, then queue_free the enemy from the tree. No more enemies! It would also work for the player. This is already 3/4 of the way there towards a victory/lose condition as well, where I can add additional code to those elements to immediately transition the current scene to a pre-made "Victory!" or "Lose!" Screen.

Right, so for Sunday, 7/30, I'm thinking the following should be nice:

• Get the health values and damage values worked out
• get the enemy to follow and fire at the player. 
• maybe work on an enemy that does a short range melee attack, giving the laser enemy some breathing room. (Though, I think I see some issues with this. The enemy laser is just copying the player laser, which means it would cause friendly fire... Do I need to create a secondary laser thats just for enemies to use, that ignores enemies? This is probably not too hard to do, but I wonder if its inefficient versus another coding example that might make things work better...)
• Work on the scene transitions to quickly create a win/lose screen. 

If I can get even most of these done Sunday, I should be left with plenty of time to really give the last week a run for my money! This is exhilarating, though I've definitely begun to felt the creeping sensation that it wont be done. I have to hunker down, ignore the distractions, and get working.

Devlog out!

Devlog 6, 7/27

What a week so far! Thankfully, I have a lot of time this weekend to really make the game pop. For now, todays accomplishments!

Making more levels is one of the MVP goals for this game. Perhaps it is not entirely MVP, as I could probably make a game with a single level, but breaking up assets and codes into more manageable chunks that won't interact negatively with each other helps more than anything. To keep that goal in mind though, I'd probably want to avoid actually just copying and pasting the same code a dozen times for each level, determining things like player movement, projectiles, and more. Thankfully, Godot makes this easy with Inheritance. Instead of making a new scene, you just make an Inherited scene.

It really is this easy.

This means I can now delete assets from my previously only scene and put them into their specific level scenes, so I can keep the code all neatly nestled in one place, and the assets in another. 

So clean.

So much pizazz!

Now Godot is supposed to show inherited nodes in yellow, but it seems to forget to do it sometimes. It's okay Godot, I forget things too. 

This is fine and all, but I also need to make sure to change the scripts. By default if you just inherit scenes you are still sharing the scripts with the base master scene, which can break things like signals. A few lines of code fixes that though. Put the following in the Master Scene and...

.. Then change the new level scene to extend this class_name.


And thats it! Now you can have all the parent code in the Master scene, and you're free to add level specific code in each levels scene. Simplicity!
I also began working on the start of a user interface - for this project I will leave fancy, colorful graphical interfaces to my "Nice to have" list. Text will work for now. Fun thing I learned about interfaces is that, if you don't anchor them, they stay in the exact pixel location you put them at. Anchoring keeps them relative to the games window, so they move with different screen sizes.





So far, I'm quite pleased with this project. I know I didn't get as much as I wanted done this week, but I have to admit I am human and that if I am too tired to think properly, I'll end up getting frustrated and lose more time than I want. I plan to sleep in tomorrow just a smidge, and then after some morning chores really dig into this project with gusto.

My main goals for Friday, Saturday, and Sunday are :

• Create a responsive user interface
• Create item pickups that recharge things like the grenade
• create enemies that have things like HP, and can damage the player

If I can do more than that, I'll try to aim for figuring out how to spawn enemies in, and creating win/lose conditions that transition the game to a new screen. 

Devlog out!

Devlog 5, 7/26

It's probably a rite of passage, but I somehow messed up my entire game. I'm not entirely sure how I did it or why. Without going into too much detail, I moved around some items in the default level and it somehow messed up my signal sources. I had to spend two hours painstakingly trying to fix the issues before I gave up and wiped the code, restarting a large portion of the project. It did go faster the second time, and the issues are fixed. 

What little time I had left was spent learning and working with the particle emitters in Godot. Perhaps a bit flashy, but it never hurts to learn something cool in between the practicals.

Tiny particles, woo!

I'm hoping that tomorrow is more fruitful of a day. I believe the next few things in my learning set is going to be how to create instanced worlds and interiors. Frankly, it doesn't really apply to me but I'll watch it and make sure I'm not missing anything. 

I've been thinking, and I believe I will end up doing 6 levels, instead of five. 

1. Entry level, that introduces you to the basic controls
2. Level 2: You learn about some of the enemies
3. Level 3: Mid game boss fight
4. Level 4: Some more enemies
5. Level 5: The hardest waves yet
6. The final boss. 

I'm not exactly well versed in game design, so I'll probably have to make more adjustments as I go.

As it stands, I have the following skills left from my MVP list:

• Creating an enemy AI that can attack the player
• Finding a way to transition from one level to the next
• Spawning in enemies
  
  • This includes things like triggers for spawning, setting in locations, etc.
• Creating a win/lose condition
• (Optional) creating a story, with text boxes that pop up when certain events are triggered.

I do feel confident that by this Saturday, 1 week into the project, I should have accumulated most of the skills I need to get this list done, which would leave me a week of refinement to really make the game pop.

Devlog out.

Devlog 4, 7/25

Today was spent learning more core fundamentals. While I feel that not much progress was made into the game overall, I do feel that what I've learned will be very helpful. Behold, learning how to properly do masking layers!

When Godot works, it works.

Learning how tile maps worked, as well as how to add collision layers and masks to them is quite fantastic. I always wondered how some games did it, and Godots way of doing it makes sense. 

I also got a proper tilemap for the background, as well as figured out how to layer tilemaps so I can choose which is on top, and which is on bottom. 

Not much to show for today, but it is still progress.

Devlog 3, 7/24

Not much progress was made today - in fact, most of today was spent backpedaling. My eagerness to apply new techniques and search up various new ways to do things in the previous days got me into trouble, namely that I was using a wide variety of code that didn't mesh with each other (and most importantly, the main tutorial I am following). So, I made the difficult decision to go back and simply redo everything according to the main tutorial, which meant re-learning some things to the Godot 4 standard.

Silver linings, I suppose, I learned some better ways to use signals and I think I'm understanding more overall.

Today's Dev Log might be more introspective than other logs will be. Going back and redoing things has left me with more time to think. I still don't believe I'm fully understanding what I'm making here. I'm good at following tutorials and directions, and I do believe I have a decent degree of logical thinking that when certain concepts are explained I go "Aha, now it makes sense!" but the real clincher of "why" still eludes me to some degree. It's probably to be expected, given that I have no real coding background or any form of programming experience, but it is filling me with a disheartening sense that I don't deserve to make a game that I barely understand. I will simply have to put these feelings on the back burner and approach them later.

For now, I will leave this log thinking about a puzzling situation I'm in. The tutorial uses a gun with 3 different position markers, and it cycles randomly through each one to fire one singular laser. A neat effect, but not what I had planned for my game. I wanted to fire a laser from specific position markers at once (and eventually create a power up that allows one to go from 1 position marker to 2, to then 3). 

Done in GD Script, the code seems to make sense to me. I'm defining the laser start positions childrens as a variable named laser_markers. A second variable then pokes inside laser markers and picks one randomly. However, I cannot get it to work as I'd like. Trying to manipulate line 26 to include all 3 position markers doesn't work, it only wants one value. I feel like I should be able to declare something in laser_markers[] that would just tell it to fire all 3...

Signing off for the night. May tomorrow bring some new perspectives.

Devlog 2. 7/23

A busy day. I tried to familiarize myself with Godot 4 as much as I could, but as stated previously my skill level isn't quite high enough to do much with it. Yet.

For now, I have downloaded assets largely from opengameart.org - their collection of assets is quite high and will serve my needs until I can make some more bespoke solutions. I set about importing my assets into Godot and I began properly. Setting up the player wasn't too hard, and some information from my very limited time working with Unity actually came in handy - how the sprite is a combination of a hitbox, a 2d node, and a character node. Very quickly I was able to produce the most rudimentary beginnings of a game. 

Not terribly riveting stuff yet.

 The asteroid has a rudimentary collission and while the main tutorial did not go into the mouse look yet, I simply googled answers and slapped some code in that seems to have worked. I did work about 50% through GDQuest a while ago, and I remembered some stuff from that and pulled out my notes. Linear extrapolations being called lerps still makes me chuckle a little. 

Now that I had a ship that moved, the next step was firing a weapon. Once again, the main tutorial is more inclined to teach me things like best practices and a more step-by-step basis to creating a game, but since I was eager I simply used some of the tutorials in my saved playlist. 

I am not moving the ship while I fire. Kind of amusing actually, you could probably make a game about a terrible ship that can only move by firing its gun.

I had an inkling of a reason why it was doing this - the bullets were colliding with the ships hit box, and there was no delay on bullets coming out so it was like a fire hose.

Here's some of the code I used, mostly cannibalized from many other online places. I created a Cooldown node and assigned it a value, and imported it in the main scene. I then created a variable version of it called cooldownTimer, and added an And statement to check when its done - it will only fire while it is available to start. 

Some fun I had here as well - a lot of older Godot tutorials for 3.0 reference instances. In 4.0, instance was renamed to instantiate. Food for thought. Some parts of the code are still going over my head, but I know it works. I created another 2d node on the ship and moved it towards the front of the ship where the main gun is, and saved it as a tscn file. Then, I could reference it in this document as the source of bullets, avoiding my hitbox entirely. The next few lines I'm still not entirely sure about, but this is probably in case the projectile being fired isn't a sphere and would thus keep it at the same rotation as the players ship, so they're not firing sideways lasers. I'm still not 100% sure about get_tree. I believe what its doing is that, since the bullet doesn't exist in the instance off to the side, it has to add it to the list of nodes? Finally, the code block ends with a call to re-start the timer. 

Thats more like it, though the bullets kind of plink off the asteroid and look weird. Continuining with my diving, I realized I'd have to set up a few statements and groups, that if the bullets collide with a hitbox, they are to be destroyed via queue_free(). I also wanted a quick animation for when they collide and are destroyed.

I can work out quirks like speeding up frames later, but for now? This is working. Although, its kind of boring that the ship doesn't have a camera following it, and that its floating in a grey void, no? I thought so at least, so I set about to fix that. What I honestly thought was going to be a difficult challenge rife with dozens of lines of code was actually one of the easiest things I've done. Just add a camera node to the parent of the ship and voila, thats it. The backdrop wasn't difficult either, but its not quite tiling to a degree I want. I'll have to figure that out later, as its a very minor concern for now.

Side note - Gifs are really hard to work with. This 15 FPS gif had to be reduced in size significantly just to fit under 3mb, and I could still only capture a few seconds worth!

With a backdrop and working camera, I can safely say I feel productive today (though I am sure there are people out there who are already steaming ahead with a lot more!). 

With a functioning ship, camera, and obstacles, my MVP list now has the following remaining:

• Creating of an enemy ship, with a very basic AI that is designed to follow the player and shoot.
• HP values for both the player and enemy, and a destroy function for both if they take too much damage.
• A victory or lose condition that then applies a screen for game over. 

I have some faint ideas about the enemy ship - I know I can easily replicate the player ship, swap over some of the nodes for the gun, and swap out the bullet color for enemy bullet colors. Making it follow the player but not get too close might be trickier. Dumber enemies would fire slowly and not update the players position as often as stronger enemies, who would fire faster and track more aggressively. 

I've set some goals for the upcoming week - as I am entering a work week, I will not have as much time to devote as I do the weekends. I'd like to ideally have enemies figure out by the weekend, with a bonus towards a game over screen for either a loss or a win. With those elements, I could then work on additionals that go above the MVP list : Multiple levels, more complex behaviors like enemies warping in, longer levels, the whole nine yards. I could even add in particle effects and lighting effects to really take things to 110%!

Signing off for the night.

This is Developer Log 1 for my game submission, Space Runners, dated 7/22 (I know this is being posted on 7/23, I had an internet outage and went to bed.) Truth be told, I've always wanted to make games but have never stuck with it. Either life or other things get in the way. Being pointed towards this jam by a friend, I figured it was time.

It is also worth mentioning I have zero. None. Nada. Experience with game development, design, and programming. This might be a bit hard.

We all have grand ideas, but you gotta walk before you can run, and you gotta run before you can complete in an ultra marathon. So, with that said I decided to pick a topic that was near and dear to my heart- Shoot em ups. Games where you shoot stuff with a space ship or airplane were my childhood, and I wanted to re-create that level of game.

It also helps that this type of game is probably the most feasible project I could approach as well.

With that said, I spent today working on setting goals. Using Trello, I set up some task cards. After deciding the game genre, I worked out some core-cards.

I set up an MVP list - the Minimum Viable Product. This list represents the bare-minimum of what is necessary to make a video game "a video game."

•  A set of graphics to represent the player, an enemy, the background, and some sort of projectile to indicate that you were firing.
• A boundary that keeps the player and enemy inside the map.
• A script that would allow for the player to move and fire their weapon.
• A script that gives the enemy a rudimentary AI to pursue and attack the player.
• A set of scripts to set up Health values for both the player and enemy, and sets up damage values for attacks done by both player and enemy alike.
• An end of level condition that, when met, finishes the game- Success or Defeat.

I consider this to be the most minimum requirements for this game. Fancier things like sounds, plot/story, background music, and more enhanced game-play elements like obstacles and special attacks are secondary (but hopefully I will get to add them to some capacity.)

For my full game submission, I have compiled the following requirements:

• 5 to 8 levels, each introducing new elements from the previous level. (I will probably lean more on 5 levels for now.)
• Waves of enemies that spawn in, either on set timers or when the previous wave is defeated.
• Dangerous, moving obstacles in the way of asteroids
• A boss fight against a mega ship, with multiple stages.

Next, I set about researching engines. There are several fantastic 2D game engines that I saw, several of which offer extensive tutorials on making the exact type of game I want to make. What feels like extreme restrictions and frankly expensive pay requirements put me off on using them, however. In the end, I decided on the latest revision of Godot. While it will require more scripting and programming research, I believe this will help me develop better practices, especially if I decide to participate in more jams. 

To end the day, I began compiling godot tutorial youtube videos in a playlist for future referencing. A similar game was referenced in a 12 hour long godot video (!!!!). While a bit longer than I hoped, it is very thorough and should provide me with a few days of work easily. The video playlists will cover a wide variety of topics and should allow me to reference them when I need to clarify something or just need a break from coding to let my mind unwind. 

For 7/23, I have set some planned goals:

• Review Godot Documentation and try to understand more of this environment. With my level of understanding being firmly on the floor of this knowledge house, this might not do a lot for me but at least I'll have it available for when I need it.
• Continue compiling resources - tutorial videos, free assets, etc. My end goal is to use 100% bespoke assets created by me, but if I must use others assets I will need to ensure they meet with the CC license requirements.
• Begin organizing my folders and creating a neat space for me to drop assets.
• Double check to ensure I am not missing something. Surely I must be..
• Begin compiling a "nice to have" list. This will go after the MVP list and will list things I'd like to see in the game to hopefully make time for.
• Begin coding.

Well, here goes nothing.