Artwork Software Writing Bitcoin

 

Tools of the Trade

Harder, Better, Stronger, Faster

Crudely modeling the benefits of developing a tool vs. using it

How much time should we spend learning something? How much time doing it? How should we think this through? Is there an optimal path? Is there something as learn-as-you-go? So many questions...


Scientific Modelling, Problem Solving, Optimization

October 4th, 2013

 

Abe Lincoln said: “If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe.” I believe he was right, for there are problems that can be solved swifter (if at all) if the tool is better.

A blunt axe would do a tree-cutter no favors, you could be the best tree-cutter in the world, that your efforts would be as good as your tool. We could model this as:

Action Effectiveness = Skill x Tool Effectiveness

If we are to hold Abe’s words as the true optimal solution for sharpening a tool. We must make some assumptions first, and stupid simple formulas like this one:

Time to Finish = Time to Chop + Time to Sharpen

First in our assumptions, is that skill is a constant which cannot be increased. Because chopping looks like this:

Chopping Effectiveness = Chopping Skill x Tool Effectiveness

Sharpening would simply mean increasing the tool’s effectiveness. Abe said nothing about training, and that is why we consider chopping skill as a constant.

The second assumption we must make is that a task’s progress is a linearly scaling value. This means:

Progress = Action Effectiveness x Time Performing

Then this means that task progress is analogous to moving a distance.

Distance = Speed x Time

An increase in effectiveness would be analogous to an increase in speed. Which is certainly the case for the previous example if the task is “moving”.

The analogy ends there. There is no way that we, as human beings, can sharpen and use a tool at the same time. Either you chop, or sharpen. Maybe there are exceptions to this, but none that I know of.

Given the previous assumptions, Abe’s words look like this:

Chopping down a tree (time) = Time x (2 x chopping + 4 x sharpening)

Basically the old man is saying that we should sharpen our tools 2x the time we use them. For the sake of example we will assume that 2x is the optimal ratio between sharpening and chopping.

Sharpening Ratio = sharpening / chopping

Sharpening more would mean losing valuable chopping time, sharpening less would mean more time chopping at a lesser effectiveness. There should be a value which is the maximum for this formula.

In more general lexicon, sharpening means improving the effectiveness of a tool in a task. We will assume the function looks something like this, although it could be sigmoidal in nature.

Tool Effectiveness = Time Improving Tool x Tool Improvement Rate + Tool Actual Effectiveness

So then, what does all of this mean? Well, it depends on the values for the system. Apparently in Abe’s system, it means that the optimal time for sharpening an axe is twice as much as cutting.

Merging the formulas for tool effectiveness, action effectiveness and progress, we end up with the following.

s x tp (ir x tt x ea )

Skill = s
Time Performing = tp
Tool Improvement Rate = ir
Time Improving Tool = tt
Tool Actual Effectiveness = ea

If we simplify the previous equation by saying that Skill, Tool Improvement Rate and Tool Actual Effectiveness are constants equal to 1. We are left with the choice of how much time to spend, either performing the task, or improving the tool at hand.

Leaving us with a two variable function.

f(x,y)=x(y+1)

With the following conditions:

 x+y=6; x≥0;y ≥0

Running it through Wolfram Alpha it gives us a Contour plot and a 3D plot.

Finding this function’s maximum value for the specified conditions, gives us: X=3.5, Y=2.5; different from Abe’s X=2, Y=4.

Of course Lincoln's quote was a figure of speech and not to be taken as literally and rigorously as here, but this is just an exercise.

A Thin Red Line

Mathematics is not my strong suit, but some analysis later, it seems that the optimum value for performing is always one more unit than improving.

Let me see if I’m wrong.

Describing Y as a function of X, gives us:

y=x-1

Plotting this, over a contour plot (with lines every unit), gives us:


Let’s remember that we have limited resources to climb this surface, and that we must choose between walking X and Y. If we only have 6 “time” units, it would seem that our very best choice would be to walk that thin red line.

This chain of thought should’ve set us up with a mindset with which to look development.

