Kongregate Developers

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.

Author

Sherri Puchalsky

Sherri Cave Puchalsky hasn't made her first game (yet), but she encourages and supports the growth of community and creativity wherever she can. She joined Kongregate in 2008, and was a volunteer moderator for chat and the Arts forum before becoming an Assistant Community Manager in 2013. Before working at Kongregate, she served congregations and communities as a liberal minister, then took time off to be with her children full-time when they were young. She is grateful to the true authors of this article: the people who shared their questions and experience in the forum thread that inspired it.

Engineering Personas

A few weeks ago, Kongregate CRO Josh Larson related the diversity of our company as identified by an activity of having people take a Hogwart’s sorting hat quiz. We found out that, without any conscious effort, we had a relatively evenly distributed team. While this exercise was mostly done for fun, it does highlight a key concept to building a successful team: How do you balance the strengths and weaknesses of individuals to propel the team forward? What are the types of personalities you might encounter? Having spent 10 years both working on and leading engineering teams, I’ve found that most engineers tend to align to one of the following personas.

The Framework Facilitator

The Framework Facilitator is focused on the bleeding edge of changes in frameworks and technology. They have their ear to the ground on what new features are coming to versions of frameworks and are ready to adopt them whenever they are available. Oftentimes, they will also try to push for more ideal solutions than practical with the best of intentions. They thrive on being able to utilize advances in the team’s technology stack.

The Process Perfectionist

Advances in technology and frameworks can make for better products, but this person is concerned with helping to optimize how the team is building things and interacting with other teams, up and downstream from them. They are looking to streamline how stories get defined, implemented, reviewed and deployed. Metrics and charts tend to be their comfort zone. The Process Perfectionist will strive to continually reduce the amount of time spent waiting for something to get done.

The Entrepreneurial Explorer

When others are debating the best way to plan an iteration or which JavaScript framework to implement next, the Entrepreneurial Explorer is trailblazing a path ahead. They are grabbing the bull by the horns while simultaneously kicking it in the ass. Their main focus is to continue progress, on anything and everything. They are not only driving forward on all decisions but want to do so while pushing the pedal all the way down.

The Gratified Generalist

Debating technologies, refining processes, and breaking new ground are important, but someone has to have a broad approach. The Gratified Generalist has their hands in a little of everything and is willing to work on anything. They are often most happy just knowing what the next thing is to work on, regardless of what that thing might be.

Being able to identify these personas among your team is only a part of building an effective team. Any highly functional group is going to learn how and when to utilize these traits. You don't want a group of only magic users in a dungeon and you don't want only one of these personas on a project. It is probably inadvisable to form a team with even 2 or 3 of these personas. If you composed a team of just Framework Facilitators and Gratified Generalists, they may get stuck never making a decision about which technology to implement. Likewise, a team of Process Perfectionists and Entrepreneurial Explorers might end up with strife in how disparate their desired approaches would be. The best teams are going to find a balance of personas and let each one step up into their strengths, but will also be able to find constructive criticisms from those personas that don’t align with them.

As important as assembling a team of diverse personalities might be, being able to identify which one you might be and which ones might exist on your team can be equally beneficial. As a contributor, it can help you determine the best way to present a problem if you know that your audience is composed of personas differing from your own. If you find yourself on a team stacked with similar personalities, perhaps you can attempt to play the advocate for a persona that is missing.

Which persona do you identify as and which do you see on your team? Are there personas that you’ve identified that differ from those I presented above?

Author

Ryan Golec

Ryan is the Director of Engineering for Kongregate and self-identified Process Perfectionist. He works to lead and grow our technical staff and make sure their TPS reports are in on time.

August 18th, 2016 10:42 1 Comments

More Terrible Games, Please

I’m an intern here at Kongregate, which means that my responsibilities are varied and almost completely uninteresting to read about (but I’m not about to let a little thing like that stop me). For the past week or two, I’ve been spending most of my time combing through hundreds of old games, weeding out anything that seems broken or miscategorized. It’s very time-consuming, and although it can be tedious to wade through a tidal wave of unplayable games, it can feel like I’m uncovering bizarre artifacts that no one has touched in a long time. I haven’t played No Man’s Sky yet, but I’m sure the feeling is very similar.

Unlike No Man’s Sky (I hope), the variation starts to run out of steam very quickly. Sure, there are plenty of great, unique games in there, but everyone knows about those already. Those are classics. The untouched artifacts that I’m talking about here are of a much different, much more specific breed:

