#learning new tools

Getting up to speed is a skill like any other. The more practice we get at it, the easier it becomes. A lot of what makes a more senior developer is how good we are at picking up new workflows. Every game project does things a little (or a lot) differently - different tools, different systems, different pipelines, different coding standards, different checkin procedures, and so on - but they still generally function in similar ways. The more projects we work on, the more we have to learn how to learn these things. The more senior we are, the less hand-holding we need in order to get up to speed on a project.

When I'm joining a new project, I turn on "knowledge sponge" mode. I read every new hire document I can find. I read the wiki, looking at the links for different systems - gameplay, workflow, procedure, etc. I note things to look at for later for better retention. I also pay attention and observe as much as I can. What steps are my coworkers taking when doing work? What workflow common steps have been left out? What are they talking about on Slack? What is the current milestone we're working toward? Who's assigned to what part? I write these things down for better retention later. I look at the repository - what kind of work have they been doing? What kind of descriptions are on their past checkins? How are they doing their task tracking? I note these things down for better retention later. I look carefully at my tasks. What parts of the game am I touching? Where are the edges of the game systems that this task involves? Who are the subject experts I can reach out to? How does the system I am touching work? I note these things down for better retention later.

The goal here is to maximize the things I can figure out on my own and minimize the amount of hand-holding I need from my coworkers to get used to things. The more experienced I got, the more familiar project structure became to me - this is how they do this kind of thing, that is how they do that part, and so on. This is how most devs who join an ongoing franchise team get brought onboard and up to speed.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I have an idea for a game, a 2-D rpg I would like to try to solo-dev. I don’t have prior dev experience. What would be a good tool to use for my first foray into amateur game making?

Short answer - since you have no experience at all with anything, use [RPG Maker]. If you can't afford the retail price, wait for a Steam sale - it goes on sale quite often. For a longer answer as to why you should use RPG Maker, read on.

In the words of the inestimable Gin Rummy from the Boondocks, we can divide all knowledge in the world into one of three categories:

Known knowns - things we know

Known unknowns - things we realize that we don't know

Unknown unknowns - things we don't realize that we don't know

The process of learning is the conversion of the known unknowns (e.g. how to code) and unknown unknowns (things you probably didn't realize you'd have to do) into known knowns. The best way to do this is to start small with as limited a scope as you can, and then gradually increase as you level up and learn to do more things.

A toolset like RPG Maker does a lot of the lifting for you by providing a map editor, event editor, and content editor to allow you to work with a bunch of common systems that already exist in 2D RPGs. You'll learn a lot of the things that go into a video game from just having those tools and playing with them. There's also a lot of assets right out of the box, so you don't have to build a bunch of them on your own. If you want to expand past that, there's a lot of documentation and tutorials available online for making all kinds of additional features and content. As you get used to building things and creating content, you can slowly expand your scope to see what else you can do beyond that.

As for the project to do - build something very simple - a single story, with a handful of characters, that has a beginning, middle, and end. I suggest something simple like an episode of your favorite TV show. If you're feeling frisky, make some branching storylines for that episode. Whatever you do, don't try to make your magnum opus epic whatever for your first project. You're learning how to make stuff first. You're going to make mistakes, you're going to learn new things, and you're going to improve your skills. Most of all, you'll start turning those unknown unknowns into known knowns and known unknowns so that you can make a plan to start figuring out what else you need to do in order to make what you want to happen. Level up, improve your skills, and then start tackling bigger challenges. Good luck.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Ramping up quickly onto a project is a skill like any other. Because it is a skill, the more I practice doing it, the easier it becomes over time to do. This is true of jumping into completely new projects as well as jumping back into older projects because projects all have similar core needs. Every project needs a work flow, every project needs a way to process assets into game data, every project needs a way to create and edit game data, every project has technical limitations, and so on and so forth. The more familiar you become with the underlying similarities between projects, the easier picking up a new project and ramping up onto it becomes. This is because you understand how a game works, and all you need to do is figure out how this particular project maps its particular details onto those core game elements.

That said, the ease of picking up an old project I once worked on is also directly proportional to how long it's been since I last used it. I worked with one particular engine something like 15 years ago then had to pick it up again when I got hired recently. The engine had, of course, changed significantly in the interim so it was farmore like learning a new engine than knocking the rust off of my old knowledge.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

It's mentally discouraging if you can't see a path to get to your goal from where you currently are. Much of human growth as we grow and mature is learning how to "operationalize" - how to break down large seemingly-impossible tasks into smaller, doable tasks. For a small child that might be learning that "clean your room" actually means "put your toys in the toy chest, put your shirts in this drawer, put your pants in this drawer, and make your bed". Before understanding that breakdown, "clean your room" might be an impossible task for the child.

