Mark Alexander started a series of blog posts a few months ago that I have read religiously every week. In his blog, he describes how he is making a game in GameMaker: Studio from start to finish, providing me valuable insight in not only tips, tricks, and techniques in game design and programming, but also the process of how to make a game. I have been itching to make a game ever since August when I started using GameMaker, and I have always planned to get back into design once I earned my bachelor's degree; I even paid for the full version and the HTML5 export module, and published the first game I ever made on GameJolt. The semester is now over, and it's time to make use of my investment. And like Mark Alexander, I will be documenting my process in a series of blogs.
Almost a month ago, the GameMaker Community held its 18th game jam. I have been growing an itch to join a jam, but sadly, not only was school still in session that weekend, it was also the weekend of my girlfriend Jasmin's birthday; no jam for me. When I saw the theme of the jam--"Cold War"--I became doubly disappointed I couldn't join. I did for a minute think there was some possible way that I could squeeze in time to make something, and for the heck of it I developped the idea for a game. I didn't do anything during the jam other than this, but nothing is stopping me from taking that initial idea and turning it into a game now!
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.
From there, I began making the game. One thing I learned from Mark Alexander's blog is not trying to bite off more than you can chew at once. I began thinking of my game as a sculpture with a wire frame. One starts with a wire frame that gives a very vague representation of how your sculpture will be shaped. Then you clump on clay in little pieces, fleshing out the sculpture slowly, focusing on local areas. Eventually, you will have a complete sculpture.
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.
Two more features were added. One was creating "areas of belief." In the game, enemy silo locations are learned progressively, and it takes three successful missions to finally learn the precise location of a silo. Up until then are circles that contain the silo location, but vary in size. The first circle drawn is large; a player basing his guess for the silo location on the information present there is likely to guess wrong. After a successful espionage mission to refine this information, the radius of this circle become smaller; while still larger than the blast radius of a nuke, it should not be too much larger, and the player could base a nuclear strike on it, though not without some risk.
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.
The last feature I added was a command in the command line to give players more silos, and a button shaped like a spy to draw areas of belief around new silos, ones that did not already have these areas drawn. All the while I had been generating game art using just GameMaker's built in art application. I'm unsure whether this will be the final game art. I know what art scheme I want: it will be very similar to the scheme in the game in the movie WarGames, and also similar to the scheme in the game DEFCON. But I may want to use vector graphics rather than raster graphics for the game art, which I would have to make in Inkscape. But that's a bridge that will be crossed later. The issue at hand was getting a working game.
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.
0 Comments
Leave a Reply. |
AuthorCurtis Miller is an instructor and graduate statistics students at the University of Utah. Archives
June 2016
Categories
All
|