Copy
View this email in your browser
Like Vikings? Like Dungeons & Dragons? My campaign book, player options, and new monsters are available for pre-order. If you are interested, just head over here: https://arcanumworldscanada.pledgemanager.com/projects/raidersoftheserpentsea/participate/?ref=mail

The Lazy Designer: The Next Game

Chapter 6 (Part 1)


There's more to creating a game than great ideas and fantastic user flow. Many games never get past the concept or prototype stages because the designers, programmers, artists and other departments fail to work together cohesively to build an engine suitable to all departments. Too often a game engine is focused on one area (often graphical fidelity) and lacks usability for other groups. Then it becomes important for a designer not only to understand the kind of game they want to make but how that game needs to be made too. This is where a general understanding of a game's engine is important, which for the sake of the following discussion will comprise the pipeline used to deliver assets to the engine, the engine itself, and the tools required.

 

Engines and Pipeline

Overview

From a designer's perspective the game engine, and consequently the asset pipeline, is an often overlooked area of responsibility. Many designers are happy creating content regardless of the infrastructure supporting their efforts. "I'll work with what I have," is a common design statement.
While this stoic determinism in the face of adversity is admirable it is also a little ridiculous. This just deal with it mentality from designers only encourages a continuation of inadequate tools, error prone pipelines and lengthy (and unnecessary) crunchtime.
As a technically oriented designer I was involved with engine development to a larger extent than some other designers. I believe this was a huge advantage for me, as was working on Neverwinter Nights, which was a toolset-centric game engine. I developed a strong sense for what worked and what did not work and I learned to care immensely about the pipeline being used.
On future projects I desired tools that worked for the design department and I wanted responsive asset pipelines. If an artist created a new model, new texture, new item, whatever, it needed to enter the game resources as soon as possible. Likewise once a section of plot was written it had to be played, immediately. A responsive engine allows this to happen.
Games do not exist until they are playable.
The engine is vital: it is where art and plot and sound come alive. As soon as reasonable content producers need to start dressing the engine up. Maybe not with final content but content that has the potential to leads towards final, quality content. This requires the content pipeline.
Will content producers manually drag and drop their creations onto a network drive or is there a more elegant solution? Perhaps a depository where content is added, verified by automatic processes, converted if necessary, and deployed?
There are many questions that need to be asked as an engine is built. How many users will need to use the game's tools at the same time? Do users need different security levels? How much content might flow into the pipeline in any given hour, minute, or second? Do old, working builds of the engine need to be maintained for demo or executive use? Are there plans to license the engine to other developers?
From understanding whether content producers (the artists and sound engineers and designers) need to learn new techniques for creating content or if they can continue to work using familiar tools, to knowing whether resources can be produced off site (maybe outsourced to a firm on another continent) there is significant planning required for a new engine.

New Engine versus Old Engine

When possible leverage past work and past experience. The longer it takes content creators to adapt to a new process the more expensive your game will be to make and the more risk to the schedule there will be. Build upon past success. Do not reinvent wheels; very likely they'll not move you forward any better than previous incarnations and while you are fiddling loads of content that could have been made will never be made.
When I moved to Neverwinter Nights the game was already well underway but the engine was not quite playable. During my transition onto the team, and then on later projects building new technology, I learned a few things about what happens during the planning phase of a new project:
  • The designers assume the engine will do everything the previous engine did, but better, with more stuff.
  • The artists and animators assume pretty much the same thing as designers, but with respect to art.
  • Production assumes, because the company is now more experienced, development will proceed faster than the previous engine.
  • The programmers assume they can repair all their previous mistakes and that no one else has any assumptions.
This causes problems. For example, designers proceed with writing design documents for kick-ass, fascinating new systems and new ways to tell better stories. But they assume every feature they had access to on the previous game will be available in the new engine. They make assumptions and details are not specified to the require extent.
And many of these assumptions are never implemented, invalidating the planning of the content producers.
"Can't the programmers just do it that way, again?"
No, they can't.
It is a different engine and content producers are back to square one, the process of negotiating tools and features and limits and functionality begins completely over. Experience might make rebuilding the engine faster than a previous engine but likely new requirements (higher fidelity art, larger content demands, new platforms) will more than overshadow that advantage.

Core Pipeline Principles

So, regardless of whether a new engine or an iteration of an existing engine and pipeline, what core principles do I suggest adhering to during engine development? Here I'll speak specifically to the requirements of the design department but much of what will be said easily applies to other content producers.
  1. Flexibility Give designers a flexible tool where they can iterate and test their work immediately (and deploy it easily) and you'll be able to build content rich games. This will have the added benefit that if care is spent on making the design tools usable then you will be able to more easily deploy an end-user toolset so that your players may construct their own scenarios\
  2. But Not Without Limits The problem with too much flexibility is that it becomes daunting to the content producers on how to start building a level or writing a dialog or building an art model that will appear in game. Some boundaries on how content is created are necessary. The content producers need to know what things they can be built and how to build them and how to get them into the game. This should be as simple as possible and might require some limitations on how the tool is used to allow this.
  3. Familiarity Breeds Success Try to model your game development tools after similar tools that already exist, either within the company or in the marketplace. If you are making a first person shooter level editor try to be similar to the toolset released by a popular competitor. This familiarity makes it easier for new hires to transition into your company's work force... if you have a similar editor to what they've used outside your company they will be up and running faster. Likewise if you are creating complicated, branching dialog, look at the dialog editors used on Neverwinter Nights and Dragon Age: Origins.
  4. Fast Deployment A game build is when all the resources and code and content required by the game is compiled into a format near as possible to what the final game will use. These builds are generally used to mark progress through the development schedule. Try to make it as easy and quick to deploy a new build. This allows the quality assurance department to test the game in a state that is as close to the state that the shipped game will be in. This makes testing more accurate. (Often the process by which testers playtest the game during development is fundamentally different from how the ship game will be organized. This is wasteful because often false positives will be found... these are bugs that would never exist in the real game but creep in due to the hacked nature of the test environment. This wastes testing time and developer time. It is time consuming to track down these false positives).
  5. Fool Me Once, Shame on You, Fool Me Twice... If there are actions that designers (or artists or programmers or anybody else) do that break the build or game and these actions can easily be caught then automate the process of catching them. That is, either reject the flawed content from entering the game resource build or allow it and broadcast a failed content mail to the content producer, the leads, and a line producer who will be tasked with ensuring broken content is fixed in a timely fashion.
  6. A Communicative Build As much as feasible build communication into the build process. When reliable builds have been vetted by quality assurance, have them archived and have an internal web page automatically update in a visible location so that others can easily figure out how to grab an installable (and functional) version of the game. Periodically even broadcast emails about this page to remind team members.
Never expect team members to look for information. They are busy. They will not do it. The information has to be transmitted to them efficiently. This might be an active background installed on all user's screens that constantly shows current build progress, bug counts, active tasks, and the like or it might be weekly email or a weekly team member or a line producer wandering the halls and updating people in person.
 
In the next newsletter, we take a look at accountability and how it can make us make better games. Thanks for reading, please let me know if you have any feedback!
Brent Knowles, Game Designer
Brent Knowles, Game Designer
Brent Knowles, Game Designer
Copyright © 2022 YourOtherMind Media, All rights reserved.


Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp