Erm... what's this?
I want to give a try at giving a weekly summary of work I've done. Or at least a summary of any significant work within what I feel is a week-worth of work, since I might not have enough work for weekly updates with all the real life stuff happening to me.
I'm doing this to hold myself accountable, to learn how to be transparent, and have my own history to look back to.
Anyways, let's get back to me blabbering about other things...
It's been a while since I've done game programming. I honestly felt so burnt out from my last two game projects. I want to get back to it, but at my own pace this time.
I went hands-on with my initial attempt of making a rhythm game editor on Godot. It got a bit too tangled for my taste. Bi-directional references, and references that might need data from their grandparents' or grandchildren. It was chaotic. I don't think it would be joyful to draw them in a diagram, even if I think it would be useful if I did to see the change we want.
So, I'm starting from scratch again. But this time, more careful.
When I was just winging it for my initial implementation, I had the "Data-Oriented Design" in my mind. At a cursory glance to what I had, it was nothing like that. It was an Object-Oriented architecture that sometimes try to be data-oriented.
So, on my drawing board, I wrote a design spec for this experiment.
I'll just leave my stream of thoughts below. The true chagrin or whatever if I'm using that term correctly:
- 24-05-02: So, I learned about C# records while navigating Rider shortcuts. It's just a fancy class with handy generated methods meant to reduce boilerplate code for classes that are meant to be data types. I thought, "Wow! This is perfect for the data layer!" There are other features that I personally have not yet explored, but having not to re-implement
Object.ToString()is so useful for debugging. Godot, Rider, and C#'s debugger can be spotty. - 24-05-02: Another dilemma I've encountered was whether to use Vector2 in Godot or the one built in C#. If I wanted to really enforce the separation, and what I've written that neither the data nor the logic layer should know that Godot should exist. I've opted to sticking with Godot. Once I've implemented this enough, I might have a vision if using the built-in Vector2 is going to be better. I'm just worried about the nasty conversions between the two, so I opted with Godot's even when I shouldn't. Eh, let me learn my lessons from these kind of mistakes later.
- 24-05-02: Another code smell I've encountered is how there are a lot of logic heavily relying on Godot's APIs, so what's meant to be in the logic layer are instead located in the View layer. I might refactor this if it gets bad.
- 24-05-03: I was doing some web dev involving Apache eCharts. I was struggling with an issue where Markpoints don't appear. This might have taken me more than an hour, but I realized that there is no error indicating I have not imported the MarkpointComponent. This is apparent for some components, because if you don't import something like LegendComponent when trying to shrink bundle size, it would cause an error when used in Typescript. There is an old related open issue about this. It might indicate I won't be seing fixes for these soon. For anyone curious about the fix, it's as simple as this:
// Should be run during initialization or at least before echarts is used import * as echarts from "echarts/core"; import { TitleComponent, LegendComponent, // personally had to add this since I saw this as an error MarkPointComponent // this one won't give an error if it's missing } from "echarts/components"; // more code to register other components // Register the required components echarts.use([ TitleComponent, LegendComponent, MarkPointComponent, // add this here // ... other components ]);
Reference: Import ECharts - Shrinking Bundle Size
