Hello internets again,
I am tuning back in to sum up what has been done, the features that have been implemented and how I spent my time. But at first I want to give a brief overview on what kind of features and trivialities I implemented in GreyHole up until I worked on this blog and social media, as the DevBlog #1 was more of a broad overview on how I came to indie gamedev in the first place. So here I share a summary of my GreyHole dev progress:
Core mechanics – the “No-Shooter”
As I mentioned earlier, the basic idea of GreyHole is that it is not a shooter but kind of behaves like one. You (WASD/Gamepad) control a character in a very open and unlimited space and have to best loads of enemies. Traditionally these type of games are Shmups where you have to aim and fire projectiles, lasers and whatnot at enemies. Since I first wanted to create something limited in scope as my learning project, I thought about ways to completely restrict me to not using projectiles and shooting at all. And I came up with the idea of objects rotating around the player with which you can damage enemies.
The mechanic proved to be quirky but fun as you have to be in constant awareness of the proximity of your enemies to be able to damage and avoid them at the same time. I took this concept and made it the core mechanic of GreyHole and now I build the whole game around that. One can now manipulate the rotation speed with a cooldown and change the rotation direction. The latter does not really impact a whole lot right now but I will expand on the direction later on. When developing a game one problem is that the possibilities are endless. You can imagine a bazillion features in matter of hours and won’t ever have the resources to implement even a fraction of them. And that’s the biggest reason I set such a strict boundary for my game. Heavy constraints on what you allow yourself to do also lead to at least some basic forced creativity. I would not have come up with the BoMB-mechanic in the first place if I had not excluded shooting categorically.
Enemy design – simple types to test gameplay
Now that I had the initial mechanic ready to work with(and it looked way worse than in the gif above) I had to add enemies and behaviors for them. I created a movement pattern for the simplest of enemies to behave like some kind of fish that is basically curious and seemingly random in its path but when you get too close it tries to flee you in a non linear way. I spent a lot of hours until I got it somewhat right after I had tested many iterations that felt clunky. I have one gripe left with their movement and that is that they freely overlap each other. I may tinker with collision detection between enemies a bit more to make them behave more “swarmy” instead. But I also have to keep in mind that I want to have loads of them spawned at the same time, so I need to watch the game’s performance very closely. I need the game to still run on weaker machines(or if I make it to a mobile release to run fluidly on phones as well).
Fleeing enemies are fine but you also need some aggressive ones, the player has to react to. So I included the rocket enemy. It chases the player as if it is heat seeking (with a slight offset to not make it too difficult to dodge). A super simple spawning timer for both of the enemies provides the first “content” and gave my personal alpha testers (my girlfriend and her brother) something to do when booting up the game.
Adding “Juice” – polish the game’s feel
After the first prototypes I then went on and learned about particle effects and screenshake effects to make everything more juicy. You have to be careful though when adding Juice to your game, the right amount is important, too. Overloading everything with too much may result in hard to read event queues or overall particle bloat that floods the screen that is just over the top.
One thing I realized when I added the fiery trails, is that particle effects can also shift the difficulty level. As the trail visualizes the path of the balls, the player has to focus more on where the ball is currently at and where it will be in the next few frames to anticipate the impact position. The fiery trail diverts the perception of movement somewhat so it gets a bit harder to actually hit enemies.
Gamepad Support – better implemented early on
Another thing I learned from other developers in the Gamemaker Studio Discord(direct invite link) was to better add Gamepad/Controller support from the get go, so that you have it in place to test everything out while you develop rather than to slap it on later. This should improve the feeling of the game significantly when played with the controller.
I struggled quite a bit with this piece of GreyHole dev progress as I myself only have a Steam Controller in my possession. In itself the controller is okay. But it only acts as a controller when paired with games run through Steam. When not using steam it emulates a kinky combination of mouse and keyboard inputs. This article on the subject over at davetech helped me a lot understanding the principles. To be able to actually use the analog stick for smooth movement transition I had to add an exported .exe file of GreyHole to the Steam launcher via “add non steam game”. It was a bit of a workaround but this way I had the gamepad support working and got native Steam Controller support on top without any extra hassle. Yay.
Other things I developed for my GreyHole Game
Right before I set up the blog I worked a lot on invisible things. I adjusted lots of things with my healthbar and its draw events by using surfaces. I changed it to only modify layer each time after the data to be displayed has actually changed instead of every frame. That made the game much better performing.
Performance in general was a huge aspect for me to tackle as I want to have the base at least semi solid to be able to run multiple instances of any enemy kind without having to worry about clogging the player’s (maybe old) computer. I learned a lot during this period while not even producing much code. Better even: I simplified the code somewhat and reviewed some aspects that had the most impacting effect on performance. Straight out sloppy things like nested if-statements that did not always get resolved correctly or particle systems that I forgot to remove after they had done their job.
Another invisible change was to set up a data structure I will be able to use for loading and saving progress and a highscore table later. Both are features that I am working on or rather planning on working on in the near future as I want to have a working main menu before I implement other features.
I finally added a dev menu to be able to “cheat” in the content I am testing. I know I should be implementing a console to be more flexible but that is a bit over my head at the moment. The possibility to manipulate the game outside GreyHole’s gameplay boundaries really hastened my whole development progress.
Another small thing I did was redesigning the “Gravergy” pickup. It used to work like this: As the player picked up Gravergy drops, he had a barely visible disk/aura around him increased in size. Every other pickup in range of this disk would be sucked in and the more Gravergy the player collected the less he had to take care about the mass and pickups the enemies spawned when dieing. That was somewhat convenient but really made the Gravergy drop itself an undesired thing on the screen after a few minutes of gameplay. The result was in playtesters ignoring it completely after a while. That’s not what I would call a fun interaction, so I thought about a redesign. Now when the player picks up a lightning bolt it provides a temporary buff to the player, sucking in every drop in the whole game world for a limited timespan. That way, collecting this token is almost always desired as you don’t have to chase game points and other pickups with your own movement. It creates some base level of satisfaction.
Working on Social Media and Sound Polish
In the end, most of my spare time the last one and a half weeks went into setting up the structure of this blog, creating social media accounts and creating content for those to have a basic setup. That is a lot of work I did not anticipate to be doing when developing a game before. I sure hope to be done with the most tedious parts as of writing this blog post. After some thought I consider this also part of my learning experience in the gamedev world because the best game in the world is worth nothing if hardly anybody knows about it.
One last thing I actually had time to do was to add in some game sounds. I stumbled across the current Humble RPG Game Dev Bundle and had to buy the highest tier as it contains quite a few quality SFX-files(please be aware that the files in that bundle are licensed so that you can only use them in one project regardless if it’s a personal or commercial one). I came to the realization that I really lack the skill to produce game sounds myself and that any meaningful progress in this area would be the highest amount of work for the least gain. Thus I ended up buying the bundle to take a shortcut here to have some more time at my disposal for other areas where I feel like I can improve more efficiently. There are still a few things to be done about the basic sounds. I have the sound for the faster rotation cooldown working with an entry and ending sound, as well as the sound for the Gravergy powerup. Both I can vary in length dynamically and stop them when needed to via code. The pause Screen now also pauses all audio files and resumes after unpausing. Impact sounds are the most important. At least I think so after testing a few different assets. From self-recorded to artificially produced and modified sounds over different bought impact asset sounds to the final sound I have implemented I achieved a presentable result.
The last audio related change was that I now interrupt the playing sound if the same sound is triggered again. When for example a BoMB collides with two enemies in rapid succession, or two enemies almost at the same time, it often occurred that the sounds became scratchy and overtuned by layering them above each other. That is now fixed and the file just starts playing anew so there are no multiple instances firing atop of one another.
That’s it for now. I apologize for creating a wall of text again. I promise, the next posts will be shorter and more content focused. (Args, never promise things you may not be able to fulfill… !)
wuzzleGreyHole - #DevBlog -