For the jam, I knew I wanted to make a game themed around the historical Cold War, or at least centered around nuclear politics and strategy. I originally started with the idea of playing as the U.S. or U.S.S.R., trying to influence their neighbors and eventually launch a devastating attack on their rival. But this was obviously way too complicated for a Jam game. I therefore tried to take this large idea and see what smaller part could be turned into a game.
I tried to focus on some of the theory behind nuclear strategy, and I took some time to think about what I knew. One concept that came to mind was the theory behind nuclear buildup. Both the U.S. and U.S.S.R. had very large stockpiles able to destroy the world a few times over. Why did the powers need so many weapons (after all, once the world is destroyed there’s not much point destroying it another 49 times)? The answer is the enemy’s stock pile size. The powers wanted to ensure that even if their rival was capable of destroying a large part of their arsenal, their rival could not destroy all of it, and therefore both powers would always be able to retaliate. Also, anti-ballistic missile (ABM) systems encouraged large stockpiles because no matter how accurate an ABM system is, it’s never perfect; this means that if a power wants to guarantee that a weapon would reach its target, they had to build lots of weapons.
I decided that nuclear build-up was a “small” enough topic to be turned into a jam gam, and after some more thought I had a concept.Two fictional Cold War era countries, West and East Cormania, are armed with nukes and relations are deteriorating. The player takes control of one of these countries and is tasked with preparing to attack his rival. At the end of the game, the player must target and destroy all of the enemy’s silos, so that the enemy cannot retaliate. If one silo survives, the enemy retaliates and the player loses the game. To reach this objective, the player must use espionage to learn the locations of the enemy silos, estimate the size of the enemy stockpile, and build a large enough stockpile of his own to destroy his rival. But there are hazards; if the player’s stockpile gets too large, the enemy may launch a preemptive strike, and if one of the player’s spies is captured and spills the beans, the enemy again launches a preemptive strike; in either case, game over.
From this I built up further ideas for the game. I keep two notebooks; in one, I keep general ideas for new games, without too much depth; in the other, I actually make an attempt at thinking through the game systems and coming up with a design. I used both journals, and after a couple days I had a design document good enough for starting programming. It includes text, sketches, tables, and the like, and ideas about how the spies should work, how stockpile sizes are estimated, some good music that would go well with the game, and even sketches of the countries’ flags.
The basic idea was to try to find some core concept, a “wire frame,” from which the rest of the game could be built out. I concluded that a good starting place would be a simple program that divides the game screen in half, with one half belonging to one player, and randomly placing three silos in this “territory.” This was not difficult at all. It was also a good way to start refreshing my GML skills. I had purchased Benjamin Anderson’s excellent guide GameMaker Language: An In-Depth Guide and read through it in a day, and I learned some GML tricks I did not know existed while at the same time refreshing my GML knowledge.
Next, I worked on adding two modules to my game, both free on the GameMaker Marketplace. One was Icarus Tree’s command line console, and the other Aperture Solutions’ debug console. Neither one of these would affect end game play, but I knew once I saw both of these that they would be a great way to add functionality for manipulating the game in ways I don’t want to be available to the player, and when I want to remove that functionality from the game completely, I merely delete the objects that make that functionality possible, no touching the code at all! Thus they’re great for debugging and testing a game. It took a little learning how to use these (and also they’re both called “console,” which could easily lead to confusion, so I also had to do some renaming) and how the GameMaker Marketplace even works, but it didn’t take too long and so far I love them. The command line is obviously the more useful of the two (and I made the debug console available only via the command line, rather than a keystroke), and my first function to it was one that toggled the visibility of enemy silos.
I wrote a script that would take a point then randomly generates a circle that contains that point. Doing so requires using a simulation method called the rejection method, which basically picks a random point in a square until it falls into the circle. This had to be done because only a random point in a rectangular region (using random_range()) could be simulated using GML’s built-in functions. To guarantee that a circle contained the desired point, I first considered a circle of the desired radius centered at the point to be included. Then I randomly select another point in the circle. This new point is the center of the new circle. The function returns an array containing the coordinates of that point, and with that the script ends. Fairly simple.
For next week, I hope to have some very rudimentary version of the game going, where the player controlling one side of the map detects the silos of his enemy on the opposite side then launches his attack. This basic game could then be sculpted into the final game. But one step at a time.