What Some Experienced Developers Learned from Making Their First Game

In a thread in the Game Programming forum on Kongregate, a developer working on his first game asked experienced developers in our community what they learned from making their first game and what they would do differently if they had the opportunity to start over again. The thread can be read here, but we also wanted to highlight some common themes that many new game developers might find helpful.

Choose Your First Project Wisely and Finish It!

People who want to get into game development often have a “dream game” they hope to make. That’s great! But set that aside for now. Your first projects are about learning, and part of what you are learning is how to manage complexity and finish projects. Light_bringer777, creator of the Learn to Fly games, advises, “Your first objective should always be to learn and improve yourself at the beginning. Do projects that teach you something rather than aiming for production value early on.”

Remember that you aren’t only learning how to code and how to design; you are learning how to plan a complex project, outline the steps you need to complete, manage your own energy, and develop habits like completing projects and taking time to learn from what you did. Shay9999 chose an amibitious, unusual project for his first game and recommends choosing projects that slowly build on your existing skills. “I knew a little walking in," he writes, "and I walked out without learning much at all. I was so focused on the game, I forgot to learn. If I had made a simple game with the knowledge I had, I would’ve picked up new tricks to process things and create my game better later on.”

For developers planning to upload their first published game, SoulGame advises, “Whatever game you do, finish the hell out of it. Don’t skip from one unfinished project to another.” This means taking the time to fix bugs, add sounds and music, integrate APIs, and create introduction and menu screens, so that the game is engaging and makes sense to a new user from the start. On your first published game, doing all these things well will probably take a lot more thought and time than you expect, but you will be learning important skills that you will take with you to your next game.

Pay Attention to First Impressions

If you're a new developer, most people who encounter your game are just putting a toe in the water to see if it’s worth playing. Light_bringer777 says, “Most people will only give your game a few minutes to form an opinion of it. If even that. Many people might only read the title and description, or even just look at the thumbnail. If your title is boring, your thumbnail is bland, you have no screenshots and your game gets fun around the 80-minute mark, that’s a very bad start.” Think carefully about all those “first things” that a user may encounter. Then, as a new player goes through the game, design things so the first-time experience is interesting and intuitive for the new player. Light_bringer777 adds, “Learning the game should be done through playing and not by reading 5 pages of text in a dry tutorial.” There are many, many low-rated games on Kongregate that are far better than one might guess by the first few minutes, or that many people can only figure out how to play by reading the comments. This leads us to...

Handling Feedback

Read and learn from the feedback you get, and make sure that your responses will help you in both the long and short run. Solicit early feedback to find out where players are getting confused. If players are getting confused early in the gameplay, a very high percentage of them will just stop playing. But even after the game is established, you can keep learning from feedback. As SoulGame puts it, “So every feedback is a different look at your game, either it is a trash talk or a love letter, they are pictures of what people grasp of your game.” I think that many developers might be helped by seeing user feedback as “pictures from different perspectives.” They all have some useful information to offer you, but you don’t need to urgently act on every suggestion, and some may need to be reinterpreted. Users may express dissatisfaction around certain items or the design of a certain level, but their suggestion on how to “fix” it shouldn’t be simply followed. If the users complain about items in the game and say you need more of them, for example, use that to take a fresh look at how the items function in the game. Instead of just asking “What are people saying I should change?” take it apart a bit more. “Is there a common source of dissatisfaction that people are pointing to?” That’s very useful information to have. Let’s imagine there’s a place that lots of users find “frustratingly hard,” and they tell you how you have to make it easier. At this point, you have a number of ways of addressing the dissatisfaction, especially if you have data that shows you whether users tend to quit the game at this point, or whether they make it through and complain about it. If the latter, you might increase the rewards for that part of the game and add in some encouraging messages that acknowledge that “Yes, this is the hardest enemy you’ve faced so far! But keep trying; you can win!”

If your early games bring lots of harsh feedback your way, try to maintain enough distance to take what you can learn from it without being overly upset by it. As Tulrog puts it, “Imagine you make your very first game and it’s a jump and run. And twenty people complain about how horrible your controls are and that you should go die in a fire...Do those twenty people behave in an unacceptable way? Yes. Absolutely. But that doesn’t mean their point is wrong. They do provide you with a new and important insight.” You can thank the users for their feedback and let them know that you plan to really focus on improving your controls for your second game. They might even check out your second game to see if you got better, decide that they are glad you didn’t go die in a fire, and become fans.

Coding and Other Learnings

As player_03, the creator of games like Run 3, puts it, “After making my first serious game, I looked back and realized that my code was a giant mess. I started fresh for my second. After making my second serious game, I looked back and realized that my code was a big mess. I started fresh for my third. None of my time was wasted.” So go ahead and make mistakes, but keep looking for ways to improve. I think this insight applies to all aspects of game-making.

If you find these tips interesting and want to read more, I highly recommend checking out the entire thread. As always, we are grateful to the members of our community who share their questions and their wisdom with us.