Game Over!

Another semester has now come and gone, and, with that being said, our game is now finished! Okay, so I sort of lied there :P The game is finished in the sense that we have submitted the game already so no matter what changes we make to it will not be graded now; with that in mind, that doesn't mean that we aren't free to go and keep working on it over the summer. Here is a trailer for our game:

Most of us probably aren't going to continue working on the game though (wildmagic is a terrible terrible terrible engine to work with in my opinion), and I think most of us are now stressing over final exams, and once that is done, most of us will probably enjoy the summer and take some time off to do something relaxing.

As for me, I will not be working on this game anymore. Instead, I will most likely be working on a new game over the summer/next year so that we can participate in the game con next year. And of course, now that blog posts are no longer mandatory this blog will probably be less updated until the next school year starts again.

Last Week!

With the GameCon coming up this week (Thursday), everybody is working hard to finish their parts so that they can be put into the game. For the most part everything is good and it is all coming together now. There are still bits and pieces missing and my biggest concern is still the networking portion of the game.

A lot of the networking stuff is there and works for the most part, but it seems everything is coming together so slowly that I can't predict whether or not we will be able to actually finish it on time. Of course since this is for marks not finishing this is not an option so I will be working really hard these next few days trying to finish the networking portion and make sure it integrates smoothly into the final game. It is rather unfortunate that I ended up being the only one to work on this for the most part so the end result will be rather far from what I originally had in mind when we planned the game earlier in January.

Other than that I will spend my time working on the postmortem for the group. This way, we can avoid writing this last minute where everybody is confused and scrambling to put the game together before the presentations. Doing the postmortem as well as planning for the presentation ahead of time is always a good idea.

Later this week (or early next week) I will post the end result of the game as well as some links to trailers and/or pictures and also possibly a release version of the game. Hopefully everyone will enjoy the game!

Balancing The Endless Game Economy

In this blog post I will talk about the game economy in Endless (which was the topic of the last game design lecture).

The currency in 'Endless' is gold and player's earn these through killing enemies. The only purpose of gold in the game will be to upgrade the weapons that the players have. Normally, when you think of any game out there what usually happens is a player earns money from killing monsters, and whoever kills the monster can pick up the gold (unless they decide to pass on that and let someone else pick it up). In our game, however, things are going to work a bit differently. To keep in the spirit of teamwork, we are going to try a system where the money is shared between the team. Instead of having gold individually for each player, the money will be the team's money. We are working on getting a few things sorted out first before we will go with this idea. Basically, in a multiplayer game, the person who started the game (aka team leader) will get control of the money, and will have to spend them on appropriate upgrades for each member. Again this may or may not work out, but I am curious to see how this will turn out in the end if we go through with it.

Here I discuss some of the points relating to a balanced game economy:

Fairness: With this system it may be possible for a player to get an unfair advantage. One scenario would be the team leader decides to keep all the gold and only spend it on himself, therefore giving him the best weapons against the enemies while leaving his teammates with only the default weapon and no upgrades. In this case the player may get a bit of an advantage in the early to mid game but I believe this will eventually fail as enemies will not drop enough gold for the player to keep upgrading his own weapon leaving him with no choice but to upgrade his teammates weapon in order to stand a better chance. Teamwork is key here in this game.

Challenge: Since the game will have the player losing eventually, that means that as the game progresses, getting the money needed for upgrades will be come harder and harder. There won't be a weapon upgrade that will be overpowered and provide for a clear advantage over everything else.

Choices: I believe the game is a bit limited here for choices since the only way to earn money is to kill enemies and the only place where they can spend the money is on weapon upgrades. Maybe if we have time we will throw in more choices and make the game more fun.

Chance: Earning money in this game will be more chance based. Killing an enemy (especially in the early game) won't be too hard provided that everyone in the team is focusing on that enemy. The money however, will most likely be randomized. Each time the difficulty or "level" of the enemy goes up, the gold drop cap will increase so that they can earn more money later on and it will also limit the amount of gold the team may receive from killing a weak enemy.

Cooperation: I think how the game works speaks for itself here. Only one person controls the money so it will be important for cooperation and the team leader needs to ensure that everyone has the appropriate upgrades so that they are able to support their teammates.

Time: I would say the way it is right now it sits between earning money too fast and being just right. Again players earn money through killing so earning money will not be a difficult task in this game where there are hoards of enemies. However, I believe that the game compensates for this by only allowing players to upgrade in between levels. This will prevent the team from earning money in between levels and makes the upgrade opportunities more valuable.

