Mentality Shift: Game Developer to Game Producer

I’ve been a game dev for more than 7 years now, and have had interest in coding since a few years before that. So it’s valid to say, my mind works in a way, where I will think like a programmer. While a good thing, it’s not always a good thing, when it comes to selling. Especially games. As I picked up an interest in the business side of the game development cycle, I realized, what I would worry about, is not a problem in the big picture scenario. I had a slight mental shift when it comes to priorities now. Let’s see a few of them:

1. Prototype core gameplay first (and fast)

As a dev, I used to love to keep making up generic modules ready to implement in a plug-n-play style. Some time later, I got into the habit of working on modules like the “settings” module, “scene transition” modules, etc. right at the start of any project. MAKE YOUR CORE GAMEPLAY PROTOTYPE FIRST. Can’t emphasize that enough. If you’re going to waste time on irrelevant modules, you’ll waste your time, and by the time you get to the development of the core mechanics, you’ll start questioning or doubting the merit in the game design, and chuck the idea out. Secondly, if you are working on a prototype for a client/publisher/Kickstarter/etc., nobody is going to care if your settings menu or scene transitions look good. Finish the core mechanics first, polish them up a little bit first, then go for the unimportant things.

2. Forget generics

The “let’s make this code reusable so that we can implement it in another project easily” is a rabbit hole which you don’t want to go down, given the bigger picture. Let me tell you from experience, you will not reuse any modules from one game to another. And if you do want to use something, then make the code generic and modular at that time. Instead of worrying about it beforehand, trying to solve a problem that won’t happen in real scenarios, most of the time.Don’t get me wrong though, this is not an excuse to write non reusable code though. Just find the right priorities, and worry about making modules generic only if needed.

3. Buy plugins

Easy to say let’s make our own system, since none of the solutions available in asset stores (or similar plugins) are providing us a solution like we need. But many of the things you integrate into your game are not the priority. Buy a plugin, and understand and rewrite some/modify your use case scenario if possible/ask the plugin devs to provide updates required on your use case, but don’t waste time writing up modules you can get free/cheap.

4. Agile

I see a lot of memes around the topic of having too many meetings and not actually getting enough time to work on programming. I understand, sometimes it’s a little too much. But mostly, it’s not really important for the devs, but it’s very important for the middle and upper management. Imagine the CEO of a small company trying to get funding for the project by promising a prototype build, and you’re worrying about the settings popup.I heard a pretty interesting thing once, very apt. Maybe once you climb up the hierarchical ladder in your career, you don’t have to get as much hands on work done, and you spend most of your time in meetings (and it might look like they’re not working, to you as a dev), but the decisions taken by the higher ups tend to have far bigger implications than your decisions ever could. So try to never avoid or miss your daily sync up calls, it might seem like a waste to you, it’s not just about you though.“I hate doing JIRA it’s not useful at all,” is what my colleague said to me. Bless his ignorance. Like I said before, maybe not important to you, but definitely important.

5. Cut down tasks

Cut them down. Do not start off coding, take the first 10 minutes of your day to cut down tasks and prioritize accordingly. Honestly a maximum of 1 day tasks, but I’m a dev and I understand that can be difficult sometimes, so I’ll say maximum shortest tasks should be of 2 days.

On a slightly unrelated note, I started doing flow diagrams, usually a UI/UX task, but developers can foresee edge case scenarios. I don’t do class diagrams yet, but I’d say start there, as a dev. This will take a little bit of time (called ‘time waste’ by some), but you’ll end up thanking yourself later.