7 Things I wish I knew when I started developing games

Updated: Jan 11

I've been professionally developing games for the better part of a decade now. When I started I made a lot of mistakes. Recently I've been receiving a lot of questions about how best to get started in the industry so I figured it would be helpful to write this down somewhere.


TLDR: Make smaller games using existing engines, ship them, get people playing them. Repeat on a slightly larger game. Don't chase perfection out of the gate, make something "good enough" and iterate on it until you are happy.

 

1. Use existing tools

If you take one thing from this post, take this: It doesn't matter what you use, just use something that's already out there. Unreal? Unity? Game Maker? It doesn't matter.

What matters is your focus on the craft of making games - not engines.


I can assure you that you will have plenty of chances to learn, tweak and break engines in the future, but when you are starting; Focus on making the game first, tech second.


2. Start small and ship it

We've all been there, we play Red Dead Redemption or see a trailer for some new game drop and think - I want to make something like that.


Before you leap into a huge project, let me just suggest this. Make something small - then ship it. You can end up working in this industry for years and years without ever actually shipping something.


The act of actually shipping a game is difficult, not only do you want to make sure your code is as bug-free as possible, the game should be fun for players. It's a different mindset from the prototyping/pre-production phase.


3. Get comfortable with bad code

Yes, get comfortable with bad code - what do I mean by that? Players don't review your code, they play the game.


If you find yourself looking at some code and think: this is terrible code, I must rewrite this. First, stop and think, what deadlines do I have, is this code good enough? Does it need to be refactored right now, or can it sit on a backburner of tasks to complete when the major features are completed?


As a new developer, you will learn things very quickly, making you think that your old code isn't "good enough" anymore. This may very well be the case, but instead of getting stuck in a loop of "learn something - refactor", finish the major features of your project and then go back and refactor things.


That said, don't purposely write terrible code. Write code that solves the problem you are facing as effectively as you can, but keep an eye on the big picture.


4. Don't get stuck in the rabbit-hole

Always focus on the big picture of a game. If you find yourself running in circles with a feature, take a step back and think - is it really important that you spend another week building this feature or should you focus on something more pressing.


This one can be very hard to spot when you are in it. I once spent a week fully refactoring a procedural world generation system for a game I was prototyping, only to find that actually it wasn't important and just burnt a bunch of time.


That's why the next step is really important.


5. Gather Feedback

The world is more interconnected than ever. My go-to was always throwing images of a project I was working on onto Twitter, then jumping into conversations with people about it. It helps to give you the big picture view I mentioned plus it can help you find what's important to focus on.


Be careful with this though, stick to your vision and don't allow too much control over your idea, you may end up losing an attachment to it.


Get to know people in the industry, share stories, problems and solutions. We're all making games so we already have that in common. Get in touch.


6. Set deadlines, deliver to it

Most studios I've worked at always ask for estimates on a piece of work before you commit to it. This isn't done to punish you for missing a deadline but instead, help with limiting the scope of work and delivering incremental progress towards the project as a whole.


Start to get accustomed to looking at a piece of work and assigning a time limit to it. You will probably misestimate, but that's okay, the important thing is that you strive to deliver against that estimate. If you miss it, that's okay, set another estimate and work towards that.


This will help keep you focused on shipping your game.


7. Don't change fundamentals in your game

This sounds obvious, right? The number of times I've played through one of my games only to look at something and think - it would be so much better if I added X.


Don't. Do. It.


Think of a design/implementation around the problem, at the very least find a compromise, otherwise, you will have to toss out a substantial amount of your game leaving you with less than when you started.


When you have all of your major features completed for your game, play through it. If you still think you need to make the major change, do it!


The important thing is to "finish" what you started, then you should iterate on it.

 

That's it for now! Over the coming weeks, I will no doubt want to write another one of these as I answer more questions. If you are just getting started and have any questions you'd like to ask me, just DM me on Twitter and I'll respond as soon as I can.


Edit 2022-01-11: Clarified the "get comfortable with bad code" and "Don't change fundamentals in your game" points.


8,391 views0 comments

Recent Posts

See All