Rewards: It can be rewarding earning/spending money, as this would essentially lead to rewards in the game in general. The more powerful the characters are, the longer play time they get.

Punishments: If the team does not cooperate and one player ends up losing early on, then the team has essentially lost one person to help them gain income, and the team also has less choices now as they will not be able to spend money on upgrades for the dead person.

Freedom: There isn't really much freedom in the economy in terms of choices as players are limited to spending the money on only the 4 characters and they are only upgrades. However, if we look at freedom as 'being able to buy the upgrade that you want', then the team leader has a lot of freedom as he can choose to upgrade anyone's weapons as he see's appropriate.

Weekly Update

To start off this blog post, I will talk about the prototype we are doing in unity.

The idea that we decided to go with was zombie / survival horror combined with bowling. This is an odd mix but I've had a few ides about a similar game in the past. Maybe either zombies replacing pins and they're running around while you try to knock them down or maybe they are coming to eat your brains and you are struggling to bowl as fast as you can to keep them away.

For the assignment we decided to go with something simple. Basically, the player is at one end of the lane and zombies are slowing approaching them from the other end. The player will try to "bowl" and knock out the zombies. At this point you may be wondering, why is "bowl" written with quotes around it? That's because we decided to change it up a bit and make it more luck rather than skill based. I've seen examples of how it would work with actual "bowling" but wanted to try my hand at throwing in luck to see how it will turn out. So instead of "bowling", the player rolls a dice, which determines where the ball gets thrown down the lane. With every throw, if the ball hits a zombie, the first one (aka one closest to player) is knocked down otherwise all zombies will move forward and a new one spawns in a random point at the end of the lane.

For GDW, everybody is working hard and making that big final push to get the game finished (and yes we did slack off a bit knowing that the due date was pushed back by a few weeks). A lot of the work is starting to come together now (the assets are about 90 - 95% finished) and whats left is putting all the pieces together and turning it into a great game.

For the modeling and rigging the medic character's rig is now completely finished and ready to go. I did run into a few problems but those have all been resolved now.

For the sounds we haven't gotten around to finishing recording the rest of the sounds but whats for sure is that we have edited the sounds we recorded previously and a lot of the sound effects are ready to go.

As for the networking, the path convergence code has been added and all that is really left is telling the clients to use that information to render. RakNet has been surprisingly easy to work with. For the remaining portions of the networking I have decided to pass it on to other group members. The networking professor has mentioned he is expecting everybody work with it and it would be wrong of me to "take away" another member's opportunity at learning. I will still help with the networking when and if they run into troubles but just thought it'd be more fair to have other people do networking rather than me finishing all of it by myself.

Hopefully we will have a game that is more playable in the upcoming week.

Progress Update

To start off I will talk about the design of enemy difficulties in our game. In our game, the waves of enemies will "level up" and get increasingly harder, eventually being too overpowered for the players to handle and cause the game to end. I have started spending more time looking into the numbers to determine if they are more balanced, as this will be important to the flow state of mind.

We want to make sure that our game is intrinsically motivating. We hope that the importance of working in a team is enough to motivate the player to try as hard as they can so that they won't let their teammates down. To create the feedback loop and give the player positive feedback, our game will have rewards (as covered in a previous lecture) such as giving them special abilities, or additional resources, more playing time, sparkle, etc. Again, hopefully the positive experiences they get from working together as a team will be enough to keep them trying their best. These are all related to the flow state of mind and covers some of the principles of learning.

In other updates, most of the sounds have been recorded already (~80% done). The remaining ones are the ones that we can't seem to nail yet as they don't have the desired effect when played back. We are looking on how to fix these problems and then re-record them.

For networking, the base has now been fully set up. The clients will connect to servers and send update packets whenever keys are pressed. I have tested this and have successfully received the position/movement update packets. All that is left now is making sure that our dead reckoning works properly.

For entrepreneurial finance, since the requirement was only a partial business plan, it has now been officially completed. All that is left is just editing or changes that anyone in the group may want to make between now and the due date.

Last, the model I was supposed to rig is nearly complete. I have ran into a few problems but they should be easy fixes and the entire thing should be fully done by the end of next week.

Implementing RakNet and other updates

With the GDW code freeze date slowing creeping closer and closer, everybody is working hard and giving it the final push so we can have it finished and ready.

