Development blindness

When you develop a game for long enough, you become blind to how difficult or how much fun the game really is. This happens because you learn the game inside out and could play it with your eyes closed. It becomes very difficult to tell how difficult or logical the game is to the average player. This can easily cause you to waste time iterating when you can’t actually tell if the game is improving or not.

You are the Steve Wiebe of your game
You are the Steve Wiebe of your game

This mostly applies to the first quarter of the development when you’re still working out whether the idea works or not and when you add new major gameplay features. I think most of it also applies to web or business applications too. Anything where you have a customer who you want to experience the product as smoothly as possible.

Ways to fight it:
1) Show your game(or app)- and have other people play it. Do not interfere or give them pointers or explain things! Try not to get involved with explaining and pointing things out because you won’t be there to explain what to do to the people who buy the game so the feedback won’t be authentic. You don’t want the first time you hear about the controls being confusing to be when the game is out and you start getting bad reviews. Take notes and try to see where people get stuck or what they liked. The second best option is to release a alpha version or a one level demo and ask for feedback online. People of the internet are known for being blunt.

1b) If you had a great idea but you’re seeing that no-one you show it to gets it without you explaining it – you have to either make it clearer or cut it out. Try to differentiate between one persons opinion and real problems. If it seems well thought out and well-reasoned or if a lot of people have the same complaint – it’s definitely something that needs addressing.

2) Take time away from playing your game. At least a week – preferably longer. It’s good if you have another side project going or maybe you can focus on building tools or prepare some marketing plans or one of the other 100 things you have to do after the game is “ready”. You are the best player in the world of your game right now, the closer you get to the beginner level every now and then the better you understand new players (literally everyone who will buy your game). You usually don’t have to make the decision to go ahead with a game so quickly that you can’t put it away and look at the idea again with a fresh pair of eyes. You can keep doing this every time a new major features is added.

3) Use different levels or maps when iterating. If you iterate on the same level for too long, it will start to feel dull and you’ll lose your intuitive feel for whether the mechanics are improving or not. Again you’re learning the level like the back of your hand so you start losing judgement on how the game is shaping. I recommend building “obstacle course” levels, which are just collections of different “edge-case”-obstacles etc. Like the highest possible jump in a platformer game. If you are tweaking gameplay values and can’t jump over the highest platform anymore, something went wrong. Also creating fun dumb levels where you for example test out your effects and particles by adding hundreds of explosive barrels can help see how much fun the game can be during the most intense moments.

4) Compare to other games in the same genre or with the kind of feel you’re looking for. Pay attention to the details. Like for controls, does the action happen when you press down the button or when you release it. Switching between the reference and your game brings out the differences and weaknesses in both. This was the most surprising one to me, when I opened my game after playing another game in the same genre, I could tell some parts were too sluggish in mine and some parts were already better. Don’t copy but try to learn from classics like Super Mario. It’s all physics and motion – once you know what feels and looks good to the player, you can start making it your own. In 1989 the developers of Prince of Persia for example used a primitive “motion-capture” technique (rotoscoping on top of video footage of one of the staff members) to get the feeling right.

What is an Interface in OOP? Example in ActionScript 3

This is written for ActionScript 3 but also works for most similar languages. If you can read the code examples, it will probably apply to you.
In Object-Oriented Programming languages – including AS3, there are special “classes” called Interfaces (it is also a keyword in many languages). You might have noticed some of them in the basic library included with the language. They’re easy to identify because the name always starts with an uppercase I; like IEventDispatcher.

To understand what an Interface class is, you must first know understand what is meant when we talk about an interface of a object.

Coffee machineLet’s say you walk out of your office into the breakroom and find the simplest coffee maker in the world. It only has one button labeled [COFFEE]. You press it and it dispenses a cup of hot and tasty coffee for you. To you as a user the interface of the coffee maker is that button. You only want a cup of coffee, you don’t want to think about what goes on inside every time you use it.

Another simple interface would be a e-reader with just one book in it. It only has two actions you can use on it, go one page left or go one page right. It still has to form the pages on the LCD screen and store and decode the content of the book, but you only see two points of interaction with it. Left and right. If the users could also access the algorithm to render the text to the screen or change the voltage from the battery, they would be very confused and probably break it soon enough.

