Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

DevLog: "Blow up the Death Star, again"

A topic by GriffinVarro created Jul 24, 2023 Views: 424 Replies: 13
Viewing posts 1 to 14
Submitted(+1)

"Who are you?"

Hi, I'm GriffinVarro on various platforms. I've been coding for over a decade but haven't managed to produce a full game in that time. I want to use this game jam to push myself to make a complete product, and pick up some more skills along the way. Unity is a fun and easy engine to use and will be my focus, and ideally by the end here I'll have practiced some basic art a bit more and learned how to make sounds and songs for any future projects.

Game Thesis: Blow up the Death Star, again

After some thinking on Day 1 I decided on a few things. With the theme of "Cycles" I want to hit two marks; the first is the meta-narrative with the work-in-progress title above. The player will be a space pilot infiltrating a large space station with a giant laser with the intent to blow it up. For the very light narrative, this circumstance happens again and again; the player will have to defeat several to end the game, but probably not end the narrative cycle. The second mark I want to hit is Cycles as a game mechanic in some way. Obstacles operate on some sort of rhythm, and the player should have some ability to control it. Perhaps the player could slow down the cycles of the machine to get through dangerous obstacles, or speed it up to get to a desirable point.

For the actual gameplay, I figured I'd attempt a space-physics drive top-down shooter. My first attempt at making a space-physics style game similar to this was with the LOVE scripting engine back around 2010-2012, so it's been on my mind before. Unity is very handy when it comes to very rapidly making a game if you want to make it physics-driven entirely, so the choice is easy. Players then should be able to move, stop, shoot, and use their ability. The game will also need obstacles like smashing zones or turrets firing at the player for the player to destroy.

If and when we get to level creation, I think this idea would work best with 3 possible levels; a simple introduction to the idea and challenges, and two more increasing in difficulty. In an ideal world maybe these could be procedurally generated forever but I don't think that's within scope for a gamejam, at least not my first one.

Actual Coding

With some free time Sunday and the basic ideas in mind from Saturday, we've made some progress! Our first goal was to get a our player moving about which took just a moment; WASD to apply force in any direction with gravity set to 0 worked perfectly for the feel of preserving momentum in space. I quickly made up a prototype ship to slot in since I'd need to know what direction it was facing; actually getting it to face the right direction proved a bit of a challenge but helpful gamejam folks pointed me a bit more in the right direction. With the ship turning and moving properly it already felt like a space game, but the strafing + mouselook combined feels a bit awkward and results in some very quick and unpredictable spinouts as the ship ends up tracing a very very wide circle. That's something to put a pin in to tweak later.



I decided to set up a turret next; I quickly drew a drone-looking spirte and could copy over the code from the mouselook function to have it face the player at all times. Firing a laserbeam is pretty straightforward, but positioning was trickier than the previous rotational trouble I was having. I needed to spawn the laserbeam object at a short distance from the turret, in the same direction as it was facing. I started with a hunt for trigonometric solutions but couldn't quite get anything to work until I discovered the Ray object had a function to get a position X units down its length at will. As long as I could point the ray in the same direction as the turret, I could spawn the object anywhere infront of it that I wanted. The important lesson I learned here today is that if a function calls for a normalized vector, it doesn't need a normalized vector at all; target - ourPosition inserted will get the correct result for a direction Vector3.


To finish things off, I made sure the newly spawned laserbeams would die after a few seconds, and die on impact as well; the first prevents garbage piling up, the second lets me insert future functions for damaging the player or producing other effects. The laserbeam uses a AddForce function to push itself through space at the player and I think around 30 units of force seems about right to start being a threat; the default 5 I set is almost comically slow.

The final look




Ultimately the result of today is pretty basic, but still a successful day of getting something out the door and functional. Hopefully once new features start popping up it'll look quite a bit more like a game.
Submitted(+2)

This sounds amazing! Great idea, looking forward to it

(+1)

This idea sound fun and  overall great! Exited to follow your progress and watch what you develop.

Submitted(+1)

Thanks for the support! I might be slightly more busy the next two days, but made plenty of progress today.

Progress

Today I started with a pretty simple checklist of things to do; Add walls, a laser dish, and a core sprite to the game. With a little collision I had a very basic level to fly around. I gave the player the ability to fire as well and implemented a damage system. Both Player and Enemy controllers have a Damage integer they pass along to any laser they fire, and when it collides that laser communicates the damage to the Player/Enemy. The script calls the damage function and if it goes below 0, it deletes the object. I think this was the most fun to work on today and between damage, HP, fire rate and fire speed together there's some fun variables to tweak; When testing I've gone with 10 HP to the player and 2 HP to the turrets, and both sides do 1 damage.

