Saturday, October 6, 2018

4.8 Winning and Losing


As you know, the game ends when the last gem has been taken. Also obvious is the fact that there are two possible outcomes for this game. The player can win the game, or the computer can win the game. Knowing this, our movie is going to have to be able to handle either situation. This will require a bit of JavaScript. Here is the final version of the gemRemoved function with the new lines bolded.



function gemRemoved(gemCount) {
   if (gemCount <= gemsRemaining) {
          gameMovie.stop();
          if (gemCount == 0) {
                 if (gamestate == GAMESTATE_PLAYER_ANIMATING)
                       gameMovie.gotoAndPlay("playerWins");
                 else
                       gameMovie.gotoAndPlay("computerWins");
          }
          if (gamestate == GAMESTATE_PLAYER_ANIMATING)
                 computerTurn();
          else {
                 gamestate = GAMESTATE_PLAYER_PLAYING;
          }
   }
}
Both sequences start out with the final gem growing larger while moving to the left side of the screen. This is a simple scaling operation combined with a movement operation. The end result is shown in the image below.







To keep the code simple, the end sequence will simply display the results for a few seconds before returning to the title screen. An alternative approach would be to have a button that the user clicks to return to the title screen. To return to the title screen we simply call a returnToTitle function at the end of the winning screen and at the end of the losing screen.
The line of code that needs to be added to both:



                            returnToTitle();



Finally, we need a function in the global script called returnToTitle that actually does the work:



function returnToTitle() {
   gameStage.gotoAndPlay("Title");
}



And now we have a our completed NIM game!

Saturday, September 22, 2018

4.7 State of the Game


Progress on the NIM game has gone well and we have the core components of the game implemented (see the earlier sections previously posted). While we now have the core game mechanics implemented, we do not have a game. Right now we just have the ability for the player to take gems unitl there are no more gems. To have a proper game we need to be able to alternate between two players (the human and the computer). We also want the user interface to not accept input while the game is animating or the computer is playing. For this we will need to know what the movie is doing at any point of time. The easiest way of tracking this is to have a gamestate variable that holds the current state of the game with constants defined for the four states that we are concerned with.



// explain the different states of the game
var GAMESTATE_PLAYER_PLAYING = 1;
var GAMESTATE_PLAYER_ANIMATING = 2;
var GAMESTATE_COMPUTER_PLAYING = 3;
var GAMESTATE_COMPUTER_ANIMATING = 4;
var gamestate = GAMESTATE_PLAYER_PLAYING;
This means that we can now update the button handling routines to make sure that it is the player’s turn before doing anything with the button click. The new code is bolded.



function handleOneButton(e) {
   if (gamestate != GAMESTATE_PLAYER_PLAYING)
          return;
   --gemsRemaining;
   gamestate = GAMESTATE_PLAYER_ANIMATING;
   gameMovie.play();
}
function handleTwoButton(e) {
   if (gamestate != GAMESTATE_PLAYER_PLAYING)
          return;
   gemsRemaining -= 2;
   gamestate = GAMESTATE_PLAYER_ANIMATING;
   gameMovie.play();
}
function handleThreeButton(e) {
   if (gamestate != GAMESTATE_PLAYER_PLAYING)
          return;
   gemsRemaining -= 3;
   gamestate = GAMESTATE_PLAYER_ANIMATING;
   gameMovie.play();
}
The gem removal routine can also be fixed up to nearly it’s final form by having it start the computer’s turn after the player’s turn has finished being animated and returning to the control to the player once the computer has finished it’s turn.



function gemRemoved(gemCount) {
   if (gemCount <= gemsRemaining) {
          gameMovie.stop();
          if (gamestate == GAMESTATE_PLAYER_ANIMATING)
                 computerTurn();
          else {
                 gamestate = GAMESTATE_PLAYER_PLAYING;
          }
   }
}



Of course, for there to be a computer player, the computer needs to know how to play the game. It is quite possible to have the computer play the game perfectly, but that is not much fun for the player so instead the computer will play randomly until near the end of the game where they will take the opportunity to win the game if it presents itself.



