Home|Projects|About

Fairy Lands Clone, C++, 3.28.2022

This was a fun one to work on, and is another that I actually have quite a bit to say about.
Of all my projects, this is the most blatantly derivative (which is saying quite a bit...) It was intended to be as close to a 1 to 1 recreation of the game Fairy Lands: Rinka and the Fairy Gems by the developer Oddmeat as I felt I could make.
This is not a well known game at all. In fact, it is a decidedly unknown game. It isn't even a particularily good game (though I would say it posesses some inalienable quality.)

So, why did I decide to clone this game? Two reasons. One: I wanted to prove that I could code a simple game like that better than the original developer. Considering Oddmeat is not a programmer by trade (I do not believe, at least) and that the game was made in a "no code" engine, this would be pretty easy. Two: I was basically stalking this poor guy lol.

Now, I wouldn't say I was stalking stalking him, but I definitely thought he was a very interesting person. I was more ... studying him. I figured maybe, if I did something extremely out-of-the-ordinary (like remake his entire game from scratch) he would talk to me and I could use it to collect more data on him.
... shit, I guess that is just stalking

Anyways,


It didn't take very long to get something quite comparable to the base game. This is obviously just a cycling array of cells, but when you get down to brass tacks thats what most of the game is.
Specifically, I have an array of pointers (to arrays of cells) and I just cycle the pointers around every dozen or so frames, and do some visual curfuckery to fake it being a smooth transition.

After I went with this. Now obviously I added textures, and made it so you could shoot new blocks into the grid, but trust me a lot of unnecessary things happened in the back of this. For example: I made code that could draw a sprite being occluded by another sprite. You know, instead of just drawing one on top of the other.
Still wasn't a great programmer.

Nextly, I added the rest of the gameplay mechanics. Already very close to feature parity between the two versions.
I also captured a bug! Ended up being a rounding issue, I believe. The way I handled the code for this was ... interesting. Every object had a linked list which held various function pointers which operated on the game world, and each of these would be called once per game tick. This ended up acting somewhat as a list of behaviors.
This is actually a somewhat intelligent system (I think) though it was absolutely NOT being used to its full potential here. At least I wasn't using polymorphism.

Next was some visual changes, and I also implemented that line which destroys the gray blocks. I used the aformentioned behavior system to do this, the gray tiles had a behavior to make them check if they were beyond a certain x value, and if they were they would self terminate. Neat!

After that I started working on an animation system. Here I just got it so a sprite could rotate around another sprite, with their different rotations recursively adding to eachother, you know, just like how it works in real life.
I also added sound effects, some text that showed your score, added a game over condition (kind of,) and I added the special moves you can do once you get enough charge. I didn't showcase it in this video, but its the one the character "Skootis" uses in the game.

Next I made a debug puppet. Its body parts rotated based on their position in his bodyplan. I also showcase the ability I mentioned before
Be aware, the way that I am managing this body plan is SUPER RETARDED. Each limb has an array of like 16 pointers which all point to another limb, which they are the parent of. I hard-coded them to a max of 16 to avoid needing to store dynamically sized arrays in a file, but oh my god there are so many better ways of doing this.
And like I said, it stored pointers to the body parts. When I would read the bodyplan from a file, I would need to subtract all the pointers from what they thought was the first element in the array, then add it to what the first element actually was, to recalibrate them. This could have been avoided if I had just used relative pointers (aka integers)

After setting up the initial framework for animations in the main program, I made a seperate program which used the same body structure format. This would be my animation editor.
I actually ran into a BIG issue with this where I spent multiple days trying to figure out why half my data was disappearing. The issue? If you're reading in a binary file without specifying its a binary file, if it hits a byte that just happens to be the same as the EOF marker, it will close the file! As far as I can tell, this is the only difference between reading in a file as binary versus just reading it in normally. Oopsie!
But after that, it worked fine right?

IT WAS ALMOST UNUSABLE! A horrible mess of esoteric keys which all did different things and had to be pressed in different orders. And the worst part? THERE WAS NO UNDO. If you messed up you either had to revert to your last save, or start over from the beginning. Suddenly, I understood why making animations in blender was such a headache.

Now, you may notice there wasn't actually any animation editing controls there. I've called this an animation editor, but it was really more of a body editor right now. The only animating you could do was the aformentioned debug spin.

Nextly, I realized I had no idea how I wanted to actually add animations. The way I did it was... fascinating.

ANIMATION PROTOCOL
Every body has a number which is literally just what "frame" of the animation its on. This ticks up, until it exceeds the end of the animation length, in which it resets. Each animation keyframe is stored in an array, and has a "start" time. Once the "frame" counter hits the animations "start" time, the body part sets its "start angle" value to the target angle of the animation frame, and then sets its "target angle" to the angle of the next frame of animation. It would then use the frame counter to linearly interpolate between the two frames. This was actually somewhat interesting, as you could pretty easily set this up to smoothly switch between animations on the fly!
Describing it like that makes it actually sound pretty clever. In fact, I think the reason I have some distain for it is just because of how I implemented in the editor.
Regardless of that, it worked, and I was able to get animations into the game.


This is the end of the project. You can see some strange popping with the gems occasionally, but its nothing major, and the original game had its own host of issues similar to that. This is the only project like this that I've had thats died just due to a lack of interest, rather than a messy codebase. I think part of it was that I realized showing someone a game that you painstakingly recreated based off their own passion project game is not something I could pass off as anything other than abject stalker behavior, so I was really making it for myself at that point, and I truly did not care that much.

If you wanna try the latest version, you can download it here. You can also download the original game from here, though the steam version is more updated, I believe.