Similarly with games, it can be incredibly daunting to see a huge gap in game skill and/or performance because you haven't yet learned how to operationalize the tasks needed to perform at that level yet. Depending on how much grit (the "not giving up" quality) the player has, that can either be the end of it or it can be the point of catharsis for the player to figure out how to get to where she wants to be. As we learn these skills and figure out how they fit and work together, the overall goal should become more and more practically achievable. As designers, we generally try to avoid creating experiences where skill gaps are shown so visibly for just that reason - we don't want players to give up before things get fun - but there's also that tradeoff of players wanting to see just how cool and awesome a thing can be at its highest potential.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Honestly, the answer is "familiarity and practice". When you wrote your question to me, you probably weren't thinking about how to spell each word, or where the key for each letter is on the keyboard, or how to put the sentence together in a coherent fashion. For someone unfamiliar with the language and keyboard layout, it could take hours or even days to compose a paragraph. You've already internalized many of those concepts such that you don't even need to think about it anymore - the rules and the vocabulary for composing and expressing your question just came naturally because of how familiar you are with the means of expression.

Much like learning a new language or how to use a particular tool, writing code and coming up with game logic requires a lot of familiarity and practice. This is because they are all essentially ways to express ideas. In order to convey the idea of how a character can move in a game to another person, you would need to use words, concepts, and maybe illustrations that the person understands to express that idea. Similarly, if you wanted to convey an idea using a computer, you would need to use words, concepts, and data the computer understands to express that idea through the computer. The more familiar you are with how the computer works, the easier this becomes. The way you gain familiarity with something is through practice.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Game design is a skill like any other. People tend to improve at skills through two primary approaches: practice and study. Thus, in my opinion the most useful exercises are the ones that allow you to practice game design, study it, or both.

If you want to practice game design, build game design prototypes and try stuff out. At the basic level, you can try coming up with house rules for a game you already know, like seeing how different chess would play if each team had four knights and no bishops, or removing scissors from Rock-Paper-Scissors. What about these variations works and what doesn’t? If you feel ambitious, step it up by [downloading a game toolset] and making your own mods or game content. Build a quest in Skyrim or a new map in Starcraft 2 or Portal. Come up with a new format for Magic: The Gathering. Then, once you’ve gotten it playable, ask friends/family/acquaintances to try it out for you and gather their feedback. What could you do better? What worked and didn’t work? Why?

If you want to study games, I suggest playing a lot of different games and analyzing them - especially games that aren’t the kind of game you normally like to play. There are a lot of available and fairly niche game experiences out there - games for children, freemium mobile games, MMOGs, sports titles, simulation titles, strategy titles, and so on. At the very least, you can grab every weekly free game on the Epic Game Store and play them. As you play through each game, keep the analytical part of your brain on. What parts of the game work and what don’t? Why do you think they made this particular choice instead of that one? Who do you think this feature or content is this for? 

This isn’t playing the games for fun, or at least not for the usual reason people play games. This is studying and you should treat it as such. Take notes down as you play and review each game later. See if you can find discernible patterns in the various games you’ve studied. Think about those patterns and what purpose they serve. Are the reasons the same? Remember, every feature and piece of content in a game was put there deliberately. There is a reason for it. The better you are at figuring out why they did certain things, the better you will be at figuring out when and where you would want to do something similar.

For best results, I suggest a mixture of both approaches. Let your observations from the games you’ve played direct the kind of prototypes and design experiments you try. If your experiments make you think of gameplay from a different kind of game, track down some good and bad games in that space and try them out. See what makes them good or bad. See if there are any interesting things to learn from them, especially the bad games. It is very rare to find a game with no redeeming qualities whatsoever - I’ve learned as much from playing bad games as I have from good ones. The goal is to increase your overall understanding of what tools might be available, how much it costs (time, effort, learning, etc.) to use those tools, and when those tools might be appropriate. Then, when you want to craft a particular experience within a game, you understand which tools to use.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Honestly? The answer is practice. You transfer your skills via practice. Find an engine or a development kit built with C++ and try to implement or modify some of those high level concepts using C++. Unreal is probably the biggest and most well-known off-the-shelf engine, but the Source engine is also freely available and utilizes C++. Find and try some of the tutorials similar to how you learned  to use Unity. Then practice using C++ to implement some of these high-level concepts that you mentioned. Look things up online if you run into issues, but C++ isn't that far off from C# so you should be able to figure things out. 

Ultimately, learning to use a new programming language is a lot like learning to speak a new spoken language. The purpose of learning a language is so you can express your ideas using that language’s rules and vocabulary to those who understand it. You want to express your ideas to the compiler that speaks the C++ language. You do so by practicing expressing your ideas with the new language’s rules and vocabulary.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr