We at Divine Knight Gaming love our tech. We use some great technology to help us make our games and we advocate for any developer to try them out. We have done what we can to advocate for these technologies and have even made some modestcontributions to the underlying software. After all that, we were excited for this latest opportunity to support HaxeFlixel.
The goal was to raise $3,000 and match that with another $3,000 Lars and other developers and founders managed to raise. This $6,000 is enough to hire Alexander, who is a Russian resident, full time for a year providing a raise as well. In a massive show of support, this campaign raised the needed $3,000 in well less than a day. As of today, they are just shy of hitting 200% in contributions.
We at Divine Knight Gaming are proud to put in what we can toward that goal. We have backed the campaign for $15, a modest sum. We would have loved to contribute more but are doing what we can with what little we are making at this time. As we become more successful, we hope to be able to provide more meaningful contributions in both time and money.
We recommend that anyone interested in indie game developers and the engines they use to consider backing HaxeFlixel. Not only will you ensure that game developers have continued access to a quality game engine, but you also have a chance to score some great indie games upon the completion of the campaign.
The title is probably a little deceptive. The truth is that HaxeFlixel already has such a camera transition. However, it didn’t function 100% in the way it needed to. You can follow this problem in this HaxeFlixel forum post.
The problem was simple. I was using grid based movement for my character. I was following that character with the camera. When that character moved off the current screen to the north or west, everything was fine. You took one step off screen and the camera switched. However, when you tried moving east or south off the screen, you had to take two full steps off the screen.
This presented a problem as the character might have interactions waiting for them on the next screen that could be impacted by taking a “blind” step into it.
Consider the original Zelda game. In some rooms in the dungeons, there are spiked blocks that move quickly to damage you when you cross their path. These blocks are often positioned so that the path is the very next row of blocks after a doorway. In Zelda, you always start a room standing in the doorway. So if the camera in Zelda functioned the way it did in Flixel, you would have had to move directly into the path of the spikes to switch the screen.
The fix was really easy. The camera was checking to see if you were on the next screen, but was using a greater than sign (>) to do it. This meant that the player character had to be 1 pixel greater than the screen width to trigger the change. In many games, this wouldn’t be an issue. But with the introduction of grid based movement, where the player moves a set number of pixels with each directional press, this is a huge problem. If the squares in the grid are 16 pixels wide, that means you have to move a full 16 pixels into the next room to trigger the camera shift.
So the fix for this was to simply change the greater than sign to a greater than or equal to sign (>=). Once again, the change is nearly imperceptible if you are not using grid based movement. But for those of us that are, it makes a world of difference.
So this makes my second HaxeFlixel contribution and my first to the actual HaxeFlixel API. If I keep this up, I might just become a HaxeFlixel contributing junkie.
Recently, I have been working on my June One Game. I decided to take the level that my son built and turn it into a quick game. So I did what I thought was all that was needed and pulled it into a HaxeFlixel project. And it borked. This is what I got.