Dragon banner

Dragon & Fox
Collective

Fox banner

The little things

Published by Jady on 5/16/23, 8:07 PM

Remember kids! Sometimes it's way easier to just have an arbitrary list of little specific things instead of one big thing that has all your use cases! For the Hashmap Deque that I just released, I needed all the settings for laying cards out in a line, and also the settings for choosing your hash function. After a few hours of trying to stuff both of them together, I just made them separate and stuck them in a list. It's much easier to use now, although if something doesn't get set up right it now throws an error in-game instead of just not letting me play (which is usually better).

Also if you're making video recordings, make sure your encoder actually has the right settings :/

Interface Inheritance

Published by Jady on 5/8/23, 1:07 AM

Today's super technical blog post: Interface inheritance!

Interface: an object type that stores no data, only manipulates it, and can therefore be used with other interfaces to make a complicated object type

C# has a neat trick where you can override one of the functions of an interface so that nothing else can access it! This was really helpful for reworking the deque rulesets, because each rule was split into two parts: one for a generic data type, and one for the data type that the deque actually uses. But also, those rulesets weren't actually interfaces because they stored data. I thought that was cringe! So I stuffed all of the data into another class I was already using, SingleDeque, which represented a single "layer" (like Array but not like Queuestack). So then with the interfaces created, I could hide the generic wishy washy versions of all the rules so that deques can only access the specialized versions. So now it's easier to write deques without breaking anything!

The other big thing I did today was create special objects to manage how the cards were laid out on the board. Previously, I had to copy and paste all the layout code from Stack to Queue since they pretty much are the same thing visually. Now each layout type gets its own object.

But then there was an issue in that each deque had its own type of data to use with the layouts, and you can't really have one function accepting all sorts of different data. So the obvious answer was to ignore the data completely and just use interfaces! So now all the data has been turned into a collection of "features": one for keeping track of direction (which Stack, Queue, and Array use), one for keeping track of time (which Cyclone and Array use), one for keeping track of flipped cards (which Memory uses), etc. Then I can just have each deque hold its own data, and only give the layouts the interfaces that manipulate that data! So now a WobblyLayout just knows it needs something for direction and time, but it doesn't care about the data behind it, so I can just give it the interfaces Array has, and it'll just accept that!

first

Published by Jady on 5/4/23, 7:04 PM

In lieu of a devlog, because that's hard and time-consuming, I'm gonna have a devblog that I hopefully post to a whole bunch, a little at a time, because yeah

We'll see what happens