When testing player firing earlier, I couldn't quite get the laser to spawn at the proper location and so I added it to a new friendlyfire layer and instructed the physics collider to ignore that layer, and it worked out pretty well. I've noticed the turrets have been murdering each other if tricked into firing along the same angle, and I'm uncertain if I want to change that yet or keep it in as a fun thing to attempt to do in play.

The game is now far more gamelike and even a bit fun to play, so I've also set about learning how to implement particle systems for an explosion once the objects die, and how to play sounds when they each fire their lasers. Adding sound was pretty straight forward and didn't require much wrangling; I used Chiptune at https://sfbgames.itch.io/chiptone to create some noises and made two separate laser sounds to differentiate player and enemy fire. The particle system was a bit involved with all of the variables to control to get the right effect, but setting it to spawn and play was also incredibly simple.

The last thing I wanted to do today was investigate UI elements to display a "game over" and "game won" tagline when the right conditions were met, but I struggled a bit to find the right iteration of UI info to use and then to understand the css UI interface in Unity. I can write up what I want on screen but I'm still unsure how to actually call and manipulate it from a script. I decided to let that stand and try again another day.

The Future

I've been keeping track of a list of goals to complete daily and so far the method is working out just fine. It's not exactly an agile/scrum methodology but I'm setting milestones and knocking them out as I go, and leaving the list open to add things as I go. I could have always started with a larger design document to work off of for all of my goals but I think that'd use up a lot of time compared to figuring out what this game will be along the way. My next set of goals is to keep hammering away at the UI until I can get "game over" and "game won" screens, establish a condition for the player to "escape quickly!" after destroying the core and lose if they're not fast enough, display the players HP on screen either as UI or a game object element, create a main menu, and create a basic bit of music to play while the game runs. Further down the pipeline I want to see about creating a cutscene, or maybe have narrative text shown to the player as they play; or both. Other enemy types I think are also on the table; a sniper that fires much faster projectiles, maybe a tracking rocket that must be dodges, or mobile enemies that orbit around the player. We also have the general obstacles to keep in mind too; the crusher idea should at least be tried. 

To show what I have so far now, here's a video showing off the gameplay


Hopefully with another day of work we'll be one step closer to a full game!


Submitted

Progress


Back at it again today and things are going swimmingly in terms of progress. While I'm still a bit staggered by UI CSS at the moment, I did still find a simple method of displaying a bit of text on the screen about the mission. We have "Mission Failed" when the player explodes, "Mission Success" when the player blows up the core and leaves, and "Self Destruct Activated" to tell the player to leave once they exit the core. So while the game doesn't quit and close out on you, it will at least tell you that you won which is a huge success.

Today I also implemented two simple gameplay elements; a door and a crusher. The door is simple; if you destroy the nearby core "keys", the door changes states and opens. The Crusher meanwhile starts at one position, moves to another, and does so every X seconds. When it comes to creating a cycle or tempo to the game, I can make sure it syncs up in multiples of seconds with everything else. I decided to simply make the entire thing active and damaging, and pretty severely at 5 damage right now compared to the players 10 hit points. Calling it some sort of force-barrier thingy that damages seemed sci-fi enough and simpler than trying to go for specific-sided hurt boxes during motion or some such to actually crush the player. Two of these together would still get the same job done.

Enemies now will cease fire when the player is not in range! This might prevent a few friendly fire incidents where a more distant turret is firing at the player through a nearer turret; this can also be prevented with game design by putting blocking terrain, but I felt it important to not have a future large group of entities all making more calls when they won't be doing anything useful. In light of that, I also decided to turn every enemy onto a global firing time. Instead of personally tracking the last time they fired, every enemy will fire at a designated cycle if it can. If these are made into multiples of each other then we can get some staggered firing going on with different groups of turrets, and create that cyclical feel we're looking for to meet the theme.

