A Turret's Life is a first-person arcade shooter/tower defence game for PC and VR where you are the tower defending an area against the endless onslaught of attacking robots and combining overpowered modules that can be traded as crypto-backed items.
Updates
Well, in regards to productivity this week was the opposite of the last. Various distractions from both at home and at work occurred and ruined my schedule
Turret Design: I have finished the core action system for the turret and designed it so it should be fairly compatible with whatever input system I end up using, more on that below. The next steps are to finally start work on the inputs themselves, using Unity’s experimental input system.
Personal Experiences: The fragility of how easy it was to screw up my personal routine has caused me to rethink a few aspects and priorities in my life in an effort to be more natural.
Progress
Turret Design
As mentioned from the previous blogs, I decided to split the inputs and actual action responses from one another, and implement a so-called interface design pattern on the action side. The interface is an abstraction layer/middle man between the inputs and the actual actions that occur in the gameplay. The reasoning for this is that I can essentially use any input system I need by changing the interface only, but leaving the rest of the action code the same regardless of what was chosen. This is in contrast to an input system that is baked/hard-coded into the action system. These systems might be easier to implement in the short term, but they are very rigid and an outright pain to change. If the input system changes (which is very common with VR nowadays) then the entire system will break and have to be redone from scratch, or you have to keep using the out of date VR APIs.
The way the actions work is through a combination of events and polling. Events are when something in the game happens like the player presses a button, which then tells the action interface which button was pressed. From there, the state of the button - for instance, pressed or released, is stored. Polling is when the game checks for the state every frame and reacts accordingly to it. So, after the event stores the state of the button, the actions will change what happens visually in the game. An example of this would be when the player shoots. The event of pressing the trigger button stores the isShooting = = true state, then the game polls this condition, and shoots the bullet, but then every frame the gun will move upwards slightly over time for the recoil effect. When the player releases the trigger, isShooting == false, and the recoil will stop. But the beauty of all of this is that no matter what input system or API is used, all they need to do is send events, and the actions will chug along no problem (in theory…)
In addition to finishing the input actions I also made a few game design tweaks to the turret, in the areas of “jamming and cooldown”. When the turret shoots, based on the damage rating of the bullet, heat will build up in the barrel. If the player shoots too much too quickly, the gun will overheat and will need to cool down before firing again. This is to create more of a strategy, where the player will balance between using both of their gun banks carefully to prevent overheating. However, there is also a jamming component as well. Originally, jamming was a stat percentage on the gun that could happen when firing, where it would also be a brief delay where you could not shoot. I decided that this was far too similar to the cooldown mechanic. So, I changed the jamming to be based on reloading instead, such that every time the player reloads there is a chance to jam. And, when the gun jams, the player fixes it by quickly reloading a certain number of times, rather than a timed situation. I think this is more preferable since it reduces some of the randomness and gives the player more agency since they can quickly unjam the gun and are not helpless about when it occurs. Likewise, with the cooldown method, the player has control over if it happens or not based on their shooting. Ideally though, the player would collect higher tier modules that have lower jamming chance and higher cooldown capabilities😉
Personal Experiences
Last week I spoke about how being consistent and keeping to a schedule was very powerful and productive; this week I also learned about how disastrous it can be when a schedule is ruined. Through a combination of some personal issues (apartment stuff), plus overtime at work, my schedule completely fell apart and it was a very unproductive week. That said, it made me do some revaluation on how I should design my schedule.
I realized that if my schedule was so easily broken, then perhaps I had not designed it properly or that I should design it so that it can still be functional if things did break. In my efforts to try to improve myself to work more optimally, I had ironically bit off more than I could chew. I was trying a whole bunch of things that had worked for other people so I thought they should work for me, such as diet and exercise times. I tried a more restrictive diet, did morning exercise, and tried to get by with less sleep – all in the effort of trying to improve my ability to work on the project more. I achieved success in all of these areas, but the effort I put in far outweighed the benefit they gave back to me, and in turn was less energized for the project. That said, I learned a lot about this experience and would like to share some of my thoughts with you guys below:
- What is good for someone else may not work for you. There are countless ways to improve your health and yourself. Some of these ways are even contradictory to one another (eating breakfast vs intermittent fasting, for instance). So, you must experiment and find out which work for you; you can’t just rely on what is sa you must experience it yourself to really know.
- Choose the methods with the highest cost-to-benefit ratio. Not all improvements will yield the same return to you as they do to someone else, and their goals might be different than yours.
- Gradual Improvement is key. Don’t try to improve yourself in multiple areas at once, or you will over-exhaust yourself and fail in all of them. Choose one and master it, then use the momentum and master another one, and so forth. I guess that is why there is the term “habit-stacking”, since you can’t generally stack multiple things together at a time.
What does this all practically mean for me? Well, through my failures I have learned more about myself and what works for me. I found that I am quite productive in the mornings but more relaxed and creative in the evenings. Thus, my plan is the work on the project every day in the mornings and leave the workouts and relaxation time for the evenings instead. Even though it is commonly said that the benefits of a morning workout are great, I found the evening was more enjoyable for me. And, it is also about priority. If I work on the project every day in the morning, I am guaranteed to make progress but if I leave it for the evening then any distraction or stressor from the day can seriously siderail it, as I have learned the painfully hard way.
I hope I don’t come across as preachy. In many ways what I have written is a reminder to myself, but I try to be helpful and share what I learned to others.
Oh dear this turned out to be a long post (and I was worried this was going to be too small)! Hopefully you guys found something interesting in this, and I will talk to you all next week 😊
Join the Community!
Website: https://www.aturretslife.com/
Telegram: https://t.me/aturretslife
Comments