Since the group hasn't gotten anywhere yet with RakNet and implementing it into the game, I have started working on it so that this isn't left until the last minute. At first I ran into 100+ errors, my worst nightmare has come true! Solving them wasn't easy, but I started looking up other similar problems people had, and started putting the pieces together. What I thought would take me a week to figure out ended up taking only a day! Here's a picture to show that the networking portion is working:

I have 2 instances of the game and the client is able to connect to the server.

Right now I am working on dead reckoning. I have the basics of it going but I still need to test it and do some tweaking if necessary. It is important that we get the position and movement updates using the first order model since this will be worth 25% of our marks. Once this is up and running I will continue to work on implementing path planning and path interpolation.

In the sound area, we haven't started yet, which is another bad thing. However, I am working with some other team members to come up with a list of sounds we will need, and we are going to record all of the sounds and it should take only 1 or 2 days at most. Unfortunately we left sound to last minute last semester and didn't get a chance to incorporate it into the game, so we are going to get it done this week so that the programmers can put it into the game early on.

For modeling, I still need to fix up the gun models from, UV and possibly texture map them. On top of that, I will also be rigging 1 or 2 of the player models. Depending on how well I manage my time this upcoming week, I may be able to get all of this done by the end of the week. Hopefully this will be everything we need to finish the game so that after the code freeze milestone all we have left to do is polishing to make the game look better for the GameCon.

Modeling with a broken laptop?

So after getting a pile of homework and midterms out of the way I have finally made time to do more modeling for our GDW game. Since other members are focusing on the characters right now I figured I would start working on the weapons models.....when suddenly...........BAM! I was hit with a hard drive failure! There goes months worth of hard work!

After getting a replacement laptop for the time being, I have started doing some modeling and here is a picture of my current work in progress:

The reference image along with the outline of the gun model

Here is the model by itself

Since the game is mainly about surviving hoards of robots one goal for all of the modelers is to keep them as low polys as possible. This gun is only at 26 polys right now so I am on the right track. Here are the other guns that will be modeled:

The assault rifle is for the assault character, and the sniper rifle will be for the sniper character (assuming we have the time to model and rig the character). The above pistol was for the medic.

An Overdue Update?!?

It's been a week or 2 now since I've last updated this blog. I will start off the updates with where I last left off: the space invaders remake homework assignment. Below is a picture of the final game:

The original mechanics are all in the game, and all it is really missing are more polished assets/interfaces; but given the 1 week time frame I had to work on it, I figured it's more important to have all the original mechanics so that it can be played properly.

For the GDW game, I will talk about some of the game balancing:

Fairness: 'Endless' is asymmetrical since players control a different character. Although they have different abilities, we are working to balance out the numbers so that everybody has a fair shot at staying alive for a decent amount of time. For example, the medic may have higher health since it has a very weak attack, while an engineer may have lower health since he is able to produce turrets that can be used to attack and distract enemies in game.

Challenge: I think our game has some good challenges for players of all experience levels. Since the gameplay generally remains the same throughout, challenge is incorporated through faster spawning of enemies as well as stronger enemies.

Meaningful Choices: 'Endless' is a good game for implementing some good meaningful choices. In the game, the gold or money is shared between ALL team members. This means that the team has to effectively figure out who's weapons to upgrade and when to upgrade them. The team could try to max out attack upgrades for the sniper, but the other members would suffer as enemies get stronger and they are unable to hold out for themselves.

Skill vs. Chance: When enemies die in the game, they will drop a certain amount of gold (determined at random). To balance out the issue where the team kills a boss and gets 0 gold, each set of enemies will have a pre-defined max drop and min drop so that the team will still be able to get upgrades even if they are unlucky and get the minimum drop every time.

Heads vs. Hands: The game will require both, and the players must be quick in order to win. Initially, the players will have more time to figure out a strategy, but as the game progresses, they will have to think and act fast. For example, if a group member were to die in the middle of a wave what should the team do? Their chances of survival have just gone down so they need to think of a way to continue surviving.

Competition vs. Co-operation: There is a fair mix of both in the game. Since the gold is shared, the team must co-operate and decide who's weapons are important upgrades. Also, the game is designed so that as a single player you are almost destined to lose very quickly, and in order to get a higher score everybody must work together. There is also some competition amongst the team as they will want to be the last man standing.

Short vs. Long: We are currently working on balancing this out, as we feel that it is possible the game may be too long. If the players get too much time they will be able to formulate many meaningful strategies and keep the game going forever. We are trying to come up with different ways for the AI to behave so that once the team formulates a strategy, it will change to a new strategy and keep players thinking.

