This week was tough. I planned to have a combat mechanic prototyped by the end of this week. Instead, I got caught up trying to write a clean, well-optimized code for understanding and future tweaking. The stupidity was I didn’t even know what the combat mechanic was going to be…
Welcome to the 6th week of development. This week wrapped up the gameplay spring of the month.
TLDR
- Created a bunch of coins to collect. They are shiny!
- Used trigonometry to program a nice pickup and dropping mechanic. Who said math is a waste?
- I struggled with not being able to write clean code from the start.
- Later decided testing is more important than optimizing at this moment. I made a good call because…
- I finished prototyping the Combat Mechanic! Phew!
Let me elaborate.
Shiny stuff
Coins — it is actually pretty cool. The coin was pretty easy to create. It’s just a flattened cylinder made to rotate using DOTween plugin from the asset store. And this is a vital part of the combat mechanic.
To upgrade your weapons, you need coins. And this got me into the rabbit hole of finding the best way to balance the economics of the game. A well-balanced game makes sure players have fun by having access to the right amount of coins. I don’t want to overpower them by giving them a massive pile of wealth or fail them by not giving them enough.
It appears there is some complicated math involved. But for now, I am going to follow a process called “Try — Fail — Adjust — Repeat.” There are plenty of resources about “game balance” out there. I’ll be checking out all of them soon.
Pickup and drop
The player has a new ability — they can pick up and drop objects. It’s a simple mechanic, which I am not sure where I can use yet, but I have some creative ideas in mind.
Here’s the plan — The egg should highlight the nearest object it can pick up. On the player’s input, the object gets picked up. Hitting the same input will drop the object in front of it.
Even though the egg doesn’t have hands, I wanted it to feel like its reaching out to grab the object with both hands and holding it up over its head. That meant it should follow a nice curve when it moves between the ground and the head.
Thinking about curves led me to think about something interesting — Trigonometry and the graphs of Sin and Cos I had drawn for the school tests a long time ago. That was it.
I used Sin and Cos function to describe the path of the object when it was in motion. It also created an excellent ease-in function for the animation of pickup and drop. Here’s the code for your viewing pleasure.
And this is how it translates in the game.
I also had to create a system to isolate only one object when multiple objects are available for pickup. There’s no visual indicator as of now to show which object will get picked, but the system works. I might have to do a check for empty space when placing the object back. Otherwise, players can place an object within another object resulting in some unexpected explosions. I’ll fix it later.
Clean code vs. messy code
I have had bad experiences with writing messy codes in my previous projects. Do know that I didn’t intend to write a messy code. When the project grew and reached its finishing stage, the codes got large and complicated. It became very tough to make changes without breaking the whole game.
So this time, I was determined to use a good game architecture and write clean and optimized code from the start.
But this week, I realized that I wasn’t progressing fast enough in the pursuit of writing clean code. I had the whole combat mechanic to design and test, and I couldn’t proceed with it because I was wasting time thinking about how I would manage the different mechanics of the combat only in my brain. All the combat possibilities were filling my head, but I had no idea what mechanic would be good and what would suck. I was getting anxious about it.
Finally, I came to my senses.
I have just started exploring the mechanic. It’s going to take some time before it becomes something fun to interact with. That meant a lot will change between now and the time the mechanics are finalized. It won’t be very smart of me to focus so much energy and time writing clean code when I am unsure if the code will be present in the final build.
Many veteran game developers first create a prototype — fast and rough to test as many possibilities as they can. Then they start from scratch for the final production of the game. It makes total sense.
Am I going to do that? Not sure. But I have marked those assets that need optimization and went ahead with writing the required code. My anxiety reduced a bit then. And now I am glad to have the combat prototype done. It’s not much, but it’s playable enough to test the concept and re-iterate.
Next step
Next week is the Visual sprint. Even for testing, the bullets need to feel like bullets. So I am going to add some essential visual flair. I am also considering designing concept arts for the world of the game. That should be fun and cheer me up!
So that’s the update. See you in the next one!
I wish you very well!
Originally published at https://www.theearlyowl.com on September 25, 2021.
