Q&A: Which tool?

I am a student in Belgium. My friends and I have decided to create a video game to understand the process and learn to code better.  We are planning to create a RPG, kinda like the early Zelda games with the top-based view, and mix it with movie pieces […], and get a sort of crafting system integrated.  The problem we are having is that we don’t really have a idea what engine / framework has the most functionality to complete our quest to create our first game!

Do you have any tips / frameworks / engines that could be more of use for us?

This is a pretty common question – the specifics change, but it boils down to “What is the best tool in order to make the game I want, considering the skills I have?”

I am a designer, so when I look at frameworks or engines, what I am really looking for are tools that get me as close as possible to the finished game without needing to create a lot of basic behaviors or systems from scratch. A designer may accept a more rigid tool with fewer options if it’s easier and faster to use and gets them close enough to their goals. A programmer may want a tool they can highly customize so they can get exactly to their goals even if it takes more time.  There’s trade offs with both directions, and any given tool is going to give more or less of each.

One person might cut a feature like playing movie-clips (from your example) if it means they could use a much easier toolset to implement the core Zelda-style gameplay. Someone else might decide to use a more difficult tool that they can customize to play those movie-clips, at the cost of cutting some of the puzzles and levels. What choice you ACTUALLY make depends on how core the feature is to your game, how much time you’re willing to spend making it, and whether you have the technical skills to implement it.

Now I started off talking about designer vs. programmer considerations with tools because students have asked me, “What’s your favorite tool for making games?”. The answer is Twine, but I’m unlikely to recommend it to a computer science student because it would be ill-suited to their goals and the technical challenges they want to pursue when making games. Unity 3D is an amazing, versatile engine but I’m unlikely to recommend it to a game design student who has no experience programming because it’s extremely complex and relies on a lot of technical knowledge with no ramp-up that the student may not possess.

Now to answer your specific question about a Zelda-style game with a crafting system –

    • For a designer: Construct 2, for the best ease of use for 2D games, excellent visual scripting language (but no coding, so it can be inflexible), lots of features, lots of tutorials, output to several platforms with a couple clicks (iOS, web, download).
    • For a designer-programmer hybrid: Gamemaker, for a combination of an easy-to-use tool for 2D games, lots of examples and tutorials, and a scripting language (code) allows much more customization.
    • For a programmer: Python and PyGame, as a very popular scripting language for making your own games, fully customizable, with lots of information and tools out there for it. If you, or your team, are mostly programmers or computer science students, this is what I’d recommend (caveat: I am not a programmer!).
    • For an experienced programmer: Unity 3D, though I have no experience with their 2D tools, is fully customizable. If you’ve never made a game before and are just starting out, Unity 3D can be a bit overwhelming. However, it’s surprisingly close to the tools used by AAA devs and a lot of really good, professional independent games have been made in it.

As your very first game, I highly recommend either Construct 2 or Gamemaker – both have free versions with enough features to evaluate them, and both can definitely be used for the style of gameplay you want. I am not sure which is better for a team project when multiple people want to work on it simultaneously: Python might be a better choice for that, so it’s worth keeping that in mind. Again, if you guys feel comfortable with code, then head toward Python and PyGame, but remember that you’ll spend more time laying down the groundwork that a tool like Construct or Gamemaker have already created. (Like I said – lots of trade-offs!).

I’m trying out a new thing where instead of responding to emails about game development privately, I’ll be posting some of the questions – with permission – and answering them here.

“The Door Problem”

“So what does a game designer do? Are you an artist? Do you design characters and write the story? Or no, wait, you’re a programmer?”

Game design is one of those nebulous terms to people outside the game industry that’s about as clear as the “astrophysicist” job title is to me. It’s also my job, so I find myself explaining what game design means to a lot of people from different backgrounds, some of whom don’t know anything about games.

The Door Problem

I like to describe my job in terms of “The Door Problem”.

