HexLife postmortem

 As the GameDev.tv Game Jam gives participants a free course, I figured I had to do something with this Jam. The theme of the jam was “Life in 2 Dimensions” so my immediate thought came to Conway’s game of Life. Life is a cellular automata simulator with a set of very simple rules for running that results in surprising results. My first change was to place the automata on a hex grid. I then added three types of life and set the rules so Red cells eat Green cells which eat Blue cells which eat Red cells. My idea was that I would have levels where you would place cells in such a way that your color would dominate the board.  I also made the decision to write the game entirely from scratch. 

What Went Right

The actual simulation aspect game together quickly and my preliminary test showed that it worked producing a rather interesting swirling effect. While the simulation is fun to play with for short bursts, and random mode makes rather interesting displays, by itself it is not really a game. My idea for a game was to have the player control one of the colors and attempt to turn the board entirely that color.  This, will be discussed in the what went wrong section.

Mixed Blessings

The decision to do the game from scratch was a good one considering I am planning to build a game engine from scratch so this would be good practice. I had not anticipated as much interruption from the real world as there was but it was good practice getting back to building everything. Had I gone with my own libraries, I would have been able to do a bit more polish on the game but as things stand it doesn’t look too bad the way that it is. While eating up a bit more time than I would have liked, creating the UI from scratch let me play around with different, and better, techniques than I have in my rather dated and overly simple SLL libraries. This will be helpful as I get further along in the book series I am working on.

What Went Wrong

While the sim as it stands has nice flashy displays, it is not quite enough to allow for good strategic design. I am sure that there are additional features and rules that could be added to allow for more strategy allowing for a challenging game, but that is not here. Unfortunately, the way the rules work make for a fairly easy way for finding solutions to win the game. I am undecided if I will revisit this game but with more rules and other features to increase the challenge of the game but that is certainly a possibility.

Final thoughts

I have been reneging on this blog, so I am thinking about taking my code for the game and cleaning it up going over the code and what I am doing to improve it. This would also result in some soapbox posts about a variety of topics. I'm not sure how often I am going to update this but may go to a fortnight format where I update  my book on Spelchan.com in one week and then post about my refactoring on this blog. I may also consider entering more game jams, depending on what my schedule is going to be like.

Death of the Phoenix Postmortem

 On itch.io, I noticed that gamedev.tv was having a game jam where all entrants got a free course. I decided to enter but have noticed a very unfriendly opening advertisement when I go to the gamedev site so am a bit leery.  The game I quickly wrote is on Spelchan.com and is called Death of the Phoenix as the theme of the jam was “Death is only the beginning” so this matched the theme. Here is my postmortem of that effort.

What went wrong

One of the most important aspects of a game jam is that due to the limited amount of time you need to have a realistic plan. The best approach is to start off with a basic game then, once it is working, add features until the time runs out. With a theoretical 10 days, it was easy to have a more ambitious plan. Unfortunately, I am taking care of my father who recently had a stroke and ended up partially paralyzed. With my caregiving responsibilities, the amount of time available to me is limited so a day is only a few hours and ended up being even less. 

My original plan was to have a map that the player would need to explore to find the material for building the nest and the location of the nest. The story would be told as brief cut frames that would happen when certain tiles were traversed, and there would be areas where the player would be able to restore their health that would act as save points if the player died.

When it became clear that the amount of working time was less than anticipated, my plans needed to be changed. I had implemented the combat system so decided to drop the map and simply have a visual novel instead. 

What went right

My original story system would have a class that would use a JSON object to provide the layout information for the scene. I had hopes that there was spare time left I could add animation parameters to the JSON data and have animated cut scenes. The JSON data format is a simplified version of class definitions in JavaScript making it extremely easy to use as objects. Because it is a human editable format, it is easy to create by hand. This makes putting together a script very quick and does not require code be written. I was even able to use the room scripts for the title screen and losing screen making a very quick visual novel language.

I want to expand this into a proper adventure game engine so will be experimenting with using JSON as a script (or collection of scripts) for some of my adventure game ports that I am planning to do. The data-driven approach makes some sense, and when combined with a command pattern may make for a straightforward way of quickly building episodes for a multiple episode adventure game but don’t want to go into details until I have something concrete. 

Mixed blessings

 My original intention was to do all the artwork myself but for prototyping I made the fortuitous decision to use creative common and public domain artwork as my placeholder art. This had the advantage that if I did run out of time, the art already is there, and I simply need to add attribution text to the game page. The downside is that mixing assorted styles of art makes the scenes less seamless. This can be fine in different regions of the game but can still be jarring. This is a worthwhile tradeoff as having a releasable build, even if not as polished as desired, is a good safety net.

Temporary artwork does need to be from a source that you can use, which reduces the source material, but does not need to be public domain or creative commons. Having royalty free assets would also work for temporary artwork. I have bought several bundles of royalty free music and art so simply need to go through the libraries I have and start using them.

Future plans

While I don’t expect to do anything with this game, I will be experimenting with building an adventure game engine using some of the approaches used in this game. I'm not sure how quickly this will be done as my time for work is limited, but an adventure game engine which is general enough for other games would allow for several of my larger projects to be completed quicker, so is a good direction to go.

JS13K Postmortem

 Due to family matters, I simply did not have time to finish my entry for the JS13K competition. I am still, however, going to do a postmortem. 

