An Artist's Approach to Programming

Two weeks ago, I published my first game to the Google Play Store. For me, this was an accomplishment relative to completing Mario Kart’s Rainbow Road as a kid. Over the past handful of years, I have made multiple attempts to create and publish a mobile game but much to my chagrin I failed, falling in the lava and burning my pants off. Why? Motivation? Time? Bad ideas? No, it’s worse than that… I am an artist.

Programming was a bit of a struggle for me. I understand the logic of how it works, but at times, it was difficult for me to wrap my head around how to accomplish what I wanted. I know plenty of artists with great ideas, but when it comes to programming, they become overwhelmed before really beginning. So, here are some basic tips and advice that may be useful for the artist that is interested in programming. I’m going to be using my new game “Grabity” as the example utilizing the Unity 5 Engine and the C# programming language.

1. Break it down.

What are the simplest elements of what you wish to do? I’m not talking about the nitty gritty, I mean the most basic idea and then go from there. With Grabity, I wanted to make a game about an astronaut getting sucked away by a UFO and the astronaut survives as long as he can by holding on to oncoming space objects.

So these are my basic needs:
- I need an astronaut that moves around.
- I need a UFO to capture the astronaut.
- I need objects to hold on to.

2. Keep it simple.

Okay, so I’ve identified the most basic parts to the idea of the game. Now what? As an artist, you might already be looking at this like “Ok, what do I do now?” An AI system? Collision detection? Classes, libraries, and APIs!? No, no, cool your jets. This is how you get overwhelmed. Start thinking about the game as an animation. In the game, the astronaut is flying back and forth, flailing about and occasionally follows another object. Let’s start there.

To make the character fly around back and forth, I simply have an empty game object with an animation that moves back and forth infinitely. The astronaut is simply attached to this object, and he moves back and forth.

The same thing happens with the UFO. It is attached to an object that either moves up if the astronaut is holding on to something or down if the astronaut is not holding anything. (We’ll address this later).

As for the objects that can be grabbed on to, we also approach them like an animation. The astronaut is attached to the empty game object that moves back and forth. Then the astronaut will be attached to a falling object. It’s like a Follow Link Constraint in animation, one object follows another and then is told at a certain time to change what it is following. What are the parameters for changing the astronaut’s parent? A) If the object is close to the astronaut and B) If the player has clicked on the object.

Now we have a simple layout for what needs done:  one object moving back and forth, one object moving up and down and changing the parent of the astronaut.

3. Write your code in layman’s terms.

This is generally referred to as pseudo code. Think of this as some quick concept sketches of your code. It’s not meant to be finalized in any way but it defines the shape, proportion, and rough perspective of your code. Let’s take the idea of the UFO moving up or down. In Grabity, if the astronaut is holding on to an object, the UFO will drift up and further away from the player.

Pseudo Code:

if ( the astronaut IS holding on ){

           The UFO should move UP;

} else if ( the astronaut IS NOT holding on ){

          The UFO should move DOWN;

}

So here we have broken down how the UFO is going to move in very simple terms.  We check to see whether or not the astronaut is holding on to anything and, depending on that outcome, we tell the UFO which direction to move. Now we have a clearer understanding of what needs to be done by boiling the code down into simple terms. Here is about how real code would appear:

public bool isHolding = false;

void Update(){
     if ( isHolding == true ){

          ufoUP();

     } else if ( isHolding == false){

          ufoDOWN();
     }
}

The script starts out with a public boolean which return as either True or False. At the start, it is false because when the game begins, the astronaut is not holding on to anything. Then we check if the astronaut is holding on to anything. Because the “if statements” are in the Update function, every frame the conditions will be checked to see if they have changed. If he is, a function is fired called ufoUP. If not, ufoDOWN is fired. We are using a very simple boolean check to determine the behavior of the UFO. Keep things simple and build on them.

4. Bite size bits.

The AI for the astronaut in the game was built out of a bunch of tiny parts. I would write one piece of pseudo code for what I wanted to do, and then another and another until I had the whole system for the astronaut. Liken this to an artist building a 3D town. Start with some roads, then add some buildings, then telephone poles, etc. Bit by bit, tiny details will be addressed and they all will fit together to make a whole scene. Address programming like these bits and pieces and you won’t become as intimidated. Breaking down your code into a series of smaller elements will help you keep focused. Next, let’s examine if the character is holding on to something:

The astronaut is holding on to something – YES.
- Attach the astronaut to the object he is holding.
- Move the UFO up.
- Multiply the rate of earning points by 50.

In Pseudo Code, this might be:

if ( the astronaut is holding on to something is true){

     The astronaut’s parent should be the grabbed object;
     The UFO should be moving up;
     Multiply the rate of earning points by 50;

}

Real code might look like this:

float RateOfScore = 1f;
public bool isHolding = false;

void Update(){
     if( isHolding){

          astronaut.transform.parent = grabbed.transform;
          ufoUP();
          RateOfScore = 50f;
     }
}

Here we are tackling multiple things by stating it simply to keep focused. We are telling the astronaut that it should be attached to a different object, telling a function to be fired that makes the UFO go up and then changing the score multiplier so the points accumulate 50 times faster.

5. The long way is OK.

We all have that programmer friend that just operates on another level. I learned most of my programming knowledge from my friend, Jim, and I understand how he would approach more complex issues. However, just because I understand what might be done for efficiency does not mean I understand how to implement it. For instance, in Grabity, there is a menu with all the different playable characters.

A skilled programmer would probably create an array for these character buttons to quickly keep track of all their properties like graphic, coin cost of the character, if they have been unlocked, button position, etc. I have no problem saying that I can’t quite do this. I understand arrays and how to loop through their properties but am not quite at the level for creating the menu through code like this. So, what do I do? I made a button for each character and a function to determine what button was clicked. Now I have some of you programmers out there yelling “BLASPHEMY!” at your computer, but hey, I understand the slight performance cost, I understand there’s a bit more work, BUT it is working and is not causing problems and I understand it, so it’s ok.

6. Don’t get overwhelmed.

This is probably the hardest part. You may get trapped going around in circles trying to figure out how to make things work like you want. But do the previous steps to keep focused. Relate what you want to do to your discipline, write in the simplest way what you are trying to accomplish, and if you figure out an easier but slower way to accomplish your goal it’s ok. Build by simple bits and pieces to make your code.

Review and wrap up:

This may help you address how to approach your programming, but research is important in the programming process. In most instances, once you break down into the simplest form what you want to do, you can find someone who has asked how to do that exact thing on a forum. The Unity forums are pretty fantastic. There are lots of resources and the community is pretty helpful. If you need to post something more specific to your problem, ask them for help. Or if you have a programming friend, ask them.

When you’re trying to learn, people are often willing to help you. Do take this with a grain of salt. How you ask for help is important. Be clear and calm. People are willing to help but they need clarity in what you are trying to do and do not need abused because you are frustrated. People are willing to help you learn but they are not there to do your project. Ask questions that will help you learn, don’t ask for someone to create code and give it back to you because you will not learn. Lastly, keep working on your project and finish it! It may be hard but it is a valuable learning experience and rewarding to finish a project to share with the community. The more projects you do, the more confident you will become with programming. Best of all, your art may actually improve because of understanding its implementation from the creation stage to the functionality stage.

Thanks for reading, I hope there was something of use in here. If any of you would like to see the finished project of Grabity, you can check the app out HERE.