WebGL Pong clones.

I see dozens and dozens of Pong clones every day. I’m suffocating under them all. We have enough now. Dear God, please, we have more than enough... But it’s crucial that people keep sending them in.

WebGL is very important. This isn’t a post about WebGL specifically -- maybe what I should say is that web games are important. But WebGL is the latest incarnation, now that Flash is comically stumbling backward into its grave and Unity’s Web Player is no longer supported by Chrome. For better or worse, WebGL has to step up and carry the torch. I hope it can survive. It’s important. Really.

Let me clarify: I don’t mean that web games are important to players (though that is certainly often true) -- I mean that they’re important to the ecosystem of games at large, and primarily to young, budding developers who’ve never made a game before. It’s easier than ever to make games, but it can still be tricky to publish them. Steam, GoG, and the App Store all have lengthy and potentially expensive submission processes. Portals like itch.io and GameJolt are starting to bridge the gap, but it’s as true as it was in the mid ‘00s: putting your game on the web is the easiest, quickest way to get it out into the world.

There are some downsides to this fact. It can be more difficult to find the great games on sites like Kong. The same is true of Steam, now that Greenlight has opened the floodgates to games of widely varying quality. I think we have an advantage over Steam in this regard, though -- all of the games on the site are free and generally pretty short, so your opportunity cost for trying something that might be bad is pretty low. Players tend to be pretty open to giving weird little buggy games a shot, mostly because they don’t have to pay for them.

Another downside: it means that a person's first introduction to Kongregate might be through a game that isn’t incredibly polished. One of the benefits of a closed platform is that you can better control the experience of people visiting your platform, and ensure that their first impression is a great one. Though Kongregate does work hard to make sure it's easy for players to find the many highly rated games on our site, we made a conscious choice to be a place where developers are welcome to try whatever they want and we leave it up to the players to tell us if they like it.

Because the upside to letting anyone upload anything is extremely real: publishing a game is a very valuable experience for a first-time developer. I know this because it was a very valuable experience for me. Everyone’s first game is terrible (please don’t make me talk about mine), but the point of distributing your first game isn’t really to show off how great a job you did. The real value comes from the accomplishment of finishing something and setting it free. It’s a huge milestone. For a young developer, it can be massively encouraging to know that someone else has played your game (even if they hated it, which [spoiler alert] they probably will).

Do we need any more rudimentary Pong clones on Kongregate? I can say definitively that the answer is no. But I think we do need to give developers a place to put their awful first games so the world can grimace at them, and we need to encourage those devs to try again, and keep working, and maybe one day make something great. If WebGL can be the jumping-off point for those people (as Flash was the jumping-off point for so many others), I think we should treasure it.

Author

Sam Suite

Sam is the mid-college intern eternally soul-bound to the Kongregate offices. He spends a lot of time puzzling out confusing programming conundrums so developers won't have to. Sometimes he also makes goofy video games, and once in a while he actually goes to class.

August 11th, 2016 10:20 3 Comments

A New Home for Our Documentation

Our documentation now at docs.kongregate.com.

Some of you will notice today that we moved our documentation to a new platform (on readme.io). Besides a cleaner interface, it allows us to provide some pretty useful tools within the docs, such as:

  • An interactive API Explorer where you can make test calls to our APIs
  • A community driven support hub where you can ask questions and request features
  • Suggest edits and changes inline
  • Better API References

We hope to it will provide a better organization of information, and a more communicative forum between us and all the great developers we work with.

5 Tips to Improve Game-as-a-Service Monetization

Written by Moonlit Wang, Partner Development Manager at Google Play Games, & Tammy Levy, Director of Product for Mobile at Kongregate

Free-to-play games are essentially games-as-a-service. The lifetime value of these players is much more complex to calculate than it was when a game’s player LTV was simply the purchase price of a game. We understand that the LTV is directly related to how much time players spend in the game, since long-term players spend more money, but how do we design a game to retain players and monetize effectively?

Google Play and Kongregate teamed up to answer this question with 5 tips to improve monetization in F2P games. To learn more, please visit this post on Google’s Developer Blog.

Author

Tammy Levy

Tammy is the Director of Product for Mobile Games. When she's not at work you'll find her rock climbing, playing board or video games, reading or sitting on the couch consuming TV series on Netflix.

Fun Fact: She used to be a professional fencer -- back home she was part of the national Mexican fencing team.