Game Tool Selection on a Time Budget

TIME MANAGEMENTGAME DEVELOPMENTEFFICIENCY

Michael Vasquez - Developer/Designer

3/24/20245 min read

Developing a game requires knowledge and proficiency in many different skills and tools. Trying to list everything needed is nearly impossible, but I did try and come up with a decent list. When reading through the list, I realized the things I didn't know how to do made up the majority. There are a few routes that I could have taken after that (excluding just quitting of course).

I could have started learning each the the skills and only started development when I felt proficient in each. I can almost guarantee that this is how developers end up in the notorious "tutorial hell". This route also feels like banishing the game development piece to the distant future which also did not work for my goals.

I could have also decided not to learn any of the skills upfront and just learned them as I needed them. Though this route was more appealing, I was worried that the long breaks between development would lead to a break in a schedule and habit that I had established.

Instead, I focused on whether the tool was needed at all and if it could be done with something I already knew how to use. This led me to my current process of selecting tools.

I select tools that I can learn while using them and have a familiar user experience with a tool I already know. I avoid tools that require a lot of upfront proprietary knowledge.

The Difference Between Tools

Some of the most powerful tools out their that come with a hidden cost which is the time spent learning how to use them. When you are on a time budget, a tool or piece of software should be as easy to use as the simplest tool in its category. Anyone should be able to open the application and start making progress on their true goal. Having to pay a large upfront cost of unnecessary learning, may cause delays without any true benefit. It's impossible to know every piece of the puzzle upfront, so needing to do a quick lookup every so often is alright, but if you are spending more time researching than producing, I would reevaluate.

All the applications that are commonly used daily, look very similar for a reason. This allows users to quickly get started and learn the distinct features only when necessary. Though applications used for game development are more complex and specialized, this doesn't mean it should be a requirement to spend tons of time learning beforehand.

The Reason I Select tools this way

My goal is not to be a professional in a specific tool I use. I also do not plan to get a degree or use those applications in my career. Therefore, I do not need to know every option or setting that is available. My goal is to create a professional game to the best of my ability. This requires the use of a tool but for a specific reason and I need it to just get the job done. My time is limited and I don't want to spend it needlessly following along with tutorials that are meant for individuals planning on using the tool professionally.

Time Efficiency Example

If my art style was pixel art, and my drawing skills only allowed me to draw a stick figure, then why sign up for a subscription-based (though powerful) suite of tools to get to use Photoshop? I would be able to draw what I needed in a few minutes using paint.net. Though this is not what I use (See My Favorite Tool), this example should prove the point that signing up, downloading, learning, and troubleshooting a big tool is a waste of time when the skill level does not match.

I want to emphasize that, there is nothing wrong with wanting to spend the time to learn a tool, especially if the goal is use become a professional with the tool, but if you know a tool that will get the job done, then use what you know.

What About Creating a Tool?

Creating a tool can sometimes be faster than learning one, but it may also lead down the dark path of wasting time. Before deciding to create a tool, you must understand your capabilities. If you know how much time creating a tool would take, then it may be worth it, but you will also have to weigh it against how much time it may take to just learn an existing tool. You should also consider troubleshooting. Getting help online from an existing tool is much quicker than troubleshooting a custom tool and may save you time in the long run.

I would only create a tool if I knew I could script it in a few minutes. For instance, there are many build tools out there. Most of the time, building is as simple as copying the dependencies to the output directory and then running the build command so I just create a Bash or Powershell script to do it for me.

How Do You Want to Spend Your Time

Tool selection and learning new applications do not have to derail your goals. A small amount of time can be spent getting exactly what you need from a familiar tool, and then only changing when it is necessary. Choosing a tool that makes you productive out of the box, can keep you on track to accomplishing your real goals.

Bonus: Krita - My Favorite Tool (Currently) and How I Got It

I know it may sound hypocritical to say earlier that paint.net would get the job done, and then reveal I use Krita, but I didn't start with Krita. I had been using Gimp for over 15 years for all my Photoshop-like needs. Gimp is an amazing product, but starting it up was slow and sometimes my settings wouldn't save correctly. I knew I wanted to change to something quicker to get open and get started. I also knew I would be using pixel art so Aseprite was the obvious next choice for me. It had a layout similar to Gimp but simpler with only the tools that I needed to create pixel art. Aseprite also had the bonus of including the ability to make animations (which Gimp did not have). Using Aseprite, I was able to immediately create the art I needed to continue development.

Then came the requirement to create large images that could be used for splash art, cover art, and posting to social media. I also around this time started enjoying the clean images of vector art styles. This led me to Inkscape. Inkscape was familiar and had many of the same "tools" and "docks" that Aseprite and Gimp used. Inkscape allowed me to create the large art I needed and sprites in the style I wanted. This worked until I had to animate. Animating with Inkscape was not easy. I would constantly have to export each image separately, join the images in a spritesheet, and then I would be able to test the animation. This was wasting time.

At this point, I was tired of switching drawing software and I had almost decided to start learning the Dragonbones animation software since it would allow me to draw using any technology, but I knew this would take a lot of time to learn. Most online resources directed me to the Adobe suite or animation-specific software. It was by luck and the algorithm overlords that I got a suggested YouTube video of how to animate in Krita.

Krita had a familiar layout, vector tools, and animation (basically everything I needed). I opened it up and started working on the next piece of art I needed and I completed the piece with only a minimal amount of looking up. Krita is what I use to this day, and I can't imagine an image drawing or editing need that Krita cannot do.