Built a full playable game from the Laser Defender tutorial!

Sooo, I went a little overboard on adding a truckload of features to my spaceshooter game, which took root from the Laser Defender tutorial in the Unity 2D course. It was a lot of fun, but admittedly the feature creep got to the point of absurdity and I had to start aggressively cutting scope in order to finish the game. However I’m thrilled with what I was able to pull off from humble beginnings!

I called the game Lord Hyperion Star Hammer and it’s playable in the browser on Itch (gamepad highly recommended) → https://donjuanjavier.itch.io/lord-hyperion-star-hammer

I would LOVE brutally honest and candid feedback if you are interested in trying out the game!

lvl-open
Opening Sequence for Final Level

I learned a freaking TON making this game. I paired the knowledge gained from the Unity 2D course with some Brackey’s YouTube videos and other tutorials to add a bunch of additional features such as:

  • Upgradeable weapon system
  • Halo-like health / shield system
  • Lots of different enemy types with unique behaviours
  • Various sandbox elements that interact together to make chaotic fun - such as mines, asteroids, nukes, missiles, destructive environments, massive beam lasers, etc.
  • Using dynamic physics for everything (this was a nightmare to get working correctly)
  • BattlePlayer system that cycles through a sequence of events and waits for different types of triggers
  • Utilizing the Unity Animation system as a State Machine for boss fights
  • Leveraging ScriptableObjects to hold global game state
  • Actions, Events, && UnityEvents to make the code SUPER de-coupled
  • Dynamic UI elements such as nav markers, moving healthbars, enemy death score text, etc.
  • A coordinate-based spawn system
  • And a whole lot of other stuff I’m forgetting


Inspector View for a BattleSequence that gets played by the BattlePlayer - the Unity Inspector is fully customizable!

Additionally, I originally planned to make the AI much smarter and started learning about Finite State Machines and Behaviour Trees (eventually I had to de-scope and stick to simpler enemy AI, but will likely pick up on this topic in the future!)

the-gauntlet
“The Gauntlet” - a very tough section to get through unscathed

Playing around with particle FX, screen shake, sound FX, gamepad rumble, and other Juice was a lot of fun to implement. Crafting a fun experience is a heck of a lot of work but is SO worth it!

If you want to read more about my experiences with this game, feel free to check out my DevLogs. :slight_smile:

I’d love to meet other devs, artists, designers, etc. so please feel free to hit me up! I would also love to hear about what you’re working on, your war stories, etc.

Cheers!

3 Likes

Congratulations on your game :partying_face:

1 Like

Thanks!

Did you use a particular pattern to create the BattlePlayer system? Just asking because I did something similar for a game I’m working on (nothing as big as this).

Thanks for asking! The pattern / system is basically it’s just a huge Coroutine that responds to various types of BattleEvents - here is the source code to hopefully show the rough outlines of how this works:

BattleEvent types - various types of things the BattlePlayer responds to
BattlePlayer::PlayBattle - the main machinery that handles going from one BattleEvent to the next
BattleSequence - this is primarily just a list of BattleEvents that get executed in sequence

Also, here’s the code that customizes the PropertyDrawer for the inspector - this made it a WHOLE lot easier to work with.

CAVEAT - note the #if (UNITY_EDITOR) in the PropertyDrawer code - I had to add this bc the build crashed without this. I quickly learned that Unity doesn’t include any inspector code in final builds (which makes sense).

1 Like

I highly suggest you look into the strategy pattern, it might help you clean out your code, don’t get me wrong, it’s really cool what you did but your BattlePlayer class is quite long and hard to read, it also basically does everything which might not be a good idea.

I have an example of that pattern here but it’s not well organized so you might have a hard time figuring things out.

In this repo I have another example, it’s better organized but I’m using Monobehaviors there instead of Scriptable Objects, not the best approach but I wanted to see if that was possible.

I suppose you could make it work with generic classes and custom inspectors.

1 Like

Yea, this code is begging to be refactored! The top priority was to get the game finished and released - if I make version 2.0 that will definitely be the time to look into using interfaces and abstracting out the functionality to make it more modular and easier to manage.

Thanks for suggesting the strategy pattern - that’s super useful! I can see based on the code you shared that it helps to de-couple concerns.

wow this is realy a few steps ahead of the tutorials you added some really exciting elemts and much veriaty to all of the aspects of the game experience. great game design and amazing execution. keep publishing good stuff!

1 Like

Thanks so much! Actually working on a sequel to this game with a host of new systems I’m excited about!

All the source code is on Github so feel free to browse through that if you’re interested. Hope it’s helpful!

Yes I will peek. Can you maybe point me what to look for if I wanna know more about how you handled the dropped loot and magnet cooect of them. Is it particles or a full game objects?

1 Like

Absolutely, used GameObjects for the dropped loot. Each GO attracts individually towards the player: https://github.com/townofdon/space-shooter-2d/blob/main/Assets/Scripts/Physics/AttractTowardsPlayer.cs#L40

However I recently did learn about the ParticleSystemForceField so that might be an alternate way of achieving the same thing. Particle system events could be used to add a callback for when the particle collides with something.