What Went Right – Good Idea

The theme for the competition was 404. This is the Page Not Found error code for HTML pages. The idea I had was a stealth game where you need to find your way out of a procedurally generated multi-level dungeon while avoiding being detected by the 404 inhabitants. Ideally, assuming I could squeeze it into 13k, I would have used my ray caster to  have the game in 3D using a procedurally generated rock texture. The sprite for the enemy would be generated using simple drawing commands then made into a sprite sheet.

To make sure the game was completable I was going to write a utility to play through randomly generated levels keeping the seed to the levels that could be completed then use the seeds for level data. This is related to my thesis work as part of my work involves creating solvers for playing through procedurally generated platformer levels.

Mixed Blessing – Components Completed

Parts of the game had been completed before hearing the bad news about my father but because I never actually got to finish the game, I consider this to be mixed. Perhaps I will be able to use the code in a future project. Three things were completed before hearing the bad news. I had a random number generator (based off of PCG) so reseeding would be possible. This is necessary for JavaScript as there is no was of seeding the build-in random method. I had my map generator for generating the levels. And I had the texture generator for generating the rock texture and with parameters and color changes this would have even allowed for variety between the map levels.

What Went Wrong – Family Matters

Things have been totally nuts over the last few weeks. With bad news regarding my father, relatives have been visiting in case they don’t have another chance (a real possibility but as this is a private matter I will not go into details). Combined with having to drive to different cities to take my father to appointments and dealing with lawyers and accountants my spare time was next to none. Then the fridge died and needed replacing. So needless to say, the real world was not kind to me so the only choice I had was to cancel the game development which is sad as I think if I could have pulled off what I wanted to accomplish it would have been a great entry.

Not sure what I am going to do next month. Probably a post-mortem on porting my Vampire Attack game from Flash to JavaScript, but going over my texture generator is also a possibility.

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.

Halloween Scratch Postmortem

I have made huge progress on the emulator finishing the preliminary disassembly and starting work on an assembler so the next few months’ worth of blog posts will be catching up with where I am at with the project. The assembler was not part of my original plans but after getting the disassembler working it didn’t seem like it would be hard. Turns out to be a bit more complex than I expected but still worth doing. As soon as I get the assembler to a stable state (hopefully by next Wednesday’s post) I will post the code that I have written. Haven’t decided were the code will be hosted yet. Since I am so far ahead, I will spend a bit of time on my Christmas trilogy so may be posting three games over the next couple of months. But this week is the postmortem of my Halloween game.

While Halloween Scratch was not originally going to be the Halloween port for this year, while porting the vector assets of most of my Flash games into Create.js compatible JavaScript, it became apparent that some games benefit from developing them in Adobe Animate CC (hereafter referred to as Animate) while others only benefit from having the vector graphics converted into Create.js code. Animate is not the cheapest of software, so with my license running out this month I decided that I would not be renewing it for a while as I don’t really need it. Halloween Scratch was a game that was very animation oriented and was a simple game, finishing it in Animate while I still had the software made sense.

Halloween Scratch is a lottery ticket where instead of winning a prize, you win a monster.  There were other lottery ticket games at the time that were just click to reveal and I wanted to demonstrate to a potential client that you could have a much closer feel to scratching a real lottery ticket.

What Went Right

The animations worked pretty much flawlessly so very little work had to be done there other than with the alien as the transport effect was using color filters. Color filters in Animate are costly so they are cached which means you need to either force the image to be re-cached or come up with some other way of doing it. Simply creating images in the colored states (create a copy of the image then apply the color effect) was all that was needed.  If your game revolves more around animation effects, then using Animate is helpful. Most of my games are more code oriented so I am not sure it is worth it.

What Went Wrong

I had some strange issues with children in a container. I am not sure if this behavior stemmed from Animate, from Create.js, or from JavaScript itself. What was happening was that I used the target of the event listener to hide the dots that make up the scratch cover. There was a reset cover method that should have reset all the children to visible but even though it thought it was doing so, nothing was happening on the screen so already scratched off areas remained invisible. I am not sure why this was happening but was able to get the display list to properly reflect the visibility of a dot by accessing the dot through the dots array instead of the event target. It should not matter which reference of the object has its visibility changed yet in this case it does. I suspect this is one of the “this” pointer related issues that I always run across in JavaScript.

Mixed Blessings

I think the original game did an excellent job of representing the feel of a lotto ticket. Unfortunately, this was originally an ActionScript 1 game so the scratch code had to be pretty much re-written from scratch. I had hoped that using roll-over events would be detectible on tablets allowing for tablet users to scratch the ticket. This was not the case with the browser window being scrolled around instead. To solve this I added click support so by touching a tile it would reveal a block of the image. Not the best solution but it does allow browser users to play the game. Interesting side effect is that the tile can only be clicked if it has not been removed yet so computer users are pretty much forced to scratch the ticket.

Overall,  Animate is a good tool for porting animations and vector artwork to JavaScript but once that is done, the coding work is easier to do in other tools making it more of a utility than a tool. Animate is still a really good tool for creating animations so it would not surprise me if I end up renting the tool in the future but for my porting work, I am pretty much finished with the tool. Create.js is a workable solution for porting Flash games to HTML5 but ultimately you are working with JavaScript which is not the greatest of languages to work with.