Some tasks, such as running, are easy to measure. There’s a start, an end, and someone moving his/her legs back and forth. When he/she crosses the finish line, a time record is set. Very bi-dimensional.

The tool, in this case, would be the athlete’s body. Time training is time improving his tool, the actual “time” running, is very short for sprinters. And that is why we now can consider Olympics as tool sharpening contests.

Bodies, like some tools, lose effectiveness over time. That variable was not included in the model, it is intentionally incomplete.

In scope, creating a game is somewhat like the Olympics, there are lots of people performing several different sets of tasks. I’m new to this stuff, but it seems to me that making games is blending science and art.

The Art/Sciences of Programming, Illustrating, Composing, Story-telling and Design

Software Development is complex, and with the annoying quality that its complexity increases (exponentially?) with size, time, people, etc…

Illustration is more like sprint-running, there’s lots of time involved in training the subject, but once its skills are ready, results can be seen in linear time. There’s something to artists’ disposition, personality, etc… but for a sufficiently disciplined and motivated artist, linear time indeed.

On Music, I don’t know. Whatever skill I had with an instrument is lost, and I’m not a Composer, so I can’t tell.

Story-telling is another story (pun not intended), the good thing is that no one is trying to win a Nobel Prize with videogame story-telling. Tell me if I’m wrong but story-telling in games is much more oriented to HOW the story is told, than WHAT the story says actually. This is great actually, because writing a great story (traditionally, as in a novel) requires talent, inspiration, and hard-work. Qualities which are hardly found together.

Luckily, the bar for videogame scriptwriting is low. As certain high profile games with HORRIBLE scripts have proven that they can still sell sizable amounts of copies.

Back to estimating, as with artwork, “well grown” videogame writers should produce something of acceptable quality in approximately linear-time.

Design, on the other hand, is very much like Software Development. With very high dimensionality and complexity conspiring against good design decisions.

Recapping.

Artwork & Scriptwriting = More or less linear time

Composing = ???

Design & Software Development = Clusterfuck

My humble guess is that designing is even a bigger mess than coding. There’s so many variables and intangibles, psychology, writing, art direction, mechanics, etc. I can’t even think of design as something to give to a specialist. Game Design is for generalists.

To make matters worse, a game can ship with sub-par art & music, and still be good. It can have a pointless excuse of a story, and still be good. It can have annoying game-breaking bugs, and still be a good game. But should it have an awful design, you won’t touch it.

This started talking about tools, and will continue that way.

Programmers have Visual Studio, Eclipse, etc.

2D Artists have Photoshop. (No etcetera here)

3D Artists have Mudbox, 3D Studio, Maya, etc.

Composers have Cubase, Audition, Fruity Loops, etc.

Writers have got generalist text editors, or specialized ones (as Scrivener)

Designers have got an arsenal, and pencil & paper.

Luckily, for the most part, the base tools have been created. All of the previously mentioned tools are very well crafted. Even programmers have it easy these days, as there’s a whole gamut of good game engines to be chosen.

The readers I really like, will have no trouble reminiscing these words:

We use crude tools to fashion better tools, and then our better tools to fashion more precise tools, and so on.

We are in an advanced position of the “tool development path”, with lots of tools ready for us, that is good, but it is also very bad. It has levelled the play-field. The thin red line is still there.

The Thin Red “Line”

While nowadays a game can be made with no thought on the tools you create (Yes, the ones YOU had to make), creators with custom tools ready to speed up their personal development pipelines, will still have an advantage.

As that good old game character said:

Technological advance is an inherently iterative process. Each minor refinement is a step in the process, and all of the steps must be taken.


You could take the x(y+1) equation and chant it all you want, spending about half the time sharpening, and the other half chopping. Preaching it won’t make it real, as the topology of the problem is not simple.

The optimal red line now looks like this.



Design is so much of a disaster, and so damn embedded in the whole process that you will discard lots of the “linear-time” work, into a never-ending black hole of despair and feature creep. When game industry positions ask for “passionate” individuals, they really mean it!

One does not simply take sand from the beach and produce a Dataprobe.