Creating Idle Sand

Hello! Are you interested in developing your puzzle idle game that has the possibility of being multi-platform? Well, you're in the right place! I've taken this journey and I'd like to share what I've learned.

I was inspired to start my journey whilst exploring the concept of an Idle game from playing current games such as Clicker Heroes 2, Cookie Clicker, and Realm Grinder. Each game had a special something that kept me coming back and that was the concept of consistent progression. I later picked up Black & White once again after I saw a community patch had fixed a couple of the problems with modern systems. This breathed some new life into the game and I have hooked again as I was as a kid. There hasn't been such a unique game such as this one in a long time. I wanted to take this concept on with my game, the idea of being able to control the whole game with just your hand. I set out and did exactly this. I can do all sorts with my player hand depending on what they're clicking, how long they click and where!

I liked this idea and documented some ideas of what I'd like to see in an idle game and never had the enthusiasm to make it take off. I was extremely lucky to be given the chance to work with Jagex in 2018 as a Junior Tech QA Engineer and after a few months, I was rearing to go. I had the know-how on how I should approach the situation after learning for so long in the workplace. I was given complex problems I'd never encountered before and it helped tune my thought process with problem-solving... Google it, YouTube it, experiment with it and then Google it some more. This process helped drill new knowledge.

During break time I was playing Where's my Water 2 and it hit me. The one thing I was loving about this game was destroying the terrain and having the water physics flow free.

This drove my interest to find a game that did this on a 3D level and I began exploring what intellectual property utilised any 3D physics with liquids. I found Borderlands 2 & Killing Floor 2 were the only major AAA titles that utilised Nvidia particle PhysX,

Over Christmas of 2018, I began my yearly pilgrimage through the Dark Souls series with my brothers and was on a constant lookout to see how a beautiful game handles their water. After closer inspection large open areas were simple layered planes with heavy reflections used to look great when the player isn't looking directly at them.

Perfection.

Until you closer look at how the sea is created

I began prototyping my idea for the game in Unity at first to see what kind of an experience I would have developing the game through that and struggled to get anything off the ground. I first looked into water physic packages created by 3rd parties such as Realistic Water Physics 3 but was deterred by the requirement of paying for lack of updates. Nvidia PhysX was still in its infancy too and still hasn't been updated as of this blog post too. One of my biggest difficulties with creating this game on Unity was the lack of tutorials. I wasn't familiar with C# so looking to get the features in the prototype working was a lot more trouble. I'd been down this route a year ago when creating my other games and figured I'd leave this concept and find something else before investing too much interest into it.

I decided to look elsewhere and stumbled across the GitHub of Nvidia Gameworks and found a few branches had been created by a user known as 0lento. I had some contact with him through the Unreal Engine 4 discord and found that he has been working to get the Nvidia PhysX API up and running on the latest versions of the engine. After finding that there was an active development ongoing and multiple branches to choose from I was able to make my decision. From here I painstakingly went through each release that used Nvidia FLEX and being very new to using UE4 through Visual studio I wasn't aware of the need for continuously rebuilding required after adding code and testing things out.

Finally! It's working. I settled for Unreal Engine 4.20 FLEX. I chose this version as it had the main requirement for my idea to get off the ground. I figured theirs less to go wrong and if I want to port this at a later stage I will have the ability to do so. In the future of this game, I would like to implement Nvidia BLAST and FLOW to create some interesting gameplay through exploding entities to earn rewards or points. Perhaps a gameplay style could be considered "loud" rather than, in the Idle genre, passive or active gameplay. These terms are used quite frequently in Diablo or Path of Exile with builds requiring more finesse than others making them possibly more fun, dangerous and more difficult to level.

Now I've got things up and running I was quite happy with the tools and examples available with the game works. There was plenty for me to look at and quite a healthy amount of documentation. As with Unity though I'm not a fluent coder so looking into C++ took a whole week to get to grips with and even then I only knew where I needed information. This is one part where rebuilds were taking a toll on my interest, each small code change was giving me 30+ minute rebuilds if not longer.

I managed to work out the complex nature of the beast which is the GameWorks code and found where I needed to add my trackers. These trackers would form the core principles of my game, is a particle being deleted? This was a feature in Flex already but after hours of searching there was no viable way for me to tell anyone that a particle is being destroyed, or in Flex's case, deactivated and then moved to the end of the list.

Once I'd gotten the game to acknowledge particles being destroyed from here I was able to set up plenty of bools and increment int functions to start scoring. Getting this communicated with the interface was a bit trickier, I wasn't familiar with how I should be passing variables around my blueprints. Using event dispatchers fit the bill very well and I was thrilled to see the code coming together.

I used these same dispatchers to use the buttons such as the upgrades or keeping track of what buttons are being pressed by the player. If the player presses the black hole button, we want to send the string to our player controller and set the right click action according to the switch case. I know now that I could have used session instances but by the time I learnt this I'd already got a working setup.

Throughout the project, I kept a firm focus on getting my 3D assets from any source I could find. One great source, surprisingly, was the Microsoft Paint 3D library which seemed to have plenty of things to use to make 3D icons and the like. I do have experience with 3D modelling but figured this was out of the scope, better get my code and game design down and then go back to do this later.

The final puzzle level involved using 4 different FLEX particles. These were surprisingly lengthy to implement, with no simple colour change but instead requiring 4 files each that had to all be changed and independent. My favourite addition to the game was the concept of the black hole. This was used primarily for objective progression and scoring. I managed to find a great tutorial on how to create a bending light material and this interacted perfectly with the FLEX particles. Adding a FLEX collision component to this and enabling a drain allowed me to selectively choose what items I wanted to be destroyed. I was able to tag, for example, rocks, as "pickable" and these would not only be movable by the player but also destroyed by the black hole.

My final work on the game involved learning how to use Houdini, Substance Designer and Maya. Houdini is a fantastic piece of software and being able to use Python inside of it was interesting and easy to get to grips with. In my current role, I use Python heavily so getting used to the way I needed to code was quick and easy. One of the concepts I did struggle with however was the math needed to work out where I would like to place things in specific patterns.

Substance Designer is really easy to get to grips with through node-based programming. One of the things I enjoyed with this program was how quickly you could make a material concept without needing much knowledge of modelling or painting. The main thing to get to grips with is how certain nodes behave and manipulate each other.

Finally, there is Maya. This was a huge busy toolbox to open and one of the most difficult concepts to understand was workspaces. I felt like I had too many tools to use and the software is trying, and does very well, everything at once. After getting over the large difficulty curve I was able to animate and rig my player's hand.

Thank you very much for reading.