Separation of Concerns, or why Nth Society needs non-coders

Separation of Concerns is an important software engineering principle. When we apply it, we simplify the process of creating software and facilitate many people to work on the same code.

We can also apply SoC to the various non-coding aspects of software development. Software developers do not make up the entire team, we also need artists, designers, and others. We can all work together using well defined interfaces. In other words, by knowing how my work slots into yours.

The "interface" doesn't need to be especially complicated. For art assets it can be as simple as using an understood file format like JPG for images or COLLADA for 3D models. We also need metadata for the game code to understand how to fit this into the world.

Let's look at a real example of something we need on the Nth Society project.

Example: world objects, aka items

One of the important tasks we can get started on right away is designing world objects, or items. There are three teams involved to realize items:

1. Designers
2. Artists
3. Coders

It's possible for all to work together but separately, at least for the most part. Here is a diagram of their relationship with each other and the work they create.

Designer

As is often the case, the designer is the creator of the requirement. In particular:

• What items are needed?
• How close do the items model their real world counterpart?
• What is the relationship between items?
• What processes can be applied to items?

The relationship between items and processes might be most important. It will result in a crafting or composing network. The level of detail will be up to the designer.

For example, do you need to combine cup + hot water + tea bag to get a cup of tea? What about the hot water, you would need to apply the heating process to water, but how to do that? Perhaps you would need to combine pot with river, then apply the heat process to the water by combining pot with stove.

You can see this can get complicated fast, so keeping this in check is the role of the designer. It's important to not get lost in the details. You could try sticking to one level of detail first, and then zooming in and out of this to complete it.

In terms of working with the other teams, a designer has almost free reign. They do not need to be aware of how the code is going to work, or what the artists are going to do. They will however need to be aware of what metadata the game engine requires. For example:

• what size class is item?
• what weight is the item?
• does the item have any special properties?

Artists

Artists bring life to visually oriented games (most games). Their work and choices set the tone and feel of the game. Coupled with interface design, this pretty much forms the entitreity of how players interact with the game world.

Artists need to be aware of what the game engine requires, but do not need to know the integration details. For example it matters if the game is a 3D world, an isometric projection world, or a classic top down tile engine. They also need to work from a particular art style which they and their team have already chosen.

In our example of item development, they will work from the list of items, creating assets for each individual item.

A special note on text only games: this entire job reduces to writing a description! It's not exactly art though it fulfils the same role.

Coders

Coders tie together item metadata and art assets to allow players to see and interact with items. They don't need to know exactly what items exist, but need to know how to process their data. We achieve this by generalization. Every item will have the same metadata format (though there can be subclasses) and the same kinds of art assets. The coder need only write the system for access, display, interaction and manipulation.

Pitch

We need exactly such contributors for the Nth Society, in all categories, and more. We already know that we need items, need to know their relationships, and need to know what they will look like.

Here are the requirements that are not yet met for each team. In other words, here's what we need Decision Makers to help us with now:

Designers

Requirements

1. Need to know the metadata format. This is a list of information about each object, examples above. Work with Coders to create this.

Artists

Requirements

1. Need to know game engine. All interest people can help decide this. Note, more than one game engine could be used, though this obviously increases overall work.
2. Need to know art style. A separate task, partially dependent on 1., generally in the hands of the artists.

In the pipeline the art usually comes last. But artists can create item art as designers create each item, they do not have to wait for full completion.

Coders

Requirements

1. Need to know game engine. See above.
2. Need to know the metadata format. See above.

The task of item integration requires some test data at least. This could be early work from the other teams, or completely made up data.

From this we can now graph out the knowledge and work each team depends on.

Conclusion

This was a simplified run down of the collaborative process of designers, artists and coders. I have shown how each of these teams can be independent from complete information of the other teams. This is a very good thing. It means that sometimes we can work asynchronously, i.e. at different times, and schedules from the other teams.

The coder can develop the engine using sample items they have created. The item designer can work without knowing much about the engine except of required metadata. The artist can work largely independently of the coder, but they cannot however work independently of the item designer. Overall there is a great degree of flexibility.

Anyone interested in any of these roles please comment, and you can always join our Slack using this link. We are already having lively conversations about game design there. 😁