Rewards: Of course our game has rewards! Monsters will drop gold that is important for upgrading weapons. Points are also given so that they can be posted on a high score board. And of course there are rewards for working as a team (the medic will be able to heal injured players so that everybody can play longer)

Punishment: The game will punish players through the use of shorter playtime and terminated play. Basically if the player makes stupid choices they will die faster, and that results in the team being unable to play for a long period of time, thus ending the game early.

Freedom vs. Controlled Experience: The game is mostly a controlled experience. The only freedom the players have is to run around wherever they please (on the map). Other than that players are only trying to survive for as long as possible and there aren't any side distractions to keep them away from their main goal.

Simple vs. Complex: We are aiming to avoid innate complexity. We want the game to be elegant in that it is easy to pick up the controls and it is fun to play.

Detail vs. Imagination: The game takes place on top of a skyscraper on planet Earth. We aren't trying to create a brand new world. Besides that there aren't that many details and we leave the imagination of the player to do all the heavy lifting.

Magic: The Gathering Cards and Unity Assignment

For the past week I've been working on the two game design assignments, one of which is the make 3 'Magic: The Gathering' cards and make sure they are balanced. Here are the cards I did for that assignment:

The balancing for 'Radiated Slime':
Benefit: 3 attack + 1 defense + 1 color bonus = 5 points
Cost: 1 baseline + 2 colored mana + 2 non-colored mana = 5 points

Here are the numbers for 'The Hooded Figure' card:
Benefit: 6 attack + 5 defense = 11 points
Cost: 1 baseline + 2 colored mana + 7 non-colored mana + 1 5+ mana cost = 11 points

And here are the numbers for 'The Lone Wolf':
Benefit: 2 attack + 4 defense = 6 points
Cost: 1 baseline + 2 colored mana + 3 non-colored mana = 6 points

The cards are above; as you can see, there is nothing special. There aren't any special effects and it is just a simple description of the creature in the cards. Balancing them was fairly easy and I just followed the instructions from the lectures. Benefit points are power + toughness + any color bonuses. Cost points are basically baseline + colored mana + non colored mana + any bonuses.

The second assignment was to remake a game in Unity. I chose to do 'Space Invaders' for this one. Below is a picture of what I have now:

It's a bit different from the original Space Invaders where the enemies are lined up and slowly moving down on you, but this remake works in a similar way. There is only one enemy coming at you at a time (the red sphere) and as the player (purple square), you have to shoot bullets and try to destroy the enemies. The blue shields are there to protect you and occasionally a ufo like object will fly across the screen and if the player can shoot it down it will provide extra points.

GDW Update

Over the past two weeks, I continued to work on the level for the game, a prototype in Unity, as well as some balancing (done as part of homework in Unity). The map is now complete, and below are some images of the level:

This is the level (Version 3)

Top view of the version 3 level

This is version 2 of the level

I posted pictures previously of what the level looked like but the story was changed and the map had to be completely re-done. The story now takes place on top of a building. Version 2 of the map was my favourite as it seemed more appropriate for a roof top. Unfortunately, most of the team didn't like it too much so I had to add more clutter to the rooftop and remove the billboard.

Since I was the one that designed the map, I was also the one tasked with the task of turning this map into 0's and 1's and throwing them into a text file for the programmer. It was an extremely repetitive task and I messed up a few times at one point, but the text file map is now done and out of the way.

Some of the balancing I did was for the attack damage. I basically threw in a static enemy and played around with the values in the javascript file, tweaking variables such as enemy health, player attack strength, and player attack speed. After tweaking them for a few hours I believe I've found something reasonable, and it allows players to kill enemies easily early one (1 or 2 hits to kill) and the number of hits gradually increases as the level gets higher and higher. Hopefully this will save us some time later on when it is time to balance the game.

For this next week I am hoping to work on either modeling, creating the sound effects, or programming. There is still a lot of work to do, however, with piles of assignments and midterms slowly creeping up hopefully we can have something playable by mid February.

Numeric Relations in Games

In this blog post I will be discussing the game ‘Final Fantasy 13’, and discuss the relationships between the numbers in that game.