You sit back to your desk and decide to write your own coffee maker in ActionScript. The pseudo-code for the first revision of your coffee maker class looks like this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package com.designoidgames.interfacetut
{
    public class CoffeeMaker
    {
        public function CoffeeMaker()
        {
                       // Constructor in ActionScript
        }
 
        public function makeCoffee():void
        {
            grindBeans();
            heatWater();
            runWaterThroughBeans();
            coffeeComplete();
        }
 
    }
}
package com.designoidgames.interfacetut
{
	public class CoffeeMaker
	{
		public function CoffeeMaker()
		{
                       // Constructor in ActionScript
		}

		public function makeCoffee():void
		{
			grindBeans();
			heatWater();
			runWaterThroughBeans();
			coffeeComplete();
		}

	}
}

Continue reading “What is an Interface in OOP? Example in ActionScript 3”

Unity objects in right z-order but still overlapping – Render Queue Index

Recently I had a problem where I had set up some background gameobjects and sorted them on the z-axis thinking this would automatically render them in the right order always. When the camera moves they start flickering/overlapping each other. At least for the most basic shaders this is not always the case and you should instead set the renderQueue value for the objects that have a strict z-order you want to render them in.

Smaller renderQueue index means it’s closer to the camera and should be drawn on top of anything with a bigger index number.

1
2
3
4
public int renderQueueIndex = 3000;
    void Start () {
        gameObject.renderer.material.renderQueue = renderQueueIndex;
    }
public int renderQueueIndex = 3000;
	void Start () {
        gameObject.renderer.material.renderQueue = renderQueueIndex;
	}

Simple one-way platform in Unity

This is a simple trick to create a Mario-style platform where it’s open when you jump from below but you will collide with it when you’re above the platform. The good thing about this solution is that it’s very simple and clear what it’s doing, and takes like 10 seconds to set up. It is not perfect and if your game relies a lot on this type of platforms I would suggest a more advanced solution. Something where you take into account what direction is the character moving towards etc.

  1. Create the platform.
  2. Duplicate the platform and child this one to the platform. Call the child AboveTrigger.
  3. On AboveTrigger, make sure that under the Collider “Is Trigger” is set to false.
  4. Move the AboveTrigger up about the height of the platform and a little extra room so they’re not touching (or down if you want a top-open block). When the player is touching this trigger, the platform will turn its collider on – otherwise it’s always off.
  5. Attach the component at the bottom of the post to AboveTrigger.
  6. (Optional) Scale the AboveTrigger down by 5% or so to improve the character entering from the edges of the block – this depends on the game and should always be tested and tweaked to fit your character and controls.
Simple one-way platform
Setting the platform up in editor
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
using UnityEngine;
using System.Collections;
 
public class OneWayPlatform : MonoBehaviour {
 
    void OnTriggerEnter(Collider player)
    {
        transform.parent.collider.isTrigger = false;
    }
 
    void OnTriggerExit(Collider player)
    {
        transform.parent.collider.isTrigger = true;
    }
 
    // Use this for initialization
    void Start () {
        transform.parent.collider.isTrigger = true;
    }
 
}
using UnityEngine;
using System.Collections;

public class OneWayPlatform : MonoBehaviour {

    void OnTriggerEnter(Collider player)
    {
        transform.parent.collider.isTrigger = false;
    }

    void OnTriggerExit(Collider player)
    {
        transform.parent.collider.isTrigger = true;
    }

	// Use this for initialization
	void Start () {
        transform.parent.collider.isTrigger = true;
	}

}

Unity: Is your 2D character pointing right or left?

A Vectors dot product tells if another vector is pointing in the same direction. It can be used for a very quick check to see if a character is pointing in a certain direction. In this code for example I don’t want the character to move along it’s transform.right if it’s pointing left because he’s always supposed to be moving right.

1
2
3
4
Some common dot-products:
Vectors are at a 90 degree angle (normal): 0
Vectors are pointing exactly the same direction: 1
Vectors are pointing exactly the opposite directions: -1
Some common dot-products:
Vectors are at a 90 degree angle (normal): 0
Vectors are pointing exactly the same direction: 1
Vectors are pointing exactly the opposite directions: -1
1
2
3
4
if(Vector3.Dot(Vector3.right, transform.right) > 0)
{
    Debug.Log("Pointing right");
}
if(Vector3.Dot(Vector3.right, transform.right) > 0)
{
    Debug.Log("Pointing right");
}

