I am a few days late with this blog post as I decided to wait and see if I participated in the 7DRTS before writing it. Due to other obligations I was not able to spend a week, or for that matter evenings during the week, to work on the 7DRTS challenge but having worked out a simplified 4X game in my mind I wanted to give it a go. This is not that game but hints at what I had in mind are all throughout this postmortem. The game was posted on Ludum Dare, but is going to be August 2nd Blazing Games release. For those who don't want to wait a few days, here is the link to the page so you can try the game out right now. http://blazinggames.com/gamejams/minild44/miniLD44.php
What Went Right
In addition to the Mini-Ludum Dare theme of 7DRTS, I decided even before I started that I would try and incorporate the One Game a Month theme of Metal into whatever game I designed. Massive space fleets battling each other on a galactic map fit this theme but when I had to reduce my scope as it was probably not realistic, fitting that theme into colonizing planets was a bit trickier. Coming up with the amount of metal different stars have affecting the production rate worked really well as it definitely determines which strategies are most effective. The most effective strategy is focusing on heavy metal stars but bottlenecking the opponent by taking advantage of the 10 light-year limit is also effective.
What Went Right and Wrong
When I first heard of the RTS component of the challenge, my first thought was a galactic conquest game with a focus on fleets. As I only had a couple of the seven days this wasn't possible, at least not the way I had in mind. While playing with my galaxy generation code I added code to detect clicking on stars and making sure that a star was within 10 light years of a star the player already owns. This is when I realized that a race to colonize the galaxy is ultimately what the game is about and by eliminating the combat it becomes easy to finish the game over the weekend. Of course, by not having any type of production choices, or fleet dynamics, the strategy element of the game is significantly reduced. My what went right added a bit of strategy back to the game so while still simple on the strategy level, the game is fun and fairly quick to play.
What Went Wrong
As was already mentioned, the original plans for this game was to be a strategic space combat game so I spent time working out a simplified fleet management system. Had there been a full week to work on this game I have no doubts that I would have been able to pull this off. As it was, after spending a few hours of putting together some basic fleet management code, I quickly realized that the game simply was too large for a weekend so scrapped the code. Except that I still want to do the original game. Yet another game in my ever growing list of projects. Ah well.
Sunday, July 28, 2013
Thursday, July 11, 2013
Creating NIM
When you look at the tag-based syntax that make up a HTML page, it is fairly clear that the format was designed more for static documents rather than interactive games. What you can do with pure HTML is rather limited. To get the interactivity necessary for all but the simplest of games, an additional programming language is need. This can take the form of the scripting language JavaScript which is built into all the major browsers. There are a number of other languages, such as Dart, that compile to JavaScript that can also be used but compiling to JavaScript is not quite the same as writing in JavaScript.
When I got a trollish email saying that JavaScript is not part of HTML5, which is only true on the most purest level, I decided to create a simple game using only HTML. A number of the tags that HTML5 added are clearly designed for use with a scripting language so to utilize HTML5 you really need to utilize a scripting language. Now if the email was complaining about WebGL, I would not have considered it a troll but still hope that Microsoft does start supporting it (as the rumours suggest).
The first problem that needs to be overcome when creating a no-script HTML game is finding a game that is simple enough to implement using only the markup language. This essentially means that the game needs to be representable using static pages with the interactive element switching between pages. While this is a huge restriction, I actually came up with a number of games that could be created using a number of static pages. These include 3D mazes, path choosing adventure games, combination puzzles, restricted move games such as Tower of Hanoi, and many of the various NIM style math games. Obviously I chose NIM.
The game must be broken into a number of pages. If we go with the traditional 17 objects, then we will need 17 pages for the player landing zones. The problem is that the computer needs to make a move. There are at least two ways to deal with this. The obvious solution is to add an additional 16 pages for the computer moves. When you think about it, the only thing that happens during the computer move is that the number of objects it is going to take is revealed so the only thing the player is doing is clicking to continue. While merging the computer results with the landing page adds a slight bit of complexity, it cuts the number of pages necessary in half.
The easiest way of implementing the game is to create the 17 item page, clone it, remove an item and repeat until all 17 pages have been created. A slightly faster, though more complex way of doing this would be to write a script to generate the pages for you. Each page simply consists of images and links to the lower-numbered three pages so this is really simple to create. That really is all there is to it. Sorry for boring you this week.
When I got a trollish email saying that JavaScript is not part of HTML5, which is only true on the most purest level, I decided to create a simple game using only HTML. A number of the tags that HTML5 added are clearly designed for use with a scripting language so to utilize HTML5 you really need to utilize a scripting language. Now if the email was complaining about WebGL, I would not have considered it a troll but still hope that Microsoft does start supporting it (as the rumours suggest).
The first problem that needs to be overcome when creating a no-script HTML game is finding a game that is simple enough to implement using only the markup language. This essentially means that the game needs to be representable using static pages with the interactive element switching between pages. While this is a huge restriction, I actually came up with a number of games that could be created using a number of static pages. These include 3D mazes, path choosing adventure games, combination puzzles, restricted move games such as Tower of Hanoi, and many of the various NIM style math games. Obviously I chose NIM.
The game must be broken into a number of pages. If we go with the traditional 17 objects, then we will need 17 pages for the player landing zones. The problem is that the computer needs to make a move. There are at least two ways to deal with this. The obvious solution is to add an additional 16 pages for the computer moves. When you think about it, the only thing that happens during the computer move is that the number of objects it is going to take is revealed so the only thing the player is doing is clicking to continue. While merging the computer results with the landing page adds a slight bit of complexity, it cuts the number of pages necessary in half.
The easiest way of implementing the game is to create the 17 item page, clone it, remove an item and repeat until all 17 pages have been created. A slightly faster, though more complex way of doing this would be to write a script to generate the pages for you. Each page simply consists of images and links to the lower-numbered three pages so this is really simple to create. That really is all there is to it. Sorry for boring you this week.
Subscribe to:
Posts (Atom)
