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.

Follow us on Twitter to keep up-to-date with our weekly blog posts.

More articles you might like:

Hello, my name is David Finseth and I am a Technical Artist at Synapse Games. I work across multiple games to create visuals that require some technical and artistic components. A big part of my job is working on particle effects for our mobile games. I am very passionate about this work and wanted to share my process and some tips for creating these effects with you. Particle effects are a unique tool that can add interactivity and responsiveness to your games. They excel at creating a lot of movement and impact. Particle effects can be used to create magical fireballs, swirling dimensional portals, or for directing the player's attention to a glowing treasure chest. First, I am going to break down the process that I go through when I make particle effects in Unity. Later I will go over some technical tips and tricks. Most of these examples are from work that I did on the games Spellstone and Animation Throwdown. The Process Breaking down the requirements: The first thing I do when I start to make a particle

pictured: Thumper Dark Souls is more likely associated with anguish than euphoria as a series, but it -- and other notoriously difficult games -- are where we can find some of gaming’s most pleasurable moments. If you work through your urges to throw your controller at a wall, you might be lucky enough to experience the joy that keeps us all coming back for more “YOU DIED” screens. We’re going to delve into what leads to these experiences, why they feel so good, and how they can be designed. That feeling? It’s called “flow.” Named by Mihály Csíkszentmihályi in the 1970s in response to interviewees describing the feeling as being carried along by water, flow is a deep, pleasurable immersion in the activity you are engaged in. Most commonly used in reference to creative pursuits like painting or performing music, this experience is absolutely found in games as well. To find yourself in a state of flow, first there are some parameters: You know your goal You know how to accomplish your goal You are receiving feedback

KONG: Hyper Hippo is a Canadian-based independent game developer best known for the hit idle game AdVenture Capitalist. How did you all meet and start making games together? CODY: Hyper Hippo sprang out of the imagination of Lance Priebe, the creator of Club Penguin. He assembled what he felt was a "dream team" for game development, then opened the floodgates and said, "GO!" TRISTAN: We all met while working on the virtual world "Disney’s Club Penguin." We wanted to try our hand at some new game experiments, create new IPs (Mech Mice, AdVenture Capitalist, etc.), develop for leading platforms (mobile, PS4, Xbox), and move away from the processes and politics of larger companies. KONG: For those of us not familiar, what type of game dev culture does Canada have? What sets Canada apart from other development hubs? CODY: Canada is similar to a lot of other "game" or tech hubs, but maybe just more apologetic? We’ve got our big guys like EA, BioWare and WB Montreal. But there’s also