“Game A Week”: Develop a game each week rapidly, for several consecutive weeks. This is the way many developers train their skills and ideas.
These games are parts of the assignments for Fundamentals of Computing, a 6-course specialization by Rice University on Coursera. My tasks at the beginning were simple, but challenge escalates as I proceed. By the end of the project, I became capable of finishing programs of about 600 lines independently. I then further studied algorithmic thinking, but those classes focus more on processing data than implementing games.
SOURCE CODE AND PLAY
See source code and play each of the games (After the page is loaded, click “Run” to play):
Mini-project # 14 – Fifteen-Puzzle
Mini-project # 13 – AI for Tic-tac-toe
Mini-project # 12 – Word Wrangler
Mini-project # 11 – Zombie Apocalypse
Mini-project # 10 – Yahtzee Strategy Simulator
Mini-project # 9 – Cookie Clicker Simulator
Mini-project # 8 – 2048
Mini-project # 7 – RiceRocks (Asteroids)
Mini-project # 6 – Blackjack
Mini-project # 5 – Memory
Mini-project # 4 – “Pong”
Mini-project # 3 – “Stopwatch: The Game”
Mini-project # 2 – “Guess the number” game
Mini-project # 1 – Rock-paper-scissors-lizard-Spock
Mini-project # 13 – AI for Tic-tac-toe
Mini-project # 12 – Word Wrangler
Mini-project # 11 – Zombie Apocalypse
Mini-project # 10 – Yahtzee Strategy Simulator
Mini-project # 9 – Cookie Clicker Simulator
Mini-project # 8 – 2048
Mini-project # 7 – RiceRocks (Asteroids)
Mini-project # 6 – Blackjack
Mini-project # 5 – Memory
Mini-project # 4 – “Pong”
Mini-project # 3 – “Stopwatch: The Game”
Mini-project # 2 – “Guess the number” game
Mini-project # 1 – Rock-paper-scissors-lizard-Spock
GAMES
WEEK 1: ROCK-PAPER-SCISSORS-LIZARD-SPOCK
For me, this was the first game I wrote. It is simple, but has all the elements a game needs: a start, an end, and rules deciding winning or losing.
WEEK 2 : GUESS THE NUMBER GAME
The computer will generate a number in a fixed range. The player then make guesses and the computer will respond by telling you whether its higher or lower than the number. This is the first game I wrote that allows player configuring it before playing.
WEEK 3: STOPWATCH
This is a game about reaction. Coding this game involves writing separate functions for each feature. Player use the buttons to call start(), stop() and reset(). The game time runs on tick(). There is also a function that converts time to style like A:BC:D.
It was the first time I realize what kind of mechanism should run beneath the visual facet of a game.
WEEK 4: PONG
It is said Pong is the first video game ever existed. This game is the first I made that does not simulate the “logic” in reality, but the “physics”. The core of it is the speed of the ball, speed of the paddles, and the collision between them. To prevent the game from running on infinitely, I used a logarithm function to control the speed of the ball. Thus the ball will slowly accelerate toward a maximum, making the late game quite intense.
I get to feel what exactly does the “control feeling” of a game is. Each micro-adjustment to a perimeter may change the controlling experience. This would allow the designer to have an intimate control over the game. Besides, from this simple prototype I can quickly see many of the future variations like:
- hitting the paddle in different positions would cause the ball to bounce in different angle
- the paddle’s speed when hitting the ball would affect the ball’s track
- or, after consecutive hits, a player get to use an ULTIMATE SKILL…
- hitting the paddle in different positions would cause the ball to bounce in different angle
- the paddle’s speed when hitting the ball would affect the ball’s track
- or, after consecutive hits, a player get to use an ULTIMATE SKILL…
WEEK 5: MEMORY
The tricky thing about Memory is that there are actually three different states in the game, rather than two, that needs to deal with separately.
WEEK 6: BLACKJACK
Ah, the good old Blackjack. The first poker game I learned in my life.
In implementing this game I created classes. Since a lot of objects will appear repeatedly in the game. With the basic classes and functions done, adding card, showing hands can be put together with these basic movements.
WEEK 7: ASTEROID
This time the game involves a lot of various systems: mechanism, animation, sound effect and user interface. I learned to develop and test module by module, making sure each function is bug-free and proceeding with the next.
Implementing this game gave me some insights on game design. There were many parameters the designer have control of: the pushing and turning of the ship, frictions in the space, forces from collision with asteroids, etc. I needed to take account of all of them, and adjusting each one can make the game totally different. Am I controlling a flexible fighter or a massive battleship? Am I rushing through a shower of asteroids or floating among them? Each choice seemed fun enough. This is when I realize how important a “commander intent” is while making a game. I need to clearly define the experience I am about to give players, and remember it, and stick to it.
WEEK 8: 2048
This one looks simple, but is actually pretty tricky. The first problem I encounter was how to represent the cells:
[[0, 1, 2, 3][0, 1, 2, 3][0, 1, 2, 3][0, 1, 2, 3]]
Then the core movement — merging cells. For this, I first wrote a merge() function which takes a list and start to iterate and return values that are merged. I then go to the main class, and define in the move() function that each time the player moves in a given direction, it creates four lists starting with four cells of that direction. merge() will process them, and replace the old ones. The moment this function ran without a bug was a moment to savor.
WEEK 9: COOKIE CLICKER
The game itself was simple. But this time I need have the computer play for me:
To design the AI for it, I made a function simulator_clicker() which buys the right item at the best timing, according to a given strategy. And each strategy is defined separately.
WEEK 10: YAHTZEE
The interesting part about building an AI for this game is that it involves chance and expectation. I have a certain number of dices, then I need to calculate a tree of all the hands I might end up with, then find the most probable one. I implemented four separate functions for the steps.
WEEK 11: ZOMBIE APOCALYPSE
Please imagine a group of human (green) got surrounded by zombies (red) in a ruined house.
Ah, zombies. The classic enemy of civilization. The game looked just like above, where:
1. Black cells are obstacle like wall, palisades or broken cars. No unit can pass.
2. Red cells are zombies. They can move in four directions and will automatically go for the nearest human.
3. Green cells are humans. They can move in eight directions and will flee from zombies.
4. Purple cells are the infected. Human who got “bitten” by a zombie becomes one. Won’t move.
2. Red cells are zombies. They can move in four directions and will automatically go for the nearest human.
3. Green cells are humans. They can move in eight directions and will flee from zombies.
4. Purple cells are the infected. Human who got “bitten” by a zombie becomes one. Won’t move.
All the cells are arranged by the player, therefore this is somewhat a sandbox game. click “humans flee” or “zombies stalk” to allow all humans or zombies to move once. They both use breadth first search to decide their actions. The game won’t end by itself, so you can set your own goals in this sandbox and have some fun imagining it all out.
WEEK 12: WORD WRANGLER
To read the input word and match it to all possible words, I was going to need a merge_sort() method to sort a list. This was the first time I get to know recursion. That means the function keeps calling it self.
Before designing a recursive function I need to clarify the base case where the recursion stop. I figured that when given a list, the function will split the list in half, and keep recursing until the number of the character become 1.
WEEK 13: TIC-TAC-TOE
Building the AI for this game requires Monte Carlo Method. That is, to simulate each possible step from now on toward the end of the game. This idea can cost a lot of resource but with such a small board, it will be enough.
Then, to test whether this AI opponent is strong enough, I “mirrored” the rule of the game, and it became “the reversed tic-tac-toe”. The first one who gets three marks in a line loses. The first time I played with the computer, I lost! By this moment the AI I wrote has entered an era where the computing power is unleashed. If I expand the board infinitely and change the winning condition to the scale, human mind will soon be outsmart.
WEEK 14: FIFTEEN-PUZZLE
The rule for a fifteen-puzzle isn’t hard. But an automatic puzzle-solving AI can be difficult to build. After playing the game repeatedly, I found out that I can dissect the board into following sections:
Below row 2 and to the right of column 1
Below row 2, column 1
Row 1
Row 2
First 4 in row 1, in the last phase of the game
Below row 2, column 1
Row 1
Row 2
First 4 in row 1, in the last phase of the game
You can check the gif and see how I have the computer solve each sections.
BOTTOM LINE
After all those programming knowledge and methods, there are a few ideas that I learned:
1. Strip down the “feeling” of your game to basic parameters, then start analysis and adjust.
2. Evaluate the approach to each feature according to the complexity and efficiency of implementation methods.
3. Break your blueprint into steps, and put them together to become a complete game.
2. Evaluate the approach to each feature according to the complexity and efficiency of implementation methods.
3. Break your blueprint into steps, and put them together to become a complete game.