Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Harmony Gardens - A beat based VR puzzle game, first devlog

A topic by sharramon created May 07, 2023 Views: 250 Replies: 2
Viewing posts 1 to 3
(2 edits)

This is my first time writing a devlog. So I don't quite know how to go about this. 

To give some background, my coding and Unity is pretty much self taught. I've been very into VR for nearly a decade now, and that's why I figured I should teach myself some Unity. Thankfully, I've managed to get a job as a Unity dev, and been working at my position for a year now. So I thought I'd try and give this a proper go.

My general inspiration for this was Beat Saber (big surprise), and the other big inspiration here is Fujii. Another game I was thinking about when I tried to put this together was Journey. It's built on an old idea I had where a player would 'play' a series of 'notes' and then that would be the spell.

I'm doing this in VR, so I'll just share progress as I go as a way to share as well as keep myself motivated to continue.

So this week, the first thing I got to was doing the input system. The OpenXR package in Unity comes with a few different ways to do input, but I think that Unity has kind of been pushing the whole Input System thing. So I built up my own little Input Actions, and then wrote some custom script for the input actions so that I can detect when certain buttons are being pressed.

That's pretty much all the inputs I could think of at this time, and I would love to include the code too, but I think if I started doing that the logs would just become a codebase. If you're curious what code is, feel free to reach out!!

But in the end (of about two days of figuring out how to stick stuff together) I got this :

Then I created some 'notes' as spheres that followed the player's head movement, and added a particle effect to it to show when you've 'hit' the note successfully. Then I wrote a very simple Rhythm keeping scriptthat plays the beat audio every time a _beatTime amount of time passes. I created teh CheckIfWindow function to quickly check if the current time is within whatever window I've decided would be appropriate for inputs to be allowed. I'm a little worried about running this on update, but I'm not too sure what I could do to make this more stable.

So ultimately I got this :


So I'll try to keep building off of this.

(1 edit)

Second post!

Sadly, I don't have too much to report. I'm in the middle of making my skill system to tie into my little boops. However, I thought that it would be a little too boring (and difficult to extend) if I just make the scripts and referenced them in a component somewhere.

The thing I decided to try and do instead was to use reflection to grab all instances of the skill class I might make in the future. I'm not planning to go so insane on skill classes that this becomes a headache for me in the future, but it would also be nice to not have to worry about hooking up every single skill I make every time I make them. It's just nice to try and follow the open-and-close principle when I can.

So how I did this was by creating a ISkill interface with a cast method and other small methods that will get overridden by the concrete implementations of the class. I then used a SkillFactory to initialize the reflection pattern. I'll show you that piece of code right below :


So the factory just created the concreate implementations of the ISkill interface and saves them to a dictionary. 

I tried this out with a bunch of dummy classes and it seems to be hooked up fine. I actually got a little fancier and made the ordering of notes to play into a scriptable object so that I could edit that on the fly.


Like that! So I don't need to go in and hard code it every time I want the notes to change. I also thought it'd probably be a good idea to have a slot for prefabs and names so that I can switch out casting effects and have a key to find these with. To get even fancier I made this scriptable object into an addressable asset. Just in case I ever want to change things on the fly if I ever end up wanting to do that after releasing the game (if that ever happens).

I know this was just a bunch of code considerations, but I think it's important. I built myself a solid base from which I can start adding skills and very simply shove the cast input to this scriptable, while confidently just casting it from a central skill manager without having to worry about writing code to initialize a new skill every time I make one. And it's actually pretty hard to find anything on code architecture online. I know mine is not the best by a long shot, but I think it's kinda cool to read and talk about these kinda things.

This was a bunch of fun to think through and make. And although there was a bit of trial and error involved, I enjoyed myself quite a bit. Hopefully I actually make some mock skills with effects next time.

I wonder how many posts get to their third post. There must be a number of posts that's a kind of event horizon that's indicative of a long term commitment at some point right? It's kind of insane thinking that three weeks used to be a third of a quarter. Like that means I learned 1/3 of my biomechanics course at this point.

Anyway, back to this.

I worked mainly on making the skills activate this week. Initially I thought that it'd be super easy, barely an inconvenience as I just 'activated' a skill by instantiating a prefab that was a ball of light. I thought 'yeah great, done'.

But then I sat there thinking 'wait I want the light to ramp up and down when I turn it on and off so that it doesn't just pop into existence'. So I went back and wrote some coroutine scripts to make that work. So then when I 'activated' my skill it would fade slowly in then it would fade slowly out. Neat!

So I thought I was done with that. But then I tried activating the light skill when it was still active and I had TWO instantiated prefabs. This wasn't ideal. I had to put in a check in my Cast method in my LightSkill class to see if there was already a light active. If there was I needed to put in a way to 'rebrighten' the light if it was in the middle of fading out.

So that was like... about five times harder than I thought it would be at least. Since I'm doing all of this after wrok, just thinking how the code would work for this and then writing it took two and a half of my evenings... I ended up with this code.


Looking at this makes me kinda sad, since it legitimately took me about 5 solid hours to just reason my way here from 'wait, I can't just instantiate it'. But this is what the result of this looked like.

I also coloured the balls from last time.

Since this was done it wasn't too hard to throw in a dark skill. 

Which looks nice. I also made it so that the light and dark skills will destroy each other on instantiation if one is 'in the way'.

I also  made all the skills through and ISkill interface with a Cast() skill.

I actually just wrote a basic post on how to make these skills with reflection here if anyone was actually curious as to how to code with at least a small amount of architecture in mind.

I'll start on creating a lamp that I can turn on and off with these this week I think.