I think the most interesting thing today though was a stab at some music. I found a sequencer (https://onlinesequencer.net/ ) that seemed like it had a variety of options, a simple interface, and import/export functions. I've played music before, I have a very very basic idea of musical theory, and I've heard people talk about composing before; so short to say I knew nothing. I looked for a synth instrument, set up a minor scale, and had the top and bottom of the scale play an appropriate chord and that fit about half of what I needed. It's not the worlds greatest art but it was pretty servicable. I added a competing descending scale in opposition to the ascending minor scale I had, put it into big long whole notes and set it to a harpsichord and it gave the whole thing a little extra oomph. It felt a plenty spacey and a bit clockwork; ultimately a very simple 4 measures but it felt very slow. I would compare and contrast the sort of slow methodical energy I had found against this track for an old favourite game of mine

There's a lot going on there that's a bit above my composition level here, but I think half of what gives that track its energy is that it has a beat and mine really doesn't. It's not complicated either; two short beats and a longer one. There's more complicated stuff happening there too if you listen in but i think that's enough to yoink and try to add in some energy, and wouldn't you know it, it merged together kinda nicely. If you want to listen to the current theme, you can use this link: https://onlinesequencer.net/3527930

Checklist

There's a lot more I can do for the game now, but I think we've hit the lowest bar now for this being a completed game. It has the bare necessities to actually be fun on its own. That said we have plenty more work we can do, and levels we can design too which aught to be extra fun. To round things out, this is the list of things I'm thinking of next.

- UI Element for players health

- A Main Menu for the game

- A player controlled stop/slow power

- Crusher collision noises

- Player hurtSound

- Crusher appearance

-- Everything could use a replacement for their filler look

- Make it more obvious that the core does something with the laser dish and that's why it's big and important. Means a dish redesign.

- Make the door key objects look different than the core. They probably should end up color coded with doors as well ala Doom keys and dors.

- Give the player an "engine" sound when manuevering, and maybe an engine flame effect too.

- Background needs objects that the player can use to orient themselves and not get lost in deep space. Deep space likely needs a technical boundary as well.

Submitted (1 edit)

Progress

Hitting a group of daily milestones seems to be working out well. Getting at least 10-12 things done feels like a good pace, though I think some things might simply take more time in the future like using all the elements I have to make a newer, bigger level and not just the demo I have now.

I started by updating a few images and sounds; the Crusher has a noise when you collide with it distinct from others, the player makes a sound when hurt, the Crusher now looks like it's dangerous on all sides with a forcefield look, and I changed up the laser dish to be more inline with the rest of the structure. Originally I was trying to go with that Death Star concave laser lense feel but it didn't look good even as a place holder. This one I think has directionality to it and it should be more obvious what it is. Maybe I should have it fire a big laser every now and then, but that might just not get seen or noticed. The Door Keys also get a new look, more plainly circular and easily color coded. I can color up the door sprites as well to reflect to the player which ones they should be after in order to progress.

I finally prodded the UI a little bit more and while I'm still confused by it all, I did manage to replicate up a heart system and make the hearts little batteries. I have red ones for health right now, and blue ones for the power bar later. I don't think there needs to be a lot more UI now aside from that; maybe a mute button? I currently have that just bound to M.

I also crushed a few bugs that started to show as I messed with more things. I realized that the doors weren't deploying a proper opening sprite until I could give it the right instantiate command. Supplying a transform directly resulted the newly created door being a parent to the old door, which got destroyed, destroying itself; not to mention the coordinates where it got deployed where all out of whack. I also found out that while deploying the UI that I could now go past 0 hp with a large enough boost from the crusher; this was because of an overflow at the UI level that when it sent an error stopped proceedings in the rest of the method that called it.

Critical to the actual game itself, I set up a slow time power for the player. It technically only slows enemy turrets and the crusher but the modification required was pretty light; really just altering the deltaTime variable for when they do their update activities. Effectively, I can now make turrets and crushers more dangerous and rely on the player to decide when they need the assistance. We can also go ahead and call this ludonarrative consonance; the player can only slow the cycle of the machine mechanically, and can only slow down the narrative cycle of violence itself. Always helpful, but never enough.

Checklist

I think there's more things I want to do that are conceptual and interesting additions, but there's plenty still I need to do that's still critical. Our checklist now is

- Create a UI element for the players current power charge

- Create a soundeffect for the players power when it starts/stops/is ongoing

- Create a Main Menu for the game

- Create a Cutscene to deploy some narrative

- Change levels as the player completes them

- Get some fanfare for success

- Better Music, Better Background that's not just a wallpaper, Better Sprites

- Brand new levels 2 and 3.

- Possibly redo player breaking to be more icey.

- Create a mobile enemy ship

Submitted(+1)

This is really starting to take shape, you're making good progress. I like the sound and particle effects when you blow up a turret.

Submitted(+1)

You're doing really good! The gameplay and especially the movement look really solid.

Submitted

Playtest!

We now have a playtest, and you can find it over at this link! https://griffinvarro.itch.io/blow-up-the-death-star-playtest

Progress

We swung through some quick updates to get everything ready for the playtest thread. We added a power bar for players to tell how much power they have, the ability to actually leave the game when you want, have scenes change when you fail or succeed a mission, and created a whole brand new level for people to play.

Feedback

Like in the above link, I think I'm looking for gameplay feel and difficulty comments; is the game actually fun is my main goal to hit. Other commentary is welcome as always. If all is well, I might be able to push to make the sprites or music better with any extra time.

Submitted

Progress

Started today with doing some 3d modeling for my 2d little game. I wanted to see if I could drop in a spaceship model and give it the same 2d collision and have it work, and short to say; it -could- work, but would require a fair bit more work all already to get going. I got it rotating but it wouldn't fire or move correctly. Being outside of scope, I still had something else I could do; take a render of the 2d model and use that for the spaceship! It certainly is a lot sleeker than the rapid drawing I did. 



I really do like doing 3d modeling, and I think if I had the time I would redo the basic walls, background, turrets, cores, keys and doors. Not improbable but I want to focus on finishing things off first. I did go ahead and make my own starfield to replace the desktop background I was using for space, and the result is also quite a bit cleaner and also tiles much better as well.



The background has a few very bright stars which should make finding the player position much easier, and in addition I added a rotating planet to the background that should be a nice big obvious landmark that'll be hard to miss if a player is trying to 'refind' the level within the generous boundaries. I was fortunate enough to remember too I had a planet texture I made back in 2008 perfect for the occasion; essentially just a mixture of blue and green cloud filters set up to layer and then tiled. I'm going to put a pin into making a handful of those for future reference.

For one last addition, I have now established scenes for and fully written out my cutscenes! I think the basic narrative I have will re-inforce the theme enough to give the project a sense of completion. Just having time to breath between levels alone already makes things much smoother. Word count for the plot comes out to 1600 words between 3 scenes, so just shy of the about 2000 I'd write if I was running a ttrpg session. The roughest part was figuring out precisely how wide I could get with each line and making sure to pre-write in a very forgiving way to the space, all for the sake of a starwars-esque title scrawl.

Final Goals

Since we're in the last week and nearing the end of the project, the last big thing to do here is to create the 3rd level. There are still plenty of tweaks and final additions I want, but everything is now optional. Sounds and effect for the players power, music for mission success, a full 20 bars of musical theme, a cinematic theme, a defeat theme, having a player hit-effect, a healing item just to reduce the difficulty, and setting the self-destruct timer to be more generous and appear on screen are all on the table. Additionally I'd love to be able to do all of the artwork in a 3d render style.

Just a few more days to go!
Submitted

Progress

Progress today is simple, I started work on Level 3. Level 1 could be said to have 1-2 sections, and Level 2 has 6 sections. The new level has 11 sections and I managed to fill up 6 of them. I think overall I'm running into an encounter vocabulary problem given I have 2 different challenges. For an example think of doom: You have Imps, Pinkies, Cacodemons, Chaingunners and Barons to spread around. The combos you do these in, their arrangement, if you do it by surprise, etc. all comes out to very different encounters. I have Turrets and Crushers, to mathematically I have something like 4 different encounters (None, One, or Both). Crushers so far have had the most versatility; their angles, number, spacing and speed all come together to make different movement challenges, and I've extracted value there. Turrets though have 1 real value; number. As far as I've played and built, going higher than 8 in a section is likely too much. You could ask people who play DOOM to fight 8+ Imps, but they've been playing the game for over 30 years now. People will be playing mine for 10 minutes; it's bound to get unfair very fast.

At least in light of unfairness, I think once I finish up general design of Level 3, I'll implement a healing item to full heal the player on touch. The mechanics for this already exist in the code, they just have to be activated. I think ideally, with this level and that item, I'll call the project complete.

Submitted(+1)

I'm really looking forward to playing this. The updated artwork and background looks great.

Submitted

Just about there!

Progress has been good today. I completed the final level for the game, added a healing item to reduce the difficulty of the game, and redid all of the art elements. I have a little more time but I think I'm ready to call it finished on the project, even sans additional music. While I have a fully built game stuffed into an exe I can run and let install for people, there is just one more thing I'd like to try to do; not have the game get flagged as a trojan by windows defender. I've received some pointing towards code signing, and it seems like a lot to wrap my head around. I'll be giving it a shot tomorrow and if it seems too much, I'll go straight to submitting the game.

Submitted

Release!

https://griffinvarro.itch.io/blow-up-the-death-star-again

The game is now completed and this should be the last build I need to do! There's still technically time, but I'm going to take the rest of the game jam to relax and enjoy completing a whole project. Things are way more fast paced than I'm used to working on projects but I think it was a good push to get my going and to stay focused instead of falling into feature creep. I'm excited to here what people have to say, and hopefully, people can have fun playing it.

If there are any errors that occur in getting the game to run, I'll see about some last second modifications.