Last summer came and went, and when school year started all my personal projects screeched to a halt. Now that summer break is here again I have started to work on this project specifically with great ferocity. Such great ferocity, in fact, that I haven't had the time to do any updates! So here's a big post of all the changes I've made in the last month or so.
Visuals
I always wanted the visuals to be first and foremost simple and easy to look at. The less clutter the better. Well, I thought, what game has less visual clutter and more clarity than chess! So I opted for the characters to be represented by chess pieces. The pieces themselves don't have any differences in how they work yet. That's for the design phase. As for the color theme, I went for a monoramp palette of dark blue and purple at the dark end, and off-white at the light end.
Animations
I have done a lot of placeholder animations to make things look a little nicer. This post will already be a little long so I will keep this rant short, but a lot of systems in unity that are necessary for this project are not great. The animation system is one such example. The new animation system has been in place for ages, but the legacy animation system is still there. I'm not gonna make claims, but it feels to me like this is because the new system is still, after all this time, lacking in some things that can only be done with the legacy system. For example, if you want to do a small animation, like moving something a short distance, you're better off with the legacy system, as the new systems api doesn't support you doing this completely in code. With the old system it's gonna be one component and about 5-10 lines of code. With the new system you need to have the animator, animation clip, add the clip to the animator hierarchy, point the arrows and set the parameters and then enable the animation with a few lines of code. All for an animation that lasts a second. This leads to a frustrating duality where you're sometimes doing the animations in code, sometimes not, and remembering which is where gets annoying. Rant over. One day I'll make a post all about the cursed tile system, that made making some of these animations genuinely take days.
Aiming and shooting
This system honestly has so far come out better than expected, even though a lot of it is still placeholder. The cone represents the area in which the shot may land, and if a piece is within the area, its health bar will blink with the amount of health it might lose, were it to be hit. I'm planning on implementing more weapons with different amounts of spread. For what I'm planning though, I want to keep randomness to a minimum, so a spread like this would be very uncommon. I would like for the spread to only really be relevant if shots are taken from great distances, or the weapon is using for example buckshot rounds.
Miscellaneous
Fog of war is another system I just finished half way implementing, whatever that means. This would be another chance to spend ages complaining about unitys tilemap system but again, trying to keep things short.
Some less interesting things was that I cleaned up a lot of the scripts and made their order a lot cleaner. This is a problem that comes up when you're designing and planning the game while you're making it, but with personal projects I like to follow the mantra of "Messy code is still better than no code at all". This means that if you get bored or frustrated while planning a project, so much so that you don't get to even making it, you're doing it all wrong. You just need to get to doing it, and then fixing it up later. Since it's a personal project after all, you got all the time in the world!
Top comments (0)