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.

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.

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.