Vectors in games Part 1

Vector’s are one of the most used tools in games. At first glance it might seem like there is a lot of magic that goes into them but actually they are very simple structures.

Here is an example of a two dimensional vector:

1
Vector A: 0, 2
Vector A: 0, 2

It only has two pieces of data! 0 is the position on the x-axis, 2 is the position on the y-axis.
If we take another two dimensional vector:

1
Vector B: 1, 4
Vector B: 1, 4

We can have a look at some of the basic operations, add and substract.

Addition:
A + B

1
2
3
4
5
0, 2
+
1, 4
=
1, 6
0, 2
+
1, 4
=
1, 6

If you read it column by column you can see that it just adds the x of the first vector to the x of the second vector and on the other set of numbers it adds the y’s together.

Substraction:
A – B

1
2
3
4
5
0, 2
-
1, 4
=
-1, -2
0, 2
-
1, 4
=
-1, -2

This is really how simple vectors are at their heart. In Part 2 we will look at how the length of a vector is calculated and what different types of vectors there are.

Unity Physics Materials – what is Friction Direction 2?

When you create a Physics Material, they have three extra options at the bottom of the panel; Friction Direction 2, Dynamic Friction 2 and Static Friction 2.

Here’s a picture explaining maybe the most common use case for different frictions for different axes. Friction 2 allows you to have high friction in one axis and low friction on another, if you think about a car it will work like this:

How to create a GitHub readme file?

Documentation is always important. In GitHub you should always have a ReadMe file to help people dive into your project. I found all the possible file formats kind of confusing and would’ve liked to see just a very simple explanation of how to put some text up there.

Here’s a very simple example of README.md for GitHub – MarkDown(.md) is basically for this purpose a simple HTML file.

README.md for Doodle Paint5