Premise: You are making a game.

  • Are there doors in your game?
  • Can the player open them?
  • Can the player open every door in the game?
  • Or are some doors for decoration?
  • How does the player know the difference?
  • Are doors you can open green and ones you can’t red? Is there trash piled up in front of doors you can’t use? Did you just remove the doorknobs and call it a day?
  • Can doors be locked and unlocked?
  • What tells a player a door is locked and will open, as opposed to a door that they will never open?
  • Does a player know how to unlock a door? Do they need a key? To hack a console? To solve a puzzle? To wait until a story moment passes?
  • Are there doors that can open but the player can never enter them?
  • Where do enemies come from? Do they run in from doors? Do those doors lock afterwards?
  • How does the player open a door? Do they just walk up to it and it slides open? Does it swing open? Does the player have to press a button to open it?
  • Do doors lock behind the player?
  • What happens if there are two players? Does it only lock after both players pass through the door?
  • What if the level is REALLY BIG and can’t all exist at the same time? If one player stays behind, the floor might disappear from under them. What do you do?
  • Do you stop one player from progressing any further until both are together in the same room?
  • Do you teleport the player that stayed behind?
  • What size is a door?
  • Does it have to be big enough for a player to get through?
  • What about co-op players? What if player 1 is standing in the doorway – does that block player 2?
  • What about allies following you? How many of them need to get through the door without getting stuck?
  • What about enemies? Do mini-bosses that are larger than a person also need to fit through the door?

It’s a pretty classic design problem. SOMEONE has to solve The Door Problem, and that someone is a designer.

The Other Door Problems

To help people understand the role breakdowns at a big company, I sometimes go into how other people deal with doors.

  • Creative Director: “Yes, we definitely need doors in this game.”
  • Project Manager: “I’ll put time on the schedule for people to make doors.”
  • Designer: “I wrote a doc explaining what we need doors to do.”
  • Concept Artist: “I made some gorgeous paintings of doors.”
  • Art Director: “This third painting is exactly the style of doors we need.”
  • Environment Artist: “I took this painting of a door and made it into an object in the game.”
  • Animator: “I made the door open and close.”
  • Sound Designer: “I made the sounds the door creates when it opens and closes.”
  • Audio Engineer: “The sound of the door opening and closing will change based on where the player is and what direction they are facing.”
  • Composer: “I created a theme song for the door.”
  • FX Artist: “I added some cool sparks to the door when it opens.”
  • Writer: “When the door opens, the player will say, ‘Hey look! The door opened!’ “
  • Lighter: “There is a bright red light over the door when it’s locked, and a green one when it’s opened.”
  • Legal: “The environment artist put a Starbucks logo on the door. You need to remove that if you don’t want to be sued.”
  • Character Artist: “I don’t really care about this door until it can start wearing hats.”
  • Gameplay Programmer: “This door asset now opens and closes based on proximity to the player. It can also be locked and unlocked through script.”
  • AI Programmer: “Enemies and allies now know if a door is there and whether they can go through it.”
  • Network Programmer: “Do all the players need to see the door open at the same time?”
  • Release Engineer: “You need to get your doors in by 3pm if you want them on the disk.”
  • Core Engine Programmer: “I have optimized the code to allow up to 1024 doors in the game.”
  • Tools Programmer: “I made it even easier for you to place doors.”
  • Level Designer: “I put the door in my level and locked it. After an event, I unlocked it.”
  • UI Designer: “There’s now an objective marker on the door, and it has its own icon on the map.”
  • Combat Designer: “Enemies will spawn behind doors, and lay cover fire as their allies enter the room. Unless the player is looking inside the door in which case they will spawn behind a different door.”
  • Systems Designer: “A level 4 player earns 148xp for opening this door at the cost of 3 gold.”
  • Monetization Designer: “We could charge the player $.99 to open the door now, or wait 24 hours for it to open automatically.”
  • QA Tester: “I walked to the door. I ran to the door. I jumped at the door. I stood in the doorway until it closed. I saved and reloaded and walked to the door. I died and reloaded then walked to the door. I threw grenades at the door.”
  • UX / Usability Researcher: “I found some people on Craigslist to go through the door so we could see what problems crop up.”
  •  Localization: “Door. Puerta. Porta. Porte. Tür. Dør. Deur. Drzwi. Drws. 문”
  • Producer: “Do we need to give everyone those doors or can we save them for a pre-order bonus?”
  • Publisher: “Those doors are really going to help this game stand out during the fall line-up.”
  • CEO: “I want you all to know how much I appreciate the time and effort put into making those doors.”
  • PR: “To all our fans, you’re going to go crazy over our next reveal #gamedev #doors #nextgen #retweet”
  • Community Manager: “I let the fans know that their concerns about doors will be addressed in the upcoming patch.”
  • Customer Support: “A player contacted us, confused about doors. I gave them detailed instructions on how to use them.”
  • Player: “I totally didn’t even notice a door there.”

One of the reasons I like this example is because it’s so mundane. There’s an impression that game design is flashy and cool and about crazy ideas and fun all the time. But when I start off with, “Let me tell you about doors…” it cuts straight to the everyday practical considerations.

Recent edits: Added localization, character artist, system designer, combat designer, composer, audio engineer, monetization designer, and I think that’ll be it for now.