MiniGames

HTML5 Game Programming with enchant.js
Brandon McInnis and Ryo Shimizu

Chapter 5
Mini games are small, made by 1 – 3 people. They can be made in less than an hour but shouldn’t take any longer that a few days. Reading this, I had originally planned that each mini game would take 2 – 3 weeks to build (code, art, sound). But now I feel that is far too long and if they take any longer than a week, they are going to be too complex.

Start by designing a small simple game around the skills I already have. Don’t be 100% original as you run the risk of no one enjoying the game. ‘Imagine a food that no one has tasted before, cooked by someone that has never cooked before’. Innovation is important, but it’s not worth ends up terrible. Instead start by combining familiar themes and gradually start creating my own unique twist from there.

The book then goes on to talk about how players should grasp the game in ten seconds or less, as people can easily loose interest with a game that has too many rules or seems overly complex. In a perfect game, players get hooked the instant they start playing. When creating the mini games, I will need to think from the average player’s view and whether they will find the game fun within ten seconds of play. Additionally, be careful with tutorials, players do not like to read massive blocks of text explaining how to play. Skip-able tutorials are most preferred, as integrated tutorial levels can become tedious to experienced players.

‘Time Attack’. The book talks about how in most games, you can up the ante and fun by adding a time pressure. It gave an example of playing “High Speed Reversi”, which is at its core Othello with a time limit. I tried to play it, however the site is in Japanese and I have no idea how it works. However the concept of time attack is often used in many games as an additional challenge to players who have already completed the game.

It also talks about how not to be concerned with what is not in the game or not having enough time to complete the game you had envisioned. Instead focus on creating the best game you can in the time you have available to you. I think this is the same concept as over scoping, planning small and building upon it if you finish with time to spare.

The section ends with saying that you should aim to make it fun for others to play. It talks about how you should not try to aim for a game that will get hundreds of hits but instead making a game that is fun for your friends to play.

Most of what this section talks about are things that I have already learned over the last two years. However, I am aware that I do have a habit of making games to my own tastes (2D, complex shooters). I feel this comes from my attitude of ‘why cant the player have an ai buddy’ or ‘why cant the player swing a sword as well’. I would then code this into the game, partly to see if I could and partly because I like games that the player has a wide range of options available to overcome a problem. However, when you add more mechanics into a game, you have more mechanics to balance. Thus often the games I created were amusing but not always fun. 

Additionally, because I am the one who is constantly testing and adjusting the game, I would find that it was too easy, so I would crack up the difficulty a little. However, when someone else tried to play my game, they would find it punishingly hard, as I had made the game for my tastes.