1
2
3
4
5
6
7
8
9
10
11
12
<h1>Doodle Paint5 for Pokki</h1>
Doodle Paint5 is a simple HTML5 painting program that uses the Canvas element and mootools JavaScript library.
It runs on the Pokki appstore (http://pokki.com)
 
<h2>Important source files</h2>
app.js - Main js entrypoint for Doodle Paint<br>
popup.js - Pokki popup wrapper<br>
window.html - HTML entrypoint for Doodle Paint<br>
default.css - All Doodle Paint CSS<br>
<br>
ToolBase.js - Abstract base class for painting Tools<br>
*****Tool.js - Painting tool implementations, pencil, brush, circle, spray, etc.<br>
<h1>Doodle Paint5 for Pokki</h1>
Doodle Paint5 is a simple HTML5 painting program that uses the Canvas element and mootools JavaScript library.
It runs on the Pokki appstore (http://pokki.com)

<h2>Important source files</h2>
app.js - Main js entrypoint for Doodle Paint<br>
popup.js - Pokki popup wrapper<br>
window.html - HTML entrypoint for Doodle Paint<br>
default.css - All Doodle Paint CSS<br>
<br>
ToolBase.js - Abstract base class for painting Tools<br>
*****Tool.js - Painting tool implementations, pencil, brush, circle, spray, etc.<br>

Touchscreen D-pad with AIR for Android (part 1 of 2)

A lot of games use the directional pad or arrow keys for movement. When you move to mobile devices with only a touchscreen, you lose one of the staples of your game controls. I’ll show a simple way of getting your D-pad back and hopefully allowing you to make the transition to mobile easier.

We need to listen to the TOUCH_BEGIN, TOUCH_MOVE and TOUCH_END events. If you’re familiar with mouse events already, you can think of BEGIN as MOUSE_DOWN and END as MOUSE_UP. The biggest difference between a mouse and touch screen is that there can be multiple touches so you need to keep track of which is which. If you got three fingers on the screen and only follow the events, it’s gonna be a mess.

How to keep track of the touches then? Each touch has touchPointID associated with it so whenever a touch event is fired, you can dig it up and compare it with all your known touch IDs. For now we will use the first touch to occur and assign that for our D-pad.

Before anything else, let’s set the input mode for the Multitouch class to Touch_Point. This means Flash will only track the basic touch events like when the touch begins, when it moves and when it ends.

1
2
3
private function init():void{
  Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
}
private function init():void{
  Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
}

Then add some basic listeners for Touch events.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// ... extends Sprite
 
private var dpadTouchID:int=-1;
 
public function init():void{
  Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
 
  addEventListener(TouchEvent.TOUCH_BEGIN, touchBegin);
  addEventListener(TouchEvent.TOUCH_END, touchEnd);
}
 
private function touchBegin(e:TouchEvent):void{
  dpadTouchID = e.touchPointID;
}
 
private function touchEnd(e:TouchEvent):void{
  dpadTouchID = -1;
}
// ... extends Sprite

private var dpadTouchID:int=-1;

public function init():void{
  Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;

  addEventListener(TouchEvent.TOUCH_BEGIN, touchBegin);
  addEventListener(TouchEvent.TOUCH_END, touchEnd);
}

private function touchBegin(e:TouchEvent):void{
  dpadTouchID = e.touchPointID;
}

private function touchEnd(e:TouchEvent):void{
  dpadTouchID = -1;
}

Something I’ve noticed is that touchPointID’s always start from 0 and go up. We’ll use -1 to tell when there is no touch assigned to the D-Pad.

We shouldn’t assume that there’s only gonna be one touch because there probably will be atleast 2. We’ll add some checks to make sure we’re only looking at the correct touch and add a event listener for TOUCH_MOVE so we can track the movement of the finger.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// ... extends Sprite
 
private var dpadTouchID:int=-1;
 
public function init():void{
  addEventListener(TouchEvent.TOUCH_BEGIN, touchBegin);
  addEventListener(TouchEvent.TOUCH_END, touchEnd);
  addEventListener(TouchEvent.TOUCH_MOVE, touchMove);
}
 
private function touchBegin(e:TouchEvent):void{
  if(dpadTouchID == -1){
    dpadTouchID = e.touchPointID;
  }
}
 
private function touchEnd(e:TouchEvent):void{
  if(e.touchPointID == dpadTouchID){
    dpadTouchID = -1;
  }
}
 
private function touchMove(e:TouchEvent):void{
//make sure a D-Pad touch is assigned at all, and then check if it matches
  if(dpadTouchID != -1){
    if(e.touchPointID == dpadTouchID){
      // success! let's print out the x and y!
      trace('D-Pad is moving!', e.stageX, e.stageY);
    }
  }
 
}
// ... extends Sprite

private var dpadTouchID:int=-1;

public function init():void{
  addEventListener(TouchEvent.TOUCH_BEGIN, touchBegin);
  addEventListener(TouchEvent.TOUCH_END, touchEnd);
  addEventListener(TouchEvent.TOUCH_MOVE, touchMove);
}

private function touchBegin(e:TouchEvent):void{
  if(dpadTouchID == -1){
    dpadTouchID = e.touchPointID;
  }
}

private function touchEnd(e:TouchEvent):void{
  if(e.touchPointID == dpadTouchID){
    dpadTouchID = -1;
  }
}

private function touchMove(e:TouchEvent):void{
//make sure a D-Pad touch is assigned at all, and then check if it matches
  if(dpadTouchID != -1){
    if(e.touchPointID == dpadTouchID){
      // success! let's print out the x and y!
      trace('D-Pad is moving!', e.stageX, e.stageY);
    }
  }

}
The red area shows where the touch area is for the finger, right now its overlapping right and up arrows.

Ok, now we’re tracking the D-pad touch around. It’s still pretty much acting like a mouse though. We want to use the touch tracking for a D-pad so we’ll need to figure out based on those X and Y coordinates if the finger is on top of any of the D-Pad buttons. Just for examples sake, we’ll draw a simple graphic to represent the four directional buttons. The buttons are 100×100 pixels in size. The touch area we’ll be using is going to be 60 pixels so it’s small enough to still be precise but big enough so that it can cover two buttons at a time. This way you get 8 directions easily.

Right now we’re using the 60×60 square for the finger area but TouchEvent’s have some interesting properties you might want to look into later. For example; pressure, sizeX and sizeY. Those should come in handy when creating more sophisticated controls.

Next create some simple graphics for the buttons. We’ll name them upArrow, downArrow, leftArrow and rightArrow. They should be a descendant of the DisplayObject class for this.

You want to re-check which buttons your finger is touching whenever it has moved and when it’s first pressed into the screen. So we should modify touchMove(e) and touchBegin(e) to check that.

Stay tuned for part 2!