Let’s start the discussion by looking at the big picture. Final Fantasy 13 is a game with progression mechanics. Players kill monsters in the game world. These monsters drop items that can be sold for gold (or they can try to find gold in treasure chests). Players also gain ‘crystogen points (CP)’, which are similar to experience points in other games. These CP’s allow the player to upgrade their character by spending points to gain benefits such as stronger attacks, more health, new abilities, etc. On top of these resources, the player also gains technical points (TP), which are spent in battles and allows the player to use special spells. The simplest explanation for using TP points is as follows: the more TP points a player has accumulated before going into battle, the more choices they have when it comes to using spells. For example, with a full TP gauge, the player could choose to use 1 very powerful spell that depletes all or nearly all of the points, or they may choose to multiple weaker spells, which deplete less TP.

Final Fantasy 13 was a fun game overall; however, there are parts of the game that I did find frustrating. I’ve only played through the entire game once, which was a few years ago, but there was one main point about the game that had me frustrated that I still remember, which was the grinding that was required. Although the game did not specifically tell you to “go grinding”, you, the player would know you had to grind in order to progress. If you were unfortunate like me, you didn’t make all the best choices when it came to upgrading and suffered the consequences. This happens around 75% - 80% into the game’s storyline, and trying to progress is fairly difficult due to the sudden spike in enemy difficulty. With no other choice, players will be forced to grind in order to get enough CP to level up their characters to a reasonable level so that they stand a chance against the enemies in the next section. Although the area seems “huge”, if you were like me and spent several DAYS grinding enemies, that map eventually becomes small and boring. It is at this point that putting the game down is something that is not hard to do.

Let’s talk about the resources and their numerical relationships. Below, I have drawn a picture of the resources in the game and how they relate to each other.

My definition for resource comes from the book ‘Fundamentals of Game Design’, written by Ernest Adams, founder of the IGDA. This is the definition in the book:

Resources: Entities in the game world that may be created, destroyed, gained, lost, transferred from place to place or from player to player, or converted into other entities. Resources must be measured in numeric quantities. If an entity in a game never changes and cannot be traded, such as a hill in a war game, then the entity is not a resource.

Now that we’ve seen how the resources are related to each other, here are some of their relationships:

Gil and Potion: 50 Gil will buy you 1 potion, which gives 150 HP, a general case of the identity relationship and is linear. (50 to 150 linear relationship)

CP and ‘Level’: The more CP a player has, the more they can level up. Increasing CP-to-level relationship used so that more and more CP is required to gain a level, and also the game is too slow in the beginning for the player to try to camp and only kill weaker enemies.

Cie’th Stone Missions and Rewards: The player only gets the set reward for the first time they complete the mission. Afterwards the rewards continue to go down in value. There is a decreasing value relationship between the two.

Time and HP: These two resources also have a decreasing relationship. The longer a player stands around thinking or doing nothing in a battle, the more opportunities an enemy has to attack the player and decrease their HP. 

Enemies and Drops: The relationship between the two could be described as linear. Rare drops, or items that are worth a lot of Gil if sold, are only dropped by bosses or enemies with huge amounts of HP and take a while to defeat (even then there is only a random chance the player may get a rare item). Lower level or common enemies only drop items that are worth little Gil.

There are definitely more relationships between resources in the game, however, to keep this post from getting too long I think the ones above demonstrate some of the key relationships in this game.

To conclude, my suggestions for improving this game would be to increase the amount of CP received in the mid game. This will allow players to level up a bit more and hopefully they won’t run into the same problem I did: under leveled characters vs. over powered enemies. Another suggestion would be to decrease the health on some of the bosses. The bosses are usually over powered and while I agree that it is important to have some challenges in the game to keep the game fun, I think the designers went a bit far with the numbers for the bosses and should tweak them a bit to improve it. My final suggestion is to change the relationship between the Cie’th Stone missions and rewards. Although the value of the rewards decreases, there is still a level of randomness to the rewards and therefore sometimes the value of a reward may be higher than that of the previous (although it generally goes down). I think it should be a strictly decreasing relationship so that players cannot spam the missions to get more and more Gil or items for easy work.

Rules vs Mechanics

In Raph's blog, he mentions that games have 3 types of games, constituative, operational, and implicit. 

Some of the arguments he makes in his blog post are:
- core precept are made out of games
- game grammer focuses on constituative rules
-"falling and dying" are seen as feedback from the game


Ralph discusses the differences between rules and mechanics and how they fit into the MDA model. I agree with his points about how rules and mechanics are not the same. Mechanics are built in functions that make up the game, while rules are there for restraining the player on what he can or can do.

GDW Update - 1

Time for a long overdue update on how I'm doing this semester for the game. I've switched from programming to working on art, modeling, design, and business stuff for the game this semester. I will also most likely be programming some of the raknet stuff for the game later on in the semester.

