Leap Year Leap Postmortem

My post last month somehow ended up on the wrong blog (probably too much of a rush and I didn't pay attention when posting). The link to part 2 of making video poker is at http://blazinggames.blogspot.com/2020/01/video-poker-part-2.html.

The source code for Leap Year Leap is at https://github.com/BillySpelchan/BlazingPorts if anybody is interested. I am planning on slowly adding code of the other games I port to that repository.

Leap Year Leap is a leap year game that I originally released back in 2008 (on February 29th), and then released as open source in 2012. This is a Flash game using the really old version of ActionScript but this was not necessarily a bad thing.  The game used an old-school technique for faking 3D. Namely taking advantage of sprite scaling to draw sprites larger as they approach you.
For the HTML5 port I decided that I would do the game using my own library. Interesting, the BGLayers library I wrote was written in 2010 so if I would have had a bit more foresight, I could have done the HTML5 version way back in 2012. Granted, back then HTML5 was not a completed standard so support for the canvas tag and API was limited.

I was expecting the port to only take a few hours, but it ended up taking about twice as long as I anticipated. This may be partially due to not having that much free time to work on the game so one quickly loses track of things when there is long periods of time between work sessions.

What Went Right - Software 3D code ported easily.

While a large amount of the game was re-written from scratch, the main scaling logic and the jumping logic for the game was pretty much ported verbatim.  This allowed me to get the game up and running quickly and the development time would have been substantially longer without this tiny amount of code.

 The 3D logic is somewhat correct with the scale of the object being determined based on how far away from the player it is. The jump logic is physics based using momentum and gravity to simulate the jump. Interestingly, the code breaks the physics into micro-intervals and performs many calculations to keep the jump as consistent as possible even with delta-based timing. The idea here is that the physics is calculated independently of the image so the time between the last physics event and the current one result in several discrete steps that the program processes. By having physics in intervals, you get a bit more consistency with the motion. While the number of steps I used was probably way more than necessary, it is interesting that more modern engines use a similar approach to physics.

What Went Wrong - No bi-linear or Tri-linear filtering

The Flash player did a surprisingly good job of scaling images, though this probably had more to do with use of vector-based images than the actual image scaling. As I am using images and scaling them using the canvas default scaling methods, the results are not as good. The canvas scaling results in images that tend to flicker in the distance as different scanlines of the image are drawn at different scales. This use to be a big problem for 3D graphics cards, with the solution being bi-linear and tri-linear filtering. The idea behind these rendering approaches is that instead of having a single image, you have multiple images at different distances. Finding the appropriate image and swapping it in results in much better scaling. Of course, you can’t have every possible size of image unless you want to use a lot of storage space for the many versions of the image that would be needed so instead you rely on filtering techniques. These take samples of the images that are near the correct size and set the color of each pixel of the scaled image based on the average of these samples.

Software filtering is certainly possible but would take far too long to do.  A better solution, which I will likely implement in the 2024 version of the game, is to use the 3D card to do the scaling work for you. While I have done some work with OpenGL and Direct-3D, I have not really done much with WebGL. I suspect that it would be fairly like the work that I have already done but simply don’t have the time to learn a new graphics API. This is something that I will be doing eventually, when I actually start having more free time.

Mixed Blessings – BGLayers

While I certainly could have used Create.js for the library, for such a simple game it is way too much overkill. Using software libraries that are multiple times the size of the project when you are only using a tiny fraction of the libraries features seems wasteful. More to the point, I like writing my own code and still want to develop my own engine so why not use my own library. The advantage is that it is significantly smaller than the Create.js libraries and I have total control of everything. The disadvantage is that it was written back in 2012 when ECMAScript 6 was non-existent. 

While there are clunky aspects to my BGLayers library, it works surprisingly good for its size. When I have the time, I am going to have to re-write this library using the proper class syntax that ECMAScript 6 uses to make for working with the library and development of games much nicer. I would probably divide this into a canvas and a WebGL version.

Conclusion - Plans for 2024

Overall, this is not too bad of a port for the game. As mentioned above, for the next leap year, I will want to do an even better version of the game. At a minimum, this would switch to a more modern version of JavaScript so rewriting, or more likely a re-imagining, will be in order. It would also probably use the WebGL API so that I can properly handle 3D elements and be able to take advantage of the filtering options to result in smoother looking results. A lot more background objects, and possibly a road that goes from a dirt trail to a modern highway as you advance through the years would be nice but that is probably pushing it unless those things happen to be developed in a different project.