I decided to finally continue with the Challenge for Game Designer course that I started way back in July of 2009. I just finished up reading the second blog post by Ian (the person running the course), in which he stresses the importants of iterating and rapid prototyping a game. The take away message from this reading is that a game gets better the more you iterate through it. With that, he gave us a small assignment to go back to the original game that you designed in Level 1 (Ice Mountain) and actually give it a play through. Afterwards he wanted us to make one change and see how that affects the game play. Below you can see a picture of the final result of the first play test. My girlfriend helped me by being my only opponent, I ended up winning as the green thumb tack
Ice Mountain Play Test 1
Observations
Lots of boring iterative play. There wasn’t really a whole lot going on, just lots of die rolling with nothing really fun/exciting happening
Perhaps this could be solved by using more then one die. You could start out by being able to roll 3 dice, as soon as you are 1/3 of the mountain up you start rolling two dice. When you hit he top 1/3 of the mountain you roll one die
Once a player got a head start, there was no real chance for the other players to catch up.
The entire game revolves around luck, it all depends on how lucky you roll the die.
No avalanches occurred the whole time we played.
In order to fix this, all players could start with one “avalanche” card. Which allows them to cause an avalanche whenever they desire on either part of the board.
After taking my notes into consideration I decide to make the following two changes.
Changes
While a player is between the starting square and the square marked with a two (see below) the player rolls 3 dice per turn. After the player passes the square marked with a two, the player rolls two dice per turn. Finally, once the player passes the 1 mark (towards the top of the board) the player is allowed to only roll one die per turn.
Each player is given the ability to cause one avalanche on which ever side of the board they choose. This is kept tracked by placing two As at the bottom of the board and crossing them out when a player chooses to cause an avalanche.
Below is a picture of the final result for play test round 2. Again, I was declared the winner as the green tack .
Ice Mountain play test 2
Here are the my notes after testing the game with the new rules.
Final Verdict
The new rules caused confusion with my previous rule of avalanches occurring when a number is rolled 3 times consecutively. What if a player was at the point where he can only roll two dice, and he ends up rolling two dice of the same number. Does that mean that if the next player rolls that same number (whether the player is rolling 3/2/1 dice) an avalanche will occur? It seems like this rule would either have to be changed/refined or completely taken out.
The ability to cause avalanches added a bit of skill to the game. Players needed to be careful when they used it, since they would like to maximize the number of square they knock back their opponent. But, at the same time not knock themselves back.
The rolling of 3/2/1 dice rule helped the game move along far more quickly. There was less of a mindless die rolling time frame at the start of the game.
That’s about it. It was really fun testing out my first paper prototype, even though I only spent 15 minutes on the design:). Looking forward to Level 3!
Yesterday evening I attended Ansca’s first developers kitchen. They invited local developer to come in and check out their office and staff. It was a great networking event and I got to see some some old faces and meet some new ones.
I had a chance to catch up with Tobiah and Angel from Yobonja. I shared a little bit of my up and coming game (which I’m building with my brother) Roly Poly with Angelo, we ended up exchanging some technical advice on how to design a level editor. Tobiah shared some of his experience on supporting multiple image resolutions for the iPhone. I also got a chance to play their game Tap Party, which was quite impressive.
There was another team of developers who are working on a music based game that reminded me of Tetris Attack. We got into discussing the pros and cons of doing an LLC vs a partnership. It’s always nice to talk about business with other small start-ups, gives you a sense that you are going in the right direction. Unfortunately they were without business cards and I forgot the name of the game =/.
All in all it was a great event. My brother and I even got a great picture taken of us supporting “Corona”
My brother and I showing our support for "Corona" (Photo provided by Ansca)
We showed up Friday evening not really knowing what to expect, this was the first time that I or my brother have ever attended a Start Up Camp. All we knew was that we had three days to work on something, and that there would be prizes! We also knew that Ansca would be there, and that we would be able to use the Corona SDK, which we would find out later to be a tremendous help in speeding the development on our game.
The first night consisted of people pitching ideas. We didn’t really come in with an idea, so I just made an announcement that we were looking for an “idea person”, someone to come on to our team and flesh out a really nice game idea. Unfortunately everyone seemed to be more focused on application instead of games. At the end of the first night we came to the conclusion that we were going to have to do this ourselves.
The next morning, Saturday, I find out that my brother stayed up for a large portion of the night (he only got 3 hours of sleep) thinking of game ideas. We went to breakfast and narrowed down the ideas to a couple game mechanics. The main game mechanic would allow the user to draw real-time platforms with physics properties. The second game mechanic would be the ability to flip the phone 180 degrees and change the gravitational pull of the game. Both of these mechanics would be used to help our rolling ball find it’s way home.
Once we got back to San Francisco, later that day, we fleshed three levels on the white board, and I began coding while my brother started on the artwork. I was able to get the walls and physics mechanics by the end of the day thanks to Corona’s built in physics engine based of the popular Box2D Physics Engine (which I’ve used in the past). By the end of the day we had a decent base of code and some nice artwork, we also came up with the code name “Sticky Spider” (which we would later change).
On the final day we decided to come in at 9am, since we needed as much time as possible to finish up the game. I spent the first half of the day implementing our real-time platform creating mechanic. My brother spent time finalizing the background and working on a replacement for the ball in our original idea, a roly poly (which we ended up using as the final name for the game). After finishing off the first game mechanic, I finalized our first level and we were ready to move on to creating level two. Level two consisted of the user flipping the phone around and changing the gravity of the game. This took nothing but a couple lines of code thanks to the physics engine and the easy accelerometer support provided by the Corona SDK. We soon realized that we wouldn’t have enough time to put in all three levels, so we decided to concentrate on putting in two very good levels. After a couple of hours of polishing up the game, we were ready to present!
Level 1 of Roly Poly (Photo provided by Ansca)
While getting ready to present we found out that only 2 out of the 5 teams made it through the Start Up Camp, so at the very lease we would get 2nd place, but we were aiming for first! We presented first and everyone was impress with the artwork and how quickly we were able to put the game together. They were especially impress with how very little lines of code it took to create the game: 340 lines (including blank lines). After our presentation we got a nice round of applause, and watched the second teams presentation.
After the second team’s presentation the judges were ready to cast their votes. We were extremely gratified when we were declared the winners! Winning an iPad, $500, and a years subscription to the Corona SDK. The judges explained that it was the fact that we had a working game with two levels that caught their eyes. In a market where games come and go, you have to be quick on your feat and have to be able to put out a game very fast.
My brother (Cesar Miranda), the Co Founder and Chief Evangelist of Ansca (Carlos Icaza), and me (Photo provided by Ansca)
I had a great weekend with everyone at Start Up Camp, made lots of great connection, and had lots of fun. I can’t wait to finish up Roly Poly with my brother and have it out on the Apple and Android market!
I have been working on a prototype for a new Flash game, codenamed “Word Attack”. The finished game will eventually be submitted to Word Play- A Flash Game Contest, that is being hosted by Dictionary.com and Mochi Media. Check out the prototype below…
Note: There is no gameplay mechanic revolving around the blocks turning red after they stop moving, this is just something that the Box2D API does to let the developer know that objects are “sleeping” (not being simulated anymore).
As you can see, the player’s goal is to clear every level by creating words with the letters provided (for the prototype I created nine levels). One thing that is worth pointing out is that the player has the choice of completing a level in whatever fashion the player chooses, as long as the player clears out all the letters in the level by typing in valid words. For example, in level seven the letters falling down consist of “c”, “o”, “m”, “p”, “u”, “t”, “e”, and “r”. So the player can complete the level by either typing in “computer”, or by typing in “mop” and then typing in “cuter”.
I plan to expand more on the gameplay by working with a game designer, since it feels like it needs a bit more “fun” in order for it to not just be Scrabble with physics. This is also the first time I have used the Box2D API to develop a Flash game, and I must say, it’s turning out quite well so far .
Feel free to comment on the game, I’m also open to suggestions on gameplay or anything in general related to the game.
Ian Schreiber’s (http://gamedesignconcepts.wordpress.com/) summer game design course (*cough* free *cough*) just started this past Monday. For each lesson (which he refers to as a level) he will make a post on his blog and assign homeplay (homework) to be completed before the next lesson. For the first lesson he went over as to what exactly is a game, and what it takes to make a basic game. Though none of the assignments stated to create a game, he did provide a small exercise half way through the lesson entitled “15 Minute Board Game Challenge”.
The basic premise of the exercise was to design a board game in which you are either “running towards something or running away from something” in 15 minutes. I chose to create my game in the “running towards” category, though I’m sure it could be easily changed to be a “running away from” game, and this is what I came up with.
Title: Ice Mountain
Goal: Be the first to climb to the top of the icy mountain.
Player representation: Mountain climbers
Number of players: 2 to 4
Game bits: Board, 6-sided die, mountain climber tokens
Board:
Rules: All players start by being positioned on the starting square (S). All players will roll a 6-sided die once to determine turn order, with the highest roll being first, second highest second, and so on. After order is determine, players take turns rolling a 6-sided die and moving that many squares forward. The game is over when one player lands exactly on the final square (F).
Game mechanics
Get out of my way! (Getting knocked down by other players): If a player’s turn ends by landing on the same square as another opposing player(s) , have the player whose turn just ended roll again and move the opposing player(s) that many squares back.
You went too far! (Falling off the top of the mountain): As stated in the rules, a player must land exactly on the final square (F) in order to win. If a player rolls the die and goes past the final square (F), have the player go back the number of squares he went over, using the final square (F) as the starting position.
Avalanche! (Being in the wrong place at the wrong time): When ever there are three consecutive rolls of the die with the same result (e.g. player one rolls 5, then player two rolls 5, then player three rolls 5) an avalanche occurs. If the number that is rolled consecutively is 1, 2, or 3 the avalanche will happen on the left side of the mountain, if the number is 4,5, or 6 the avalanche will happen on the right side of the mountain. If a player is on the side of the mountain were the avalanche occurred, that player must move SOUTH exactly one square. If there is no square south of the player’s location, the player is moved to the starting square (S).
That’s it! It felt pretty good sitting down and designing a game withouth having to think about how it was going to be programmed . Looking forward to level 2 on Thursday!