function computerTurn() {
   if (gemsRemaining <= 3) {
          gemsRemaining = 0;
          setMessage("Computer taking " + gemsRemaining);
   } else {
          var numToPick = Math.floor(Math.random() * 3) + 1;
          setMessage("Computer taking " + numToPick);
          gemsRemaining -= numToPick;
   }



Random number are technically not random, but are pseudo-random but the details is not important. What had to be understood is that the Math.random() function returns a number between 0 and up to but not including 1 so that number needs to be adjusted to a usable value. Multiplying by three gives us a random number between 0 and just under 3. We want a decimal number so we use the Math.floor function to round the number down giving us a number between 0 and 2. Add one to this and we have the number in the desired range.



This leaves us with one final issue, which is winning or losing the game. This will be covered next fortnight!

Saturday, September 8, 2018

4.6 Gem Removal


The game revolves around the removal of gems, so we obviously need a way of removing gems. As the goal of this movie was to limit the amount of Action Script that is to be used, we will have to animate the removal of all the gems by hand. This is not that difficult of a task, only requiring that we have forty short animation sequences. The question is how do we stop all forty gems from being removed?


Unfortunately, this will require a bit of action script at the end of each removal sequence. This means that each gem removal sequence also must have a script frame which contains a function call.


gemRemoved(numberOfGemsAtThisPoint);


This calls a function that handles the removal of gems. The logic here is simple. We have a common variable that holds the number of gems there should be. When gems are removed, this value gets reduced. The gemRemoved handler keeps the movie playing until the number of gems remaining matches the number of gems displayed on the screen.


As you develop a game, the code changes as new features are added. It is always good to follow the KISS (Keep It Super Simple) acronym and start by writing just the code you need to get the goal you are currently working on working. As the program develops it becomes more robust. At this point you can review the code you have and do what is known as a refactoring pass. This means that you clean up the code so that it is easier to understand and more maintainable. At this point we are only concerned about getting gems to be removed so the code in the remove gems function and the related player panel button handlers will just contain the code necessary for doing the gem removal. This code will be changed in the next section as we add the game states but for now is what is needed to get our gem removal goal completed.


function handleOneButton(e) {
   --gemsRemaining;
   gameMovie.play();
}
function handleTwoButton(e) {
   gemsRemaining -= 2;
   gameMovie.play();
}
function handleThreeButton(e) {
   gemsRemaining -= 3;
   gameMovie.play();
}
function gemRemoved(gemCount) {
   if (gemCount <= gemsRemaining) {
          gameMovie.stop();
   }
}

For the gem removal, I just randomly selected a way of removing gems and manually created that sequence. Before you can remove the gem, you need to remove the gem from it's gem layer and place a gem in the same position as the removed gem but on one of the animation layers. From there, you can freely animate the gem to be removed. I came up with three separate ways of removing gems. Shrinking, Fading, and Rockets.


The shrinking technique simply has the gem shrink into nothing. As variations on this technique, some rotation can also be applied to the gem. Essentially you have the first keyframe with the gem at normal size. You then have the last keyframe with the gem at a percentage of what it was, optionally rotated. You then have a Motion Tween between the two frames.


Fading is simply having the motion tween between the gem with 100% alpha and the gem with 0% alpha. Rotation can also be done to this, but with gems near the gem you will want to keep the rotation to only a small amount.


Finally, rocket is simply moving the gem from one location to another off-screen location.

Saturday, August 25, 2018

4.5 Player Panel

At this point in the development of NIM, we are ready to create the panel. This is important as it is the way that the user interacts with the game. As discussed earlier in this chapter, there are other user interfaces that could have been used but this approach was chosen as it is the easiest to implement. The player panel could have been designed as an all in one object, but that would have added a bit of complexity to the design and I wanted to try and keep this movie as simple as possible for those new to Animate CC. Instead, the panel is simply a rectangle with rounded corners. It is animated into its final position by using a simple motion tween.

Once in its final position we add the components on the panel. The first component on the panel is the message bar at the top of the panel. This is a simple dynamic text object labelled “messages” and set to use a center aligned 24-point grey “serif” font. Below that we create a static text message that reads “Take how many?” I broke this into vector text and created a graphical symbol out of the text. Finally there are three buttons labelled “1,” “2,” and “3.” These three buttons are created the same way we created the "Start the Game" button. Simply type in the number. Break apart the number so you get a Flash object. Select the "Make Symbol" option to convert the object into a button symbol. Fill in the over and down keyframes with different colored versions of the number object. Finally, in the hit keyframe, create a solid box that covers the number.

Once all the components of the panel are visible, we need to make the three buttons do something. The code for the buttons is like the code that we used with the start game button. The one significant difference is that we are using a function that handles setting up all three buttons and we also need to be able to turn off the buttons. This code is simple enough as we simply call/remove the handler for each button by using the addEventListener or removeEventListener methods.

function startPanel(gm) {
    gameMovie = gm;
    gm.messages.text = "You go first!";
    gm.one_btn.addEventListener("click", handleOneButton);
    gm.two_btn.addEventListener("click", handleTwoButton);
    gm.three_btn.addEventListener("click", handleThreeButton);
}
function stopPanel(gm) {
    gm.one_btn.removeEventListener("click", handleOneButton);
    gm.two_btn.removeEventListener("click", handleTwoButton);
    gm.three_btn.removeEventListener("click", handleThreeButton);
}

The actual handlers for when the buttons are clicked are game-play related so will be covered in a later section once we start implementing the gameplay logic. Another function that we will need for the panel is a function to write the message bar text. While this is a very simple thing to do and could be done directly wherever the message needs to be set, I find calling a function that sets the message bar is a bit easier to understand, and adds some flexibility in the case that how messages are displayed changes in the future.  Quite simply, this function takes the text passed to it and assigns that text to the dynamic text object we defined in the panel.

function setMessage(s) {
            gameMovie.messages.text = s;
}

As the buttons that make up the user interface cover removal of gems, we need a way to remove gems. That will be covered next section.

Saturday, August 11, 2018

4.4 Limiting Layers


In theory Animate lets you have as many layers as you desire. However, you should try to limit the number of layers that you use to make managing the movie easier. Designer overload is caused by the designer having to deal with a huge number of layers. When you have too many layers to deal with, it becomes harder to find the layer you need and if there is interaction between layers that are of substantially different levels, then work can be frustrating.

To layout the game, we need to get the 40 gems to appear. If you look at screenshots for the game you will see what the final layout looks like. The problem here is that 40 gems would result in 40 layers. That is a lot of layers to keep track of. So instead of forty layers, let us group each row into a layer. Extra conservative designers would probably have all forty gems in a single layer, but I originally designed this around four layers.

Those of you familiar with Animate CC probably already know that Animate CC tends to act funny when you try having animation on a layer that contains more than one object. It wants to only deal with one object for a tween so when it has many to deal with it automatically generates its own movie clips to hold intermediate tweens. This is almost never what you want so it is best to avoid that situation. As that is the case how are we going to animate the gems? After a bit of thought, I realized that at any given time, I would only need five gems animated at a time. This can be handled by creating five animation layers.

The animation is simply handled by assigning gems to animation layers. When the gem reaches its final position, the layer it belongs to then adds that gem to it's objects. The animation layer is again free to hold another gem.

To demonstrate, lets deal with the first few gems. We create the gems outside the screen in a pattern that wraps clockwise around the screen. The first gem gets assigned to GemAnim1, which is our first animation layer. It uses simple position keyframe animation to move (the first keyframe is where the animation starts, the last keyframe has the gem where the animation ends and a motion tween is placed between the two keyframes). The second gem uses GemAnim2, the third uses GemAnim3 and so fourth. Gem number 6 has no layer, but as it will not start to be animated until gem 1 is in it's final position, it can use GemAnim1. It can do this because there is no longer an object in this animation layer as a gem has been added to the appropriate gem layer. Gem 7 is not needed until gem 2 has been placed in it's layer, so it will use the GemAnim2 layer. And so on, until all forty gems have been animated.



Saturday, July 28, 2018

4.3 The Play Game Button

The play game button is made by just typing the words "Play the Game" in a large font, converting the font into vector objects by using the break apart command twice and then coverings the whole group of objects into a button symbol. The color of the text is changed for the over and down frames of the button. A solid box that covers the text is used for the hit button.

The appearance of the play game button is easily handled by having a keyframe with the button outside the screen and a second keyframe with the button in the final position. A motion tween is added between the two frames. Likewise, the same thing is done with the other two buttons.

For a button to do something, some JavaScript is needed. Typically, a button needs three pieces of JavaScript which are letting the system know you want to listen to the event, an event handler for handling the event, and letting the system know you no longer care about the event.

The first piece is simply some code to let the system know what function is going to handle the button. It is possible for the same handler function to handle multiple buttons, but that will be covered in the future. The code can be placed in several places with no strict rules on where you want to place it. For this game, I have created a layer on the main timeline called “Code” where I can add code to frames.

To associate code with the button, the button must be given a name. This is done by typing the name into the instance name section of the properties panel (in the left corner of the properties panel). In our case, we are calling the button “play_btn”. The code to let the system know you want to do something when the button is clicked is simply:

this.playGameBtn.addEventListener("click", playTheGame);

The method addEventListener tells the button that when the indicated event, in this case the Click event though other events can be listened for, it is to call the function playTheGame. This is where our approach to handling multiple scenes becomes an issue. Multiple scenes need a way of communicating with each other. The easiest way of dealing with this issue is to have some global code that all the scenes can access. Animate provides such a script, so the code for handling clicking the play game button will be placed there.

This global script needs access to the main scene movie. To do this we simply have the main movie call a registerStage function which stores the stage movie into a variable movie which gives us the ability to change scenes and access functions within any of the movie clips that we are using as scenes.

function registerStage(stg) {
    gameStage = stg;
    gamestate = GAMESTATE_PLAYER_PLAYING;
    gemsRemaining = 40;
}

The playTheGame is the function we will be writing to handle the start of the game. The function simply is a function that contains the code that is to be run when the event happens. In our case this is very simple:

function playTheGame() {
            gameStage.gotoAndPlay("Game");
}

The gotoAndPlay() method simply tells the main movie that it is time to start playing from a different frame. If we had multiple buttons that went to distinct parts of the movie, we could easily set up each button to go to a different frame of the main movie.

Saturday, July 14, 2018

4.2 Title Screen

Normally when I create a game, the title and menu screens are the last screens that are created. For this chapter, however, I am going to create the games title sequence first. This demonstrates one of the big differences between Flash games and Animate HTML5 Canvas games. As of Animate 2017, there is only a single scene so switching between scenes is not allowed. The normal approach to creating a game is to break up the different screens of the game into separate scenes. For Animate, this can’t be done but there are several different alternatives. The approach that I will be taking in this book is to break the game up into separate movie clips that act like scenes and have a single master movie that contains the movie clips as separate frames of the main movie.


 The screen starts off blank. Seven gems then grow onto the screen in what at first seems to be a random pattern. Once the gems are fully grown the letter N fades in behind the gems. This is followed by three gems appearing to create the letter I and another 7 gems to form the M. If you look at the screen shot of the final logo  you will see what the final screen looks like.


To create this sequence, many layers are used. While the number of layers could be reduced (you will see a technique for that later in this chapter), I figured that for a title sequence, the extra layers wouldn't hurt.

Each gem is on its own layer. When I created this title, I first laid out all the gems into a rough NIM pattern. To make sure that people could read the title, I then used the line tool to create an outline of the letters. I filled the outlines with a solid color and turned each of the letters into a symbol.



The appearance of the gems is stepped so that they don't all appear at once, with additional delays for the appearance of the letters added. Each gem is animated using two keyframes. The first keyframe is scaled to 10% of the original size. A motion tween between the two keyframe's is then added.

The fading letters is a simple alpha blending tween. You start by creating a second keyframe of the letter. The first keyframe is then set to an alpha level of 0. A motion tween is then placed between the two keyframe's.



Saturday, June 30, 2018

4.1 NIM Design

While NIM is a very simple game, it is a good game to start learning game development with. The game is very straight forward in its presentation. The rules of game play are very easy to implement. Most importantly, at least for beginning Animate developers, the game requires only a minimal amount of JavaScript.

While I personally have no problem with JavaScript, I know a lot of Flash and now Animate developers who fear scripting languages. Games, by their interactive nature, require scripting. There is, however, no need to jump right into extensive JavaScript use. Our first project will attempt to keep JavaScript to a minimum.

We already know what the game is about from the description in the previous section, so what is needed is specific details on the game. There are three things that must be decided. What is the object that is being removed, how many objects are there to be removed, and how does the player remove them?

All of the questions can be answered pretty much any way the designer wanted and the game will still work fine. For the object, anything could work, though I look at the object as something valuable that the person would want the last one. To me I think of jewels or gems when I think of something valued. The reason that gems are valued is because they are rare. The bigger the gem the rarer it is. This means that if the last gem is a big gem then it is a very valuable gem.

The number of objects is simply a matter of how many can fit on the screen. Four rows of ten seemed to make sense, so for this version we will have 40 gems. This would also leave room for a space where the user could specify how many gems to take. As the only interaction the user has is select how many gems to take, the user interface is simply three buttons, with a text area to describe what is happening.

Using buttons to remove the gems is not the only way this could have been handled. An alternative interface would be to have the player click on the gem to be removed. This would be intuitive, especially if the allowable selections were highlighted in some way, but without use of JavaScript would be a huge amount of work.

Saturday, June 16, 2018

Chapter 4 NIM

For the next few months I will be posting Chapter 4 of my "Creating HTML5 Games Using Animate" eBook, which is broken into 8 sections. Once that has been completed, I will post an update for my spelchan.com plans. With my Masters program starting in September, I am not sure how much time I will have to devote to the site so hopefully will have a better idea once this chapter has been finished being posted. I do plan on continuing porting a game a month from Blazing Games to Spelchan.com but may focus on the simpler games. I am planning on blocking out time for both porting and my emulator project but obviously if I need the time for my course work and TA/RA duties then those hours will be sacrificed.

While I have seen this game go by other names, I was introduced to the game as NIM. I have no idea why it was called that, but figured that I would stick with the name I am familiar with. The game is a very simple game where you have a set number of objects. Each turn the players can take from one to three objects. The goal of the game is to be the player who grabs the last object.

Apparently this game has been used within the mathematics of Game Theory to demonstrate certain principles. I have also heard that the game has been mathematically solved and that there is a way of playing the game that will guarantee winning the game. I have not researched either of these things, but readers who are interested in this game may want to do research on these topics.

The game has already been posted on my Spelchan.com site for February (NIM). Here is a screen shot of the game:



This chapter starts out with a look at the design behind the game in the section “NIM Design Overview”. Normally when I am developing games, I focus on the game play and getting the core game working before getting to things such as title screens but for this game I am developing the game in sequence. The ”Title Screen” section then covers the creation of the animated title logo sequence with the “The Play Game Button” section explaining how the start game button was created and how to write the JavaScript to activate the button.


With the title screen out of the way, we need to start work on the game so the “Limiting Layers” section covers the laying out of the playfield in such a way that we don’t need to use 40 different layers for handling the layout. As the game is controlled by the player, the “Player Panel” section covers how the user interface element of the game works. Having buttons to remove gems doesn’t do very much unless you are able to remove gems so “Gem Removal” covers removing gems from the game screen. The removal of gems is refined by adding different game states and a computer-controlled player in the “State of the Game” section. Finally, we have “Winning and Losing” which covers ending the game.

Saturday, June 2, 2018

Fleet Postmortem

Fleet is one of the first Java games that I wrote. As the game was written in Java, and Kotlin is a replacement to Java which can compile to JavaScript, I decided to see how well Kotlin works for HTML5 games. The create.js library was used for handling the GUI aspects of the game. To make the game more playable on tablets, I had to rework the user interface quite a bit which makes this more of a re-write than port.

Fleet was released on Spelchan.com on June 1st and is based on the classic pen and paper game that is now played on a board with easily lost plastic pieces. You control a fleet of ships. You have an opponent who also controls a fleet of ships. Your goal is to destroy your opponents fleet of ships before your opponent can destroy your fleet of ships.



What Went Wrong

In the original Fleet, ship placement was done one ship at a time with the player using the space bar to rotate the ships. As I wanted this to work on touch-only devices this meant that requiring a key stroke was out of the question. Dragging the ships around to move them seemed like the ideal touch-based controls. Double-clicking on a ship to rotate the ship became the obvious solution for ship orientation.
While create.js does have some support for drag-and-drop, I still had to write a fair bit of code to get this to work. Getting it working with the mouse was easy but for some reason it would not work on the tablets that I have access to. I finally searched on-line for any information where I discovered that you had to enable touch by using the Touch class. Seconds later I was running it fine on my tablet, but my Dad's older tablet ran very poorly and inconsistently. While I suspect that this is predominantly due to the age and slow speed of the device, I decided it would be a good idea to have the initial layout of the player's ship be randomly generated just like the AI ships so that if a player was having problems moving ships around, they could just go with the default random layout.
Testing the dragging and dropping of ships resulted in the ship often not going where the player was expecting due to the way the sprite snapped to the grid. One solution to this problem was to simply have the grid snapping happen as you dragged the ship but this simply did not feel right. The original version would highlight the grid squares where you were going to place a ship in white or red so I figured that I would do the same thing here but opted for yellow and red. This took a bit of work to accomplish but I think the results are quite nice.

Mixed Blessings

Kotlin is a rather new language that came to the scene more as an alternative to Java programming on Android but with the ability to compile to JVM, JavaScript, or Native it has a lot of potential. I started my Atari 2600 project to try out the language where I found myself enjoying the language. I wanted to see if it could be used for porting games so decided that as Fleet was originally written in Java, it would be a good contender.
One of the nice features of Kotlin is that you are able to use the "native" features of the platform you are compiling to so a JavaScript project can make use of JavaScript libraries and other native features. This has to be specified using the external designation but there is a utility to convert TypeScript definition files into Kotlin definitions so it was simple enough to get a create.js definition. Using create.js with Kotlin always felt like a kludge and its JavaScript nature made working with it awkward for many activities such as tweening.
The biggest downside to using Kotlin and Create.js together is that both are large libraries making the loading time a bit larger than I would like. For a larger project this would be okay, but startup time for Fleet seemed to be way too long.

What Went Right

The AI that I created for the original version of this game was surprisingly good and yet was fairly simple to implement once the base ideas behind it were worked out.  The version of the AI in this game is essentially the same as the original version except that it was cleaned up. It didn't take too long to port the code over and it just work. If all the code I ported went this smoothly, I would have ported many more games by now.

Summary

I think this version of Fleet is a bit nicer than the original though there is still a lot of things that I would have loved to do had I the time. It is possible that I may revisit this game in the future with a deluxe version of the game, but that will not be for a while.
As for using Kotlin for future HTML games, I am still up in the air. If I could find a good cross-platform library with similar functionality to Create.js, then this would possibly be a good thing. Writing my own cross platform library is not likely in the near term, but after I get my Masters it may be something I would think about. I am still wanting to try out the Rust language, so how much I like that language will determine which of the two languages I will be focusing on in the future.

Saturday, May 19, 2018

Towels for Earth Postmortem

This is a postmortem for the game that I will be posting on May 25th for Towel Day which is the HTML5 port of Towels for Earth. Towels for Earth was a game that I created for a Game Jam back in 2013. The theme of the game jam was towels in honor of Douglas Adams. I suspect that there are several Douglas Adams fans who managed to encounter my Blazing Games site somehow as the polls show that there are quite a few people who wanted to see this game ported to HTML5. It is a fun but short missile defense game where missiles are destructor beams and anti-missiles are towels with the player tossing towels at destructor beams to save the Earth.



What Went Right

This was a game-jam entry so it was very quick to port over. I had a bit of time left over from what I budgeted so I decided to add some sounds to the game. The original game is in space for which there is no sound, but purists can simply turn the sound off via a nifty sound toggle that I added. The speaker artwork was taken from another game I wrote that had a sound slider but I didn’t have enough spare time to try and create a slider, but that is probably something I should be doing in the future if I ever get enough spare time, which won't be in the next couple of years.

I started going through some of the public domain and royalty free sounds that I have collected over the years to find a few sounds that would work with the game. While some people may not like my choices, I think they work well for the theme of the game. Sound in Create.js is very easy to play if the files have been downloaded which I am using preload.js to do so this was trivial to add once the sound files were found.

What Went Wrong

I went a bit overboard with the original game and had created a pixel-perfect collision detection routine. This requires the use of bitmap libraries that Create.js doesn’t have and would have been very painful to do – not to mention excruciatingly slow – to do so I reverted to good old-fashioned bounding circles. The wonderful thing about bounding circles is you just find the distance squared between two objects and see if the squared distance is within the combined radiuses. The problem is that if one of the shapes is not spherical, then the collision results can be a bit inaccurate. I don’t really mind too much but suspect that I may hear some complaints about this. I did try to be a bit generous with my circles feeling it is better to have more false positives than false negatives.

Some of you may be wondering why I am using distance squared. This is an old-school technique to save a bit of CPU cycles. Distance is sqrt( (x1-x2)^2 + (y1-y2)^2) which is a slow routine to calculate since square roots are very slow to calculate. On the other hand, radius*radius is very fast to calculate so by forgoing the square root portion of the calculation you can speed up the check while keeping the accuracy of the calculation.

Mixed Blessings

The original game used a combination of background images and vector artwork, but I opted to go with all images even though I could have saved a bit of space by using some vector images. The tradeoff of a slightly larger file size for slightly faster game rendering and a easier coding was arguably worth it. The images I did want to have as vectors were actually fairly large so it wasn’t that much space that I was using. My original plans were to have the backdrops converted into a separate jpeg file while the other parts were stored in a png file so I could get a bit better compression. When using my image view to see how different compression ratios would affect the image quality, I noticed that the images looked pretty good when converted to 8-bit png files with only a small increase in file size so I put all the images into a single image atlas.

For people who still have slow internet connections, these decisions may have resulted in longer loading times. For that I apologize as I know most people with slow internet don’t have a choice in the matter.

Conclusion

Overall, I am happy with how this game turned out. Sound does add a bit to the game, but sound and music is my Achilles heel. I really have to start trying to add more sound to my games in the future.

Saturday, May 5, 2018

State of the Site May 2018 update

With my being accepted into a Master of Science in Computer Science program I will be extremely busy for the next couple of years. I do want to keep up with my site, which is not that time consuming if I predominantly post ports of the games from Blazing Games so both this blog and my homebrewgamejam.blogspot.ca blogs will continue while I am in university. The frequency of the updates is going to be shifted from weekly to alternating between the two blogs with each having an article posted every other Saturday. If things get too hectic, I may cut back to a monthly update but am going to allocate a block of time towards the site and blogs so that things will continue unless something bad happens.

My Easter Egg generator is not really writing a postmortem for. While I did learn a bit about color filters while creating it, this is not enough to warrant a full article.

This month is seeing the release of two games. The first being the HTML 5 version of Four in a Row which is not a new port but does need to be transferred over from the Blazing Games site eventually and as towel day is so late in the month why not this month. The original version was still rough so I decided to clean up the AI a bit and to add animation to the game. There is still a lot that I would like to add to the game before I would consider it to be complete but not sure when I will find time to do that so it may be a decade before this game is properly completed.

Towel day will be the release of my Towels for Earth port. However, I will be posting the postmortem of the game before the actual release of the game. That will be the topic for next fortnight’s post after which I will start posting Chapter 4 of my Animate CC eBook.

Fleet, which I was planning on posting in June, is not quite ready. If it is not ready in time I may post a different game in it’s place but hope to have it finished. If the game is not ready by the 25th then I will go with an alternate post. Either way the site will have information about what I am going to post. If the game is delayed, it will still be worked on so will be posted later in the year. 

July's game will be released on the 13th of the month as that month has a friday the 13th. It is going to be 13^2 Spikes. August is String Along, but I may substitute it for Fleet if a delay is required.September is when CQ is finally suppose to appear but if things go as planned there may be a bit of a surprise with that release.