To try to help the group get off to a better start this year/semester, what I am doing now is doing a placeholder level. The other artist and I have been working hard to get some placeholder objects/levels in place so that the programmers will have something to work with while we model the actual stuff during the semester. This way, hopefully there will be no complaints and when the models are completed they can be smoothly and easily incorporated into the game with no trouble. Below are some pictures of what the placeholder level looks like right now:

Here is a screenshot of the level from perspective view

The same level from top view

A lot of the stuff isn't 100% finalized yet so they can still change. This should, however, be enough for the programmers to work with for now until the game is more planned out during this next week.

Some of the stuff that have been planned out:
Characters: We have planned 4 characters/classes: Assault, Sniper, Medic, and Engineer. To provide a rough idea, the assault character will be the most well balanced of the 4, the sniper will have high damage and accuracy but is slow, the medic is able to heal allies, and the engineer is able to place turrets that will fire at the enemy automatically.

Gameplay: The game will basically be similar to a 'horde mode' game, where hordes of enemies will come at the players until they die. There will endless waves of enemies, hence the game name 'Endless'.

Multiplayer: As part of the assignment, the game will allow for multiple players to play over a network. A maximum of 4 players is allowed with AI controlling the other un-chosen characters. There will also be a public and private chat option.

Obstacles: The obstacles will be destroyable. Depending on what the object is, it will have a set amount of HP and once there has been enough damage (whether from player or enemy), it will be destroyed and nobody will be able to hide in that area without being shot at.

Story: Basically, the year is 2050 and the game takes place on planet Earth. An evil corporation sees the human race as nothing more than a "disease" that will continue to pollute the world and bring it to its doom. In an effort to prevent this, the evil corporation is trying to take over the world and replace humans with robots. The player will play as part of a special task force the government has assembled in an attempt to infiltrate headquarters and steal highly sensitive information / bring down the corporation.

I will stop here for now for this post. For those interested, you can read more about the development of our game on this blog: http://www.slightlytoastedgames.blogspot.com This is our new team blog and will have posts from everybody in the group.

This Game is......Ingenious!

I've recently had the chance to play the board game 'Ingenious' in my game design class. 'Ingenious' is the English name for the game, however, we played the German version, which was called 'Einfach Genial'. (Everything is the same, just that the original instructions were most likely in German) Let me start by saying that although we had some trouble getting the scoring correct, the game was still very fun to play.

There were 4 of us playing and the game took about 45 minutes, which is not bad and fits perfectly with the time we were given in class to play the game. Personally, I think that if a game takes too long (example: Monopoly), everyone will eventually get bored and pissed off at each other for whatever reason.

The first thing that stands out about this game is the use of little colored cubes to keep track of score. That was quite unique and allowed everybody to see what everybody else's score was at any given time. Also, I liked the similarities it shared with the PC game 'Civilization', where everybody starts off with their own little 'island' and working on their own thing until they hit the turning point later in the game and start planning their strategy. Lastly, I liked the idea of being able to co-operate with each other. I'm not sure that was "allowed" in the instructions, but it was fun co-operating with another player and trying to stop the other 2 players from winning.

Of course, the downside to this co-operating allows for the possibility of a 3 vs. 1 situation if 3 players decide to gang up against one player, thus giving that player no hope of winning. Also, I disliked the idea that it is hard to redeem yourself in the late game, as the stronger player will be able to keep scoring the bonus moves and eventually get all their scores to 18 and automatically win. This leads to my last dislike about this game, the limited randomness. Besides drawing tiles, there really isn't anymore randomness in this game, meaning that more experienced players will almost always have the upper hand against less experienced players.

If I were to change the design of the game, one thing I would definitely do is add a timer rule. Although nobody in our group tried this, adding a timer would force everyone to make a move, and eliminates the possibility of purposely taking forever to make a move in the hopes of frustrating other players. Also, I would make the game a bit more random, most likely through drawing tiles. As an example, each player must empty their entire hand after each turn. I think this would make the game a bit more random and limits the advance planning a player can do. Finally, I think I would limit the amount of bonus moves allowed. It just doesn't feel right if a strong player has all their scores really high, and then they make 1 "super move" in which they place a tile, get the score to 18, get a bonus move, place next tile to get next score to 18, and repeat the process for all or a majority of their scores and allowing them an easy victory. To allow for more strategy, I think I would throw in a few 'single' tiles, allowing players to fill in the odd gaps and can potentially help in some situations.

Here is a picture of the game: