Hockeynamite was an unusual game for me. It was born out of a technical demo created for a series of tutorials, so it didn't quite follow the usual workflow of evolving an idea into a fully playable game mechanic. In my case, the starting point was an existing technical demo that was not a game whatsoever.
This post-mortem is an overview of the process I had to come up with to insert a "soul" into a technical demo to turn it into a game. I made several mistakes and (I hope!) right moves along the way, so I am really glad to share the lessons I learned.
Play the Finished Game
How It Plays
Hockeynamite is a simplified hockey game featuring a fraction of the sport's original rules. The player controls a single athlete of his team at a time, and the primary objective is to score as many times as possible within the time limit. In order to score, the player must carry the puck and make it touch the opponent's goal. There is a catch, though: if an opponent touches the athlete carrying the puck, he freezes and shatters into a million pieces!
Before coming up with that crazy game mechanic, my starting point was this demo:
The demo had two teams of AI-controlled athletes all trying to carry the puck to their opponents' goal. There was no score, but if the puck eventually touched any goal, both teams would re-organize for a new match.
Since I had to use this demo as a starting point, my first thought was to add some interaction by allowing the player to control any athlete of his team. I also thought that a score count would help with the fun.
To bring a bit more action to that idea, I also added a time countdown, so the team that scored most during a period would win. There was just one problem: it was boring as heck!
For the tech demo, I used a simplified version of hockey's rules because it would be too complicated to implement them all within our development budget. That became an outstanding problem, since the game was too simple without the sport's original rules. Beating the AI-controlled athletes was a challenge, but the fun was over after a few seconds. I needed something to keep the player focused on the opponents and the puck while trying to score (or prevent the opponent from scoring).
I could not change my development budget to accommodate all the official hockey rules, so I decided to add an unusual one: if you are carrying the puck and are touched by the opponent, you explode. As I expected, the result was more engaging and interesting gameplay:
I think that was a good addition. Even though hockey athletes don't usually shatter into thin air, this gameplay twist saved me time and gave the game an objective. It might not be the best idea ever, but at least the game didn't feel boring anymore.
I had postponed my deadlines far too many times by this date. I decided to add a title and an instructions screen (with text only, no images) and ship the first playable version of the game. I knew I was rushing things and that this was a mistake, but I didn't want to miss another deadline. I thought the instructions were clear, but I knew players would not read them. I ignored a very important lesson I've learned from past projects: instructions need less text, and more images:
Validating Everything With First Impressions
To check how the game would be received, I was recommended a service that FGL offers, called First Impressions. The idea of this service is best described by FGL itself:
First Impressions are an innovative way to get feedback about your game's initial play experience. We ask gamers with wildly different backgrounds to play your game for at least five minutes and then give you feedback about their experience.
A gamer (a real one, not an FGL employee), who has never seen your game before, plays it for a while (usually five to 20 minutes) and reports the experience using a questionnaire. The responses are organized in categories such as graphics, gameplay, sounds, and controls, with each one given a score from 0 to 10. You must pay USD $1 for each gamer session (called a "first impression"). I bought 10 first impressions and ran them all at once. The results started to arrive within 24 hours.
I was skeptical of this service at first, but the results were overwhelmingly satisfying. Usually I ask friends and family for feedback, but they are always polite and soft when evaluating the game, even when I ask them to be as honest as possible. FGL's first impressions were straight to the point and without euphemisms: users were testing the game with no fear of hurting my feelings.
Here are a few comments (and the ratings I received) regarding the "Fun" category:
"The game is quite fun to play but the controls sucks." 7/10
"I am not really a hockey fan, but I did enjoy the game. It is easy to control and it is a challenge to beat the opposing team." 8/10
"The game does not have enough elements to it. You need to be able to earn power ups." 6/10
"The game was a bit frustrating at first then I figured out all you had to do was click on the goal right from the start and it will go in 9 times out of ten. Making it a bit more challenging by giving more control of the players would be helpful. Also making it compatible with a touch screen would be cool." 5/10
"Fun but would be more fun if you could better aim shooting and passing the puck." 6/10
"The game can be more fun if you could do special moves or shoots." 8/10
I was expecting far worse comments, but overall I was happy with the feedback. The game was not that fun, but at least I had a start that was rated above zero. The comment that struck me the most was this one, regarding "Polish":
"It would be an instant oxymoron to talk about polish and quality in the context of this current monstrosity. I get the idea that there is fun to be had because the guys explode upon contact and whatnot, but in reality, the main idea, I feel, is simply is too brute to operate on such a small playing field. The game, on the other hand, is not sophisticated enough to legitimally call itself a manic shooter. As said, and, as I'm sure you aware of, this genre has been delivered and designed according to far superior qualifications back in the '90s by the Speedball franchise, and it even had a revamp in the not too distant past. Your product should be able to offer something to rival the conventions that are reflected by similar games, but this product, I feel, needs a lot more effort being put into it before reaching a state that is presentable. It, I feel, is under AND beyond criticism at its current state. You need to give this game a lot of love AND a PACING to call it one. Please do not let yourself be let down by my words. You just need to realize that this simply won't be enough when grannies are running around with handhelds. Peace!" 1/10
After carefully reading all the feedback, several problems in the game became evident. The controls were not okay, the playing field was too small, there were too few elements (like power-ups), and it was hard to identify who had the puck and where it was.
I assumed some players were complaining about the controls because they didn't understand how to move and shoot properly, probably because they never read the instructions or read them too quickly. I could fix that by tweaking the controls and improving the instructions.
Regarding the playing field being too small, I had thought about that early in the development, but had decided to ignore the problem. A serious mistake.
A top view camera covering the whole rink was fine for the tech demo, because it allows the user to see the whole arena and to understand what is going on. As a downside, however, it drastically reduces the player's strategy in a game, since moving from one side of the rink to the other is really quick. As a consequence, the rink also felt crowded. Luckily, I could fix that by making the athletes smaller and changing the camera's field of view.
Finally, there was the complaint about the game having very few elements. I knew the game was too simple and the first impressions just made that more obvious. I had to come up with some more additions to make the game a bit more complex, without blowing the development budget.
Fixing the Wrong Things
Based on the feedback, I discussed a few ideas with my "producer" (the tutorial editor), and we decided to make a few changes.
New Camera
The first change was to improve the camera system to allow players to use more movement strategy. I made the rink 4x bigger and locked the camera on the puck. As a result, the player could see just a fraction of the arena now, instead of the whole place at once:
If I had to create this game again, I would choose this camera system from the very beginning. It reduced the claustrophobic feeling that the tech demo had, and definitely improved the game play.
A Better HUD for Active Elements
Next, I added a few visual marks to the HUD to make it more explicit who is carrying the puck and where it is. The athlete being controlled by the player received a animated green halo. The puck received a permanent animated purple circle, too, to make it easier for the player to spot:
Honestly, I didn't think the puck circle was necessary, but the first impressions clearly stated the opposite. Maybe I was too good at finding the puck because I had spent hours looking at it during development, but if a first-timer player is not able to find it, the results are catastrophic. Without the first impressions, I would never have added that purple circle, which would have been a significant mistake.
Better Instructions
This time I decided to follow my experience (and the feedback from the first impressions) to use more images and animations and less text in the instructions screen. I spent a significant (but necessary) amount of my precious development time re-working this screen:
If the player completely ignored the instructions' text, the images and animations would still make it clear how to play the game. While working on the instructions, I decided to make the player able to speed up the athlete being controlled by holding the Shift key. It was a small addition, but it made the gameplay feel much better.
After I finished the instructions screen, I was satisfied with the results. I should have used those animated instructions from the very beginning. After reading all the instructions, I noticed there was too much information to remember. Players would probably forget about the keys as soon as they leave the instructions screen, so I should have added some sort of in-game reminder about the keys. I didn't do it because of time constraints, but I feel that was another mistake.
Power-Ups
Finally, I implemented some power-ups. They were a decent addition, and shook things up, because they allowed the player to improve his team with "super-powers". Giving power-ups to both teams when anyone scored helped to balance the game and ensure that gameplay remained competitive.
Because of time constraints, again, I only implemented two power-ups, but several others could have been added. I think it was a mistake to add just two of them, because they really made the game better, especially if two human players could eventually play together.
On the other hand, I am glad we just stuck with two power-ups; otherwise, we definitely would have exceeded the deadline by several days, maybe weeks.
A Second Batch of First Impressions
I bought a second batch of 10 first impressions (another USD $10 spent). That was a small investment for receiving fresh feedback within 48 hours. This round of first impressions confirmed a few thoughts I had, and gave a mix of opinions regarding gameplay and fun.
I knew players would at least notice the instructions this time, and the impressions confirmed that. As a side effect, however, players had problems remembering them all (as I predicted—but I decided to ignore the problem):
"It was hard to remember all the instructions for how to use the game. I suggest in-game help or a small list of the instructions to appear on screen. The character was also hard to control as in directing it to go a certain way." Ease of Use: 6/10
"Game would be easier to play if more of the options were on screen instead of having some many buttons its just too many to remember." Ease of Use: 5/10
If I had added that in-game help I'd previously thought about, players would not be complaining about the lack of it now. It is really hard to distinguish the essential features from the cosmetic ones, but that in-game help was an easy one to identify as important. I made a mistake by ignoring my instincts here; those instructions would have been essential for understanding (and enjoying) the game.
"I think it would be more fun just if the game had its movements a little more under control as it it is harder to enjoy when the puck or character seems to drift away from where it is directed." Fun: 8/10
I also received complaints about the athletes' movement. I tried to mimic the movement of something over the ice where things continue to slide in one direction even after they are forced to another. I thought about removing the sliding effect, but sharp and precise movements would completely defeat the idea of moving on the ice. I decided to keep the sliding movement untouched, and I think that was not a mistake.
I received divergent opinions regarding the "Fun" category:
"More realistic. Every time I clicked to hit the puck it was more beneficial to just run with it." Fun: 5/10
"Game was fun eventually got a little boring. Maybe let player versus each other or have little mini challenges." Fun: 7/10
"I am not a sports game fan, but it is pretty fun." Fun: 7/10
"Would be better if graphics were better." Fun: 5/10
"'Retro' feel games like this can be fun, but only if they're modern with a retro look. This game kept starting and stopping, blinking images would interfere with the game, players would vanish into thin air, etc. TOO retro." Fun: 2/10
At this point, I was pretty confused. Some players seemed to enjoy the game, while others were complaining. They were not complaining about shattering athletes, though, so I assumed my game mechanic was working—I just had to improve other aspects of the game (such as the graphics).
The Feature Creep Vortex
After reading the second batch of first impressions over and over again, I had a list of things I could improve. I could have added more power-ups, worked on the movement system a bit more, and so on... but this was turning into a feature creep vortex.
I was about to miss my deadline (again), so we decided to make two last adjustments: describe the power-ups in the instructions screen and improve the HUD to show when a power-up is active.
After completing those, I decided to stop working on the game and ship it. I think this was a wise decision, considering the time constraints I was under. Feature creep is a never-ending cycle and I could find more and more things to work as I progressed. I am glad I just called it a day and stopped.
Conclusion
The development of Hockeynamite took a lot more work than I planned. Finding a simple mechanic to be inserted into an already existing tech demo was a tough task, but polishing and shaping the game built on top of that mechanic was even harder.
FGL's first impressions service was really helpful. I quickly spotted several problems (game play, HUD, and so on) using the service; I would probably have missed or ignored those details if I were evaluating the game by myself. I spent just USD $20 to get almost instant feedback. It was totally worth it.
I think the game could be better enjoyed with gamepads and two human players, but I had no development budget to pursue that. A significant amount of the comments I received support that idea. I would definitely make it a desktop offline game played with gamepads if I were to iterate on it some more.
Takeaways for Other Games
Below is a "TL;DR" list summarizing the things I will do differently when I next make a game, based on my experience developing Hockeynamite:
- In the instructions screen: less text, more images and animations, no matter how close or overdue the deadline is.
- If I have a feeling that something is not correct (like the missing in-game help in Hockeynamite), I will address (not ignore) the problem—especially if it was spotted by a person other than myself.
- I will not treat a tech demo as an "almost finished" game. It was really hard and painful to come up with an acceptable game using that demo as a starting point.
- I will not assume players see the game the same way I do. The green and purple halos I added to the game HUD made a huge difference in helping the player quickly identify important things on the screen. I can't image the game without them now.
- If I don't have platform constraints (like "web-only"), I will definitely explore different input methods (such as gamepads) when an idea or opportunity arises.
- I will polish the game as much as I can after the main mechanic is solid.
